Too-Smart-Business-Object Anti-Pattern

Building up a good business library is art. Because every bad decision made early will eat project’s time later. Bad decisions will also waste many time of developers who have to use this library in their work. One of the most common mistakes made is mixing DAL functionality to business objects. At first it may seems like a good idea – why not have a smart objects? – but as project goes this solution causes more and more problems. And, be warned, each next problem is worst than previous.

Well, the correct answer to this problem is n-tier architecture and design patterns (in most cases), but let’s see how bad can be too smart business class. By the way, notice how hard are problems going everytime we make one step forward.

Seems like a good idea

Well, project is started and it is time to create classes for business objects. To save some coding time the team decides to make objects as smart as possible. The point is – application programmers who have a lot of work to do can use those objects and doesn’t have to worry about how these objects are persisted and restored after persisting.

So, seems like this class is okay. We can modify it easily and if it is necesaary we can save this object or delete it. Very convenient.

Let’s see what happens

First problem rises when somebody wants to extend one of those business classes. Methods dealing with data get override, some guys call base methods in overrides and some guys just write new logic without calling corresponding method of base class. It is done economically: let’s use as much base class features as possible. Sometimes it is possible, sometimes it isn’t.

Let’s see what kind of trouble our guys are building and let’s look at the near future. Let’s see what happen three months later. The number of classes is not small anymore and there are couple of hundred business classes. Inheritance hierarchies are much longer than before and there are many problems with data access. Nobody has good picture of what is happening inside those override methods. Nobody knows what classes call base class methods and what classes have their own logic.

There are many problems related to data access and time losses are heavy. When problems were small then these problems were solved by simple hacks. Now there are hundreds of simple hacks and the code is out of control.

And even worse scenario

Let’s suppose that in the beginning of project there was made one important decision about required web service: let’s write the service later when business classes don’t change anymore or when changes are at least very small. Now, how to show these business objects to web services? All those objects must be serializable. But how can one serialize live communication resources like database connections?

Okay, let’s say that writing hundreds of DTOs is solution. Maybe it is but I doubt about it. Still there is need for wrapping business objects because it is not possible to send them over network. And this wrapping maybe pretty expensive job to do for server.

This storty ends with web service hack because there is not time enough to rewrite business layer from the ground. There is time for fast hacks but who guarantees that these hacks will work?

Be careful when you are making decisions about system architecture and design. If something seems very smart then check it over many times to make sure you don’t create the small problem that grows larger exponentially in time.