Multiglom B2B, vendor of the CRM suite Manjok for small businesses, currently reworks the internal data model.
Manjok supports the mapping of various levels of a customer's enterprise. They are represented by a couple of entities, such as holding, company, and division and staff member. One goal of the new design is to detect common aspects and build hierarchies to treat these entities in the same way in certain use cases.
Thinking in terms of a graph obviously all the entities belong to the enterprise and can be seen as enterprise nodes. However, holding, company and division nodes can have child nodes (part-of-relation), staff member cannot.
The goal is to reflect these basic relationships in the design to simplify common tasks like listing or counting.
In this scenario we want to apply the Composite Pattern to compose objects into tree structures to represent part-whole hierarchies (GoF).
We have identified the EnterpriseNode as a common interface for Holding, Company, Division and StaffMember, further we have detected that only the first three can be parent nodes in a part-of-relation. This can be reflected by an abstract base class AbstractEnterpriseUnit.
Only entities inheriting from AbstractEnterpriseUnit can have child nodes, all elements (including StaffMember) can have a parent node. So bottom-up we can navigate without any explicit type checking.
Open CompositeTest.java to start playing with this pattern. By setting the log-level for this pattern to DEBUG in logback.xml you can watch the pattern working step by step.
- The most familiar example of a composite is the File, which can be plain file or a directory.
- The initial design of a good composite is tricky, starting with plausible naming. Also it can be a pain, if any property or method decided to be common is in fact not common. A consequence is the ugly UnsupportedOperationException violating LSP. On the other hand later making anything common leads to subsequent changes.
- (GoF) Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley (1995).