One of the central principles of object oriented programming is Encapsulation. Encapsulation states that the implementation details of an object are hidden behind the methods that provide access to that data. But why is encapsulation a good idea? Why bother to do it in the first place? Just stating that it's "good OO design" isn't sufficient justification.
There is one primary justification of encapsulation. It's a principle I call "Local Change - Local Effect". If you change code in one spot, it should only require changes in a small neighborhood surrounding the original change. When used properly, encapsulation allows software to change gradually without requiring bulk changes throughout the system (Change of code in one place requires code change in many places is known as Domino effect).
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.
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:
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.
courtesy: http://www.simberon.com/domino.htm
There is one primary justification of encapsulation. It's a principle I call "Local Change - Local Effect". If you change code in one spot, it should only require changes in a small neighborhood surrounding the original change. When used properly, encapsulation allows software to change gradually without requiring bulk changes throughout the system (Change of code in one place requires code change in many places is known as Domino effect).
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.
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.
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.
courtesy: http://www.simberon.com/domino.htm
Comments
Post a Comment