Having recently spoken about the importance of designing for testability, I thought it would be worth mentioning a few more key design practices that are worth following to help ensure the software produced is of high quality. After all - as I've stated many times before - quality software is not simply about great testing but is best achieved when we design it right from the beginning.
Many of these principles may be common principles we find in programming and software textbooks, but it's amazing how often we tend not to put them into practice and dismissal their value. Yes, there may be more pressure to deliver on promised functionality in our software design, but there is a lot of wisdom in following proper design practices that will have a lasting impact on the quality delivered.
So hopefully, the below principles will serve as a good reminder of practices we need to ensure become standard parts of the way we produce software.
The Goals of Quality Software Design
Firstly, I will start with the goals that are trying to be achieved by these quality design practices. Because if we can understand what we're trying to achieve and why it's important, it will help motivate us to apply them with more rigor in our work.
Even though there are many ways to structure your software applications. To help ensure you are designing your software correctly, it needs to adhere to the following goals:
Correctness
Good software design means building a system characterized by a correct, conflict-free integration of all essential software elements and functionalities. Put simply, we need to build software that does what it says it does, without adding unnecessary complexities and ensure it works with all the eternal models that are required.
Optimal Resource Consumption
Software needs to operate in an efficient manner that utilizes the computing resources efficiently. Software that works well, but taxes processors or utilizes memory too aggressively, is likely to cause a high number of performance issues over time.
Modularity and Scalability
Good software design should be easily scalable and easy to understand long after it has been delivered. It needs to be built according to the famous modularity principle widely used in all fields of engineering, with all modules arranged in layers.
Completeness
Good software design encompasses the necessary software components of modules, data objects, external interfaces, and more. All dependencies between modules and other virtual entities should be harmonized and comply with inheritance principles.
Maintainability
Software needs to not just work once off but needs to be worked on throughout its entire life cycle. Code needs to be maintainable in order for it to be improved, adapted, and maintained easily during this life span.
Testability
I've mentioned this in my last two previous blog posts but will mention it here again. Code needs to be written in such a way that it is easy to test and automate, as this will greatly speed up the testing and regression effort and allow the team to prepare code for continuous integration and deliver quality code more quickly.
Principles to Reaching these goals
So, now we know what we are trying to achieve through quality design practice,s we need to look at the different software design principles that will help us to achieve these goals.
When correctly applied, you can apply the following principles of software design to guarantee that your software product will achieve these goals:
Abstraction
All modern software techniques predominantly involve working with abstractions of various types. Using abstractions means hiding the coding complexities and redundant details behind high-level abstractions and not delving into them until absolutely required. This allows you to decrease irrelevant data, speed up the development process, and improve the general quality of your programming outcomes.
Refinement
This means getting rid of structural impurities by moving from higher levels of software design (abstractions) to lower levels in a step-by-step manner. According to this idea, refinement is an incremental process in which a team of software engineers drills down to acquire more technical details at each increment. In this way, software design is consistently elaborated without wasting time on irrelevant or side matters.
Modularity
Dividing a complex project or system into smaller components helps to better understand and manage the product. It’s difficult to try and build the complexity of an entire system altogether, but if you break it up into small components which each have their own prescribed functionality, then it's significantly easier to ensure each component works well in isolation. And if these modular components can operate independently, even better.
Everything within your software system should be pre-planned and approved with the help of engineering assessment methods. Serious systems flaws must be avoided at the beginning.
Interactions between different system components (e.g., modules and abstractions) should be the focus of architectural efforts—all of which should be seamlessly arranged within a solid software structure. Their interrelationship should be described in detail.
Patterns
Delivering pattern-based solutions is one of the most important techniques that allow software developers to achieve system predictability while saving a great deal of time. This also makes it possible to quickly deal with typical issues and apply pattern-based solutions to fix them in no time. I’m not going to subscribe to a particular pattern to follow as the best one, because there is no specific
Data Protection
Data must be protected from unauthorized access. Therefore, secure software development life-cycle principles should be applied and propagated throughout the entire software structure.
For example, information accessible via one software module should not be accessible via another module unless it is explicitly allowed and regulated by the software architecture plan.
Refactoring
Refactoring is the continuous process of bringing improvements to an internal software structure without affecting its behavior or functions. In fact, refactoring practice is a part of the perpetual software maintenance process and involves regular review of and improvement of the code in order to make it more effective and lightweight.
THE SOLID Principles
While the above principles may include some new ideas that are not always common across design practices, they all ad massively to the ability of software design to deliver on quality. Below are 5 very common design principles that you will find in most textbooks and organizations as their effectiveness has been proven over many years. Despite this, I've come across few development teams that adhere to these and work on ensuring their code is designed accordingly.
Hopefully mentioning them again here will help to reiterate their importance to quality software design.
Single responsibility principle (SRP): A class has only one job, and only one reason to change. A class with more than one responsibility can weaken the design and lead to damage when changes occur. The SRP principle prevents the coupling of responsibilities and improves the design’s overall cohesion.
Open/closed principle: This software principle conveys that after a class of code has been created and tested, it should be closed to modification, but open to extension. During the development process, requirements can change and new functionality may be requested. Modifying code can introduce errors into the existing code. The open/closed principle helps keep the class code fundamentally intact while allowing for it to be extended to include new functionality.
Liskov Substitution Principle (LSP): Under this software design principle, objects of a superclass should be replaceable with objects of its subclasses, meaning they behave in the same way.
For example, if B is a subclass of A, objects of B should be able to replace objects of A without undermining the performance of the program. In other words, objects of a subclass can replace objects of the superclass without impairing the system.
Interface segregation: Each class should have its own isolated interface, and class dependencies should be based on the smallest possible interface. A large and cumbersome interface with multiple class dependencies adds methods to the interface that the clients don’t need.
Dependency inversion: This software principle states that high-level modules should not be dependent on low-level modules, and both should depend on abstractions. Abstractions in turn should not depend on details, but vice versa. The underlying premise here is that abstract interfaces and abstract classes are more stable than details, which are variable, and architectures built on abstractions are more stable than those built on details.
Software development is a complex art that can easily go wrong when we try to just write code that works and does not follow the appropriate principles. Yes, trying to implement the above principles does require more time and effort from the developer, but in the long run, it creates code that operates more reliably and is much easier to work with, maintain, and is likely to lead to fewer operational errors.
Comments