-
Notifications
You must be signed in to change notification settings - Fork 1
Software Design Principles
The SOLID principles are not rules. They are not laws. They are not perfect truths. These are statements on the order of ‘An apple a day keeps the doctor away.’ This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.
Classes are one of the most fundamental building blocks of modern application development and the foundation of object-oriented design (OOD). Classes consist of both state, exposed through fields and properties, and logic, exposed through methods. Applications that adhere to the single responsibility principle consist of many small classes, each of which have only one responsibility or reason to change, that are used collectively to build higher-level features. Having more, smaller, focused classes makes applications easier to maintain and test.
When a developer makes a change to an existing codebase, there’s always a risk of introducing new bugs. This isn’t a criticism of the developer’s abilities but merely a reality of software development. As an application continues to grow, the possibility of inadvertently introducing unexpected behavior increases with even the most minor change. The open/closed principle attempts to mitigate this side effect by favoring extension of existing software entities over modification. This principle encourages developers to treat extensibility as a first-class citizen and isolate areas of probable change when writing code. When combined with judicious test coverage and continuous integration, the open/closed principle can significantly increase overall application stability and enable shorter release cycles by reducing the need for extensive regression testing. The goal of the open/closed principle is not to prevent changes completely but to limit them by emphasizing the importance of extensibility.
The main idea here is that subclasses maintain the correctness of the contract defined by the parent class. This means that subclasses shouldn’t override a method that does one thing to do something completely different. Code that uses the superclass should be able to use the subclass and not know the difference. Microservices don’t really have the notion of inheritance, but the idea is still applicable here. If I decide to completely replace the implementation of a service, the API should be maintained. That is, other applications shouldn’t know or care that the service has been written or rewritten in Java, Node.js or C#. One implementation can be transparently substituted for the other.
TODO: Write Paragraph on how it applies to cloud native and microservices
TODO: Write Paragraph on how it applies to cloud native and microservices
“Keep It Simple, Stupid!” – I would add some extra exclamation marks (!!!!) to try to keep this in your mind. The simpler your code is, the simpler it will be to maintain it in the future, and of course, if other people see it, they will thank you for that. The KISS principle was coined by Kelly Johnson, and it states that most systems work best if they are kept simple rather than making them complex; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. My advice is to avoid using fancy features from the programming language you’re working with only because the language lets you use them. This is not to say that you should not use those features, but use them only when there are perceptible benefits to the problem you’re solving. With this premise, From https://itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life
Don’t Repeat Yourself – How many times do you see that there are similar codes, in different parts of a system. Well, this principle is formulated by Andrew Hunt and David Thomas in their book The Pragmatic Programmer that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In other words, you must try to maintain the behavior of a functionality of the system in a single piece of code. In the other hand, when the DRY principle is violated it is called as WET solutions, which is stand for either Write Everything Twice or We Enjoy Typing. I know this principle is very useful, especially in big applications where they are constantly maintained, changed and extended by a lot of programmers. But you also should not abuse of DRYing all things you do, remember the first two principles KISS and YAGNI, in first place. From https://itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life
“You Aren’t Gonna Need It” – Sometimes, as developers, we try to think a lot in the future of the project coding some extra features “just in case we need them” or “we will eventually need them”. Just one word… Wrong! I’ll repeat it this way: You didn’t need it, you don’t need it and in most of the cases… “You Aren’t Gonna Need It”. YAGNI is a principle behind the extreme programming (XP) practice of “Do the Simplest Thing That Could Possibly Work”. Even when this principle is part of XP, it is applicable in all kind of methodologies and own processes of development. When you feel an unexplained anxiety to code some extra features that in the moment are not necessary but you think they will be useful in the future, just calm down and see all the pending work you have at this moment. You can’t waste time coding those features that maybe you will need to correct or change because they do not fit to what is needed, or in the worst scenario, they will not be used. From https://itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life
A key principle of software development and architecture is the notion of separation of concerns. At a low level, this principle is closely related to the Single Responsibility Principle of object oriented programming. The general idea is that one should avoid co-locating different concerns within the design or code. For instance, if your application includes business logic for identifying certain noteworthy items to display to the user, and your application formats such items in a certain way to make them more noticeable, it would violate separation of concerns if both the logic for determining which items were noteworthy and the formatting of these items were in the same place. The design would be more maintainable, less tightly coupled, and less likely to violate the Don’t Repeat Yourself principle if the logic for determining which items needed formatted were located in a single location (with other business logic), and were exposed to the user interface code responsible for formatting simply as a property.