💡 Designing for Change
If your application is successful, many of your decisions now may need to be changed later.
So, your application's design will determine your ability to make those changes in the future. The easiest way to make changes is to add code that is easy to change. The consequences of change should be evident in the code that is changing and in any code that relies on it.
If an application is successful, its biggest problem will be dealing with change.
Object-oriented (OO) metrics can expose how well an application follows OO design principles. The wrong metrics imply future difficulties, while good metrics could be more helpful. A design that produces excellent metrics but does the wrong thing may still be costly to change.
Snippets of Text is a publication its readers support. To receive new posts and support my work, please consider becoming a free or paid subscriber.
Every change that applies to a codebase should be built with flexibility.
To achieve simplicity, ensure the code works and passes all tests. Then, make it more expressive by reflecting the programmer's intention. Duplication is a significant problem in well-designed systems, so it's essential to hunt for and remove any duplication in the code. One way to do this is to move extracted methods to another class to improve visibility.
The ultimate goal is to simplify the design as much as possible.
Like ❤️ if you appreciate my work and getting insights. You can also earn rewards by sharing this post.
Each change will simplify the application's structure further by applying simple design rules. Each class should be responsible for achieving maintainable and flexible object-oriented software. Object-oriented programming languages are designed to model reality efficiently and effectively.
Keep reading with a 7-day free trial
Subscribe to Snippets of Text to keep reading this post and get 7 days of free access to the full post archives.