Another aspect of coupling in Object Oriented paradigm

I had previously written a post related to coupling and cohesion here and that was more of a basic definition of both the terms.

In this post I would like to throw some light on the tight dependency on the type of the component in use. Generally we would aim to design classes such that they interact via the interfaces or more generally put via API. Suppose we use interfaces (more of a generic term where we dont have implementations, not specific to keyword interface in Java or C#), but this is not enough, we need to provide some kind of implementation for the interface which is actually consumed by the other client classes.

Before going into details let me pick some example (examples in Java): I would like to design a Reader which would help the client classes to get the information from any source specified- be it File System/Web. So the interface would be:

interface Reader
{
  public String read();
 
  /**
   * Get the source to read from
   */
  public String getSource();
}

I would want the user to seamlessly use the API for reading file from the file system or from the web/ web document. The next step would be to create implementations to read from file system and from the web.

class FileSystemReader implements Reader
{
  private String source;
  public FileSystemReader(String source)
  {
    this.source = source;
  }
  @override
  public String getSource()
  {
    return this.source;
  }
  public String read()
  {
    //Read from the source.
    //The source is a file in file system.
  }
}
class HttpReader implements Reader
{
  private String source;
  public FileSystemReader(String source)
  {
    this.source = source;
  }
  @override
  public String getSource()
  {
    return this.source;
  }
  public String read()
  {
    //Read from the source.
    //The source is a document in the web.
  }
}

One way of using these Interfaces and implementations is- The client classes deciding which Implementation to instantiate based on the format of the source. So it would be something like:

class Client
{
  /**
   * This is the consumer of the Reader API
   * @param source Source to read from
   */
  public void performSomeOperation(String source)
  {
    Reader myReader = null;
    if(source contains "http://")
    {
      //its a web document, create a HttpReader
      myReader = new HttpReader(source);
    }
    else
    {
      myReader = new FileReader(source);
    }
    print(myReader.read());
  }
}

All looks good, the classes interact with each other via the API, but you might feel within that something’s not good. Then there comes another requirement where in there can be a third source to read from and you would have to change in all the places where ever such a creation was being done. If you miss out the change in some place then you end up with a broken code, see how fragile your code has become.

Apart from that your client class knows that HttpReader is used for this and FileReader for that, so you are giving away the type related information about the instance you are using and thereby the client code gets tightly coupled with this type information. This approach can at times break the Open Closed Principle because you end up editing the class each time a new implementation of the interface is added. So there should be someway we can shield this creation of instances, of different implementations of the interface, from user of these interfaces. Yes there are ways and I know by now you must have been waiting to unleash the Factory Method pattern.

So how can the above code be modified to use a Factory

/**
 * Factory to get the instance of Reader implementation
 */
class ReaderFactory
{
  public static getReader(String source)
  {
    if( source contains http)
    {
      return new HttpReader(source);
    }
    else if(someother condition)
    {
      return new SomeReader(source);
    }
    else
    {
      return new FileReader(source);
    }
  }
}
 
class Client
{
  /**
   * This is the consumer of the Reader API
   * @param source Source to read from
   */
  public void performSomeOperation(String source)
  {
    Reader myReader = ReaderFacotry.getReader(source);
    print(myReader.read());
  }
}

See how simple the Client code has become, no type related noise, the user would not need to know what type of instance is being used and hence keep itself less coupled with the type. The factory method takes care of seeing which implementation to return to the client code based on the pattern in the source string. This way we end up having a less coupled code in terms of the coupling due to exposing the type information. And now when there comes a new requirement for a new reader for a new source then you know where you have to make the change and the change would be only in one place. You can see that your code is less fragile and also you have eliminated unwanted redundancy from the code.

One thing to keep in mind is that encapsulation is not only data hiding but also hiding the type related information from the user.

Reference: Another aspect of coupling in Object Oriented paradigm from our JCG partner Mohamed Sanaulla at the Experiences Unlimited blog.