CSE687 - Object Oriented Design

Design Note #3
Favor Local Consequences

Revised: 4/28/2011

Design your code so changes have local consequences.

Ideally any change made to a package only affects that package. When you don't do that changes are much harder to implement correctly. Most developers who work on large code bases have had the experience of making a change in package A only to find that that breaks the design of package B. Fixing that causes package C to malfunction, and so forth.
If you've designed a package so its interface does not provide any direct access to its implementation, then changes to the implementation will not cause build failures, and are much less likely to cause changes to the run-time behavior of its clients, other than to see its changed semantics, and presumably that is why you made the change.
Sometimes you violate this rule intentionally - some design techniques use remote consequences to do very powerful things:
- Delegate some processing to another package.
- Handle library events in application code.
- Defer execution of a function to a later phase of processing.
- Sharing objects or data, as in a database, e.g., one application instance may affect the operation of another due to changes in a shared resource.
We will discuss all of these techniques later in this course.

Code with only local consequences of change is easier to develop and maintain.

Keep consequences local by strong encapsulation and avoiding sharing and remote delegation.
Try to make most of your code satisfy this rule, but break it intentionally to do powerful things in small parts of your design.