Skip to main content

Understanding the SOLID principles


On today’s blog we are going to talk about the SOLID principles, which were discovered by Robert Martin, the famous Uncle Bob from the podcast of the previous entry. This principles are recommended to be used whenever someone wants to create an object oriented program. There are 5 principles where the acronym SOLID comes from which are the following
  • Single Responsibility Principle (SRP) -> it says that any class should only have one responsibility. Yet, the author ends up saying that there might be some classes that have two responsibilities (the invoicing class that has some logging routines). In the end, I didn’t understand this principle well because I found the explanation confusing (as the author said, practice is much more difficult than theory). 

  • Open/Closed Principle (OPC) -> open extension but closed modification Although the author says that if you change a parent class method it might kill another part of the code, I think that this would only reflect your lack of knowledge of your own code, and we should have the capacity of modifying our own code.

  • Liskov Substitution Principle (LSP) -> avoiding inheritance, as we have seen before, is actually a really useful advice. I think that we should try to use composition as much as we can.

  •  Interface Segregation Principle (ISP) -> I had never heard about this principle before, which describes that instead of having a huge interface that has many different methods, we should create a bunch of small interfaces. I find this principle pretty useful, because it is easier to refactor a small and well-organized code.

  • Dependency Inversion Principle (DIP) -> this last principle says that we should code base on abstractions, rather than coding based on concrete objects. I think this is also a great advice. If we code thinking that our objects might changes, and that they should look like this, instead of being like this, it would be easier to modify them and to adapt the future.

Comments

Popular posts from this blog

Who needs an archiect?

I n this blog entry we are going to talk about an article written by Martin Flowers entitled, “Who needs an architect”, were it talks about software architecture (kind of obvious don’t you think) and the architect's role in a software development team. To be honest, a didn’t get the author’s purpose of the article, but I think I have got the general idea, so I can review this properly. On the article the author gives many two explanations the software architecture, one of them is quoted by someone else which basically says that a high level concept of a system is only visible (or significant) to developers, now, for me this is really abstract, because I don’t thing it applies to all the projects of this topic, but the second one which is given by the author himself says that the architecture is a a shared understanding of the system design by all of the expert developers involved in the Project, now this makes more sense to me because we can understand that not only the d...

Ethical Reflection on Ready Player One

Todays blog is the last one!!!!!! It has been quite a journey, but as everything, its time to end this. On today’s blog we are going to talk about a book, Ready Player One, written by Ernest Cline, this is the book that everyone in my class has been reading during the semester, and it was really, really good, I actually enjoyed it a lot. The plot is quite simple, it talks about a kid called Wade Watts, in a world were the actual real world is kind of a huge disaster for not saying other words, but in the book exist another world, a virtual one called the Oasis, were technically everyone plays it, because it was a whole new world, not only a videogame, in there people can have jobs, meet people, study in schools. The creator of the Oasis was James Halliday, and I say was because in the book he is dead, and after his dead he created 3 easter eggs that, when a player has the three, that player will own the oasis, and be the richest person in the world, and that is the goal of our dear...

The 4+1 View Model

On today’s blog we are going to talk about the 4+1 view model, which all of this was taken from two videos. This model says that, when we are creating software we need to focus on 4 things: The logical view: which is the logical design of the software The development view: the way the program interacts between its components The process view: the way the program functions The physical view: the way the software and the hardware interact between each other Now to explain more these 4 things, the logical view refers on what are we going to build, not the actual code, but the design and logic it will have, a good example of it is a class diagram.   The development view refers on how the program is organized and how it communicates between its own parts, the component may be a good example of this because it shows exactly that, how is organized and how it communicates to work. The one that refers on how the program works is the process view, it...