SOLID Principles … and why you should care. 

What is S.O.L.I.D. ● SOLID is an acronym that represents five core principles for effective Object Oriented Programming, and is fundamental core knowledge for any developer. ● SOLID principles were defined in the early 2000s by the “God of OOP” Robert C Martin (Uncle Bob) as a way of effective management of dependencies in code. ● It was a chap called Michael Feathers that applied Bob’s principles to the acronym SOLID. 

What is SOLID The SOLID principles are a set of recommendations that help us obtain the following benefits when applied to our code: ● Code is easy to maintain. ● Code is easy to extend. ● Code is robust. 

No content

Single Responsibility Principle (SRP) “A class should have only one reason to change.” ● Or put in a better way, a class should have only one responsibility. A class should do one thing, and do it well. ● Mixed responsibilities are not conducive to change. ● An example would be don’t put HTML or even call a service which renders HTML in a controller. ● Instead, inject a service responsible for rendering output. ● Take this with a pinch of salt, perfect design is often not practical. 

Open Closed Principle (OCP) “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” ● All this means is that a class should be extendable without modifying the class itself. ● Open for extension: new behaviour can be added to satisfy the new requirements. ● Closed for modification: by extending the new behaviour we are not required to modify the existing code. ● Use an interface, interfaces are your friend. Something conforming to an interface makes it simple to code another implementation. 

Liskov Substitution Principle (LSP) “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” ● All this means is every subclass should be substitutable for its parent class. ● if you’re a good developer and have coded to an interface and your class returns a value, then that value type must be consistent. ● For example a repository interface with getResult and the callee expects an array. If you have another implementation that returns an object the callee doesn’t know how to handle it. ● Put another way - any code calling a derived class should be generic and not change per implementation. It should behave in the same way! 

Interface Segregation Principle (ISP) “Many client-specific interfaces are better than one general-purpose interface.” ● A class must not be forced to implement interface methods it does not use. ● Do not implement a FAT interface. ● Implement an interface fit for purpose. ● A FAT interface violates SRP as it indicates the interface is handling more than one responsibility. ● Remember a class can implement multiple interfaces. ● Benefits: decoupled system that is easy to refactor. 

Dependency Inversion Principle (DIP) “High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.” ● This means that a class should not directly depend on another class, but instead on an interface of the class. ● This reduces coupling and makes code more reusable. ● Imagine a logger class as an example, each logger does something different yet they all need to work the same. 

Nice and SOLID articles: https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea 

Keep it Simple, Stupid (K.I.S.S.) ● The simpler your code is, the simpler it will be to maintain in the future. ● Simple code is easy to read by fellow developers. ● This is one of my favourites after writing magical code in the past. 

You aren’t gonna need it (YAGNI) ● This one simply means don’t overthink, or over engineer software. ● Don’t implement functionality you think you might need, only implement what you do need. ● By following SOLID principles it should be easy to add extra functionality later. 

Don’t Repeat Yourself (DRY) “every piece of knowledge must have a single, unambiguous, authoritative representation within a system” - The Pragmatic Programmer. ● Simply try not to duplicate bits of functionality all over the place that can be easily shared. ● By “knowledge” in the quote above they mean business logic. Don’t duplicate any implementation of business logic, e.g. an APR quotation function. ● Take with a pint of salt, don’t try to abstract EVERYTHING into little classes. You’ll end up with an unmaintainable nightmare that is hard to follow.