Dynamic Object Model (using Java Collections and Spring)

How many times in the past did you create complicated class diagrams to describe every possible entity within the business domain? I’ve done many of them and the result was a nice object-oriented model which clearly defines what the business entities are, what their attributes and functionality is and how they relate to each other.

Well, that was ok for the most part when dealing with stable business models. Today businesses must be agile, which means that the systems that support them must be agile as well. What that means is that changing certain aspects of the business should involve very minimal system changes if any. And that is why I changed my beliefs and created something I call “dynamic object model”.

Ok, hold on, it just sounds complicated but in reality it’s much simpler then a traditional object model. This model can be applied to most businesses and changes to business will not require changes to the model.

Ok, here we go – high level:

I basically designed a top level Interface Entity, which has something like this:

public Object get( String name );
public String getString( String name );
public int getInt( String name );
public double getDouble( String name );
public void set( String name, Object value );

Of course there is more stuff, like a Map of attributes which can be derived from other attributes, copy(), toXml(), and other useful functions.

Then I create a GenericEntity which can actually be instantiated and play a role of any business object.

I don’t have any business specific attributes. All attributes are basically inside a Map.

Everything is then configured with Spring framework's dependancy injection and that is where I can specify specific information regarding the contents of my business entities.

Sounds too simple? It is. I used this model on several projects without changes and had no problems whatsoever.

You can always extend GenericEntity and create something like Customer or Product, but I never had to do this, because I want flexibility when designing applications.

I guess what I am trying to say is that most solutions must be straight forward, flexible and developed fast.

I still use the best object-orientation concepts when designing application logic, but I am no longer in favor of complicated business domain models.

-Igor