O(1) Effort per Change¶
Context¶
Without careful planning, adding new functionality to your system can increase the cost of future changes. If you create patterns where one logical change means O(N) code changes because of N users of the same logic -- you are setting yourself up for a painful time.
What is it?¶
As the number of already-supported functionalities increases, your cost to make changes should grow as little as possible.
How to Use?¶
As you're designing a system or even a class structure, ask yourself -- when I want to add more supported cases, how will that affect the number of literal changes I need in order to make future logical changes? Where do changes need to happen when I add new support? Do those places grow with O(N), or O(1)?
Related¶
- Issues with effort per change can arise from failure to Separate Concerns