Peter Ritchie's MVP Blog : Patterns

A Upcoming Pandemic of Domain Anaemia

PeterRitchie — Thu, 29 Jan 2009 17:10:00 GMT

There's a well-known anti-pattern called the anaemic domain model[1][2]. This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour).

It should be obvious that a domain model that isn't truly object oriented is a domain model with a problem. But, let's look at other reasons why the Anaemic Domain Model is an anti-pattern. Your Domain is the nexus, the essence, of your system.

An anaemic domain model is basically a reporting system. Each "Entity" becomes, essentially, a query. This is fine, reporting systems are necessary and prevalent. But, to shoe-horn a domain model on top of this leads away from good reporting patterns that could add value and increases complexity, needlessly. The designers spend most of their time trying to force entities on the system, without recognizing the basic reporting nature of the system. This usually leads to "reports" that have to pull in multiple domain "entities" to generate the report--rehydringing data into an entity (usually through some sort of ORM) with no value added. i.e. an ORM that will manage the child-parent relationship (and either pre-load or lazy-load aggregates) doesn't provide much value here.

The worst case scenario with an anaemic domain model is that there really is behaviour there; but it's not handled in the domain entities; it's handled in a different layer. This is a problem because this circumvents the whole point of a domain model and layering.

One indication of anaemia is that most of the domain classes simply contain attributes. Anyone familiar with patterns should recognize this as a Data Transfer Object, not a Domain Entity. There's nothing wrong with DTOs, they're very important in almost all systems with any sort of complexity; but they're not Domain Entities. Let's be truthful, there are systems with little or no behaviour in the domain; and that's not a bad thing. Systems like this likely don't need a Domain Model and may not need techniques like Domain Driven Design. The quicker people recognize that, the quicker they can be using a more appropriate architecture and design. In some extreme cases the anaemic-domain-entity-DTOs service other DTOs

Now, where am I going with this? Well, there's been a series of guidance out of Microsoft Patterns and Practice about some application "patterns".

First, let me describe what a pattern is. A pattern is a way of "documenting a solution to a design problem" [3]. First, for it to be a pattern, it needs to detail the problem and it's context, then provide a solution. The latest "patterns" from P&P do not detail the problem or a context. They're simply architectural descriptions.

Now the association between the Anaemic Domain Model and the latest P&P guidance. In 3 of the 5 recently publish "patterns" the following is detail is included: "A Domain Entity pattern is used to define business entities that contain data only." This is the very definition of an Anaemic Domain Model. Plus, in the RIA pattern the following, contradictory, detail is included: "Domain entities are responsible for implementing business rules. Entities from the domain model represent business objects that contain data and implement behavior [sic]. In other words, the business objects are responsible for implementing business operations and interacting with other business objects."

This is disconcerting because historically sample code and guidance from Microsoft is simply reused without thought. This leads to poorly designed and architected applications, and the .NET community as a whole is seen as one that produces poor-quality code and design. Without context about the problems these patterns try to solve, they will be misused—likely forced upon contexts and situations where they don’t fit, simply because “they’re from Microsoft”.

[1] MF Bliki- AnemicDomainModel

[2] Anemic Domain Model - Wikipedia, the free encyclopedia

[3] Design pattern (computer science) - Wikipedia, the free encyclopedia

Technorati Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model,Microsoft

del.icio.us Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 17:55:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

Bridges and Factories

PeterRitchie — Fri, 21 Dec 2007 15:45:00 GMT

In my previous post, I talked about Dependency Injection (DI). One implementation of DI is using interface-oriented design to abstract a class from an injected dependency via an interface. This is one possible implementation of the Bridge pattern. Depending only upon an interface and classes to implement that interface opens up some very interesting possibilities.

The tried-and-true means of creating an object is to simply directly use it's constructor, for example:

        IPerson person = new Employee("Peter", "Ritchie");

This is nice and simple; but we're still coupled to Employee despite using an IPerson object thereafter. The above code hasn't truly eliminated the dependency upon the Employee class. Moving all that type of logic to a single method encapsulates the logic into one, reusable, place. This is the Factory pattern, for example:

        person = Person.Create("Peter", "Ritchie");

The Create method, a "Factory Method" on a concrete (likely static) class Person, would know how to create an IPerson object. At this point using a IPerson object is completely abstracted from a specific concrete type and its creation.

        InviteToMeeting(person);

InviteToMeeting is completely independent of the concrete type implementing IPerson (and it can actually be a private type) and how it was created or where it came from. This abstraction leaves IPerson objects free to be created however they need to be. The benefits of Dependency Injection, Bridge, and Factory patterns are synergistic--together they offer more than if they were apart. In the above example they're created as Employee objects; but because their creation is completely encapsulated it could also be affected by policy. Policy that clients of the factory would have no dependency upon.

In the simplest case Person.Create could always just create Employee objects; but because creation is hidden from the client the factory method could use other logic to decide what classes to use. Person.Create could be implemented this way:

    public static IPerson Create ( String firstName, String lastName )

        if (Configuration.IsAdministrator)

            return new Employee(firstName, lastName);

        else

            return new Subordinate(firstName, lastName);

Now we're injecting policy into the creation process. Somewhere, likely not in source code, whether the current user is running as an administrator. This state is used in a policy to decide what type of IPerson object to create.

Dependency Injection

PeterRitchie — Thu, 13 Dec 2007 15:42:00 GMT

Dependency injection (DI) is a form of inversion of control. There seems to be a tendency in some circles to refer to dependency injection as inversion of control (IoC).

Dependency injection is a form of abstraction by removing physical dependencies between classes and potentially assemblies. This abstraction can have many different motives. One motive is for Aspect Oriented Software Development (ASOD) where you're abstracting shared (or cross-cutting) concerns into independent classes. Another motive is for Test-Driven Development (TDD) where you want to be able to test each class independently of its dependencies--in which case injected dependencies are "mocked"--technically this is still AOSD because you're separating the testing concern.

Dependency injection in .NET is most frequently implemented using interface-oriented design/programming, where a dependency of a class is on an interface. Any class implementing that interface is then a candidate for being "injected" into the other class. There's many ways to inject dependency, one is at time of construction the other is at time of operation.

There are many examples of dependency injection at time of operation in the .NET Framework. Normally when an interface is involved, dependency injection is also involved. Serialization is a good example. Serialization in .NET allows programmers to serialize to pretty much anything. "Anything" being a stream. Serialization abstracts the destination from the act of serializing and allows programmers to inject a dependency on any type of destination (media, resource, mock, etc.) simply by implementing IStream. For example, for any given class in .NET I can "serialize" it to any stream:

            MyType myType = new MyType();

            IFormatter formatter = Configuration.CreateFormatter(typeof(myType));

            using (Stream stream = new MemoryStream())

                formatter.Serialize(stream, myType);

                // TODO: something with stream.

In the above example, IFormatter.Serialize(Stream, Object), uses dependency injection at time of operation to serialize to a MemoryStream object. In no way is IFormatter.Serialize dependant on MemoryStream. The same call could be written as follows:

            using(Stream stream = new FileStream("file.dat", FileMode.Create))

                formatter.Serialize(stream, myType);

                // TODO: something with stream.
            }

The above form of DI is interface (and class) based, in that you need to implement a specific interface to inject as a dependency. Another form of DI is via delegates. You can abstract a particular class from other concerns simply by accepting a delegate. Any class that wants to be injected simply needs to implement a method with the same signature as the required delegate. Events are an example of this. Any class that raises events is completely independent of any other classes that want to act as observers and subscribe to these events. Subscribers are, in effect, are preforming dependency injection by subscribing to an event. This form of DI is not limited to DI, it can be any delegate. In .NET 2.0 there were many examples of this introduced. List.ForEach, for example:

namespace Examples

    using System.Collections.Generic;

    public class Program

        static void Main()

            List<string> names = new List<string>();

            // TODO: populate names

            names.ForEach(Print);

        static void Print(String name)

            Console.WriteLine(name);

In this example, List<T>, of course, is completely independent from Program and Program is free to be static because there are no interface implementation requirements.