The SOLID principles

When you are planning and coding your projects within Unity as an Object-Oriented Programming (OOP) practitioner—programming that is based on objects containing data—patterns are a great way of making things uniform, saving time, and, hopefully, relating to other programmers who share the same patterns with you.

However, you won't always have a design pattern for all of your projects and it may not be practical to try and force plans that simply aren't practical. If we brush the design patterns to one side, there is an even deeper methodology to programming—your SOLID principles. These principles are guidelines that remind OOP programmers of what you should be thinking about when coding your projects. They outline what you should and shouldn't be doing with your code. Yes, you could ignore SOLID principles, and even ignore design patterns, but difficulties will occur and increase the risk of you coding yourself into a dead end and creating multiple errors when you change a single line of code. You'll have colleagues scratching their heads not knowing what your code is doing, as well as inefficient classes and methods that potentially slow down your system—the list goes on. It's very easy to notfollow a plan and be keen to just get the job done. Eventually, this will haunt you and you will have to accept that you need a plan and you need to follow rules, especially if your project expands, even if it's just you coding the project.

The five SOLID principles are as follows:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Let's look at each one in more detail, starting with the "S" in SOLID—the single responsibility principle.

Single responsibility principle

A class should only have a single purpose, changes to the class should be specific to affect the specification of the class alone.

This means that we should keep classes simple and not give our classes multiple roles. If we have a class that handles bullets, don't let any extra features fall into it; save them for another class. A common problem that programmers come across is making a class that constantly grows and mutates. This will eventually create problems and typically results in refactoring code, especially if you want to add something specific to your class, which can have an effect on the other properties tied to it.

Let's now move onto the "O" in SOLID—the open/closed principle.

Open/closed principle

Scripting should be open to being extended but closed for modification.

Create a class that supports extra work applied to it without having to constantly revisit and modify your original class. For example, if I had a spaceship that fires a bullet and I wanted to add different types of weapons, I want to avoid adding any more to the original script. If I wanted to add 50 weapons, my original script would simply keep growing to an unwieldy size. Ideally, this weapon script should be able to receive an extension that can swap out what weapon is fired, so even if I had 50 weapons, the script wouldn't need to change; it would just swap out the weapon from the extension. Something such as an interface (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/interface) or an abstract class(https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/abstract) that receives the weapon type would work well with this. Also, if the class is encouraged to grow and cater to all these weapons, you will start violating thesingleresponsibilityprinciple.

Let's now move onto the "L" in SOLID—the Liskov substitution principle.

Liskov substitution principle

Content in objects should have the ability to be replaced with an instance of a subtype without altering the base of the object itself.

If a class inherits from another class, the inherited class should be able to access the original base class as if it was the original class. But what does that mean? So, in theory, the child class should be able to be used in the same manner as the parent class.

The main benefit of this is you can have a class with a method containing values that can be overridden for a particular object. For example, if a car is factory-made, its default color when leaving the factory is white. Several of these white cars can be sprayed with different colors even though it is the same car; the color is being overridden by another factory.

By default, a base class could, for example, return a default value, while a child class using the same method could override it for its own. If this principle was ignored, you will likely end up using a lot of if statements to cover each child's class method, which would then involve expanding code, which then violates the two previous principles we spoke about.

Let's now move on to the "I" in SOLID—the interface segregation principle.

Interface segregation principle

Specific interfaces are better than one general interface.

This one is fairly simple—when implementing interfaces, try to keep them light and interchangeable with other classes and methods, as opposed to having one huge interface that will likely be redundant to the specific class you are inheriting from. For example, an interface can contain variables for health points, defense, strength, and so on. If I was going to apply this to a character, this would make sense, but if I also applied it to an apple, it wouldn't so much. However, you would still have to implement them on the apple as it's an interface.

Let's now move on to the "D" in SOLID—the dependency inversion principle.

Dependency inversion principle

Lean on abstractions and not concretions.

Abstract classes can be used to cover a general field of classes, which is ideal for something such as a gun script. You can have multiple different types of guns with different shot powers, bullet counts, and so on. Otherwise, you will rely on the specific gun class, which can then lead to multiple variants and class calls to that specific gun class. Abstraction means that no matter how many gun classes there are, it won't affect other scripts catering for all the variants.

In summary, the SOLID principles encourage you to cut up your code into segments and remove expanding classes. It encourages you to look for other ways of writing your code instead of creating a chain reaction when a new piece of code is written.

So, when it comes to a project, if you ignore the SOLID principles and design patterns, you will survive but you will be creating a mold of what your next project will be like. Eventually, it will turn into a bad habit and it'll become more difficult to retrain yourself. Speaking of projects, let's check out the game design brief for the game we are going to make—Killer Wave!