SOLID Design Principles

These are agile, class level design principles. They allow you to minimize coupling and maximize cohesion. The result is code that is easy to read and maintain.

• Single Responsibility Principle (SRP)

• Open/Closed Principle (OCP)

• Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

What are software design principles?

• guidelines

• less prescriptive than design patterns

• not a replacement for thinking critically about code

Module A

Module B

High Coupling, Low Cohesion

Module A

Module B

Low Coupling, Low Cohesion

Module A

Module B

High Coupling, High Cohesion

Module A

Module B

Low Coupling, High Cohesion

Orthogonality

Two or more modules are orthogonal if

changes in one do not affect the other.

• When components are highly interdependent, there is no such thing as a quick, local fix.
   

• Orthogonal software provides increased productivity and decreased risk because developers never have to worry about side-effects of making changes.
   

• Orthogonal components are easier to swap meaning less dependence on a specific library or vendor.

Law of Demeter

• Object A can call a method of object B but should not "reach through" B to acquire a reference to object C.
• A method m of class A may only invoke methods on:
  1. A itself
  2. m's parameters
  3. objects instantiated within m
  4. A's direct instance objects
  5. a global variable, accessible by A, in the scope of m

Since objects are less dependent on the internal structure of other objects, classes can be changed without reworking their callers.

Law of Demeter

SOLID 

Each class or module should have only one responsibility, and thus, one reason to change.

• Why this principle? It provides guidance around how large to make classes/modules.

• Large classes tend to be incohesive.

• The single responsibility should be entirely encapsulated by its class. 

• Bottom line: make classes small enough to maximize cohesion, but large enough to minimize coupling.

Single Responsibility Principle (SRP)

public class BlenderToaster 
{
	String toasterModel, blenderModel;
	int toastFactor, blendFactor;
	
	public void blend()
	{
		System.out.println(blenderModel + 
                " blending with a factor of " + blendFactor);
	}
	
	public void toast()
	{
		System.out.println(toasterModel + 
                " toasting with a factor of " + toastFactor);
	}
}

This class is trying to do too much.

A Violation of the SRP

SOLID

• Why this principle? It provides guidance around how to make your software maintainable.
• You should be able to add new features to an existing system without modifying preexisting code.
• The concepts for "extension" are language specific, for example subclasses, extension methods, or categories.
• Bottom line: implementation of new functionality should not require modification of existing functionality.

Open/Closed Principle (OCP)

Software entities should be open for extension,

but closed for modification.

A Real World Example

• What is closed for modification?
  • Layout (The autolayout system figures out where the textfield should be positioned)
  • Lifecycle (There is an entire system for figuring when to destroy and recreate the view)
• What is open for extension?
  • Pretty much everything related to how the screen is drawn.

UI components in iOS are an excellent implementation of this principle. 

SOLID

Routines that use objects of parent classes must be able to use objects of subclasses without altering the correctness of the program.

Liskov Substitution Principle (LSP)

• Why this principle? It provides guidance around how to correctly use inheritance.
• Inheritance facilitates an "is-a-kind-of" relationship. Make sure that your subclass really is-a-kind-of its parent.
• Bottom line: A subclass may or may not accept more input and provide more functionality than its parent, but it must accept and provide as much as its parent.

public class Circle extends Rectangle
{
        double radius;    
    
	public Square(double r, Point c)
	{
                radius = r;
		super(r * [Math.pi/2], r * [Math.pi/2], p);
	}
}

The Circle class seems to be cleverly reusing some of Rectangle's functionality, but the calculateCorners method will return results that don't make sense.

public class Rectangle
{
	double width, length;
	Point center;

	public Rectangle(double w, double l, Point c)
	{
		width = w;
		length = l;
                center = c;
	}
	
	public int calculateArea()
	{
		return width * length;
	}

        public Point[] calculateCorners()
	{
                Point[] edges;
		// do some calculations here
                return edges;
	}
}

A Violation of the LSP

SOLID

No client should be forced to depend on methods it does not use.

Interface Segregation Principle (ISP)

• Why this principle? It provides guidance around how large to make interfaces.
• Multiple client specific interfaces are better than one general purpose interface.
• Keep interfaces segregated by behavior.
• Bottom line: make interfaces large enough to handle specific client use cases, but no larger.

Interface-based design:

• The foundation of APIs
• Design from the outside in
• Write the interfaces first
• Practice TDD

Interface Segregation Principle