Composite Programming
| Composite Programming: break up, put together |
|---|
| Convenor: Rickard |
Participants:
|
| Summary:
When doing entity modeling it is a common problem that the class code grows over the years as the entity takes on more and more responsibilities related to that particular entity. For a User entity, for example, it might initially only deal with the username and password, and later include profile information, preferences, group memberships, etc. All of these are related to the entity itself, but not necessarily to each other. They are orthogonal aspects of the same entity. What can be done to split up the entity is to use the composite pattern, where a group of objects are used to represent a single entity. But this has some serious object identity issues, and also requires a lot of boilerplate code for access of the different parts. What COP does is to make it possible to model these aspects as different mixins, each of which represents a different part of the entity. These mixins are put into the same entity, with a single identity, and can be sent around as a single object. Once this is done the mixins, which are now orthogonal and responsible for only one thing, can be used in many different entities that share these needs. For example, a mixin might handle "list of labels" for an entity, which could be useful for many different types of entities. So, that mixing is now easily usable in all such cases. Once a certain amount of entities and mixins have been written it becomes easier to create new entities, as typically a lot of the needed mixins are already available, as a library. This is the basis for COP. What has happened lately is that the DCI paradigm, or Data-Context-Interaction, has added a theoretical definition of why this is useful, and how to apply it appropriately. What happens is that a usecase in the application is represented as a Context, and within that Context a set of Roles are implemented as mixins that are then added to entities. The roles, which are technically a part of the entities, supply the usecase-specific behavior and provides the "glue" code between different entities. They are however stateless, as all real state is provided by the data-part of the object. By modeling entities this way it becomes possible to grow the number of usecases for entities without encountering either the "Monster Entity" problem on the one hand (if all logic goes into the entity class) or the "Anemic Domain Object" problem on the other (where all logic is in services). It provides a natural way for algorithmic and object-oriented code to come together, making it easy to read and scalable with regard to usecases. |
| Recommendations:
(as above) |
