Query on Objects Design
Project details:
A distributor has attributes like
Distributor
distId
selectedYear
bu
context
asOfDate
foCode
foName
distName
distStrAddr
distAddrLn2
distAddrLn3
distAddrLn4
Each distributor can have zero or 4 deal types.
Distributor Deal Type
deal type
payout type
Each deal type has one or more details like
Deal Type Details
level
premium threshold
award pct
Start date
End date
As of date
Now my question is how I relate these objects.
1. Distributor class
has all the Distributor member fileds as mentioned above
DistributorDealType[] -- Array
2. DistributorDealType
Deal type
Payout type
DealTypeDetail [] -- Array
3. DealTypeDetail
- (contains all the fields mentioned in the Deal Type Details attributes).
OR
do I need to use Inheritance concept in connecting them. Though it sounds silly to you guys, it抯 starting point to our big project. So I like to take expert抯 advice before I confirm the design.
[1209 byte] By [
tekbonda] at [2007-10-2 0:14:57]
To my knowledge this is the best approach always Object Composition will be better than inheritance and infact here we dont see any parent child relationship and the Distributor class is haing has or contains relationship and we can think of inheritance for is kind of relationship which is conventional design approach and better one for better scalability.
One suggestion is we can revisit the object names that you have mentioned.
Try to make all your methods either abstract or final and you should be ok for reuse.
You can use an interface to declare the array of DealTypeDetails and let DealType and PayoutType implement that interface. This way you can change the distributor deal type at runtime if you wanted to.
Interface IDistributionDealType {
}
Class DealType implements IDistributionDealType {
//deal type operations and attributes
}
Class PayoutType implements IDistributionDealType {
// payout type operations and attributes
}
Avoid using arrays. Just use a List and save yourself a lot of trouble.
> You can use an interface to declare the array of
> DealTypeDetails and let DealType and PayoutType
> implement that interface. This way you can change
> the distributor deal type at runtime if you wanted
> to.
>
> Interface IDistributionDealType {
> }
>
> Class DealType implements IDistributionDealType {
> //deal type operations and attributes
> }
>
> Class PayoutType implements IDistributionDealType {
> // payout type operations and attributes
> }
I think this is on the right track but it misses the mark. Having an interface with no methods or defining implementors whose methods are different makes it pretty pointless to define the interface. It's not polymorphic. You might as well just extend Object for each of the deal types.
This design might benefit from a Detail interface. Then each detail might have special behavior. Or, it might be better to just keep it declarative as the OP has it. It's hard to say.
> Try to make all your methods either abstract or final> and you should be ok for reuse.I wish it were that simple.I've seen a lot of classes with all final or abstract methods that were not good for reuse. Not the slightest bit.
I agree, I was trying to avoid using inheritance. How about this
Interface IDistributionDealType {
}
Abstract class AbstractDDT{
// common behavior goes here
}
Class DealType extends AbstractDDT {
//behavior unique to DealType goes here
}
Class PayoutType extends AbstractDDT {
// behavior unique to PayoutType goes here
}
This way you get polymorphism but you are taking the risk of tying the implementation of your distribution types to a parent class.
> I agree, I was trying to avoid using inheritance.
> How about this
>
>
> Interface IDistributionDealType {
> }
What does the above do? Is it just a marker interface or are you omitting methods because you don't have the names for them?
If I have a IDistributionDealType reference, what can I do with it? I can't call any methods that aren't defined in Object unless I cast to another type.
> > I agree, I was trying to avoid using inheritance.
> > How about this
> >
> >
> > Interface IDistributionDealType {
> > }
>
> What does the above do? Is it just a marker
> interface or are you omitting methods because you
> don't have the names for them?
>
No its not intended to be a marker interface.... i do not have the methods because I do not have names for them.
Interface IDistributionDealType {
void method1();
void method2();
}
> If I have a IDistributionDealType reference, what can
> I do with it? I can't call any methods that aren't
> defined in Object unless I cast to another type.
This is what I had in mind,
IDistributionDealType deal1 = new DealType(); or
IDistributionDealType deal1 = new PayType();
so you can do a
deal1.method1() or
deal1.method2() without casting.
> No its not intended to be a marker interface.... i do
> not have the methods because I do not have names for
> them.
OK, that's where I was confused.
> This is what I had in mind,
> IDistributionDealType deal1 = new DealType(); or
> IDistributionDealType deal1 = new PayType();
>
> so you can do a
> deal1.method1() or
> deal1.method2() without casting.
From the OPs description, though, these methods are either going to do exactly the same thing (return a list of Details) or you will have a different set of methods for each implementor. If this is not the case then, the above makes sense, otherwise, it's better to have a single class composed of Details.
Now, it's possible the Detail instances might need different implementations, though how to define that interface is equally impossible from the information available.
> > Try to make all your methods either abstract or
> final
> > and you should be ok for reuse.
>
> I wish it were that simple.I've seen a lot of
> classes with all final or abstract methods that were
> not good for reuse. Not the slightest bit.
I'm not recommending you make all the methods in a class the same whether that be abstract or final. Take each method individually and decide if it should be abstract or final. No its not that simple. However, when you feel the desire to override a method with a new implementation, ask yourself if that implementation really should be moved to a new child class and declared as abstract in that class.
I have found this is a good rule of thub that will keep you out of many knots.
> I'm not recommending you make all the methods in a
> class the same whether that be abstract or final.
> Take each method individually and decide if it
> t should be abstract or final. No its not that
> simple. However, when you feel the desire to
> override a method with a new implementation, ask
> yourself if that implementation really should be
> moved to a new child class and declared as abstract
> in that class.
>
> I have found this is a good rule of thub that will
> keep you out of many knots.
The thing is that I don't follow this and I don't find myself in knots. The knots I have to deal with now are an overuse of abstractions. Interfaces with only one implementation and no need for another. Abstract methods where the child class has only no-op implementations. Overuse of design patterns creating a confusing facade on top of horribly coupled classes.
I also think it's perfectly valid to both provide default implementations that a child can override only if needed. It's also quite useful to be able to decorate the parents method, i.e. call the super version and add specific code.
I think rules of thumb like this allow people to over-estimate their abilities. They say something like "I've designed for reuse, all my concrete implementations are final and don't override any concrete methods." But they've built a huge mass of spagetti code that's completely unreusable and unmaintainable.
