Object decomposition depth in Java

Question

I'm wondering about the following issue: How deep should one go when designing an application in decomposing the working entities into objects?

What I mean could be described better by the following example.

Lets consider that I'm designing an application that is used to manage books. For that the basic model would be the book. So at the bottom of my application I would create a Book class that would have a number of fields (string) for title, authors name, book category, printing date.

Considering this and that perhaps the printing date and category could be somewhat independent entities/concepts should I create a class for each one with all the bells and whistles or could I use lets say an enumeration (in the case of category) and a string (in the case of printing date).

One argument with what I could come up to argue for the creation of separate classes would be that this way I can modify and validate the data related to them more easily but in the same time it could generate performance issues.

Which one would be the best practices? What factor decides the depth of entity decomposition in such cases (when common sense or brain power gives up)? Any thoughts? Thank you!

P.S. The example is only for explanation purposes and I hope it describes clearly enough what I want to ask.

Answer 1

I like to think of it in terms of data modeling. Is the data a separate thing, or a part of the thing I am describing.. For instance a book has an author and publisher. The author and publisher are not part of the book. You should probably create separate classes for those things if you will be manipulating them in any meaningful way. If not, they can just be "attributes" of the book class. I stop at the limit of what I care about; for instance, I probably don't care about creating each page of a book as page object instances (unless the problem I was working on somehow required it).

Answer 2

I would argue that for true object-orientedeness that it would be better to create objects for the different pieces. And as far as object-oriented design goes, it exists for human understanding and not for performance. Thus if this is a large application, it would be easier, as you say, to deal with the objects and not some other data type. I would also argue that you could create a so called "category" base class and then easily sub-class it for each subject. This is what I think would be easiest and best.

Answer 3

For the printing date you should use some appropriate date type (I'd suggest something from Joda Time personally), and for the category I would probably use a string if it were reasonably freeform text... but if there could be a hierarchy of categories (e.g. Computing -> Programming Languages -> C#) then I'd model that explicitly.

As for guidelines: ask yourself "is this a simple data type which is already in my toolbox, or does it naturally have more complexity?"

Answer 4

I wouldn't worry too much about performance until it's become a problem, and you've measured it and determined that your object model is at fault. The above advice may not be true if (say) you're building a low-latency trading system, but otherwise is generally sound.

Whether I create such low-level objects often depends upon the usage of the classes and the clients consuming these. If the fields aren't going to be exposed widely or subject to particular rules, then I may stick with Strings/primitives. If the objects are accessible to clients, I may use objects in order to emphasise type safety and enforce some degree of data validation.

e.g. what's easier to use and less subject to mistakes ?

public Book(String title, String author, String date, String deweyClassification, String isbn)

or

public Book(String title, String author, Date date, Dewey deweyClassification, ISBN isbn)

I may use the former if the Book class isn't widely disseminated (e.g. built by a single factory).

I would use the latter if expecting clients to use this. The ordering of parameters is enforced by the types making it easier to program to (you can only confuse the title and author - perhaps splitting these in the constructor would be better), and classes such as ISBN can enforce a valid book number.

In the second scenario, your IDE will be able to offer better assistance re. coding. e.g. better code completion, because the typing helps the IDE decide what are valid inputs to the method. That alone may be worth the extra development codes in creating new classes, if you're using the consuming class (Book) a lot.

Note that the implementation of these data types can be trivial. They can start off as objects wrapping Strings, int etc. in a simple fashion, and (if necessary, or if required) be later enhanced to provide validation and sanity checks.