I’m currently reading…

Domain-Driven Design: Tackling Complexity in the Heart of Software
by Eric Evans

Read more about this title…

It’s really as good as they say it is! And it’s got me thinking… I really enjoy reading a book that makes me think, I sometimes prefer reading tech books that only give you concepts to think about. It’s up to you to understand those concepts then find a way to implement them when you see their use is necessary. There’s a lot of great concepts that came from this book, and after seeing them out in the wild in episodes of DNRTV and source code buried in svn repositories it’s all starting to make sense…

Note: the definitions above are right out of the glossary.

The toughest part to grasp and seems to be the underlying theme of this book is “The Ubiquitous Language”. The tough part is not grasping the “concept” but rather the implementation. The concept makes a lot of sense, but how you can practically apply it is a separate story. One that I think takes experience through trial and error. Time will tell…

Go buy this book, I know I will… until then thank you Mr. Adam! (just in case I can’t I put it on my wish list for Santa, he always pulls through!)

After reading through some examples on specifications and reading through JP’s example, this sparked some ideas in my mind. So I hacked together some code and came up with this. Let’s say I’ve got a bank of questions, and that each question is part of a category, and I want to be able to search through the bank of questions…

[Test]
  public void Should_Return_3_Questions_That_Are_Not_Math( ) 
  {
    IEnumerable< IQuestion > matches = CreateSut( ).FindAllWhere( Question.IsIn( Any.Category ).But( Not.In( Category.Math ) ) );
    Assert.AreEqual( 3, GetCountFor( matches ) );
  }

Notice the use of “But”, I wonder if this will catch on…

Basically I started looking into creating specification for boolean operations, with a slightly different take from what the book offered.

I’m not sure it’s the most elegant interface, but I really wanted to be able to make the client code as readable as possible.

What I ended up with was types like “Is”, “Not”, “And” & “Or”. I’m not sure I’m completely happy with the end product, but I see potential for extending this further, and the best part is how readable the code seems to be. I think that excites me more then anything else… I think I’m just starting to understand this concept of the “fluent” interface. Not truly implementing it well, seems to be difficult, but fun!

Here’s what my Question type turned in too…

public class Question : IQuestion 
  {
    public Question( ICategory category ) 
    {
      Category = category;
    }

    public ICategory Category { get; private set; }

    public static ISpecification<IQuestion> IsIn(ICategory category) 
    {
      return Is.In(category);
    }

    public static ISpecification<IQuestion> IsNotIn(ICategory category) 
    {
      return Not.In(category);
    }
  }

The Is type looks like…

public class Is 
  {
    public static ISpecification< IQuestion > In( ICategory category ) 
    {
      return new Specification< IQuestion >(
        delegate(IQuestion question) 
        { 
          return category.Equals(question.Category); 
        }
      );
    }
  }

And the “Not” type looks like…

public class Not 
  {
    public static ISpecification< IQuestion > In( ICategory category ) 
    {
      return new Specification< IQuestion >(
        delegate( IQuestion question ) { return !category.Equals( question.Category ); }
      );
    }
  }

To me it still seems that the “Not” and “Is” types shouldn’t be responsible for returning the specification, and that responsibility should belong to the Question, but I’m just not sure… and it’s getting rather late so I should head to bed.

source code(2.17 MB)

comments powered by Disqus