Multiple variations of customer - know a good design pattern?

Discussions

EJB design: Multiple variations of customer - know a good design pattern?

  1. 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.
  2. "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).
  3. 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.
  4. 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