Poor Designs - Using Managers extensively.

I recently had the opportunity to work on a project which used the DSL to design object model and T4 to generate code, using the object data base as data store. And for some reason the team had decided to go for an anemic object model which meant all the business logic needed to be accommodated in the Managers. As a result there were a bunch of managers which enclosed a set of functionality and exposed it through WCF service to client.


A closer look at the whole scheme of things could easily reveal design flaws which have the potential to turn maintenance into nightmare. 

Issues

The design breaks some of the object oriented design principles:

1. SRP – Single Responsibility Principle – A class should have only one reason to change.

I believe object oriented programming models the real life objects where an object not only has data but also knows how best it can do an operation on that data. The managers should be the façade to the functionality provided by the underlying object model. However, instead of delegating the action to an object, the managers are doing all the logic and the objects are used to contain only the data. The Manager classes should be similar to our Managers who know their resources capability (underlying object model) and provide a range of functionality to the outer world by breaking the jobs into smaller pieces (object methods) and delegating them to the resources (objects) who know how best it could be done.

2. The design leads to a big class which has all the functionality where the modification of the class may require frequent merging resolution while checking-in. As every one is working on that same big class.
3. All the automated unit test cases and manual/integration test cases related to the manager needs to be executed to verify that code changes didn’t have any side-effects. Note you would need to run the test cases for even unrelated code just because that code also exists in that same class.
4. It appears to be procedural programming with all objects having the data and the logic contained in the functions of a big class.

Resolution:

Using an anemic model is not true object oriented programming, its always better to have the functionality encapsulated in the object model. However if for some reasons the anemic model is required then it would be better to have another layer of wrapper objects which could encapsulate the functionality.