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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Another aspect of coupling in Object Oriented paradigm"

  1. If you have the environment, Dependency Injection is even better than a Factory!

    PS: In your HttpReader class the constructor is (wrongly) named FileSystemReader…

Leave a Reply


× four = 36



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close