CSC/ECE 517 Summer 2008/wiki3 6 esb

Protected Variation

Open-Closed Principle "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification [Martin, p.99]"

Description of protected variation

Protected variation and Polymorphism Protected Variation and Polymorphism seem related. What is the difference between the two? Where would you apply one pattern over the other?

Polymorphism is a powerful technology that is very useful for handling Protected Variation. Protected Variation gives one reason "why" for a particular use of Polymorphism.

An example of an .Key Open-Closed Principle is... X can be opened to Y and always Z. And it's only open to Y if it Y needs to access something and has permission to. While Z can always access it because it has permission to. That look right?

I'd express it like this: if X uses Y in some way or other you don't want changes to Y to effect X, but you also want to be able to change Y in ways that don't change X.

Open-closed principle “Software should be open to extension but closed to modification” (Bertrand Meyer). The idea is to enhance functionality by making non-intrusive changes. Intrusive changes are changes that alter code that has been previously written; changing inside of classes. Rather, interfaces should be changed/extended rather than the implementation of classes.

Introduction

When programming code, care should be made to protect against change to the existing code. Information should be kept out of the grasp of components that could damage integrity. New design should be implemented at designated "variation" and "evolution" points. The pattern of Protected Variation involves identifying points of predicted variation and creating a stable interface around them.

Protected Variation is closely knitted with the Open-Closed Principle. When points of predicted variation are identified, the code becomes easy to extend/adapt ("open"), while the stable interfaces around these points provides for "closed" code, wherein modification will not affect clients. This stable interface surrounding the points of change also promotes the concept of Information Hiding, in that design information is hidden from other modules at the points of likely change.

Why use Protected Variation?

Protected Variation is a principle which can save much time and money. It is important to reduce the introduction of new defects, and in order to do so, the impact of change to a piece of code on the overall program must be minimized. Protected Variations help to introduce low coupling (i.e. minimizing the degree to which each program module relies on each one of the other modules), which in turn reduce change impact.