Dependency Inversion Principle

This is the last principle of the SOLID principles and what it states is:

“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.” (wikipedia)

This principle was stated by Robert C Martin. The main goal of this principle is decoupling.

Now as an example, let’s consider a “manager class which is a high level class, and the low level class Worker. We need to add a new module to our application because in the company there are some new specialized workers employed. We created a new class SuperWorker for this.”

“Let's assume that the Manager class is a complex one containing a very complex logic. And now we have to change it in order to introduce the new SuperWorker. Let's see the disadvantages:

• we have to change the Manager class (remember it is a complex one and this will involve some time and effort). 

• some present functionality from the manager class might be affected.

• the unit testing should be redone.”

So, here is the code that violates the principle:

class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;

public void setWorker(Worker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
} 

And applying this principle we should obtain something like:

interface IWorker {
public void work();
}

class Worker implements IWorker{
public void work() {
// ....working
}
}

class SuperWorker  implements IWorker{
public void work() {
//.... working much more
}
}

class Manager {
IWorker m_worker;

public void setWorker(IWorker w) {
m_worker=w;
}

public void manage() {
m_worker.work();
}
}

Bibliography
OODesign.com. (n.d.). OODesign.com. Retrieved august 11, 2013, from http://www.oodesign.com/dependency-inversion-principle.html
wikipedia. (n.d.). wikipedia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Dependency_inversion_principle

Interface Segregation Principle

This principle was postulated by Robert C Martin. It says that “no client should be forced to depend on methods it does not use” (wikipedia.org). But also in another site I found this other that I like much more “The ISP specifies that clients should not be forced to depend upon interfaces that they do not use. Instead, those interfaces should be minimised.” (Carr, 2011)

As an example of the violation of this principle we can have:

public class Contact
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string EmailAddress { get; set; }
    public string Telephone { get; set; }
}

public class Emailer
{
    public void SendMessage(Contact contact, string subject, string body)
    {
        // Code to send email, using contact's email address and name
    }
}
  
public class Dialler
{
    public void MakeCall(Contact contact)
    {
        // Code to dial telephone number of contact
    }
}

But wait, why that this code violates the principle?? well the answer is that the classes Emailer and Dialler just need  some “attributes” of the class Contact, but they have access to all of them. And what we do is to hide the attributes or properties that are not needed for the classes.Doing that we got a consequence an violate another SOLID principle, but it represents clearly what  this principle means.

So, applying this principle we should get:

public interface IEmailable
{
    string Name { get; set; }
    string EmailAddress { get; set; }
}
public interface IDiallable
{
    string Telephone { get; set; }
}
public class Contact : IEmailable, IDiallable
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string EmailAddress { get; set; }
    public string Telephone { get; set; }
}


public class MobileEngineer : IDiallable
{
    public string Name { get; set; }
    public string Vehicle { get; set; }
    public string Telephone { get; set; }
}

public class Emailer
{
    public void SendMessage(IEmailable target, string subject, string body)
    {
        // Code to send email, using target's email address and name
    }
}


public class Dialler
{
    public void MakeCall(IDiallable target)
    {
        // Code to dial telephone number of target
    }
}


Bibliography
Carr, R. (2011, january). blackwasp.co.uk. Retrieved august 11, 2013, from http://www.blackwasp.co.uk/ISP.aspx
wikipedia.org. (n.d.). wikiperia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Interface_segregation_principle

Liskov´s Substitution principle

What this principle states is that “in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of that program”. The principle was first introduced by Barbara Liskov.

The principle imposes some requirements that are:

• Contravariance of method arguments in the subtype.

• Covariance of return types in the subtype.

• No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype (wikipedia)

Also I have to say that in the 11th video of the clean code they talk about this principle and say important things like:

• The representative rule: it says that representatives don’t share the relationships of the things they represent.

• Inheritance brings rigidity

• One of the possible solutions in problems with violation to the Liskov´s Substitution principle could be apply the adapter pattern.

Moreover there are some heuristics:

• If the base class do something the derive class must do it too.

• Violation: A derive  function is written to unconditional throws an exception.

• Violation: The presence of “if instance of” statement.

As an example I’m going to reproduce the example showed by Uncle Bob in the video of clean code. The example consists of a program that uses the class rectangle but then there is a new requirement that makes implement the square class, and as all of we know a square is a type of rectangle. But what happens is that sometimes we don’t know what type of object will be returned.

//Violation
class Rectangle
{
protected int width;
protected int height;

public void setWidth(int width){
width = width;
}

public void setHeight(int height){
height = height;
}
public int getWidth(){
return width;
}
public int getHeight(){
return height;
}
public int getArea(){
return width * height;
}
}

class Square extends Rectangle 
{
public void setWidth(int width){
width = width;
height = width;
}
public void setHeight(int height){
width = height;
height = height;
}
}

/*Applying the Liskov´s substitution principle, what we can do is making a class square that does not extend the rectangle class. And we can do that because as Uncle Bob says a square is a type of rectangle but the class rectangle is not a rectangle is a bunch of methods that represents the behavior of a rectangle.*/

class Rectangle
{
protected int m_width;
protected int m_height;

public void setWidth(int width){
m_width = width;
}

public void setHeight(int height){
m_height = height;
}
public int getWidth(){
return m_width;
}
public int getHeight(){
return m_height;
}
public int getArea(){
return m_width * m_height;
}
public int getPerimeter(){
return (2 *m_width ) + (2 * m_height);
}
}

class Square 
{
protected int side;
public void setSide(int side){
side = side;
}
public void getSide(){
return  side;
}
public int getArea(){
return side * side;
}
public int getPerimeter(){
return 4* side;
}
}

Bibliography

wikipedia. (n.d.). wikipedia.org. Retrieved august 11, 2013, from http://en.wikipedia.org/wiki/Liskov_substitution_principle