Dynamics of object creation

A fundamental starting point is that all the classes in a domain model are connected. This means that there is always an association path from one class to another.  In most cases the creating objects are directly associated with the new object. On the other hand domain layer objects don’t have any reference outside the domain. All domain objects must be created by a domain object even if the stimulus to do so comes almost always from outside (from application layer).

When an application usage starts, some entity object exists. So creation of these objects is out of the scope of the application. Of course technically every object of an application must be created, but this is not the issue. So a set of objects exists and are in a way given to the application. In most cases for example the home organization, its roles and persons exists.

Now when we start to analyze object creation, the first fundamental base finding, that by the way is easily passed by beginners, is that an object cannot ever create itself. The next issue is can an object from the same class create an object from the same class. This is true from some classes and not true for others. For instance object in Persons class can create a new person. Now actually this needs two objects from person class and 9 months – but serves as an example anyway. An example of entity class that cannot create an object from same class is the class House.

When we take into account the Coad’s color categories then we can be more precise. My first examples were bots entity-type classes. So we can say in general that some entity class object can create object from the same class.

Role-type classes are actually objectified associations. There is even no theoretical aspect why a role object should create similar objects. The same applies to Description-type as well as to Event –type.

Typical creation patterns

Let look at different dependencies and situations at object creation. Let’s go through Coad’s categories what are the creation patterns and their justification. The bottom line here is to set the behavior into an object that “knows” most or best what to do. This seldom corresponds strictly reality instead some level of abstraction (read imagination) is needed.

Creating Entity-class objects

As I already mention some entities can create similar entities. Here are some typical patterns to create entity objects. One example of these abstract ways is the first very common entity creation pattern.

Creating entities from descriptions

Here the idea is that we have a description object, that describes an entity. The responsibility of creation is put in this description. Let’s take a couple of examples: The drawings (the design) of a house will create (read build) the house. A recipe will create (read cook) a meal and so on. In reality this description in most cases is unable to do this, but the abstract way of thinking this is that the description is the actual performer but it uses something of someone in reality as an instrument to do so. In the case of a meal the instrument is the cook.

Creating entities  from events

Similar to description are event. The production of entities from can also be modeled with and event object. In these cases the responsibility of entity creation is typically but into the event. For instance a cook event can also be considered to be responsible of creating a meal. This is an alternative solution instead of the previous one.  The need to have the event in the model instead of just a method is the need to know something about this event itself. Simple example of cook event could be the duration.

Creating Description-class objects

This is very similar to entity case. The domain stories often starts from a description, so they are not actually created within the domain but rather outside. Of course the application layer have to have a functionality to crate object that are starting points of the domain behavior. This is however another story.

Creating Role-class objects

In most cases a entity object will create a role for another entity. This creation of a role enables this entity to participate in some activity. For example a role of developer have to be created for a person by the organization entity before it can be associated for instance I a project task.

Creating Event-class objects

This is perhaps most flexible category. Entities, role are typical creators of events, but event can be created by other events and descriptions as well.


One Response

  1. […] This post was mentioned on Twitter by Rui Curado. Rui Curado said: Dynamics of object creation : http://j.mp/ba2k5l #oop […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: