OOP vs Structured/Procedural programming (or DDD vs ADM)

I think I may have succeeded in creating a headline with most Jargon evar… It is almost as bad as the name of my blog.

I have been having this dilemma. I have an enterprise level application written using OOP and ActiveRecord. It utilizes many OOP concepts such as Inheritance and Polymorphism. Recently I have been looking into making the system more friendly for Unit Testing. I talked about it to some developers working on the system and I had an interesting revelation: most of the developers prefer Structured/Procedural programming over OOP.

Here is the general overview of Procedural programming and OOP.
From http://www.umsl.edu/~subramaniana/concepts1.html

Procedural/Structured programming

• Procedural Approach Data Structures can be represented as a network of associated structures, referring to one another.
• Procedures can be represented as a network of routines which call one another, i.e., “call tree”

OOP

• Object Oriented Approach Collection of discrete objects that incorporate data structures and behavior.
• Each data structure has, combined with it, the procedures which apply to that data structure.
• Contrasts with conventional programming in which data structures and behavior are only loosely connected
• These entities, called objects, can be associated to one another in one network, rather than two.

DDD is based on OOP, while Anemic Domain Model is all about procedural programming.

Back to Dilemma. As much as Anemic Domain Model is an anti-pattern – it has one really nice thing going for it – it is simple and it makes sense to most developers and non-developers. How can Order ship itself, how can cake bake itself? Instead order and cake are just data and you have some OrderService and CakeService operating on them. With SOA even many business people can easily think in procedural terms.

My current system is written using OOP – objects have both data and actions. So I was hoping that switching to DDD would make OOP even more central to future development. The problem is that separating Active Record Entities into Repositories, Domain Entities and Application Services layer is confusing other developers on my team. Many of them come from procedural programming (aka Java EJB), so as soon as they see Entities and Services – then all logic goes into Services while Entities are just data structures.

Here is an example of what I have in my system:

Order
{
     OrderStatus _status;  (InProgress, Paid, Shipped)
     List _orderLines;

     Customer _customer;
     OrderBilling _billing; //Includes ShippingAddress and payment info
     OrderShipping _shipping;  

     DateCreated _dateCreated;

     AddOrderLine(product, quantity)
     RemoveOrderLine(orderLine)

     CalculateTotal();

     TakePayment();
     Ship();
}

Here is the same code written using ADM/Procedural:

Order
{
     OrderStatus _status;

     List _orderLines;
     Customer _customer;
     OrderBilling _billing;
     OrderShipping _shipping;  //Includes ShippingAddress and payment info
     DateCreated _dateCreated;
}

OrderService
{
     AddOrderLine(order, product, quantity)
     RemoveOrderLine(order, orderLine)

     CalculateTotal(order);

     TakePayment(order);
     Ship(order);
}

So what are the benefits of OOP vs ADM:
1. In OOP all the methods that operate on Entity are part of entity (or delegated to appropriate command/domain services by entity), while in Procedural – the code can be dispersed through many different services.

2. OOP is better for code re-use. Will need some examples for this one.

3. When refactoring, can use OOP Design Patterns like State Pattern for switching Order status.

But saying all this is not enough. There is only one way to make a convincing argument in Software Development:

SHOW ME THE CODE

In the upcoming blog entries, I will try to provide a real world coding example for each one of the points above…

One class per file or multiple classes in one file

I browsed the internet for an answer to this question and the best I could find was:

“The primary benefit of a class per file is for source control and concurrent access: Why deal with the inevitable human error of code merges if each developer is really dealing with the separate classes.”

In my case there are several really small classes that seem like they can go into one file or be separated. As a personal style it seems best to put each class into separate file. This way I can easily see/find all the classes through solution explorer.

On the other hand it seems more like a stylistic argument, since I couldn’t find any evidence that it actually improves performance. I could also use VS diagramming tool to create a nice diagram for all the classes in a module.

So some possible guidelines for development team that can come out of this are:

1. Allow including several classes in file only if each class is max of 10 lines of code.
2. Classes in the same file must belong to the same Module (DDD Module)
3. Enums should go in .cs file that uses them. If there are several classes that use enum – pick one.

Found another good reason for keeping classes in separate files:

“Also you’ll find many errors/diagnostics are reported via file name (“Error in Myclass.cpp, line 22″) and it helps if there’s a one-to-one correspondence between files and classes. “
From: http://stackoverflow.com/questions/28160/multiple-classes-in-a-header-file-vs-a-single-header-file-per-class