The benefits of learning how to write reusable SOLID code

You don’t need to be a professional programmer to benefit from learning how to code!

Everyone knows how to write, but not everyone becomes a professional writer. Writing is a tool for communicating and expressing thoughts and ideas, just as programming is a tool for solving problems. You may not wish to become a full-time programmer but learning basic coding principles can help designers solve some of the design challenges they face every day. It can become another tool in your design toolbox.

If you are new to coding, I would imagine you are spending your time trying your best just to get something to work. There comes a time when you have a strong enough grasp of the core concepts, and you start to find solving problems less of a difficult task, however I urge you to think long term, and not to simply create a code that will give you a one-time fix.

At times like this it is important to step back and examine how you code. Writing your code to be modular, maintainable and concise are important skills to learn alongside solving problems. Mastering this will mean that you will have a backlog of little solutions which you can start plugging together instead of having to re-write and digest a monolithic totem of code. And it makes understanding and reading the code much easier for you and your colleagues. Think about if someone else needs to read your code, will they understand it?

When it comes to coding, we need SOLID thinking

Robert C. Martin is widely known as one of the leading global authorities when it comes to software design patterns and most famously known for the SOLID principles.

The SOLID principles are guidelines to follow when building software so that it is easier to scale and maintain.

These concepts can be fairly in-depth, but I will present them here in a short and concise fashion. It is well worth a read in more depth as these overarching rules form some of the most important best practices when it comes to writing good code.

S – Single-responsibility Principle
O – Open-closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

Single-responsibility Principle

When you write a method or function, the focus should be that it has a single responsibility while making it as generic and reusable as sensibly possible so that it can be put in many circumstances without needing code hacks to make it work. If it performs more than one task, it should be separated into two independent functions.

Open-closed Principle

If you are finding that you have a method where you are writing a number of if / else statements to choose different cases, you might be breaching this principle. Let’s consider solving the area of a shape. The solution to this is different if you are comparing the area of a circle to that of a square. Instead of having a method which takes a shape and uses an if /else to determine what algorithm is required, it may make more sense to create a base shape class which requires an implementation of area, and for each different shape type you make entire the correct calculation of area to it. Meaning you can just make a shape and tell it to give you its own area.

Liskov Substitution Principle

Every subclass or derived class should be substitutable by their root or parent class. Understanding this requires a level of understanding of inheritance. An example might be looking at our shape class which defines the basics of a shape, and a circle and square as derivatives of a shape but have their own implementations of area. What those area methods return should be of the same data type, an integer value or a floating-point value for example. If they remain consistent you avoid errors where you have requested an integer but receive a floating-point value instead.

Interface Segregation Principle

You shouldn’t be forced to implement an interface or method that you don’t use. Stick to a basic theme, for example a 3D shape might require a volume calculation, however a 2D one may not. A circle and square shape should not have to implement the volume method but if you were to make a 3D shape interface which contains the requirement to have a volume, you can add that to any other class you see fit without forcing implementation of methods you don’t require.

Dependency Inversion Principle

Entities should be decoupled from each other. By making things more abstract you can achieve this. A simple example of this might be considering a database, there are many types of database out there but if you create an interface which describes the core requirements for a database you should theoretically be able to give any database to this entity in order to save and store data.

These SOLID principles are a philosophy rather than a piece of software, created to make coding more modular and reusable. Some of these principles may look similar but they are not targeting the same goal. It is possible to satisfy one principle while violating the other, even though they are alike.

SOLID is a good grounding upon which to begin, without these principles it will be difficult for others to understand, maintain and update at a later stage.

Implementing the SOLID principles may feel overwhelming at first, however regularly working with them and understanding the differences between code that complies with the principles and code that does not will help to make good design processes easier and more efficient.

 

At BIM Academy, all of our software development projects utilise these principles; if you would like to know more about effective and efficient coding practices, contact Lee Maguire at [email protected].