Solid Principles

SOLID Princples

SOLID is a acronym for 5 important design principles when doing OOP (Object Oriented Programming).

This was conceptualised by Michael Feathers. The intention of these principles is to make software designs more understandable, easier to maintain and easier to extend.

There are some principles, These are:

S - Single Responsibility Principle (SRP)
O - Open Closed Principle (OCP)
L - Liskov Subtitution Principle (LSP)
I - Interface Segregation Principle (ISP)
D - Dependancy Inversion Principle (DIP)

All of them are broadly used worth knowing.

Single Responsibility Principle (SRP)

"A class should have one, and only one reason to change" - Robert C. Martin.

The Single Responsibility Principle makes your software easier to implement and prevents unexpected side-effects of future changes.

An Example of how the SRP works in JavaScript - Lets say we have some shapes and we wanted to sum all the areas of the shapes. Well this is pretty simple right?


							const areaCalculator = (s) => {
	const proto = {
		sum() {
			// logic to sum
	},
	output() {
		return
	<-h1->
	Sum of the areas of provided shapes:
		${this.sum()}
	<-/h1->
	}
	}
	return

	Object.assign(Object.create(proto),
	{shapes: s})
}

// using the areaCalculator factory function below
// an array of shapes are passed in and display 
the output at the bottom of the page

const shapes = [
	circle(2),
	square(5),
	square(6)
]

const areas = areaCalculator(shapes)
console.log(areas.output())

The problem with the output method is that the areaCalculator handles the logic to output the data. Therefore, what if the user wanted to output the data as json or something else?

All of the logic would be handled by the areaCalculator factory function - This is what the SRP frowns against. The function should only sum the areas of provided shapes. To fix, we need to create another function to handle the logic needed to sum areas of all provided shapes:


const shapes = [
	circle(2),
	square(5),
	square(6)
]

const areas = areaCalculator(shapes)
const output = sumCalculatorOutputter(areas)

console.log(output.JSON())
console.log(output.HAML())
console.log(output.HTML())
console.log(output.JADE())

Now whatever logic you need to output the data to the users is now handled by the sumCalculatorOutputter factory function.

The single responsibility principle is one of the most commonly used design principles in OOP. You can apply it to classes, software components, and microservices.

To follow this principle, your class isn't allowed to have more than one responsibility, e.g. the management of entities or the conversion of data types. This avoids any unnecessary, technical coupling between responsibilities and reduces the probability that you need to change your class. It also lowers the complexity of each change because it reduces the number of dependant classes that are affected by it.

Open Closed Principle (OCP)

"Objects or entities should be open for extension, but closed for modification"

With this principle, we should be able to to add new features or components to the application without breaking existing code.

Let's look at the areaCalculator factory function, especially it's sum method:


							sum() {
	
const area = []

for(shape of this.shapes) {

	if(shape.type === 'Square') {

		area.push(Math.pow(shape.length, 2))

    } else if (shape.type === 'Circle') {

    	area.push(Math.PI * Math.Pow(shape.length, 2))

	}
}

return area.reduce((v, c) => c += v, 0)
}

If we wanteed the sum method to be able to sum areas of more shapes, we would have to add more if/else blocks and that goes against the OCP. A way we can make this sum method better is to remove the logic to calculate the area of each shape out of the sum method and attach it to the shape's factory functions:


							const square = (length) => {
	const proto = {
		type: 'Square',
		area() {
		   return Math.pow(this.length, 2)
		}
	}
	return

	Object.assign(Object.create(proto), {length})
}

// The same thing should be done for the circle
 factory function, an area method should be added.
// Now to calculate the sum of any shape 
provided should be as simple as:

sum() {
	const area = []
	for (shape of this.shapes) {
		area.push(shape.area())
	}
	return area.reduce((v, c) => c += v, 0)
}

We can now create another shape class and pass it in when calculating the sum without breaking our code. However, how do we know hat the object passed into the areaCalculator is actually a shape or if the shape has a method named area? To solve this we would need to create an interface, that every shape implements. JS, however does not have interfaces. Using TypeScript with closeures and function composition along with interfaces can achieve the solution, but to keep this already growing page short, I will not include the solution here.

Liskov Substitution Princple (LSP)

"Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T."

This means that a subclass should override the parent class methods in a way that does not break functionality from a client's point of view

Say, we have a volumeCalculator factory function that extends the areaCalculator factory funcation, and in our case for extending an object without breaking changes in ES6 we do it by using Object.assign() and the Object.getPrototypeOf():


							const volumeCalculator = (s) => {
  const proto = {
    type: 'volumeCalculator'
  }
  const areaCalProto =
  Object.getPrototypeOf(areaCalculator())
  const inherit = 
  Object.assign({}, areaCalProto, proto)
	return
  Object.assign(Object.create(inherit), {shapes: s})
}

Object.assign() for inherit is extended by shapes.

This helps to not break functionality from a client's point of view.

Interface Segregation Principle (ISP)

"A client should never be forced to implement an interface that is doesn't use or clients shouldn't be forced to depend on methods they do not use."

We want to calculate the volume of the shapes we get, we can add another contract to the shapeInterface:

An Example of how the Interface Segregation Principle works - Here is the given code:


							const shapeInterface = (state) =>
({
	type: 'shapeInterface',
	area: () => state.area(state),
	volume: () =>

	state.volume(state)
})

Any shape we create must implement the volume method, but we know that squares are flat shapes and that they do not have volumes, so this interface would force the square factory function to implement a method that it has no use of.

The ISP says no to this, instead you could create another interface called "solidShapeInterface" that has the volume contract and solid shapes like cubes, etc. can implement this interface:


							const shapeInterface = (state) =>
({
	type: 'shapeInterface',
	area: () => state.area(state),
})

const solidShapeInterface = (state) =>
({
	type: 'solidShapeInterface',
	volume: () =>
	state.volume(state)
})

const cubo = (length) => {
	const proto = {
		length,
		type   : 'Cubo',
		area   : (args) =>
		Math.pow(args.length, 2),
		volume : (args) => 
		Math.pow(args.length, 3)
	}
	const basics = 
	shapeInterface(proto)
	const complex = solidShapeInterface(proto)
	const composite = Object.assign({}, 
	basics, complex)
		return
	Object.assign(Object.create(composite), 
	{length})
}

This is a much better approach, but a pitfull to watch out for is when to calculate the sum for the shape, instead of using the shapeInterface or a solidShapeInterface.

You could create another interface, maybe manageShapeInterface, and implement it on both the flat and solid shapes, this is why you can easily se that it has a single API for managing the shapes.

Using higher order functions to achieve abstractions helps in doing this principle.

Dependancy Inversion Principle (DIP)

"Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions."

As a dynamic language, JS doesn't require the use of abstractions to facilitate decoupling. Therefore, the stipulation that abstractions shouldn't depend upon details isn't particularly relevant to JS applications. The stipulation that high level modules shouldn't depend upon low level modules is, however relevant.

Let's review our code with the manageShapeInterface and how we accomplish the calculate method:


							const manageShapeInterface = (fn) => 
({
	type: 'manageShapeInterface',
	calculate: () => fn()
})

What the manageShapeInterface factory function receives as the argument is a higher order function, that decouples for every shape the functionality to accomplish the needed logic to get to final calculation, lets see how this is done in the shapes objects.


							const square = (radius) => {
	// code

	const abstraction = 
	manageShapeInterface(() =>
	basics.area())

	// more code ...

}

const cubo = (length) => {
	// code

	const abstraction  = 
	manageShapeInterface(
		() => basics.area() + complex.volume()
	)

	// more code ...

}

For the square what we need to calculate is just getting the area of the shape, and for a cubo, what we need is summing the area with the volume and that is everything needed to avoid the coupling and get the abstration.

The Dependancy Inversion Principle (DIP) is very much needed in non-dynamic programming languages such as Java and c#. The abstractions should not depend upon details.

These are the principles of SOLID.

SOLID Principles (Concepts)