Can’t seem to understand SOLID principles and design patterns [closed]

by

I’ve taken a class in college that spent two weeks around design patters, and read the Gang of Four book to no avail. Understanding what each pattern served for and how to use them to fit my problems was very hard for me, a developer that didn’t have much experience in OO programming.

The book that really made it click for me was Head First Design Patterns. It starts by showing a problem, different approaches the developers considered, and then how they ended up using a design pattern in order to fix it. It uses a very simple language and keeps the book very engaging.

Design patterns end up being a way to describe a solution, but you don’t have to adapt your classes to the solution. Think of them more as a guide that suggest a good solution to a wide array of problems.

Let’s talk about SOLID:

  1. 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.
  2. 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.
  3. 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”.
  4. Interface segregation principle. 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.
  5. Dependency inversion principle. Objects should not instantiate their dependencies, but they should be passed to them. For example, a Car that has an Engine object inside should not do engine = new DieselEngine(), but rather said engine should be passed to it on the constructor. This way the car class will not be coupled to the DieselEngine class.

More Related Contents:

  1. Interface Segregation Principle- Program to an interface
  2. Does the Single Responsibility Principle work in OOP?
  3. In SOLID, what is the distinction between SRP and ISP? (Single Responsibility Principle and Interface Segregation Principle)
  4. What is an example of the Liskov Substitution Principle?
  5. Examples of GoF Design Patterns in Java’s core libraries
  6. What is Inversion of Control?
  7. What does “program to interfaces, not implementations” mean?
  8. Does functional programming replace GoF design patterns?
  9. Where do I use delegates? [closed]
  10. What is the dependency inversion principle and why is it important?
  11. What is the scope of the Single Responsibility Principle? [closed]
  12. What is the meaning and reasoning behind the Open/Closed Principle?
  13. What is an example of the Single Responsibility Principle? [closed]
  14. Are there any rules for OOP?
  15. Mediator Vs Observer Object-Oriented Design Patterns
  16. What is composition as it relates to object oriented design?
  17. Differences between Proxy and Decorator Pattern
  18. adapter-Any real example of Adapter Pattern [closed]
  19. Learning/Implementing Design Patterns (For Newbies) [closed]
  20. Switch statements are bad? [closed]
  21. Writing PHP functions that has many parameters/modifiers [closed]
  22. Why would I want to use Interfaces? [closed]
  23. What is the difference between an abstract method and a virtual method?
  24. Can you create instance properties dynamically in PHP?
  25. R and object oriented programming
  26. is it possible to call overridden method from parent struct in Golang?
  27. Why encapsulation is an important feature of OOP languages? [closed]
  28. A way of casting a base type to a derived type
  29. Mixin vs inheritance
  30. Coupling, Cohesion and the Law of Demeter

Leave a Comment