Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SOLID Principles

Avatar for Mark Taylor Mark Taylor
September 24, 2018

SOLID Principles

Avatar for Mark Taylor

Mark Taylor

September 24, 2018
Tweet

More Decks by Mark Taylor

Other Decks in Technology

Transcript

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.