Design Principles In Software Architecture
This article discusses time-tested and highly-relevant Design Principles which are extensively used in Software Architecture. Numerous Design Principles such as DRY, SOLID, and many more are discussed with their importance and need when implementing software architecture.
Software Architecture
Software Architecture refers to the overall understanding which a seasoned developer has of the system design. It is the core foundational structure of a software system and the discipline with which the structure and the system are built. With proper architecture, decisions about a product and project lifecycle becomes much easier. Making an analogy of Software Architecture with a Tree, the architecture helps us build a strong foundation with branches. Creating features will be synonymous with putting leaves on those branches.
Importance of Software Architecture
Every software which is well-architected will lead to high velocity with time as the result of good quality software. High Quality always wins which we consider a trade-off between quality and cost. In time, properly architected software will pay off the investment in due time as implementing new features can be done in a short span later on.
Design Principles
Design Principles refers to the principles that a designer should abide by while designing their craft. In Regular, Design Principles can be accredited to the rules a designer follows to create an attractive, effective composition by following the fundamental principles of design such as balance, repetition, emphasis, and so on. When we do this for Software Architecture, it is analogous to the visual design element principles but also more on the code, cost, and efficiency of the software to be designed.
Why do we need Design Principles in Software Architecture?
It is a vivid notion to any developer that building software is a hard business. Maintenance and re-changing over iterations of poorly designed software is not an economical task. Moreover, fragile code leads to bugs that can be very costly to fix but carry over to the organizations and businesses in case of any failure or unexpected performance. Thus, changing bad code is extremely hard and a better solution to all these issues would be to design quality software from start. This is where Design Principles come in handy to design efficient, clean, and quality systems.
How does the Code need to be?
The code should be easy to maintain and read. It should be less prone to error thus reducing failure probabilities. The less breakable it is, the better the code. Besides, the code should be more reusable and decoupled.
It is vital to understand that Design Principles are not implementations. Design Principles are not patterns either. The path to achieving the goal of the system is not determined by the principles. It is merely a way to attain a better-quality code. In order to attain a proper software architecture, there are lots of design principles that can come in handy. We’ll learn about a few of them in this article. Some of these are easier concepts to understand and thus great for your junior developers. However, some of these take time and experience to master.
Separation of Concerns (SoC)
In software architecture, Separation of Concerns as the name says is a design principle that suggests separating each distinct section to address different individual concerns. It follows the idea that we don’t need to mix up things that don’t belong together.
Don’t Repeat Yourself (DRY)
Don’t Repeat Yourself is a principle for software development that aims to minimize the repetition of software patterns. It is widely acknowledged that repeating code all over your application is problematic. With the DRY principle, a system can be designed with a single, authoritative and unambiguous representation for every piece of knowledge. The Pragmatic Programmer written by Andy Hunt and Dave Thomas discusses this principle in their book.
You Ain’t Gonna Need It (YAGNI)
You Ain’t Gonna Need It is a principle of software development methodology that states that Functionalities shouldn’t be added unless it is deemed necessary. We shouldn’t and don’t need to add complexity that we may not need.
To learn more about Design Principles and Patterns, Watch this video,
Keep it Simple Stupid (KISS)
This Principle has quite many variations in the title name, “Keep it Simple, Stupid”, “Keep it simple, silly”, “Keep it short and simple”, “Keep it Sweet and Simple”, “Keep it Simple, Soldier”, “Keep it Simple, Sailor” — all meaning the same thing. As said by 15th Century genius, Leonardo Da Vinci, “Simplicity is the Ultimate Sophistication” that even Steve Jobs lived by, the best design if often a simple design and this principle states that most systems would work best if they are kept simple instead of complicated.
SOLID — Principles of Object-Oriented and Agile Design
As quoted by Robert “Uncle Bob” Martin, “Poor dependency management leads to code that is hard to change, fragile and non-reusable”. On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. The SOLID is a mnemonic acronym for design principles which consists of 5 key principles dedicated to making software designs flexible, maintainable, and flexible.
Single Responsibility Principle (SRP)
As per the SRP, a class should have one, and only one reason for the change. In other words, there should only be one responsible for any class.
Open — Closed Principle
According to the Open-Closed Principle, software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that entities can allow extension for their behavior without the source code being modified.
Liskov Substitution Principle
The Liskov Substitution Principle states that the functions must be able to use objects of derived classes that use pointer and references to base classes, without explicit declaration.
Interface Segregation Principle
The Interface Segregation Principle states that the Clients should not be forced to depend upon interfaces that they don’t use. The client-specific interfaces and often a lot better than the interface which are designed for general purpose.
Read the full article in C# Corner:
