Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design Query

 
Varun Chopra
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Varun Chopra
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Ilja, that helps. Thanks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic