• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Design Query

 
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes Ilja, that helps. Thanks.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic