Construction vs. Use

Construction iin DTLA

In reading Clean Code, I wanted to dig deeper into the principle that states that software should separate construction from use.

There is the “startup process” which refers to when the application objects are constructed and dependencies are wired. There is also the “runtime logic” that happens after the startup, that describes the actions and processes taking place. For instance, creating a new instance of an object within the runtime logic can make things hard to test. Describe personal experience with mocking.

There are a couple of solutions to ensuring separation of concern. The first is to move all object creation to `main`, which is the initial point of entry and makes sense to a certain extent. However, this assumes that all objects are to be created at one time, at the beginning. If an object needs to be created at a specific point in time, the second solution is to create a `factory` to handle it. This gives the application control of when to build an object, but it should be noted that the details of that construction still remains separate from the application code.

The third solution is dependency injection, which I wrote about in an earlier blog post. A dependency refers to any other object the current object needs to hold onto as reference. Dependency injection is basically providing the dependency, by passing it as an argument, instead of having it construct them itself. For instance, say you have an object with constructor method that does the following:

public SomeClass() {
    myObject = OtherObject.getProperty();
}

This is demonstrative of what I had previously written in my code (not too long ago, in fact). For instance, what if want to run some unit tests on SomeClass? This requires mocking `myObject` but also having to intercept a call to `OtherObject`. Ideally, you should pass the object in as an argument to the constructor which maintains separation of concerns. Here is how that would look like and is the Java convention:

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

One of the major advantages of dependency injection is that it can make unit testing, especially mocking and stubbing of those dependencies, a lot easier. Here is an example of what that would look:

@Test
public void testSomeClass() {
     MyClass myMockObject = new MyMockObject();
     SomeClass someClass = new SomeClass(myMockObject);
}

You can see that I’ve created a mock object and simply passed it into `someClass` and it will return the outcome that I expect. Dependencies can be injected into objects by many means (such as constructor injection or setter injection) and I’ve noted its prevalence in Java through setter methods and constructor arguments that are used to inject dependencies. In Ruby, dependency injection would look something like this:

class SomeClass
  def initialize(my_object)
    @my_object = my_object
  end
end

Our class is no longer coupled to the details of creating an object. Instead, it is only going to use its interface, enabling more flexibility and less coupling. The benefits include the ability to test and the ease of refactoring. Hopefully by being cognizant of dependency injection and recognizing design patterns, I can better understand how to craft better code.