How do you know what Classes to make?

[BlackStar0703]

Ok so I've started learning Java and am half way the book 'Head First Java' (which isn't a bad book btw); but what they've failed to mention is when you know when you need to make a new class. I've learnt that each Class is for each object but how do you know what objects you need?

As an example, the book is guiding me through a battleship game whereby each battleship is called a 'DotCom'. The book has made 3 classes: DotComBust, DotCom and GameHelper. In my naive view on this I would have thought that DotCom is the only object but can anyone explain why I'm wrong?

Any help would be appreciated :)
Thanks

[stultuske]

if you want to program something, first, write down what you want in plain english (or your own language, if english isn't your first language :) )

the nouns you find in that text, are the objects (classes) you'll need. the verbs are the actions (methods) to write.

actually, they don't fail to mention it in those books, but not every one has got grip on the OO concepts on the first read.

[BlackStar0703]

I see what you're saying... but in that case why is DotComBust a class? That's not an object is it? I would have thought that it's a state... :S

Also does that not mean that in more sophisticated programs there would be hundreds of classes, making it pretty unorganised?

[zeroliken]

if DotComBust class is an object then it has its own state and behavior
maybe these Oracle docs will help you clarify some things
http://docs.oracle.com/javase/tutorial/java/concepts/object.html
http://docs.oracle.com/javase/tutorial/java/concepts/class.html

[BlackStar0703]

Thank you :)

[JamesCherrill]

... does that not mean that in more sophisticated programs there would be hundreds of classes, making it pretty unorganised?

Yes there will be hundreds of classes, but no. that's not necessarily unorganised, especially compared to the alternative of having all that code but not organised into classes. OO isn't perfect, but it's the best we've got.

Also, not every noun in the spec needs a class - many of them will create an attribute (variable) within a class. It sounds vague, but when you actually do it a couple of times it's not that hard to guess which nouns are classes and which are just attributes. For big applications you also spend a lot of time reviewing the class design and manually running through the messaging sequences for the use cases. This gives yhou plenty of opportunity to refine the class design before writing any code.

[BlackStar0703]

Ok I'm getting there, haha. Could you give me an example of where one noun would be a variable and when one would be a class? Also how do you distinguish between whether it needs to be a class or variable? :S

[JamesCherrill]

"A Library has books, each book has an ISBN, a title and an author..."
Library and Book are classes, ISBN, title, author are attributes of a Book.
One rule of thumb is if something can be represented by a Java primitive or a String then it's probably an attribute, if it needs multiple primitives or Strings then it's definitely an object.
You have to read the whole spec to ensure none of the attributes are actually more complex than that, and need to be upgraded to objects, eg
" ... authors are paid royalties for each book sold..." - aha! there's more to Author than just a String, make it a class.

[BlackStar0703]

Right that clears up things. Am I right in saying that it is similar to a relational database then, with the key fields being like classes and the others as variables?

Another thing I'm not overly sure about is the launcher class I see in a lot of projects? Why do you need a complete class to start everything else? Can you not just write it in any of the existing classes?

[JamesCherrill]

Yes, sort of. In practice you usually end up with each class having an attribute that corresponds to the database table key (eg ISBN), so the class corresponds to a table, and instances correspond to rows. Of course, attributes can themselves be instances of classes or collections, so most classes need more than 1 table.

Once you start to implement you will add a load more classes to handle the mechanics of the application, and a launcher is very common. There will often be a lot of startup to be coordinated - opening databases, starting servers, loading parameters and defaults, initialising GUIs... So a (small) class to do all that makes sense.
Yes, you could put all that in one of the other classes, but that would degrade the encapsulation - each class should be/do one thing. Designs with many single-purpose classes are easier to write and understand than designs with fewer multi-function classes.

[BlackStar0703]

Ah ok, thanks for your help. I'm guessing this is something I'll grasp more with practise over time. Your help has been much appreciated :)