This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: The Local Change - Local Effect Principle
Feed Title: David Buck - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/buck-rss.xml
Feed Description: Smalltalk can do that
There's a principle of object oriented programming that I've never seen written up formally. For me, it's one of the key reasons to have object oriented software in the first place. I don't remember whether I came up with the term myself or whether I heard it from someone else first, but since I haven't seen it written up anywhere, I thought I'd do it here.
The principle is called "Local Change / Local Effect". It states:
Any localized design change to a software system should only require changes to a small amount of code in the immediate vicinity of the change. There should be no wide-spread or system-wide changes needed.
Encapsulation helps follow this principle by allowing changes in the representation of an object's state. The methods for the object may be affected, but callers of those methods shouldn't be. The effects of the change are localized.
Polymorphism helps by allowing us to add new objects without changing existing code to know about them. You only need to add the new classes and new methods. You shouldn't need to change existing code. (This is also known as the Open/Closed Principle).
Inheritance helps by providing one place to put common code for many similar objects. Changes to this code can be isolated to the superclass and may require no changes to subclasses in order to make them work.
There are many coding practices that tend to work against the local change/local effect principle. They include:
Copy and paste code - by making more copies of code, you have more things that need to be changed for any change in design.
Public instance variables - by making instance variables public, more people can use them directly and require more changes if you need to change the representation.
Manifest types - the type information for variables and parameters often causes domino effect changes. When you change the type that a method accepts, you may have to change its callers and their callers and so forth.
In any software system, the one thing you can count on is change. The local change/local effect principle makes change possible. Without it, as a system gets larger, it becomes more brittle and eventually becomes unmaintainable.
Think about your design principles. If they don't support local change/local effect, you may be building a system that will become too brittle to ever change again.
Previous Topic
