Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Help with class design / general software design  (Read 1344 times)
0 Members and 1 Guest are viewing this topic.
Offline Eyesackery

Junior Member


Medals: 1



« Posted 2012-09-08 06:57:47 »

Hi again guys, quick question for anyone interested Smiley

Was wondering if anyone knew of some good tutorials or material that teaches good program design, good OOP design techniques, or code architectural organization.

That being the planning and design of classes and class structure.

I am becoming very comfortable with the language now, but still struggling with the correct structure of java classes/programs.

I have been searching and all I can really find are tutorials on the actual building of classes and the such, none on the design aspect.

I hope I'm making sense, only had 2 hours sleep last night!  Cranky Smiley
Offline ctomni231

JGO Wizard


Medals: 98
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #1 - Posted 2012-09-08 07:46:54 »

Well, good coding design can be found by just looking in the Java Tutorials. You really want to make sure you are using your tabs and spaces to organize basic functions into groups and comment so you know what your code does.

For Object Oriented Programming practices, you just want to make sure you are separating your functionality into separate classes so they can be used later on. It stresses not using static, but instead keeping code modular (or separate) meaning plenty of getters and setters.

For code architectural design, it largely depends on what you are designing for. The best advice for design is just to keep it simple and to the point. For games, it usually helps to design logic and graphics code separate from each other, where logic resides in an update function and graphics interact with logic in a render function. Depending on the amount of features you have and what you are building, design architecture grows with the amount of features.

But... since you are just beginning, it is probably not best to be dabbing in all these advanced techniques. You will learn all of these overtime if you just choose a simple game and try to design it. Like Pong, Breakout, or Tic-Tac-Toe (Noughts & Crosses). It will be a lot more valuable than a bunch of people talking in tutorials and you'll probably learn plenty too.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #2 - Posted 2012-09-08 17:01:13 »

What the previous poster said: experience is the best teacher.  Beyond very expensive textbooks, there's not a lot out there that covers design aspects, but one I can recommend is Head First Design Patterns which is a somewhat more modernized and streamlined take on the original.  One thing I really need to stress about design patterns is that they are descriptive, not prescriptive.  As in, they're about naming and cataloging existing best practices, but you don't want to force your program to use them if they're not an obvious natural fit.  Nothing's worse than seeing a program unnecessarily blown up to use Facades of Factories of Strategies of Visitors of blahdeblah etc ad nauseum.  But a program that uses patterns properly can be a thing of beauty.

Another really biblical text in the design area is Bertrand Meyer's Object-Oriented Software Construction.  Meyer loves to explain everything in terms of Eiffel, a language that frankly only continues to exist for Meyer's books and papers, but most of the ideas in there should apply to any language.

What little theory OO has to offer is worth reviewing, and two in particular are:

  • Law of Demeter - Only talk to your "neighbor" interfaces
  • Liskov Substitution Principle - The difference between subtypes and subclasses
     (but remember that a subclass may add interfaces, so don't take it too strictly)


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 342
Projects: 2
Exp: 5 years


I'm the King!


« Reply #3 - Posted 2012-09-08 20:07:02 »

Head First Design Patterns!!!! I highly recommend this book Smiley

Offline ags1

JGO Ninja


Medals: 46
Projects: 2
Exp: 5 years


Make code not war!


« Reply #4 - Posted 2012-09-08 23:58:57 »

Try to keep you classes small and your methods smaller :-)

Build the application one feature at a time and test as you go along.

Avoid big detailed designs which are just inflexible and ultimately not related to reality, no matter how good the class diagram looks.

Offline Eyesackery

Junior Member


Medals: 1



« Reply #5 - Posted 2012-09-10 09:55:05 »

What the previous poster said: experience is the best teacher.  Beyond very expensive textbooks, there's not a lot out there that covers design aspects, but one I can recommend is Head First Design Patterns which is a somewhat more modernized and streamlined take on the original.  One thing I really need to stress about design patterns is that they are descriptive, not prescriptive.  As in, they're about naming and cataloging existing best practices, but you don't want to force your program to use them if they're not an obvious natural fit.  Nothing's worse than seeing a program unnecessarily blown up to use Facades of Factories of Strategies of Visitors of blahdeblah etc ad nauseum.  But a program that uses patterns properly can be a thing of beauty.

Another really biblical text in the design area is Bertrand Meyer's Object-Oriented Software Construction.  Meyer loves to explain everything in terms of Eiffel, a language that frankly only continues to exist for Meyer's books and papers, but most of the ideas in there should apply to any language.

What little theory OO has to offer is worth reviewing, and two in particular are:

  • Law of Demeter - Only talk to your "neighbor" interfaces
  • Liskov Substitution Principle - The difference between subtypes and subclasses
     (but remember that a subclass may add interfaces, so don't take it too strictly)




What a great response!! Thank you so much, will definitely check out that material.

Thanks for the advice ra4king and ags1!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (14 views)
2014-08-01 22:53:16

CogWheelz (14 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!