SOLID Design Principles

SOLID is a subcategory of five principles, the first being:

Single Responsibility Principle (SRP)

SRP states that a class, module, or function should only have a singular function.

For example, having a class ‘Animal’ with methods ‘displayAnimalName()’, ‘animalSound()’, ‘feedAnimal()’ would be a violation of SRP because each method has a different function. Creating three separate classes that would each represent a functionality resolves the violation. This entails new classes are created for DisplayName, Sound, and Feeding. Although this may lead to more code overall, having separate classes allows for better maintainability. Without SRP, making changes to one functionality may break another.

Open-Closed Principle (OCP)

OCP states that code should be open for extension, but closed for modification. Therefore the code’s behavior should be extended by adding more code rather than modifying the existing code.

Function ‘getArea()’ calculates the area of a shape using a switch statement where there are cases for a square and circle. To add another shape, the switch statement must be modified to add a case for the new shape, violating OCP. To satisfy OCP, one would create separate classes for each shape that implements the Area interface. Now to add a new shape, one would add a new class and implement the Area interface rather than modify the original switch statement.

Liskov Substitution Principle (LSP)

LSP states that child class objects must be substitutable with objects of the parent class without affecting the correctness of the code.

Imagine a parent class ‘Bird’ with method ‘fly()’, and child classes ‘Penguin’ and ‘Eagle’. Both inherit ‘fly()’ because ‘Penguin’ and ‘Eagle’ are child classes of ‘Bird’. Because penguins cannot fly, the ‘fly()’ method in ‘Penguin’ has been overridden to do nothing. Doing this would violate LSP because objects of ‘Penguin’ would not be substitutable for objects of ‘Bird’.

Interface Segregation Principle (ISP)

ISP states that users should not be forced to implement interfaces they will not use.

Imagine an interface ‘Worker’ that has methods ‘work()’ and ‘eatOfficeLunch()’. Classes ‘FieldWorker’ and ‘OfficeWorker’ both implement the ‘Worker’ interface. Because ‘FieldWorker’ does not eat in office, the method ‘eatOfficeLunch()’ is unnecessary. This violates ISP because ‘FieldWorker’ is forced to implement ‘eatOfficeLunch()’ although the method will not be used.

Dependency Inversion Principle (DIP)

DIP states that high-level modules should not depend on low-level modules, keeping that as separate as possible.

For example, there’s a project with high-level systems (backend logic), that relies on low-level modules (database access). However the project’s team wants to change the database from one type to a different. Because the high-level systems are specifically written and depend on the database type, they would no longer work once the database type changes. Having high-level systems be more abstract and able to be implemented in different ways is ideal.

Conclusion

The article used was chosen because it gave examples with code, making understanding easy. As someone who wishes to have a career in software development, knowing the best practices for designing maintainable code is crucial. I expect to apply these principles to all future projects.

Resources:

https://www.freecodecamp.org/news/solid-design-principles-in-software-development/

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

In the intricate world of software development, as developers strive to create elegant and efficient solutions, they encounter not only best practices but also pitfalls to avoid. These pitfalls, often referred to as anti-patterns, are common design and coding practices that may initially seem like solutions but ultimately lead to more problems than they solve. Understanding and recognizing these anti-patterns is a crucial part of becoming a seasoned software developer.

At its core, an anti-pattern is a recurring design or coding practice that appears to be helpful but is counterproductive in the long run. It’s like a mirage in the desert – promising relief but ultimately leaving you more parched. Anti-patterns often arise from misapplications of well-intentioned ideas or a lack of experience in software development.

One common anti-pattern is known as “Spaghetti Code,” where the codebase becomes entangled and challenging to maintain. While quick fixes and shortcuts may seem like a solution, they often lead to a tangled mess that hampers productivity.

Another notorious anti-pattern is “Cargo Cult Programming,” where developers mimic code without understanding its purpose. This blind imitation can lead to code that lacks context and may introduce errors.

By studying anti-patterns, developers can proactively identify and avoid these pitfalls. It’s akin to recognizing warning signs on the road and taking detours to smoother coding practices. In the ever-evolving landscape of software development, understanding what not to do is as important as knowing what to do. Recognizing anti-patterns empowers developers to make informed decisions and craft robust and maintainable software solutions.

References:

• Anti-patterns
• Design Patterns and Anti-patterns
• Common Anti-Patterns in Software Development

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.