Solid principles
- 1. Solid Principles By : Ahmed Saad Khames Backend Lead Developer @ Shopbox https://www.linkedin.com/in/ahmedsaadkhames/
- 2. What’s Solid Principles In object-oriented computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable.
- 3. Single responsibility ● A class should have only one responsibility. ● That means that for example, a Person class should only worry about the domain problem regarding the person itself, and not for example, its persistence in the database. For that, you may want to use a PersonDAO for example. A Person class may want to keep its responsibilities the shortest it can. ● If a class is using too many external dependencies (that is, other classes), that's a symptom that the class is having too many responsibilities. ● This problem often comes when developers try to model the real world using objects and take it too far. Loosely coupled applications often are not very easy to navigate and do not exactly model how the real world works.
- 5. Open Closed ● Classes should be extendible, but not modifiable. ● That means that adding a new field to a class is fine, but changing existing things are not. Other components on the program may depend on said field.
- 6. Liskov substitution ● A class that expects an object of type animal should work if a subclass dog and a subclass cat are passed. ● That means that Animal should NOT have a method called bark for example, since subclasses of type cat won't be able to bark. Classes that use the Animal class, also shouldn't depend on methods that belong to a class Dog. ● Don't do things like "If this animal is a dog, then (casts animal to dog) bark. If animal is a cat then (casts animal to cat) meow".
- 8. Interface segregation ● Keep your interfaces the smallest you can. ● A teacher that also is a student should implement both the IStudent and ITeacher interfaces, instead of a single big interface called IStudentAndTeacher.
- 10. Dependency inversion ● Classes should be extendible, but not modifiable. ● That means that adding a new field to a class is fine, but changing existing things are not. Other components on the program may depend on said field.
- 12. References ● https://en.wikipedia.org/wiki/SOLID ● https://stackoverflow.com/questions/13692126/cant-seem-to-understand-solid-principles-and-design- patterns ● https://www.javabrahman.com/programming-principles/single-responsibility-principle-with-example-in- java/ ● https://www.javabrahman.com/programming-principles/liskov-substitution-principal-java-example/ ● https://www.javabrahman.com/programming-principles/interface-segregation-principle-explained-examples- java/ ● https://www.javabrahman.com/programming-principles/dependency-inversion-principle-example-java/