SOLID Principles

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. 

Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. 

The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. 

The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. 

The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. 

The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. 

Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

Comments

Post a Comment

Popular posts from this blog

UML Diagrams

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing. There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components wor
Read more

Expose Your Ignorance

Hello and welcome back to my blog. After presenting what we did in this capstone class, the apprenticeship pattern “Expose Your Ignorance” was brought up and I wanted to check out what this pattern was. The pattern "Expose Your Ignorance" in "Apprenticeship Patterns" by Dave Hoover encourages apprentices to embrace their ignorance and actively seek opportunities for learning and growth. Rather than hiding gaps in knowledge or pretending to know everything, the apprenticeship pattern suggests acknowledging what you don't know and being open about it. Embrace the lack of knowledge and use it as a stepping stone for learning. “Expose Your Ignorance” is about normalizing the learning process. It is about showing your willingness to learn, and acknowledging that the only way to fill gaps in your knowledge is to first admit that these gaps exist. I can use this pattern in many scenarios, such as during team meetings. Instead of pretending to understand a concept, I sh
Read more

YAGNI.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for "Ya ain't gonna need it" or "You aren't gonna need it." My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I've done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time. YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try
Read more