Understanding the SOLID Principles


Hi, this entry is going to talk about a section called “Understanding the SOLID principles” from the book “Ace the Programming Interview: 160 Questions and Answers for Success” by Wiley in 2013. Basically, the acronym SOLID is explained a round this book section. This acronym stands for five accepted principles about object-oriented programming and design:

1.     Single Responsibility Principle: It stays that a class should have just one responsibility. Despite the fact that this principle sounds easy, I found it a little bit complicated, because the explanation wasn’t direct and simplified. Also, the author mentioned that there might be cases in which a class might have two responsibilities. So, at the end, what exactly does this principle stands for?

2.     Open/Closed Principle: It stays that a class or a function should be open for extension but closed for modification. What does this mean? Our code must have the capability of being extended, but we have to always avoid modifying an existing method or class. I understand this principle, but I think that there could be situations in which modifying the code will result much simpler that extending it. Since its our code, we have to know what exactly does modifying it will affect other sections and be able to correct it, but also extending is fine to avoid that.

3.     Liskov Substitution Principle: It is intended to keep a happy working relationship between classes and functions alive and well. What is “happy working relationship”? An example is passing a new class to an existing function written to work with a base class, so that function will work as if you passed a base class’s instance. This principle is very clear, as the author said, we should avoid inheritance and instead use composition.

4.     Interface Segregation Principle: It stands that to avoid writing monstrous interfaces with a lot of methods, we should create a collection of smaller interfaces. This one is easy, we will end with a smaller and more organized code

5.     Dependency Inversion Principle: It stays that instead of writing code that refers to actual classes, we should write code referring to interfaces or even abstract classes. Basically, we are writing code easier to modify and with dependency injection. 


I was expecting simpler principles, but after reading them twice, I finally understood them. I think they’re very important for having a well-organized and much better code. We must follow them while doing object-oriented programming.

Comments

Post a Comment

Popular posts from this blog

Hidden Figures

Hi­, today’s entry is going to be about the second movie we watched on this course. This time I’m talking about “Hidden Figures”, an American movie that tells the story of three African-American women that worked for the NASA during the famous space race to first reach the space and safely come back between the USSR and the United States. Those three women are Dorothy, Mary and Katherine, and they were key during the launch of those first betas and successfully trips to space. First of all, as these women were very important employees inside NASA and that had a meaningful contribution to this space race, the fact that I hadn’t heard about them before really surprised me. In those times they were suffering two types of discrimination at the same time, being a woman and being Afro-American. I really liked how they manage to show how key they were in that project to gain respect and equality inside NASA. I think the main message of this movie is to demonstrate the importance of K
Read more

An Introduction to Metaprogramming

Hi, today's entry is going to talk about an article called “An Introduction to Metaprogramming” written by our professor Ariel Ortiz in 2007. First of all, I just want to mention that I’m really impressed because I didn’t know that our professor had many published articles and papers (we saw the others in my other blog for Compilers Design course). Basically, as its name says, it talks about metaprogramming, which is defined during the article as a program that generates other programs or just program parts. It is used to eliminate or just reduce a “tedious” programming task. It is like instead of writing complex machine code programs, we use any high-level language and use the compiler of that language to do the translation into the programs equivalent in machine code (low-level language). I have to admit that before reading this paper, I hadn’t fully understood the metaprogramming meaning and importance. We used and applied that term in a past course called Programming Languages
Read more

Microservices

Hi, today’s entry is going to talk about an article written by James Lewis and Martin Fowler called “Microservices” in 2014. Basically, by calling microservices, they are referring to like a particular way of designing software applications as suites of independently deployable services. But something interesting is that there is not a precise definition of that type of architectural style, there are only common characteristics around distinct organizations, business capability, automated deployment, intelligence in endpoints and also decentralized control of languages and data. This was the first time I heard this term, and something strange is that despite I didn’t notice about its existence I’d used them sometimes. Later in the articles, the authors gave us some characteristics that any Microservice Architecture must have. They are the following: 1.       Componentization via Services:  This is telling us that by building software, we put together components. So, this archite
Read more