Chapter 7: One of our favorite state of matter´s principles.

So, we are talking about SOLID in this blog post. No, not our favorite state of matter (that should be plasma, of course) but a group of five principles of object-oriented programming and design. SOLID covers how to program better and cleaner through different principles. I think that these 5 principles come together and forms a “solid” foundation on what and how needs to be done (it took me some days to think of that pun).

The first principle may be pretty straight forward, however, it is often overlooked, leading to the start of some messy code; every class should have exactly one responsibility. While many people avoid following this principle and starts delegating responsibilities to functions inside a class, this can lead to confusion of how a specific class works, and the design of the whole project may start to crumble.

The open/closed principle allows us to make classes ready to be extended if needed, but be closed to modifications, this avoids fragility to the object-oriented code.  I could consider this as using the properties such as inheritance and polymorphism adequately, allowing the extendibility of the base class to fulfill the new requirements without breaking the whole class foundation.

The Liskov Substitution Principle, while similar to the previous principle, it aboard specifically inheritance; to look carefully where an instance of a class is better than inheriting from that class. Sometimes it seems easier to inherit the class and then implement the method, function, or get a value you need; however, it can mess up the code and how the behavior of a class is shaped.

The Interface Segregation Principle covers how it is better to partition an interface into smaller interfaces to avoid making one interface with a lot of responsibilities. Similar to the first principle, this time it is applied to interfaces.

Finally, the Dependency Inversion Principle covers how we can avoid a class dependency by creating an interface of a class and then applying this interface to different classes. This allows class dependency to be interface dependency, avoiding overhead of classes that aren’t needed.

At the end, these SOLID principles can shape up how we can code cleanly and easier, allowing our co-workers (or why not, ourselves) understand thoughtfully our code, permit us expand the use of our code and have a strong foundation in our programs.

 References:

 Guiness Edward (2013). Understanding the SOLID Principles. Available on: http://webcem01.cem.itesm.mx:8005/s201713/tc3049/solid.html

Comments

Post a Comment

Popular posts from this blog

Chapter 4: Architectus Reloadus vs Architectus Oryzus

Image
So, who needs architects anyways? Here lies one of the most important roles in the software world the unstoppable Architectus Reloadus. After reading the article, it reminded me of an image picturing 2 groups of people; each group having either a boss or a leader commanding them. While the boss was just instructing where to go and what to do, the leader was working with its group. This is the same analogy we get in the article with the 2 types of architects mentioned, the  Architectus Reloadus  and the  Architectus Oryzus . Architectus Reloadus  is the architect that proclaims himself as the  most important part of the project , as the design is made only by him, leaving the other developers to follow. While the  Architectus Oryzus  works within the team to improve the team’s level so they can approach harder and more complex issues. In other words, the Architectus Oruzys  is a guide, skillful enough for being the anchor of the team, and clearly selfless, as he works at the
Read more

Chapter 9: Microservice Architecture: A whole new Architectural world.

Image
After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar
Read more

Chapter 11: Metaprogramming

Image
The last article read was “An Introduction to Metaprogramming”, an interesting article where Ariel explains the concept and some examples of metaprogramming. Starting of describing the different types of metaprograms, like compilers, interpreters, parser generators, assemblers and preprocessors, metaprograms come in many shapes and forms, which main goal is to eliminate or reduce error-prone programming tasks. I have heard of this concept as a utopic approach to things, however, I haven’t seen metaprogramming first hand. At first, I thought it was a really complex way to do things, but after reading the article, it doesn’t go that deep into weirdness. Beginning with the first example; it clarified how the concept of metaprogramming works, a script that wrote another file with the code expected. While the ruby snippet shown was not some other world stuff, but the example is pretty clear, we can write codes through code. Now, the second example goes a little bit deeper
Read more