Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T23:16:26Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions<ref name=pdf></ref>.
* Make all Member Variables Private: Member variables of classes should be known only to the methods of the class that defines them. Member variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected. In light of the open-closed principle, the reason for this convention ought to be clear. When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable. 
* No global variables: The argument against global variables is similar to the argument against pubic member variables. No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that the other modules don’t expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one. 
* Avoid run time type identification: Another very common proscription is the one against dynamic_cast. It is often claimed that dynamic_cast, or any form of run time type identification is intrinsically dangerous and should be avoided to comply with the open-closed principle.

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T23:13:33Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions.
* Make all Member Variables Private: Member variables of classes should be known only to the methods of the class that defines them. Member variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected. In light of the open-closed principle, the reason for this convention ought to be clear. When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable. 
* No global variables: The argument against global variables is similar to the argument against pubic member variables. No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that the other modules don’t expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one. 
* Avoid run time type identification: Another very common proscription is the one against dynamic_cast. It is often claimed that dynamic_cast, or any form of run time type identification is intrinsically dangerous and should be avoided to comply with the open-closed principle.

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T23:10:08Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions.
* Make all Member Variables Private: Member variables of classes should be known only to the methods of the class that defines them. Member
variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected. In light of the open-closed principle, the reason for this convention ought to be clear. When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable. 
* No global variables: The argument against global variables is similar to the argument against pubic member variables. No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that the other modules don’t expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one. 
* Avoid run time type identification: Another very common proscription is the one against dynamic_cast. It is often claimed that dynamic_cast, or any form of run time type identification is intrinsically dangerous and should be avoided.

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T23:09:30Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions.
* Make all Member Variables Private: Member variables of classes should be known only to the methods of the class that defines them. Member
variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected. In light of the open-closed principle, the reason for this convention ought to be clear. When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable. 
* No global variables: The argument against global variables is similar to the argument against pubic member variables. No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that
the other modules don’t expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one. 
* Avoid run time type identification: Another very common proscription is the one against dynamic_cast. It is often claimed that dynamic_cast, or any form of run time type identification is intrinsically dangerous and should be avoided.

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T21:35:20Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions.
# Make all Member Variables Private: Member variables of classes should be known only to the methods of the class that defines them. Member
variables should never be known to any other class, including derived classes. Thus they should be declared private, rather than public or protected. In light of the open-closed principle, the reason for this convention ought to be clear. When the member variables of a class change, every function that depends upon those variables must be changed. Thus, no function that depends upon a variable can be closed with respect to that variable. 
# No global variables: The argument against global variables is similar to the argument against pubic member variables. No module that depends upon a global variable can be closed against any other module that might write to that variable. Any module that uses the variable in a way that
the other modules don’t expect, will break those other modules. It is too risky to have many modules be subject to the whim of one badly behaved one. 
# Avoid run time type identification:

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T21:28:16Z

Sdkshirs: /* Conventions to follow */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

==== Conventions to follow ====
In order to obey open-closed principle it is good to follow some conventions.
# Make all Member Variables Private:
# No global variables:
# Avoid run time type identification:

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T21:27:03Z

Sdkshirs: /* Description */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

== Conventions to follow ==
In order to obey open-closed principle it is good to follow some conventions.
# Make all Member Variables Private:
# No global variables:
# Avoid run time type identification:

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:58:49Z

Sdkshirs: /* Strategic Closure */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====
It should be clear that no significant program can be 100% closed. For example, consider the above DrawAllShapes example. What would happen to the DrawAllShapes function if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:42:46Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

Note that in the above solution, if we want to extend the behavior of the DrawAllShapes function in to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes function does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its behavior can be extended without modifying it.

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:40:57Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw. Now let us look at a more better solution for this problem.

class Shape
{
public:
virtual void Draw() const = 0;
}; 
class Square : public Shape
{
public:
virtual void Draw() const;
}; 
class Circle : public Shape
{
public:
virtual void Draw() const;
}; 
void DrawAllShapes(Set<Shape*>& list)
{
for (Iterator<Shape*>i(list); i; i++)
(*i)->Draw();
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:38:53Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

In the above example, the function DrawAllShapes does not conform to the open-closed principle because it cannot be closed against new kinds of shapes. If we wanted to extend this function to be able to draw a list of shapes that included triangles, we would have to modify the function. In fact, we would have to modify the function for any new type of shape that we needed to draw.

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:37:20Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

===== Abstraction Example =====

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:37:04Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

====== Abstraction Example ======

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
}; 
//
// These functions are implemented elsewhere
// 
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break; 
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:35:27Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

====== Abstraction Example ======

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
};
//
// These functions are implemented elsewhere
//
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break;
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:35:10Z

Sdkshirs: /* Abstraction Example */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

====== Abstraction Example ======

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
};
//
// These functions are implemented elsewhere
//
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break;
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-11-18T19:33:10Z

Sdkshirs: /* Abstraction */

=The Open/Closed principle=
__TOC__

== Introduction ==
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming] the [http://en.wikipedia.org/wiki/Open/closed_principle Open/Closed principle] states<ref name = meyer />,

''Software entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification.''

It sounds like a contradiction in terms, but it's not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. All systems change during their life cycles. One should keep this in mind when designing systems that are expected to last longer than the initial version. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written<ref name = microsoft />.

Open/Closed principle is one of the five principles basic of [http://en.wikipedia.org/wiki/OOD object-oriented design(OOD)] which are defined as the [http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 S.O.L.I.D.]. The principles of SOLID are guidelines that can be applied while working on software to remove [http://en.wikipedia.org/wiki/Code_smell code smells] by causing the programmer to refactor the software's source code until it is both legible and extensible. It is typically used with [http://en.wikipedia.org/wiki/Test-driven_development test-driven development], and is part of an overall strategy of [http://en.wikipedia.org/wiki/Agile_software_development agile] and [http://en.wikipedia.org/wiki/Adaptive_Software_Development adaptive programming]<ref name = openclosed_video />.

== Motivation ==
All software systems are subject to change. Thus designing a system which is stable is a very crucial task. When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”
design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. Open-closed principle states that the code should be designed in such a way that it should not change. Whenever requirements change, the existing code should be extended by adding new code and leave the old working code intact.

Most of the times it easier to write all new code rather thank making changes to existing code. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you did not break any of the existing code.

The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged. Thus following open-closed principle leads to good software design.

== Description ==
Every module obeying open-closed principle have the following key attributes:
* They are “Open For Extension”. This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
* They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.

At starting, these two points seem to be very contradictory to each other. How can the module be extensible when it is not supposed to me modified? The key idea to go about this is [http://en.wikipedia.org/wiki/Abstraction_(computer_science) abstraction]<ref name = abstraction_wiki> </ref>.

==== Abstraction ====
In object oriented design, it is possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors. The abstractions are abstract base classes, and the unbounded group of possible behaviors is represented by all the possible derivative classes. It is possible for a module to manipulate an abstraction. Such a module can be closed for modification since it depends upon an abstraction that is fixed. Yet the behavior of that module can be extended by creating new derivatives of the abstraction.

====== Abstraction Example ======

struct Square
{
ShapeType itsType;
double itsSide;
Point itsTopLeft;
};
//
// These functions are implemented elsewhere
//
void DrawSquare(struct Square*)
void DrawCircle(struct Circle*);
typedef struct Shape *ShapePointer;
void DrawAllShapes(ShapePointer list[], int n)
{
int i;
for (i=0; i<n; i++)
{
struct Shape* s = list[i];
switch (s->itsType)
{
case square:
DrawSquare((struct Square*)s);
break;
case circle:
DrawCircle((struct Circle*)s);
break;
}
}
}

==== Strategic Closure ====

== Example ==
Suppose you are writing a module to approve personal loans and before doing that you want to validate the personal information, code wise we can depict the situation as:

public class LoanApprovalHandler
{
public void approveLoan(PersonalValidator validator) 
{
if ( validator.isValid())
{
//Process the loan.
}
}
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

So far so good. As we have already discussed, the requirements always change and now we are required to approve vehicle loans as well. So one approach to solve this requirement is to:

public class LoanApprovalHandler
{
public void approvePersonalLoan (PersonalLoanValidator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
public void approveVehicleLoan (VehicleLoanValidator validator )
{
if ( validator.isValid())
{
//Process the loan.
}
}
// Method for approving other loans.
}
public class PersonalLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}
public class VehicleLoanValidator
{
public boolean isValid()
{
//Validation logic
}
}

We have edited the existing class to accommodate the new requirement and in the process we ended up changing the name of the existing method and also adding new methods for different types of loan approval. This clearly violates the Open/Closed principle. Lets try to implement the requirement in a different way

/**
* Interface Validator class Extended to add different validators for different loan type
*/
public interface Validator
{
public boolean isValid();
}
/**
* Personal loan validator
*/
public class PersonalLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/**
* Vehicle loan validator
*/
public class VehicleLoanValidator
implements Validator
{
public boolean isValid()
{
//Validation logic.
}
}
/*
* Similarly any new type of validation can
* be accommodated by creating a new subclass
* of Validator
*/

Now using the above validators we can write a LoanApprovalHandler to use the Validator abstraction.

public class LoanApprovalHandler
{
public void approveLoan(Validator validator)
{
if ( validator.isValid())
{
//Process the loan.
}
}
}

So to accommodate any type of loan validators we would just have create a subclass of Validator and then pass it to the approveLoan method. That way the class is CLOSED for modification but OPEN for extension.

== Conclusion ==
In reality, achieving Open/Closed principle-compliance system-wide is not possible. There will always exist some change that the system is not closed against. Therefore, this principle must be applied judiciously to the areas of the system that are most complex and dynamic. Even partial Open Closed principle compliance results in more resilient systems. Isolating violations of Open Closed principles to specific classes, such as object factories, certainly serves to reduce the overall maintenance efforts.<ref name = journal/>

This principle is at the heart of object oriented design in many ways, it motivated many heuristics associated with object oriented design<ref name = pdf/>. For example, “all member variables should be private”, or “global variables should be avoided”. Conformance to this principle yields some of the great benefits such as the application will be more robust because we are not changing already tested code, flexible because we can easily accommodate new requirements. Yet conformance to this principle is not achieved simply by using an object oriented programming language. Rather, it requires a dedication on the part of the designer to apply abstraction to those parts of the program that the designer feels are going to be subject to change.

== See Also ==
Below are some of the patterns and principles that are used to structure code to isolate changes.

*[http://en.wikipedia.org/wiki/Single_responsibility_principle Single-Responsibility Principle]
*[http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern]
*[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov Substitution Principle ]
*[http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) SOLID - Object Oriented Design]
*[http://css.dzone.com/articles/openclosed-principle-real A real world example of Open/Closed Principle]

== References ==
<references>
<ref name = meyer> [http://en.wikipedia.org/wiki/Bertrand_Meyer Meyer, Bertrand] (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3. </ref>
<ref name = pdf> Martin, R.C. (2000). "Design Principles and Design Patterns." http://www.objectmentor.com </ref>
<ref name = microsoft> http://msdn.microsoft.com/en-us/magazine/cc546578.aspx Patterns in Practice: The Open Closed Principle </ref>
<ref name = openclosed_video> http://ruby-toolbox.com/categories/testing_frameworks.html </ref>
<ref name = journal> http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0702/knoernschild/index.html </ref>
<ref name = abstraction_wiki> [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction wiki] </ref>
</references>

CSC/ECE 517 Fall 2012/ch2b 2w69 as

2012-09-15T00:21:09Z

Sdkshirs: /* Banking account example in AspectR */

=Aspect Oriented Programming (AOP): AspectJ and AspectR=

Aspect Oriented Programming (AOP) refers to a new way of designing software. It aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. It is not a replacement to popular Object Oriented Programming (OOP), but is complimentary to it.

== Overview ==
Aspect-oriented programming entails breaking down program logic into distinct parts, called concerns. Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. An example to this is logging. In an normal object oriented language program we might need to invoke a logger function from everywhere we this functionality.

==Why do we need AOP? The banking example==
Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred.

Consider a simple banking application written in Ruby.

require 'insufficient_funds'
class BankAccount 
attr_accessor :balance 
def initialize
@balance = 0.0
end 
def deposit(amount)
@balance += amount
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFunds
end
@balance -= amount
end 
end

This is simple enough. But is not very useful. What if we need persistence too?

require 'insufficient_funds_error' 
class BankAccount
attr_reader :balance 
def balance=(amount)
@balance = amount
persist_balance
end 
def initialize
@balance = retrieve_balance
end 
def deposit(amount)
@balance += amount
persist_balance
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance
end 
def retrieve_balance
# Get from database
end 
def persist_balance
# Save to database
end 
end

We can see that now other interests have become tangled with the basic functionality (sometimes called the business logic concern). Now add:

* Transactional behavior
* Authentication and authorization
* “Observers”, like a UI

Also this code will be repeated across other domain objects which need the same behavior. Finally, attempt to reuse this code in a new application with a different persistence store, transaction engine, security model etc.

===The Problem===

* Persistence itself is already modular
** But the code that uses it isn’t!
** Persistence invocation code is scattered
** BankAccount code is tangled with code from other concerns
** BankAccount’s modularity is compromised
* Also, similar persistence code is added to other components
** Redundancy:
*** Hard to change all occurrences consistently.
*** Hard to replace the Persistence solution.
*** Breaks Don’t Repeat Yourself! (DRY)
** Reuse is hard.
*** The persistence solution may be different in another context.

===The Solution: Aspect Oriented Programming===
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Then it provides mechanisms for fine-grained modification of target component behavior to incorporate the aspects’ behaviors. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account.

For example in the above program, the behavior is modified by adding a 'Persistence aspect' to the program. We specify separately where these aspect should be invoked in the banking account application. Now the banking account remains agnostic and the aspect code is maintained in one place. Also, now it is easy to change to a different solution or to remove the concern altogether.

We will see how this is implemented exactly in various implementation of AOP such as AspectJ and AspectR below.

==AOP Concepts==
The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things:

* Joinpoint - a well defined event in the execution of a program (such as the core functionality provided by the persistence class). eg: A call to a method persist_balance from inside the withdraw method.
* Pointcut - A collection of join points. eg: A collection of all mutator methods in BankingAccount.
* Advice - A block of code that specifies some behavior to be executed before/after/around a certain joinpoint.

Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed.

==AspectJ: AOP in Java==
AspectJ extend the Java programming language with constructs to support AOP. It is a superset of Java such that each valid Java program is also a valid AspectJ program. Also, it is designed as a general purpose language as opposed to a domain specific language. AspectJ is currently the most notable AOP technology.

AspectJ was created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

===History and contributors===
Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

===Lanugage description===
All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are:

====Inter-type declarations====
These allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class:

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}

====Pointcuts====
Pointcuts allow a programmer to specify join points. All pointcuts are expressions (quantifications) that determine whether a given join point matches. A call joinpoint captures an execution event after it evaluates a method calls' arguments, but before it calls the method itself.

For example, this point-cut specifies all calls to GetBalance method in the class BankingAccount that takes no arguments and returns long

call(public long BankingAccount.GetBalance())

We may also use logical operators in the definition of pointcuts inorder to combine pointcut expressions.

# || (OR operator) - Matches a joinpoint if either left pointcut expression or right pointcut expression matches
# && (AND operator) - Matches a joinpoint if both left pointcut expression and right pointcut expression matches
# ! (NOT operator) - Matches all joinpoints NOT specified by the pointcut expression

Example of a pointcut which matches both mutator methods of the BankingAccount class is

pointcut mutators(): call(public long BankingAccount.Withdraw(long)) || call(public long BankingAccount.Deposit(long))

Various types of joinpoints that are possible in AspectJ are:
# Calls to methods and constructors
# Execution of methods and constructors
# Field access
# Exception handling
# Class initializaiton
# Lexical structure
# Control flow
# Self-target and argument type
# Conditional test

Patterns in pointcuts 
Patterns can also be used to specify events in pointcuts. This would be useful to specify a set of events concisely.

The use of * character is highly overloaded.
* Using * operator where a type is expected matches any type
* Using * where an identifier is expected matches any identifier
* * can also be used in identifier patterns
** the expression foo* would match any identifier that starts with foo
** the expression *foo* would match any identifier that has foo in it
* We can add + to the end of any identifier pattern to indicate that we wish to match a class and all of its subclasses

Examples
* foo - class foo
* foo+ - class foo and all of its subclasses
* foo* - all classes starting with foo
* foo*+ - all classes starting with foo and all of their subclasses
* *foo* - all classes with foo in it

====Advice====
Advice allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. An advice must be define with respect to a pointcut. Given below is an advice defined with respect to the mutators pointcut.

before() : mutators() {
System.out.println("Mutator called");
}

This is a special type of mutator called the before mutator which is called before the joinpoint specified by the pointcut is executed.

There are three ways to associate an advice with a pointcut:
# Before - run just before the pointcut
# After - run just after the pointcut
# Around - Runs instead of the pointcut with the provision for the pointcut to resume execution through a method called proceed().

AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). Pointcuts and advices together define composition (weaving) rules.

====Aspect====
Much like a class, an Aspect is a unit of modularity. It is defined in terms of pointcuts, advices and ordinary java fields and methods. Pointcuts say which event to match and advice body says what to execute when it matches.

public aspect Tracer {
pointcut mutators(): call(public long BankingAccount.Withdraw(long)) ||
call(public long BankingAccount.Deposit(long)); 
before() : mutators() {
System.out.println("Mutator called");
}
}

===Banking example in Java using AOP===
Now let us look at how persistence may be added to the BankingAccount example using AspectJ

class BankAccount { 
float balance; 
public BankAccount(float balance) {
this.balance = balance;
} 
public void deposit(float amount) {
balance += amount
} 
public void withdraw(float amount) {
if (balance < amount) {
throw new InsufficientFundsException();
}
balance -= amount;
}
}

aspect PersistenceAspect { 
pointcut stateChange(BankAccount ba):
(call(void BankAccount.deposit(*)) ||
call(void BankAccount.withdraw(*)))
&& target(ba); 
after(BankAccount ba) returning: stateChange(ba) {
// persist ba.getBalance() value to database
}
}

We define the pointcut stateChange as calls to the mutator functions of the BankAccount class, which are the deposit and withdraw functions in the PersistenceAspect. The persistence action should be performed after the above mentioned pointcut. So we define an advice returning, after the pointcut stateChange. So this code will execute everytime after the withdraw and deposit functions and the balance will be persisted.

Thus the BankAccount class contains code only related to the BankAccount. It is completely free of any cross-cutting concerns such as persistence. Other concerns such as user authentication might be implemented similarly.

==AOP in Ruby==
Ruby does not have native AOP support. But Ruby's metaprogramming features cover many of the aspect requirements. 'method_missing' and reflection in Ruby are classis examples of that. 'method_missing' allows the code to inspect the method call at runtime and redirect to some default method or define a new method if the called method does not exists. Similarly Ruby provides naive support to implement pointcuts and wrapper methods. They are discussed below.

===Pointcut equivalent in Ruby===
There are no pointcuts in Ruby. But they can be simulated by the inspect method that Ruby provides.

# List all the classes
ObjectSpace.each_object(Class) do |o|
puts o.inspect
end 
# List all the modules
ObjectSpace.each_object(Module) do |o|
puts o.inspect
end 
# List all the instances of class String
ObjectSpace.each_object(String) do |o|
puts o.inspect
end

===Adding advice in Ruby===
In Ruby, alias can be used to wrap methods with advice.

foo.rb
class Foo
def bar
"bar"
end
end 
foo_advice.rb
class Foo
alias old_bar bar
def bar
"{[< "+ old_bar+ " >]}”
end
end

In the above code, the alias will be executed eveytime a call to method 'bar' is made. The output of the above code will be as follows:

puts Foo.new.bar
=> "{[< bar >]}"

==AspectR==
We saw how AOP can be implemented in Ruby without any extra support in the above sections. AspectR is free library which provides API's to the same for Ruby. Essentially it allows you to wrap code around existing methods in your classes. This can be a good thing (and even affect how you design your code) since it separates different concerns into different parts of the code. The code for AspectR can be downloaded from [http://prdownloads.sf.net/aspectr/aspectr-0-3-5.tar.gz here]. AspectR was originally called advice.rb and written by Avi Bryant. Later Robert Feldt changed/tweaked/extended it.

===Main features of AspectR===
*Joinpoints: Ruby does not have the notion of Jointpoints. But it can be considered as method or constructor calls or even exception handlers.
*Advices: It contains before (pre) advice, after returning and after throwing (post) advice, which indicates what is to be done before/after the jointpoint is called.
*Aspects: They are the classes that inherit from Aspect. It supports "abstract" Aspects and overriding between advices.
*Wildcards: RegExp can be used in pointcut designators, ie. to specify classes and methods to wrap advice's to.
*Pointcut parameters advices can access: object and method receiving call, arguments to call, return values, and exceptions raised.

===AspectR Syntax===
Advice methods are passed a variable number of parameters:
*the first is the name of the method currently being wrapped
*the second is the object receiving the method call
*the third is the exit/return status:
**Array with return value(s) if the method exited normally
**true if the method exited with an exception
**nil if the method hasn't yet exited (for preAdvice)
*the rest are the arguments that were passed to the wrapped method.

Here is the sample syntax:
require 'aspectr'
include AspectR
class MyAspect < Aspect
def someAdviceMethod(method, object, exitstatus, *args)
...
end
... some other advice methods ...
end 
ma = MyAspect.new
ma.wrap(someClassorObject, :preAdvice, :postAdvice, ... methods to wrap...)
or
ma.wrap(someClassorObject, :preAdvice, :postAdvice, /patternToWrap/)
or
AspectR.wrap_classes(ma, :preAdvice, :postAdvice,
[Class1, Class2], ...methods to wrap...)
===Banking account example in AspectR===

class BankAccount
attr_reader :balance
def balance=(amount)
@balance = amount
persist_balance
end 
def initialize
@balance = retrieve_balance
end 
def deposit(amount)
@balance += amount
persist_balance
end 
def withdraw(amount)
if @balance < amount
raise InsufficientFundsError
end
@balance -= amount
persist_balance
end
end 
class Persist < Aspect
def retrieve_balance
# Get from database
..
end
def persist_balance
# Save to database
..
end
end 
Persist.new.wrap(BankingAccount, :retrive_balance, :persist_balance, /[withdraw|deposit]/)

In the above code class persists is a subclass of Aspect and has the before(retrive_balance) and after(persist_advice) advice defined in it. Then the last line of the code wraps the this persist class to the BankingAccount's withdraw and deposit methods. It also specifies what pre-advice and what post-advice should be used. The API for wrap class is as follows:

def wrap(target, pre, post, *args)
get_methods(target, args).each do |method_to_wrap|
add_advice(target, PRE, method_to_wrap, pre)
add_advice(target, POST, method_to_wrap, post)
end
end

Thus as we can see from API, the wrap method directly adds the pre and post advice to the methods (Join-points in AspectJ terminology).

==How AspectR is different from AspectJ==
*Join points: Join points are not defined separately in AspectR as they are in AspectJ. Instead the method and constructor calls acts as join points.
*Most of the point cut designator primitives that are present in AspectR differ from AspectR.
*There is a huge difference in composition of pointcut designators. But you can of course specify several method calls in different classes and objects in a point cut.
*Around advices are more easy to add in AspectR than AspectJ but mostly before and after advices are used.
*AspectR has control-flow based crosscutting.

==References==
{{reflist}}
# [[Aspect-oriented_programming|Aspect Oriented Programming - wikipedia]]
# An introduction to Aspect-Oriented Programming with AspectJ by Constantinos Constantinides, McGill University
# [[AspectJ|AspectJ - wikipedia]]
# [http://aspectr.sourceforge.net/ AspectR - Simple aspect-oriented programming in Ruby]
# [http://www.ruby-doc.org/gems/docs/a/aspectr-0.3.7/AspectR.html AspectR - Ruby documentation]
# Aspect-Oriented Programming in Ruby by Dean Wampler