sfeldman.NET

The leading bargeman

A few months ago I blogged about Domain Objects vs. Primitive Types. Back then it felt right to me to transform a primitive type, like a Guid that represented an organization ID, to an Organization domain object. Unfortunately at that time I was not educated enough to know that this is a common idiom among many object designers. Apparently it is. Craig Larman writes it nicely in his book (in my case Organization is what Craig references to as a Customer):

Why bother? Having a true Customer object that encapsulates a set of information about the customer, and which can have behaviour , frequently becomes beneficial and flexible as the design grows, even if the designer does not originally perceive a need for a true object and thought instead  that a plain number of ID would be sufficient.

The other important note is when this transformation is taking place - when an ID or a Key leaves the UI layer and gets to the Domain Layer.

It is very hard to provide an honest opinion when you are involved in a situation. I found it always difficult for myself and admired people of being able to do it, lifting themselves from emotional attachments to the matter.

I am a big fan (if not huge) of the whole Google Apps platform. I use heavily Gmail, rely a lot on Google Calendar, abandoned Excel for simple-to-average stuff and went with Google spreadsheets. I used Google Maps, because it was better than Microsoft's competitive version of the product. Till I had a chance to re-evaluate it again. This time around Microsoft has produces a better result. Microsoft Live Maps gives me more than Google Maps does (weird even to think it, not mentioning writing it :).

What made the difference? The level of details, an option of having a closer look, real images. Anyway, I am not using Live Maps.

A few days ago read in Larman's book about Command-Query Separation Principle. Funny to mention  that I heard about the concept many times ago, but this is the only source that stated it as a principle. And it makes total sense once you evaluate all the pros and cons of the idea.

What's the principle? Simple. There are two kinds of messages to objects:

• Commands - ones that are affecting the state of the object
• Queries - ones that are querying an object for its' state without affecting its' state at all

A Command message would be "void Calculate()" or "void Add(double value)". Command message never returns a value, and that's for clear separation of the messages and easier maintenance of the object state (i.e. no surprises). A Query message would be what Command isn't "int GetValue()" or "IsVisible()".

One exception the author brought up was internal/private messages that are not a part of the interface, and therefore can violate the principle - I guess this is a matter of personal preference.

An example is an implementation of a Die (for a monopoly game) modified by myself.

    public interface IDie 
    {
        void Roll();
        int GetFaceValue();
    }
    
    public class Die : IDie
    {
        private int faceValue;
        private Random rand = new Random();
        
        public void Roll()
        {
            faceValue = rand.Next(6) + 1;
        }
        
        public int GetFaceValue()
        {
            return faceValue;
        }
    }

I added the interface on purpose, to have DbC, where implementation doesn't matter that much, because the contract is expressing well enough the intension of how to use an implementer of  an IDie. Thanks to the CQS Principle it becomes crystal clear. It is easy to determine a value of a die, and there's no surprises when a die is queried for it's value.

Now imagine a system with a significant number of components that violate this principle versus a system where components follow it. Can you imagine the difference?

Today is 3 years since I started working with the company I work today. It's being a long journey from figuring out what I want, till realizing what I am and need to be. The team has accepted all of my wildest ideas about the code and was very tolerant to the fact that I cannot wait to get something done. We've made a long way.

Besides improving as a software developer, I also realized a few bitter realities - it doesn't matter how good I am, still need to strive to be better. Besides the excellence in code, there must be a proficiency in human relationships. The code is not only about a single developer level, but about team level, because if you are the only one who can have fun with it, it is no longer fun.

Lessons are good, but I have to look forward and setup certain goals for myself, what do I want to achieve the next year? A lot.

• I want the team to get to the point where I am right now, and I can do more for that
• I want to have more fun while working, because without it work is useless
• I want be more influencing people, help them realize themselves better, without getting into conflicts
• I want to improve a lot myself, and by doing that to show, that you can achieve if you want to

Some of my targets will change or get updated, but the core set of goals will remain.

A lot ahead, I better start moving towards it.

Interesting difference I picked up from a book this morning - code smell vs. code stench.

Code smell might indicate there's a problem in code that requires refactoring, but a closer evaluation might prove the smell is false alarm.

Code stench is an obviously bad/poor code that has to be refactored.

From now on I will be more accurate on describing the code issues :)

For all keyboard junkies out there - if you are also hooked on Google products (GMail, Reader, Calendar, etc), don't miss the option of using GMail with keyboard shortcuts. The are awesome. I loved the navigation shortcut (combination of pressing first G and then another key, neat).

To enable keyboard shortcuts, you will have to go to the settings under you GMail account and check off the option to enable it.

In the

Table 1

namespace Local.ADL.Home
{
  public class HomePresenter : IPresenter
  {
    private readonly IHomeModel model;
    private readonly IHomeView view;

    public HomePresenter(IHomeView view): 
                        this(view, new HomeModel()){}

    public HomePresenter(IHomeView view, IHomeModel model)
    {
      this.view = view;
      this.model = model;
    }

    public void Initialize()
    {
      view.Load += View_OnLoad;
    }

    private void View_OnLoad(object sender, EventArgs e)
    {
      if (!view.IsPostBack)
      {
        view.AssignInitialData(model.IsUserMemberOfPlanAOrPlanB(),
                model.CanShowSomething());
      }
    }
  }
}

Table 2

namespace Local.ADL.Home
{
  public class HomeModel : IHomeModel
  {
    public bool IsUserMemberOfPlanAOrPlanB()
    {
      return UserSession.IsPlanAorB;
    }

    public bool CanShowSomething()
    {
      return UserSession.ShouldSeeSomething;
    }
  }
}

Q: Can HomePresenter be tested based on the code in Table 1?

A: Yes. It has a parameterized constructor that accepts all dependencies for HomePresenter as contracts (interfaces) without knowing or carrying who are the real components that implement those contracts. Loosely coupled code, where we depend upon abstraction and not concrete implementation.

Q: Does HomePresenter is loosely coupled at run-time?

A: No. It has a direct dependency on HomeModel class. This is a tight coupling, meaning that anywhere in the code we used this type of coupling, we made HomeModel “visible” for HomePresenter, i.e. we violated the principle of depending upon abstraction and not concrete implementation. What would be a solution? Dependency Injection Principle with a standard container (lets call it DependencyResolver). Using this simple principle would change the code to be something similar to the code in Table 3. Now HomePresenter is loosely coupled to the implementer of the IHomeModel contract. Some configuration file / startup code will determine who is the actual implementer at run-time. Testing is still possible.

Table 3

namespace Local.ADL.Home
{
  public class HomePresenter : IPresenter
  {
    private readonly IHomeModel model;
    private readonly IHomeView view;

    public HomePresenter(IHomeView view): 
       this(view, DependencyResolver.GetImplementerOf(IHomeModel)){}

    public HomePresenter(IHomeView view, IHomeModel model)
    {
      this.view = view;
      this.model = model;
    }

    // ...

Q: Can HomeModel be tested based on the code in Table 2?

A: No. It is tightly coupled to the UserSession, which in its’ case is a static class and cannot be mocked / faked / taken out as a component that is not required to be tested at this moment.

To solve it:

• UserSession has to be implementer of a contract, lets call it IUserSession
• The implementer of IUserSession has to be supplied / injected as a dependency during construction time either directly or through container, similar to the example in HomePresenter code in Table 3

Strive for loosely coupled designs between objects that interact.

By minimizing the knowledge one class has of another, you decrease dependency between those classes. Independent classes provide more flexibility in design.

Does this mean your application becomes more difficult to understand? Yes to a certain degree. You have to understand a few things before trying to work with loosely coupled code, things like the idea behind this principle. Why coupling is bad in first place. Determine how coupled your code that you normally created. Why you need loosely coupled code (or "what's in it for me").

One of the benefits of TDD I figured out for myself is that it forces you (yes, forces) to stick to the loosely coupled design. Program to an interface, not an implementation. By defining interface/contract first, and deferring it's implementation for later, you defer the concrete implementation of other components that are not the primarily target at the moment. That is a loose coupling, since you minimize the dependency on details of those components. Depend upon abstractions. Do not depend upon concrete classes. Interface is the abstraction, allowing to substitute implementer of it. Combined with Dependency Injection Principle, you achieve a true loose coupling.

So the code like the one at the bottom (that doesn't really do anything significant) is loosely coupled to the component of type IComponentA, which is an abstraction. We don't know who is the implementer of this contract unless look into either a startup code or configuration file that sets the implementers for the contracts.

How difficult to learn that from looking briefly at the code? Probably not the easiest task. But you would never get it in first place, without understanding the principles. So saying that the code is 'hard to trace' indicated that there's no understanding of the principles. When you understand what DependencyResolver is, and concepts it implements, you immediately understand what the chained constructor is doing. TDD is forcing to expose the 2nd (parameterized) constructor for easier dependency supply. You could configure DependencyResolver for tests, but then it adds complexity to the testing.

So my question is can code be too loosely, or your code is so coupled, that anything else is difficult to digest?

   1:  public class ComponentB : IComponentB

   2:  {

   3:      private IComponentA dependency;

   4:      

   5:      public ComponentB() :

   6:            this(DependencyResolver.GetImplementationOf<IComponentA>()) 

           {}

   7:      public ComponentB(IComponentA dependency) 

   8:      {

   9:         this.dependency = dependency;

  10:      }

  11:   

  12:      public void SomeFunctionality(string param)

  13:      {

  14:         var result = 

                   dependency.OperationDefinedByDependencyContract(param);

  15:         return DoSomethingWith(result); 

  16:      }

  17:  }

[Pure personal content] 

My vacation with family in Israel almost over - packing luggage, sitting for the last time at cafes with people I will miss, enjoying the extra hot weather while it's more fun than burden. This vacation was a great refresh for the entire family: kids, wife, myself. Having a break from daily thoughts, code, work - feels that it has gave me more will to kick in and go forward that it felt a month ago. Speaking about going forward...

Going forward has to be directed. A list like JP and Mr. Mo suggested is a great idea. Having a master plan partitioned by timeline can be another concept. Sitting back and analyzing what has being accomplished, with what costs, and was it worth it or not is another way. I guess this is the path I went while staying on vacation. I see better what fights I should not go into - they are just not worth it and I have better things to do in my life. I can definitely distinguish better between friend and foe. I realize that tolerance is blessing, and a curse at the same time, and that it's my responsibility to make the judgment and deciding call what persist on and what to let go.

I am returning from vacation this time, knowing better what I want from myself. This will allow me to manage better my expectations from others, and hopefully, communicate better and spread the ideas I believe in. This time around I also know that I am coming back and there are friends waiting. This time the concept of "everything should be with good proportion" fits better than never. Enough of vacation, let's code!