Problem Statement

Each issue of "The Architect" will address a common problem in object-oriented programming. This month, we will take a look at how to get a reference to an instance of the class that you would like to use in your code.

Potluck Principle of Getting Objects You Want

If you want to get a reference to an instance of the class, you should first understand what type of object you are trying to create. Is it an Entity, Value Object, DTO, or something else? Once you answered this question, select one of the options below. Choose the option that better fits your situation:

1. You may be able to create the object yourself
2. You may be able to ask another object to give the object to you
3. You may be able to reconstitute the object from a previously stored state

When I discussed these options with Svetlana, she said that they reminded her of organizing a potluck. Potluck suggests an assortment of dishes, just like an object-oriented code is an assortment of objects. When you want a particular dish to be prepared for a potluck, you can do it yourself, assign it to one of the guests, or pick it up from a local grocery or a restaurant.

Option 1: Create the object yourself

You can create the object yourself by calling its constructor or using one of the Creational Design Patterns. Here are some examples when it may be applicable:

1. New Entity. Entity, aka Reference Object, is an object defined by its identity as opposed to its attributes. Examples: a new Account, a new Person, a new Application.
2. Value Object. Value Object is an element of the domain model with no concept of identity. Examples: Money, DayPoint, Address.
3. Policy, Specification, or another member of the Decision Making layer. Examples: IsCosignableApplicationSpecification, IsEligibleFor401KEmployeeSpecification.
4. Data Transfer Object

Option 2: Ask another object to give the object to you

Here are the examples:

1. Local Entity inside of an Aggregate. Aggregate is a cluster of associated objects treated as a unit for the purposes of data changes. The root is the only member of the aggregate that outside objects are allowed to hold references to. To find an object inside the aggregate, you need to traverse its associations. Examples: Order Items of a Purchase Order, Wheels of a Car.
2. Value Object used to describe an Entity or another Value Object. Examples: Age of a Person, Amount in a Bank Account.

Option 3: Reconstitute the object from a previously stored state

1. Existing Aggregate or Global Entity. For each aggregate (or global entity) in your domain model, create a repository responsible for performing a database query and recreating the aggregate (or global entity) based on the query results. Examples: a Car, an Application.

Note that the Potluck Principle does not attempt to answer where and when object references may be obtained and how long they can be kept in memory. These are good themes for our future blog articles.

Let me know what you think. Happy coding!

I am happy to announce a new monthly column called "The Architect" where we will touch on many issues facing designers and developers creating object-oriented business applications.

I will share with you rules, principles, and techniques that I found useful over the years. I hope you will be able to identify with the problems described and will take pleasure in learning from the situations that apply to you.

We have a wide scope to cover: object-oriented analysis and design, domain modeling, design patterns, domain-driven design, responsibility-driven design, service-oriented architecture, etc. If you are a member of a development team, or if you work with software developers, this column is for you.

iBatis.Net DataMapper is our de facto standard for implementing persistence in .NET applications. The framework works well with an object-oriented domain model and relational data store.

Today, we stumbled upon a bug in the latest production release of iBatis.Net DataMapper. A new parameter was added to the existing stored procedure and although this parameter came with a default value, the application threw the following exception: 
"Specified argument was out of the range of valid values. Parameter name: index" from IBatisNet.DataMapper.Configuration.ParameterMapping.ParameterPropertyCollection.get_Item.

One way to work around this issue is to replace the original procedure configuration:

<statements>
  <procedure id="OurStoredProcedure" parameterMap="OurStoredProcedure_Parameters" >
    up_YourStoredProcedure
  </procedure>
</statements>

</parameterMaps> 
   <parameterMap id="OurStoredProcedure_Parameters" class="OurParametersClass">
     <parameter property="Value1"/>
     <parameter property="Value2"/>
   </parameterMap>
<parameterMaps>

with a dynamic statement:

<statements>
  <statement id="OurStoredProcedure" parameterClass="OurParametersClass" >
    EXEC up_OurStoredProcedure #Value1#, #Value2#
  </statement>
</statements>

Happy coding!

Our new open source product went live this week: Modelus Specification. It is an implementation of a very powerful design pattern originally described in the Domain Driven Design book by Eric Evans as well as in this article by Eric Evans and Martin Fowler.

The library is written in C# using generic interfaces. The source code, binaries, and documentation are distributed under the Apache open source license, version 2.0. 

Give Modelus Specification library a try and check out our other open-source products. Let me know what you think or if you have any questions. Enjoy!

Videos from last year's OreDev conference are available for general public:
http://www.oredev.org/topmenu/video.4.45b270a411a9ed8e1278000948.html.

Check out sessions from all three days and do not miss my favourite Domain Driven Design (DDD) track. Enjoy!

Eric Evans
Domain Driven Design

I met Eric Evans in August of 2004, when his book had just came out and he was in Twin Cities at the Object Technology User Group (OTUG) talking about Ubiquitous Language, a language used by all team members to describe the domain model. I was very impressed with Eric's presentation. In very simple terms, he was able to find and explain the essence of what is often missing in domain implementations focused too much on technology.

You will not be disappointed with Eric's book. It describes patterns on how to explore a complex business domain and express it with a comprehensible software model. These patterns help me focus on central business problems while keeping the overall design of the systems understandable and manageable.

This is a must-read book for a business application designer and developer. Happy reading!