aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Design Query Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Design Query" Watch "Design Query" New topic
Author

Design Query

Varun Chopra
Ranch Hand

Joined: Jul 10, 2008
Posts: 211
In our system we have blocks, block-holes, sub-blocks relationships. As an example, we may have a Block B1, which has 2 holes in it H1 and H2, and sub-block B2 can go in hole H1 and sub-block B3 can go in hole H2.

Block holes are also treated like blocks and table that we have stores this data as below:

id parentId Type
B1 None top block
H1 B1 hole
B2 H1 sub block
B3 H2 sub block

Now, block ids (B1, B2 etc.) have many more attributes which are not applicable to holes. They have actual data associated (like dimensions, color, price etc.). Holes do not have any data.

Now my question is, how should we create Java Domain Objects for above.
Should it be using inheritance, like below:

class Structure;
class Block extends Structure;
class Hole extends Structure;

Inheritance will means, we can put all common attributes of Holes and Blocks in Structure class and each of concrete classes will have their specific attributes. Disadvantage here is we need to check instanceof object before we can call a method.

OR on the other hand, should we use only one product class, and keep fields not applicable for holes as null or blank all the time?

class BlockORHole
{
//attributes will always be blank for Holes
attributes = new ArrayList();
}

OR do you see table structure has faults in it and concept of treating Holes and Blocks similar is faulty?








We are using Hibernate for persistence.


-Varun -
(My Blog) - Online Certifications - Webner Solutions
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
The object structure is best decided upon not by the data the objects hold (which should be very much private, anyway), but which behavior the objects show.

From your description, I would *guess* that holes are used differently than blocks, so they should likely be different classes.

Whether they should be in the same class hierarchy is mainly decided by thinking about whether you want polymorphic behavior. That is, do you have code that needs to work both with holes and blocks interchangeably?

Another, much weaker, reason for using inheritance could be code reuse - putting code that is used by both holes and blocks into a common superclass.

Does that help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Varun Chopra
Ranch Hand

Joined: Jul 10, 2008
Posts: 211
Yes Ilja, that helps. Thanks.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Design Query