GeeCON Prague 2014*
The moose likes Java in General and the fly likes OO Design Debate at our company Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "OO Design Debate at our company" Watch "OO Design Debate at our company" New topic
Author

OO Design Debate at our company

Matthew Gerring
Greenhorn

Joined: Nov 18, 2004
Posts: 3
Hello,

My boss and I have a design debate. We have two interfaces called 'Product' and 'Component'. A Product may have several Components. Both Product and Component have the methods:

getName();
getDescription();
getIcon();
isLicensed();

I want to put these methods in an interface called LicenseNode which Component and Product extend. But my boss says that Product and Component are not related and we should repeat the methods in each interface. There are occasions, such as when I am rendering the GUI, that all I need are the common methods, above. Therefore I wanted the extra super interface to give indirection there. Whom is right?

Please give me your thoughts so that I can email this link to my boss, be nice
[ November 18, 2004: Message edited by: Matthew Gerring ]
Barry Higgins
Ranch Hand

Joined: Jun 05, 2003
Posts: 89
How about superclassing both interfaces with the methods needed by both.
Then when you want to only reference these 4-5 methods you refer to the superclass but other instances of Product/Component can be refenced by their specific interfaces?
Jayesh Lalwani
Ranch Hand

Joined: Nov 05, 2004
Posts: 502
This is my 2 shiny pennies worth.

You need to ask yourself why you want to pull the common properties into a superclass? Is it because they really share attributes or just because you display them similarily? If the answer is just because you want to display the simlarily then I would ask you to take a step back and take a better look at your overall design. Because it sounds to me like you are not seperating your Model from your View.

Your Product and Component entities are not related to each other. So, your boss is right. Your Model classes should reflect the real-world relationship between the entities.

However, when displaying your Product and Component, there are places where you display them simlarily and you dont want to duplicate code. So, you are right too!!.

What to do? what to do??? What you need to do is add is a ProductView and a ComponentView that hold the Product and Customer objects respectively. ProductView and ComponentView can both implement a LicenseView interface that contains the common properties, plus properties that are specific to the ProductView and ComponentView. At the very least your XXXView classes can delegate the calls to your Product/Component class. If required your View classes can format your data for display. So, in your GUI where you display common elemtns, you can use the LicenseView

But, the question is why do we want to add an additional wrapper? You will reduce performance.. blah blah. The idea is to seperate your data from your view, and also to reduce dependencies in your design. Currently, let's say the "name" property is a string in both the Product and Component. You have a subclass called License that has a getName function, and Product and Component extend it. Fine. It works without problem. Let's say your requirements change and you need to store the name of the Product as a NameBean. So, what do you do?? You will have to pull your getName out of License and put them in Product and Component, and change all the code that uses your License interface. By seperating your Model and View, you can change the Product class, and change your ProductView to format the NameBean into a string
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Matthew Gerring:
... Whom is right? ...

In programming, there is seldom a single right answer. From the point of view above, you are both right. Design patterns are a common topic in OO. In particular, the Model-View-Controller design may help in this instance. I suggest you google for some of these topics to find more information.

Keep Coding! (TM)

Layne


Java API Documentation
The Java Tutorial
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Just to enter the aggregation vs inheritance topic. What if these four methods:

represent a bit of behavior that any number of objects might have to provide? That would argue for a small interface with those four methods all by itself. Your concrete products would be required to implement Product and Licensed, your concrete components would be required to implement Component and Licensed. They could both delegate the four methods to a private object that implements only Licensed. That way they could both share the implementation code in the concrete licensed thingy.

With basic things like name & description this may not be the right approach. Just something to chew on.

BTW: Scroll down the forum list to the OO, UML, etc forum. We talk this kind of stuff day & night down there.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

Whom is right?

In software design aspect, there is usually no right or wrong. There would be only good or not good.

Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Matthew Gerring
Greenhorn

Joined: Nov 18, 2004
Posts: 3
Thanks all for your thoughts. Mat
 
GeeCON Prague 2014
 
subject: OO Design Debate at our company