CSC/ECE 517 Fall 2009/wiki3 3 cp: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Common Closure Principle ==
== Common Closure Principle ==


In simple words the Common Closure Principle refers to ''classes that change topether, belong together'', this is a very simple definition taken from the book [http://books.google.com.mx/books?id=4pjbgVHzomsC&pg=PA26&lpg=PA26&dq=Common+Closure+Principle&source=bl&ots=snjcz2p1Uc&sig=KfIZS53bVf8ESsoZc8cJl9Ajl0A&hl=es&ei=S1MDS6SFLIvjlAed87HpAQ&sa=X&oi=book_result&ct=result&resnum=9&ved=0CDIQ6AEwCA# Java Design: Objects, UML and Process] written by Kirk Knoernschild.
In simple words the Common Closure Principle refers to ''classes that change together, belong together'', this is a very simple definition taken from the book [http://books.google.com.mx/books?id=4pjbgVHzomsC&pg=PA26&lpg=PA26&dq=Common+Closure+Principle&source=bl&ots=snjcz2p1Uc&sig=KfIZS53bVf8ESsoZc8cJl9Ajl0A&hl=es&ei=S1MDS6SFLIvjlAed87HpAQ&sa=X&oi=book_result&ct=result&resnum=9&ved=0CDIQ6AEwCA# Java Design: Objects, UML and Process] written by Kirk Knoernschild.


A more explained definition of Common Closure Principle is given by  [http://www.objectmentor.com/omTeam/martin_r.html Robert Martin], which states that:
A more explained definition of Common Closure Principle is given by  [http://www.objectmentor.com/omTeam/martin_r.html Robert Martin], which states that:


       THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINTS THE SAME  
       THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINTS THE SAME  
       KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE  
       KIND OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE  
       CLASSES WITHIN THAT PACKAGE.  
       CLASSES WITHIN THAT PACKAGE.  
        
        
See [http://www.objectmentor.com/resources/articles/granularity.pdf Granularity PDF Article] written by Robert Martin for more details
See [http://www.objectmentor.com/resources/articles/granularity.pdf Granularity PDF Article] written by Robert Martin for more details


In other words, '''what affects one affects all''', a broader and detailed explanations are given in this wikiwork.
In other words, '''what affects one affects all''', a broader and detailed explanations are given in this wiki work.


==Introduction and Objective==
==Introduction and Objective==
Line 18: Line 18:
Therefore the objective of the wiki work is to dedicate a deeper investigation on this topic with examples.
Therefore the objective of the wiki work is to dedicate a deeper investigation on this topic with examples.


==A deep definition of Common Closure Principle CCP==
==A Deeper Definition of Common Closure Principle CCP==


CCP is another package design principle which tries to look at maintainability rather than usability. The principle advises on which classes should be packaged together from a change and distribution point of view
Common Closure Principle or CCP is a design principle whose objective is to achieve maintainability, whereas usability is not important. This principle says what kind of classes should grouped or packaged together from a common change that affects all its components.


Even though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes cannot be avoided. CCP tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. Sometimes some of the class design principles are violated consciously to improve performance, just like denormalization in databases. However this violation should be a conscious decision and the product should be ready for changes because of it.  
This is also called coupling in the package, however there are other design principles that advise the loose of coupling between classes, the basis of those principles are the need of change without affecting others, however as explained in granularity paper by
[http://www.objectmentor.com/resources/articles/granularity.pdf Granularity ] by Robert C. Martin,  
   
    DEPENDENCIES CANNOT BE AVOIDED.


To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.
Therefore CCP identifies the classes that are totally dependent from each other, on this matter the Open-Closed Principle or OCP advises full closure which is difficult to achieve.


One issue is when dependencies between packages in a design should be in the direction of stability of the packages, in other words a package should only depend upon packages that are more stable than it is.
The previous statement leads to the overlapping of principles that shall not be confused as a violation of principles, however the decision to overlap principles in the design must be very carefully studied in the early stages.


Some volatility is necessary if the design is to be maintained. This is achieved by using the Common Closure Principle, in this way we design packages to be volatile and we expect them to change. Any package that we expect to be volatile should not be depended upon by a package that is difficult to change.
The CCP principle recommends identifying the common changes in a package, only after that the package can be released with the functionality that a change affects all its classes; the benefit of this is "maintainability", which is easier for the user in the way that a change or update surely affects all classes in the package  


Some things we don’t want to change. For example architectural decisions should be stable and not at all volatile. Therefore classes that encapsulate the high level design should be stable.
For a design to be maintained a degree of volatility will be required, this is easily achieved when the CCP principle is applied in the sense that all classes in the package can change simultaneously, any package expected to be volatile should not depend on a package that is difficult to change.


==Regarding Granularity==
Another advantage of CCP is stability of packages; to have packages with common changes makes the package itself more stable, which in the end improves stability


More important than reusability, is maintainability.
== Examples of the Applied Common Closure Principle ==


If the code in an application must change, where would you like those changes to occur: all in one package, or distributed through many packages? It seems clear that we would rather see the changes focused into a single package rather than have to dig through a whole bunch of packages and change them all. That way we need only release the one changed package. Other packages that don’t depend upon the changed package do not need to be revalidated or rereleased.
One simple example are the classes that handles schedules like, Weekly schedule, Biweekly schedule, Monthly schedule, Change Schedule, etc. can form a single Package


The CCP is an attempt to gather together in one place all the classes that are likely to change for the same reasons. If two classes are so tightly bound, either physically or conceptually, such that they almost always change together; then they belong in the same package. This minimizes the workload related to releasing, revalidating, and redistributing the software.
[[Image:Package_1.JPG]]


This principles is closely associated with the Open Closed Principle (OCP). For it is “closure” in the OCP sense of the word that this principle is dealing with. The OCP states that classes should be closed for modification but open for extension. As we learned in the article that described the OCP, 100% closure is not attainable. Closure must be strategic. We design our systems such that the are closed to the most likely kinds of changes that we
Where a change of summer time will sure affect all classes within the package
foresee.
-------------
The following is a group of classes that have the METHOD common change, they actually form another package.


The CCP amplifies this by grouping together classes which cannot be closed against certain types of changes into the same packages. Thus, when a change in requirements comes along; that change has a good chance of being restricted to a minimal number of packages.
[[Image:Package_2.JPG]]


==What are the advantages and disadvantages?==
==Common Closure Principle from the Granularity Point of View==


Goal: limit the dispersion of changes among released packages
According to the granularity [http://www.objectmentor.com/resources/articles/granularity.pdf Granularity ]  written by Robert C. Martin states that
u changes must affect the smallest number of released packages
 
        MORE IMPORTANT THAN REUSABILITY IS MAINTAINABILITY
 
Think it in this way, what if an application must change, it is better to have it all in one package? Or it is better to have it spread through different packages?
 
Of course it is easier to have it in a single package for maintainability purposes instead of looking up trough all packages and then apply the change.
 
It is now clear the purpose of the Common Closure Principle, which is to gather in a package all the classes that almost always change together, conceptually they must belong a the same package for maintainability. This approach reduced the work when releasing, revalidating, and redistributing the software.
 
Granularity also mentions that CCP is a kind of OCP where the classes should be closed for modification but open for extension, however the closure is not always achieved, the difference with CCP is that the closure is made on the most likely kinds of changes that the designer can foresee.
 
== Common Closure Principle From the User Point of View==
 
As said before the CCP is more stable since the common features are grouped in packages, however it is not good for reuse, since stability carries inflexibility, Figure below explains better this trade of for the user.
 
[[Image:Triad.JPG]]
 
Special thanks to '''Stefan Kluth''' for allowing to use the previous image from his work [http://www.wlap.org/file-archive/atlas/newoodpp.ppt OO Package Design Principles]
 
The designer must choose how to organize the packages according to his needs the Triad helps to understand the effect when applying CCP, REP or CRP (see appendix for definitions)
 
==What are the Advantages and Disadvantages?==
 
The first advantage is that CCP avoids dispersion of changes; the conclusion is that changes must affect the smallest number of released packages
 
It is easier to maintain since a particular change will affect all classes, this is another advantage from the maintainability of the design.
 
Another advantage is that clients can use specific interfaces instead of a single general interface.
 
The disadvantage is the inflexibility to reuse the design; if a new application is to be implemented the design based on CCP will be difficult to export it.
 
== Conclusions of Applying Common Closure Principle ==


Classes within a package must be cohesive
Classes within a package must be cohesive


Given a particular kind of change, either all classes or no class
* Reduces frequency of release of packages
in a component needs to be modified.


Group classes with similar closure together, package closed for anticipated changes.
* Confines changes to a few packages.


Confines changes to a few packages.
* Reduces package release frequency.


Reduces package release frequency.
* Reduces work for the programmer and makes easier to maintain it.


Reduces work for the programmer and makes easier to maintain it.
* All classes that are likely to change for the same reason should be packaged together.


Going from OCP to CCP, in this case the classes should be open for extension, but closed for modification, this is an ideal scenario, instead classes will be designed for likely kinds of changes
* The Common Closure Principle makes the closure strategic instead of fully closed


Cohesion of closure in a package should be closed to the same kinds of changes
==Reference Books==
and they will be confined within few packages


Reduces frequency of release of packages
* [http://www.amazon.com/dp/020163385X/?tag=ootips Object-Oriented Design Heuristics ] by Arthur J. Riel


==Reading Recommendations==
* [http://my.safaribooksonline.com/0131857258 Agile Principles, Patterns, and Practices in C#] by Robert C. Martin; Martin Micah


==Reference Books==
* [http://www.informit.com/store/product.aspx?isbn=0131428489 UML for Java™ Programmers] by Robert C. Martin
 
* [http://www.amazon.com/Java-Design-Objects-UML-Process/dp/0201750449 Java Design: Objects, UML, and Process] by Kirk Knoernschild
 
== External Links and Articles==
* [http://www.objectmentor.com/omTeam/martin_r.html Bob Martin's ]  Robert C. Martin web page
 
* [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns ]  by Robert C. Martin


== External Links ==
* [http://www.objectmentor.com/resources/articles/granularity.pdf Granularity ]  by Robert C. Martin
[http://www.objectmentor.com/omTeam/martin_r.html Bob Martin's ]


==Appendix==
==Appendix==
'''Open/Closed Principle OCP:''' Entities like classes or modules need to be open to extend them, at the same time they need to be closed for modification.  
* '''Open/Closed Principle OCP:''' Entities like classes or modules need to be open to extend them, at the same time they need to be closed for modification.  
 
* '''Liskov Substitution Principle LSP:''' Any base class function must not be confused when a derived class is substituted for the base class. It is also known as "Design by Contract" principle in [http://www.example.com Robert Martin]


'''Liskov Substitution Principle LSP:''' Any base class function must not be confused when a derived class is substituted for the base class. it is also known as "Design by Contract" principle in [http://www.example.com Robert Martin]
* '''Dependency Inversion Principle DIP:''' The details must be based on abstractions and not in the other way around, abstractions based on details.  


'''Dependency Inversion Principle DIP:''' The details must be based on abstractions and not in the other way aroud, abstractions based on details.  
* '''Interface Segregation Principle ISP:''' Some interfaces can be grouped in member functions, in this way the clients use one group of member functions, and other clients use the other groups according to their purpose. The clients use specific interfaces instead of the general interface.


'''Interface Segregation Principle ISP:''' Some interfaces can be grouped in member functions, in this way the clients use one group of member functions, and other clients use the other groups according to their porpouse. the clients use specific interfaces instead of the general interface.
* '''Reuse/Release Equivalency Principle REP:''' Reuse and Release are almost the same in the sense that only Released components through a tracking system are Reused components.  


'''Reuse/Release Equivalency Principle REP:''' Reuse and Release are almost the same in the sense that only Released components through a tracking system are Reused components.
* '''Common Closure Principle CCP:''' If the changes are of the same kind then they should be closed together, in other words, classes that change together, belong together and form groups


'''Common Closure Principle CCP:''' If the changes are of the same kind then they shloud be closed together, in other words, classes that change together, belong together and form groups
* '''Common Reuse Principle CRP:''' It refers to the classes that are reused together, if they are not then they should not be grouped. The effect of applying Common Reuse is that if you reuse one you reuse all of them.


'''Common Reuse Principle CRP:''' It refers to the clases that are reused together, if they are not then they should not be grouped. The effect of applying Common Reuse is that if you reuse one you reuse all of them.  
* '''Acyclic Dependencies Principle ADP:''' The structure for released components must never form a dependency cycle.  


'''Acyclic Dependencies Principle ADP:''' The structure for released components must never form a dependency cycle.  
* '''Stable Dependencies Principle SDP:''' this principle recommends that the dependee must be more stable than the depender; they usually follow the direction of stability.


'''Stable Dependencies Principle SDP:''' this principle recommends that the dependee must be more stable than the depender, they usually follow the direction of stability.
Most of the definitions were inspired on the web page [http://ootips.org/ood-principles.html What Makes A Good Object-Oriented Design?] written by Tim Ottinger

Latest revision as of 16:19, 19 November 2009

Common Closure Principle

In simple words the Common Closure Principle refers to classes that change together, belong together, this is a very simple definition taken from the book Java Design: Objects, UML and Process written by Kirk Knoernschild.

A more explained definition of Common Closure Principle is given by Robert Martin, which states that:

      THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINTS THE SAME 
      KIND OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE 
      CLASSES WITHIN THAT PACKAGE. 
      

See Granularity PDF Article written by Robert Martin for more details

In other words, what affects one affects all, a broader and detailed explanations are given in this wiki work.

Introduction and Objective

There are several web pages that explain in few words what is Common Closure Principle, but they fall short by just giving definitions and very few examples.

Therefore the objective of the wiki work is to dedicate a deeper investigation on this topic with examples.

A Deeper Definition of Common Closure Principle CCP

Common Closure Principle or CCP is a design principle whose objective is to achieve maintainability, whereas usability is not important. This principle says what kind of classes should grouped or packaged together from a common change that affects all its components.

This is also called coupling in the package, however there are other design principles that advise the loose of coupling between classes, the basis of those principles are the need of change without affecting others, however as explained in granularity paper by Granularity by Robert C. Martin,

   DEPENDENCIES CANNOT BE AVOIDED.

Therefore CCP identifies the classes that are totally dependent from each other, on this matter the Open-Closed Principle or OCP advises full closure which is difficult to achieve.

The previous statement leads to the overlapping of principles that shall not be confused as a violation of principles, however the decision to overlap principles in the design must be very carefully studied in the early stages.

The CCP principle recommends identifying the common changes in a package, only after that the package can be released with the functionality that a change affects all its classes; the benefit of this is "maintainability", which is easier for the user in the way that a change or update surely affects all classes in the package

For a design to be maintained a degree of volatility will be required, this is easily achieved when the CCP principle is applied in the sense that all classes in the package can change simultaneously, any package expected to be volatile should not depend on a package that is difficult to change.

Another advantage of CCP is stability of packages; to have packages with common changes makes the package itself more stable, which in the end improves stability

Examples of the Applied Common Closure Principle

One simple example are the classes that handles schedules like, Weekly schedule, Biweekly schedule, Monthly schedule, Change Schedule, etc. can form a single Package

Where a change of summer time will sure affect all classes within the package


The following is a group of classes that have the METHOD common change, they actually form another package.

Common Closure Principle from the Granularity Point of View

According to the granularity Granularity written by Robert C. Martin states that

       MORE IMPORTANT THAN REUSABILITY IS MAINTAINABILITY

Think it in this way, what if an application must change, it is better to have it all in one package? Or it is better to have it spread through different packages?

Of course it is easier to have it in a single package for maintainability purposes instead of looking up trough all packages and then apply the change.

It is now clear the purpose of the Common Closure Principle, which is to gather in a package all the classes that almost always change together, conceptually they must belong a the same package for maintainability. This approach reduced the work when releasing, revalidating, and redistributing the software.

Granularity also mentions that CCP is a kind of OCP where the classes should be closed for modification but open for extension, however the closure is not always achieved, the difference with CCP is that the closure is made on the most likely kinds of changes that the designer can foresee.

Common Closure Principle From the User Point of View

As said before the CCP is more stable since the common features are grouped in packages, however it is not good for reuse, since stability carries inflexibility, Figure below explains better this trade of for the user.

Special thanks to Stefan Kluth for allowing to use the previous image from his work OO Package Design Principles

The designer must choose how to organize the packages according to his needs the Triad helps to understand the effect when applying CCP, REP or CRP (see appendix for definitions)

What are the Advantages and Disadvantages?

The first advantage is that CCP avoids dispersion of changes; the conclusion is that changes must affect the smallest number of released packages

It is easier to maintain since a particular change will affect all classes, this is another advantage from the maintainability of the design.

Another advantage is that clients can use specific interfaces instead of a single general interface.

The disadvantage is the inflexibility to reuse the design; if a new application is to be implemented the design based on CCP will be difficult to export it.

Conclusions of Applying Common Closure Principle

Classes within a package must be cohesive

  • Reduces frequency of release of packages
  • Confines changes to a few packages.
  • Reduces package release frequency.
  • Reduces work for the programmer and makes easier to maintain it.
  • All classes that are likely to change for the same reason should be packaged together.
  • The Common Closure Principle makes the closure strategic instead of fully closed

Reference Books

External Links and Articles

Appendix

  • Open/Closed Principle OCP: Entities like classes or modules need to be open to extend them, at the same time they need to be closed for modification.
  • Liskov Substitution Principle LSP: Any base class function must not be confused when a derived class is substituted for the base class. It is also known as "Design by Contract" principle in Robert Martin
  • Dependency Inversion Principle DIP: The details must be based on abstractions and not in the other way around, abstractions based on details.
  • Interface Segregation Principle ISP: Some interfaces can be grouped in member functions, in this way the clients use one group of member functions, and other clients use the other groups according to their purpose. The clients use specific interfaces instead of the general interface.
  • Reuse/Release Equivalency Principle REP: Reuse and Release are almost the same in the sense that only Released components through a tracking system are Reused components.
  • Common Closure Principle CCP: If the changes are of the same kind then they should be closed together, in other words, classes that change together, belong together and form groups
  • Common Reuse Principle CRP: It refers to the classes that are reused together, if they are not then they should not be grouped. The effect of applying Common Reuse is that if you reuse one you reuse all of them.
  • Acyclic Dependencies Principle ADP: The structure for released components must never form a dependency cycle.
  • Stable Dependencies Principle SDP: this principle recommends that the dependee must be more stable than the depender; they usually follow the direction of stability.

Most of the definitions were inspired on the web page What Makes A Good Object-Oriented Design? written by Tim Ottinger