Here's one that has my group stumped...
We have multiple variations of customer where there is some core data attributes (name, address, phone, etc), but that's were the common data ends. There are specific business rules for each customer with some applications having relationships between the customers (i.e. manager to employee). We want to allow the applications to have these extensions, but have the ability to extend improvements to the core functionality to all the applications.
Anyone know a design pattern that allows core functionality with extensability? I could use an interface or inheritance, but that just strikes me as too simple a solution.
-
Multiple variations of customer - know a good design pattern? (3 messages)
- Posted by: Chris Russo
- Posted on: October 15 2002 15:42 EDT
Threaded Messages (3)
- Multiple variations of customer - know a good design pattern? by Dave C on October 15 2002 15:51 EDT
- Multiple variations of customer - know a good design pattern? by Chris Russo on October 15 2002 16:17 EDT
- Multiple variations of customer - know a good design pattern? by Dave Wolf on October 15 2002 08:09 EDT
- Multiple variations of customer - know a good design pattern? by Chris Russo on October 15 2002 16:17 EDT
-
Multiple variations of customer - know a good design pattern?[ Go to top ]
- Posted by: Dave C
- Posted on: October 15 2002 15:51 EDT
- in response to Chris Russo
"I could use an interface or inheritance, but that just strikes me as too simple a solution."
What's wrong with a simple solution? Your description sounds like the exact instance when inheritance would be warranted. Why come up with something more complex when inheritance will do what you want?
The only design decision you need to make is how to model your data in a relational database (assuming that's where this all gets stored). -
Multiple variations of customer - know a good design pattern?[ Go to top ]
- Posted by: Chris Russo
- Posted on: October 15 2002 16:17 EDT
- in response to Dave C
I agree that simple is best and concur that basic inheritance is certainly a solution. There are implications to inheritance that is making it a less than optimal solution.
My biggest concern about inheritance is that changes to the parent can ripple through the children - especially when your unsure of who the children are. The "diamond" problem came to mind that's described in the link http://www.artima.com/designtechniques/interfaces2.html.
I was hoping there was a design pattern, like the EJB Command Facade, that may help in this area. -
Multiple variations of customer - know a good design pattern?[ Go to top ]
- Posted by: Dave Wolf
- Posted on: October 15 2002 20:09 EDT
- in response to Chris Russo
That depends on what those changes are. If your inheritence is from an Abstract class as a parent, changes in API of the Abstract members in the parent would break the compilation of the children. Assuming you build completely you would recognize the incompatabilities immediately.
If the changes are in the implementations of the abstract members, then yes that can be problematic. I really believe however that simply using an Abstract parent who himself implements an interface will solve your problem.
Dave Wolf
Personified Technologies LLC