SOLID Principles

Transcript

1. SOLID Principles … and why you should care.
2. 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.
3. 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.
5. 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.
6. 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.
7. 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!
8. 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.
9. 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.
10. 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
11. 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.
12. 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.
13. 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.