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 ]
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?
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
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.
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