Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-28T20:53:02Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs rot: rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle] ==

<blockquote>
Principle:
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

Said another way, the degree to which a component is reusable is directly proportional to the degree to which that components various versions are tracked. The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
Principle:
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are affected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
Principle:
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
Principle:
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
Principle:
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

...which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
Principle:''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns] (PDF)
*[http://today.java.net/pub/au/90 Robert C. Martin] biography (web page)
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility] (PDF)
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility] (web page)
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal] (PPT)
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] (web page)
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub] (web page)
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] (web page)
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability] (PDF)
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] (web page)
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] (web page)

Note that the PDFs provide the best sources of information for these topics. As web pages seem to restate or refer to topics covered by Martin, these are the most thorough sources on the web.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-28T20:42:09Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle] ==

<blockquote>
Principle:
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

Said another way, the degree to which a component is reusable is directly proportional to the degree to which that components various versions are tracked. The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
Principle:
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are affected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
Principle:
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
Principle:
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
Principle:
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

...which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
Principle:''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns] (PDF)
*[http://today.java.net/pub/au/90 Robert C. Martin] biography (web page)
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility] (PDF)
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility] (web page)
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal] (PPT)
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] (web page)
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub] (web page)
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] (web page)
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability] (PDF)
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] (web page)
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] (web page)

Note that the PDFs provide the best sources of information for these topics. As web pages seem to restate or refer to topics covered by Martin, these are the most thorough sources on the web.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-28T20:18:47Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are affected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

...which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns] (PDF)
*[http://today.java.net/pub/au/90 Robert C. Martin] biography (web page)
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility] (PDF)
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility] (web page)
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal] (PPT)
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] (web page)
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub] (web page)
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] (web page)
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability] (PDF)
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] (web page)
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] (web page)

Note that the PDFs provide the best sources of information for these topics. As web pages seem to restate or refer to topics covered by Martin, these are the most thorough sources on the web.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-28T20:14:20Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are affected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

...which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns] (PDF)
*[http://today.java.net/pub/au/90 Robert C. Martin] biography (WWW)
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility] (PDF)
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility] (WWW)
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal] (PPT)
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T21:49:51Z

Mbsimmon: Proofreading

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are affected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

...which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T21:47:07Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

<center>[[Image:Stability.jpg]]</center>

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

<center>[[Image:Abstractness.jpg|Determining 'Abstractness'|Two Packages, Each with Seven Classes]]</center>

In the figure above, Package A has seven classes, two of which are abstract. This yields an abstraction value of 0.286. Conversely, Package B has seven classes, none of which are abstract -- yielding a value of 0.0. In accordance with the matrix for determining abstractness, Package A is more abstract and is therefore more stable.

== Does Stability Produce Inflexibility? ==

No. Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

File:Abstractness.jpg

2007-11-19T21:36:15Z

Mbsimmon:

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T21:35:56Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

[[Image:Stability.jpg]]

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

[[Image:Abstractness.jpg]]

== Summary ==

Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

File:Abstractness.JPG

2007-11-19T21:34:28Z

Mbsimmon:

File:Stability.jpg

2007-11-19T21:04:58Z

Mbsimmon:

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T21:04:38Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

[[Image:Stability.jpg]]

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

== Summary ==

Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

File:Stability.JPG

2007-11-19T21:02:36Z

Mbsimmon: This file demonstrates the matrix for calculating stability.

This file demonstrates the matrix for calculating stability.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T20:23:32Z

Mbsimmon:

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
''Stable packages should be abstract packages.''
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

== Summary ==

Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T20:19:55Z

Mbsimmon: Added References

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
Stable packages should be abstract packages.
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

== Summary ==

Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

== References ==

*[http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Design Principles and Design Patterns]
*[http://today.java.net/pub/au/90 Robert C. Martin] biography
*[http://www.objectmentor.com/resources/articles/oodmetrc.pdf Software Rigidity and Fragility]
*[http://linux.dell.com/libsmbios/main/presentation.html Immobility]
*[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principal]
*[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle]
*[http://www.objectmentor.com/omSolutions/oops_what.html Design Pattern Hub]
*[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle]
*[http://www.objectmentor.com/resources/articles/stability.pdf Stability]
*[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle]
*[http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle]

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T20:09:04Z

Mbsimmon: Added SAP.

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

== [http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle] ==

<blockquote>
Stable packages should be abstract packages.
</blockquote>

The stable abstraction principle is a natural consequence of the Stable Dependencies Principle (above). By definition abstract classes are maximally stable because they can't change; conversely, concrete classes are maximally instable because they can change. It follows that stability in a package is directly proportional to the level of abstraction in the design.

Martin defines metrics for calculating abstractness as the number of abstract classes in a package divided by the total number of classes in a package. Just like instability ('''I'''), the result is between zero and one, with zero being a package with no abstract classes and one being a package with only abstract classes. According to the SAP, ranges closer to one are desired.

'''Note'''

Remember that instable packages are easy to change whereas stable packages are difficult to change. Designing a stable package does not make it difficult to modify at all. Beyond the scope of this article is the [http://www.eventhelix.com/RealtimeMantra/Object_Oriented/open_closed_principle.htm Open Closed Principle] which states that modules should be designed to be extended. A stable package is difficult to change but not difficult to extend. Stability does not therefore contradict our maintainability and extensibility requirements of elegant programming – we can still maintain a flexible system.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T20:03:37Z

Mbsimmon: Add SDP.

== Introduction ==

The objective of this document is to introduce a series of design patterns developed by '''Robert C. Martin''' (Uncle Bob) that relate to packages.

[http://today.java.net/pub/au/90 Robert C. Miller] defines the [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf domain of design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. He sites the need for design patterns being to address the four major reasons that designs 'rot,' rigidity, fragility, immobility and viscosity.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf RIGIDITY] phenomenon occurs when software managers become reluctant to address minor changes because fixing them inevitably causes other defects due to design flaws, which may end up being more numerous and severe than the original defect addressed. The result is that the software becomes rigid – it does not change as change is needed.

*The [http://www.objectmentor.com/resources/articles/oodmetrc.pdf FRAGILITY] phenomenon is similar to rigidity in that the software system is so poorly designed one small defect fix or enhancement leads to numerous other defects. In fact, software rigidity is a direct result of software fragility.

*Software [http://linux.dell.com/libsmbios/main/presentation.html IMMOBILITY] occurs when software is either coupled so tightly or encapsulation is so improperly managed that the system, component or module can't be used in either other systems or the current system in other places.

*VISCOSITY (of design) is a quantitative or estimated measure of how easy it is when making a change to follow good design principles vs. implementing a hack. If it is always easier to implement a hack, viscosity is high.

The following design principles are designed to avoid the pitfalls associated with the above four reasons of unsuccessful software engineering. The first three are concerned with the cohesion of packages – how they are stuck together or constructed. The last three are concerned with the coupling of packages, or the degree to which they rely on each other.

== [http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalency Principle] ==

<blockquote>
''The granule of reuse is the granule of release. Only components that are released through a tracking system can be efficiently reused.''
</blockquote>

The idea behind this principle is based on client needs. It should not be expected of a user to upgrade the system whenever the designer implements a change to an external component. Because upgrading is sometimes a slow process with a high potential for difficulties that need to be managed, it is usually a process that is implemented with a great deal of care – and sometimes avoidance. Because of this, authors that don't implement a release system and ensure that older versions of a system are maintained for a period of time don't support reuse in that the demand for their components will decrease greatly.

To illustrate this principle, consider the third-party image processing libraries provided by Leadtools, Inc. These libraries and modules are release controlled and the company provides release support for various versions up to a specified time limit in the past. The reason for this is clear – without a release tracking mechanism users of their libraries would be forced to constantly upgrade as both major and minor changes were implemented. As upgrading can be a painful process, this type of solution would be less than ideal and users of Leadtools libraries would get their support elsewhere because the software would effectively be non-reusable.

== [http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle] ==

<blockquote>
''Classes that change together belong together.''
</blockquote>

This principle is concerned with the design of groupings of classes, or how packages should be organized. Experience has taught that the amount of testing required for a new release of a system is proportional to the number of packages that were changed in that system. If a package is changed, all functionality using that package must be tested regardless of whether individual classes within that package were utilized (this is due to the fact that classes can send messages to each other).

The common closure principle requires a bit for foresight and experience as it suggests that packages should encompass classes that are likely to change together. Doing so minimizes the number of packages that are effected by a change and therefore minimizes and adverse effect on a system as a whole as well as decreases the scope of required testing. In doing so, the effect of changes is minimized.

This type of thinking requires both experience and a good understanding of the environment in which the target system will be employed. When environment knowledge is limited, end users may be a good source as to the most likely changes that will occur to a system in the future (which is to say, if you don't know – ask).

== [http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle] ==

<blockquote>
''Classes that aren't reused together should not be grouped together.''
</blockquote>

This is another principle concerned with the grouping of classes into packages. The idea behind this principle is that classes which provide the same 'reuse' functionality will more than likely be used under the same set of circumstances. For example, consider an application that maintains information about patients in a Patient object. Certainly other objects will interact with Patient objects – Insurance objects, Employer objects, etc. Because these objects are likely to be used in concert with each other, they should be packaged together.

Consider what would happen if the class PatientCollection – which maintains a list of Patient objects as well as performs various operations on those Patient objects) were placed into Package A, but the Patient, Insurance, and Employer classes were placed in Package B. If this functionality set changes, both Package A and Package B change. As previously stated, when packages are changed, all code which uses those packages must be re-validated. If Package A also contains functionality used elsewhere in the using system, the validation required has been greatly increased.

== [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle] ==

<blockquote>
''The dependencies between packages should not form cycles.''
</blockquote>

When classes are arranged into packages, they should be done so in such a way that if Package A depends on Package B, it should not be the case that Package B depends on Package A (either directly or indirectly). In some cases, current IDEs such as Microsoft's Visual Studio prevent this from occurring at compile time by terminating the compilation process and reporting an error. Other IDEs allow it.

The problem associated with cycles presents itself when packages are modified. When modified, the package itself must be re-validated (obviously), but each package that uses it must be re-validated and so on. Its easy to see that with the introduction of cycles this leads to headaches. It gets complicated further by considering the following situation:

<pre>
Package A depends on Package B
Package B depends on Package C
Package C depends on Package D
Package D depends on Package A
</pre>

Not only does the aforementioned cycle present hardship when Package A is modified, but it does so when B, C and D are modified. The illustration above is fairly simple – imaging the complication added when several other packages are added with various dependencies on A, B, C and D. If there were no cycles, the prorogation effects of changing one package would terminate.

== [http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle] ==

<blockquote>
''Depend in the direction of stability.''
</blockquote>

In some sense, stability of a package increases with the number of packages that depend on it. A package of this nature is said to be responsible – that is, other packages depend on it (likewise, a package that depends on nothing is said to be independent). This follows the definition of stability being 'difficulty to change,' and a package that is responsible to a great number of packages is difficult to change because all dependent packages in the scenario need to be re-validated.

[http://today.java.net/pub/au/90 Martin] presents [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf metrics] used for calculating stability. Consider '''Ca''' to be the incoming dependencies of a package (referred to as afferent coupling) and '''Ce''' to be the number of all outgoing dependencies (referred to as efferent coupling). Then instability ('''I''') is a measure of the efferent divided by the sum of the afferent and the efferent, or:

'''I''' = '''Ce''' / ('''Ca''' + '''Ce''')

Which results in a number between zero and one. If there are no outgoing dependencies and at least one incoming dependency then '''I''' is zero and the package is stable. If there are no incoming dependencies and one outgoing then '''I''' is one and therefore the package is instable.

According to this design principle, “Depend upon packages whose I metric is lower than yours.” [http://today.java.net/pub/au/90 Martin].

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:55:04Z

Mbsimmon: Added ADP.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:53:09Z

Mbsimmon: Added CRP.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:47:24Z

Mbsimmon: Added CCP.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:44:38Z

Mbsimmon: Wording.

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:43:19Z

Mbsimmon: Added REP

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T19:37:56Z

Mbsimmon: The introduction

CSC/ECE 517 Fall 2007/wiki3 8 42

2007-11-19T02:41:36Z

Mbsimmon: Reservation of the page (data to follow).

This page is reserved for Matthew B. Simmons for Wiki 3 assignment on Robert Martin's design principles.

I will be transferring my notes from Open Office to this platform on Monday, November 19.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-30T15:47:26Z

Mbsimmon: Added outside links, gave a LISP multi-method example inline.

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to present the concepts of method '''overloading''' and method '''overriding'''. In doing so, it will contrast how method overriding is handled in common object-oriented programming languages (such as C#, Java or C++) and in multimethod languages.

== Overloading ==
Method [http://articles.techrepublic.com.com/5100-22-5074021.html overloading] occurs when there are two methods within the scope of a class that have the same name but different parameter list (and therefore different signatures). The scope of a class is not necessarily limited to the file that defines it, but it will also include methods from each superclass up the inheritance hierarchy.

The principal becomes a little more complicated when one considers the method in which the compiler uses to determine which overloaded method to activate when parameters involve subtypes. Consider the following partial class definitions taken from a national dental practice management system. In it there are Tooth objects and PerioTooth objects, which are a subclass of Tooth objects. There are also Restorations objects and PerioSplint objects, which are children of Restorations. The syntax is in C#.

<pre>
public class Tooth
{
    public bool AddRestoration(Restoration restoration) { }
}

public class PerioTooth : Tooth
{
    public bool AddRestoration(PerioSplint restoration) { }
}
</pre>

PerioTooth now has two overloaded methods AddRestoration() that add either a normal Restoration (the first definition) or a PerioSplint, which is specific to periodontal work (the second definition). They are both within the same class scope of PerioTooth.
Consider the following:

<pre>
Tooth tooth = new Tooth();
PerioTooth perioTooth = new PerioTooth();
Tooth ptTooth = new PerioTooth();

tooth.AddRestoration(new Restoration(Restorations.Amalgam, "MO", 32);
perioTooth.AddRestoration(new Restoration(Restorations.Composite, "O", 3);
ptTooth.AddRestoration(new PerioSplint("4-6");
</pre>

When the compiler sees calls to AddRestoration(), it first checks the type of the receiver of the call -- which is determined by the object type followed by the variable name when the object is instantiated. For example, Tooth in "Tooth tooth = new Tooth()" or PerioTooth in "PerioTooth tooth = new PerioTooth()." From there it begins looking for a signature match by using the types of the arguments.

Method overloading requires caution. A method should not be overloaded if it and the newly created method do not mirror functionality almost exactly. It would be counterintuitive to overload one AddRestoration() to add a Restoration object to a tooth and another AddRestoration() to determine the current temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), [http://www.akadia.com/services/dotnet_polymorphism.html overriding] occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class ImageButton
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void Paint(Graphics graphics, EventArgs e) { }
}

public class ToggleButton : ImageButton
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void Paint(Graphics graphics, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the ImageButton class. ToggleButton has a method Paint() that overrides the Paint() method of ImageButton that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<ImageButton> buttons = new List<ImageButton>();

buttons.add(new ImageButton());
buttons.add(new ToggleButton());
buttons.add(new ImageButton());
</pre>

...then polymorphism allows the following actions with the displayed results (in C# syntax):

<pre>
foreach (ImageButton button in buttons)
    button.Paint(this.CreateGraphics(), new EventArgs());

// iteration 1 -- calls ImageButton's Paint()
// iteration 2 -- calls ToggleButton's Paint()
// iteration 3 -- calls ImageButton's Paint()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the Paint() method.

Whereas overloading resolution was a function of the compiler, overriding resolution is a function of the runtime environment. With overloading, any decisions about which method to call was based first on the type the object was declared to be (for example, Tooth in Tooth ptTooth = new PerioTooth()). Overriding uses [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg dynamic method invocation] to look at the actual class type (PerioTooth in the aforementioned example) to determine which override to call. In the most common object-oriented languages, the types of the arguments are not considered.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message (dynamic method invocation illustrated above) and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored!

On the other hand, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call. In the above example, languages of this type would decide that since the person argument is of type Administrator, FormatPrint::Print(Administrator) will be selected and executed at runtime. The effect is that the code is "smarter" in such a way that it's flexibility is increased with the ability to differentiate receivers given this higher degree of information. For example, the following LISP example illustrates two methods that could be properly decided at runtime because of the argument types:

<pre>
(defmethod equals-to((x ficus) (y rose)))
(defmethod equals-to((x rose) (y ficus)))
</pre>

Contrast that with the decision algorithm of a non-multi-method language at runtime and the increased flexibility is clear.

<blockquote>
('''NOTE''': Although the LISP example presented does illustrate the power of the multi-method runtime decision methodology, it is considered bad form to overload methods by switching the order of the arguments. In practice, this should never be done.
</blockquote>

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

== Reference Summary ==
The following references were used in the text of or creation of this document:
* [http://articles.techrepublic.com.com/5100-22-5074021.html Method Overloading]
* [http://www.akadia.com/services/dotnet_polymorphism.html Method Overriding]
* [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg Dynamic Method Invocation]
* [http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)]
* [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]
* [http://c2.com/cgi/wiki?MultiMethods Multi-Method Language]
** [http://www.cs.cmu.edu/~fp/courses/03-312/handouts/20-objects-old.pdf Description (p. 4)]
** [http://en.wikipedia.org/wiki/Multiple_dispatch Good Example in Common Lisp]
** [http://www.cunei.com/files/TR-2001-81-cunei.pdf Language-Independent Discussion (ch. 2)]
* [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx Polymorphism]

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-30T15:13:26Z

Mbsimmon: Added a references table to gather and show existing outside links.

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to present the concepts of method '''overloading''' and method '''overriding'''. In doing so, it will contrast how method overriding is handled in common object-oriented programming languages (such as C#, Java or C++) and in multimethod languages.

== Overloading ==
Method [http://articles.techrepublic.com.com/5100-22-5074021.html overloading] occurs when there are two methods within the scope of a class that have the same name but different parameter list (and therefore different signatures). The scope of a class is not necessarily limited to the file that defines it, but it will also include methods from each superclass up the inheritance hierarchy.

The principal becomes a little more complicated when one considers the method in which the compiler uses to determine which overloaded method to activate when parameters involve subtypes. Consider the following partial class definitions taken from a national dental practice management system. In it there are Tooth objects and PerioTooth objects, which are a subclass of Tooth objects. There are also Restorations objects and PerioSplint objects, which are children of Restorations. The syntax is in C#.

<pre>
public class Tooth
{
    public bool AddRestoration(Restoration restoration) { }
}

public class PerioTooth : Tooth
{
    public bool AddRestoration(PerioSplint restoration) { }
}
</pre>

PerioTooth now has two overloaded methods AddRestoration() that add either a normal Restoration (the first definition) or a PerioSplint, which is specific to periodontal work (the second definition). They are both within the same class scope of PerioTooth.
Consider the following:

<pre>
Tooth tooth = new Tooth();
PerioTooth perioTooth = new PerioTooth();
Tooth ptTooth = new PerioTooth();

tooth.AddRestoration(new Restoration(Restorations.Amalgam, "MO", 32);
perioTooth.AddRestoration(new Restoration(Restorations.Composite, "O", 3);
ptTooth.AddRestoration(new PerioSplint("4-6");
</pre>

When the compiler sees calls to AddRestoration(), it first checks the type of the receiver of the call -- which is determined by the object type followed by the variable name when the object is instantiated. For example, Tooth in "Tooth tooth = new Tooth()" or PerioTooth in "PerioTooth tooth = new PerioTooth()." From there it begins looking for a signature match by using the types of the arguments.

Method overloading requires caution. A method should not be overloaded if it and the newly created method do not mirror functionality almost exactly. It would be counterintuitive to overload one AddRestoration() to add a Restoration object to a tooth and another AddRestoration() to determine the current temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), [http://www.akadia.com/services/dotnet_polymorphism.html overriding] occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class ImageButton
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void Paint(Graphics graphics, EventArgs e) { }
}

public class ToggleButton : ImageButton
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void Paint(Graphics graphics, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the ImageButton class. ToggleButton has a method Paint() that overrides the Paint() method of ImageButton that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<ImageButton> buttons = new List<ImageButton>();

buttons.add(new ImageButton());
buttons.add(new ToggleButton());
buttons.add(new ImageButton());
</pre>

...then polymorphism allows the following actions with the displayed results (in C# syntax):

<pre>
foreach (ImageButton button in buttons)
    button.Paint(this.CreateGraphics(), new EventArgs());

// iteration 1 -- calls ImageButton's Paint()
// iteration 2 -- calls ToggleButton's Paint()
// iteration 3 -- calls ImageButton's Paint()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the Paint() method.

Whereas overloading resolution was a function of the compiler, overriding resolution is a function of the runtime environment. With overloading, any decisions about which method to call was based first on the type the object was declared to be (for example, Tooth in Tooth ptTooth = new PerioTooth()). Overriding uses [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg dynamic method invocation] to look at the actual class type (PerioTooth in the aforementioned example) to determine which override to call. In the most common object-oriented languages, the types of the arguments are not considered.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message (dynamic method invocation illustrated above) and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored!

On the other hand, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call. In the above example, languages of this type would decide that since the person argument is of type Administrator, FormatPrint::Print(Administrator) will be selected and executed at runtime.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

== Reference Summary ==
The following references were used in the text of this document:
* [http://articles.techrepublic.com.com/5100-22-5074021.html Method Overloading]
* [http://www.akadia.com/services/dotnet_polymorphism.html Method Overriding]
* [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg Dynamic Method Invocation]
* [http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)]
* [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]
* [http://c2.com/cgi/wiki?MultiMethods Multi-Method Language]
* [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx Polymorphism]

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-27T22:23:24Z

Mbsimmon: elaboration

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to present the concepts of method '''overloading''' and method '''overriding'''. In doing so, it will contrast how method overriding is handled in common object-oriented programming languages (such as C#, Java or C++) and in multimethod languages.

== Overloading ==
Method [http://articles.techrepublic.com.com/5100-22-5074021.html overloading] occurs when there are two methods within the scope of a class that have the same name but different parameter list (and therefore different signatures). The scope of a class is not necessarily limited to the file that defines it, but it will also include methods from each superclass up the inheritance hierarchy.

The principal becomes a little more complicated when one considers the method in which the compiler uses to determine which overloaded method to activate when parameters involve subtypes. Consider the following partial class definitions taken from a national dental practice management system. In it there are Tooth objects and PerioTooth objects, which are a subclass of Tooth objects. There are also Restorations objects and PerioSplint objects, which are children of Restorations. The syntax is in C#.

<pre>
public class Tooth
{
    public bool AddRestoration(Restoration restoration) { }
}

public class PerioTooth : Tooth
{
    public bool AddRestoration(PerioSplint restoration) { }
}
</pre>

PerioTooth now has two overloaded methods AddRestoration() that add either a normal Restoration (the first definition) or a PerioSplint, which is specific to periodontal work (the second definition). They are both within the same class scope of PerioTooth.
Consider the following:

<pre>
Tooth tooth = new Tooth();
PerioTooth perioTooth = new PerioTooth();
Tooth ptTooth = new PerioTooth();

tooth.AddRestoration(new Restoration(Restorations.Amalgam, "MO", 32);
perioTooth.AddRestoration(new Restoration(Restorations.Composite, "O", 3);
ptTooth.AddRestoration(new PerioSplint("4-6");
</pre>

When the compiler sees calls to AddRestoration(), it first checks the type of the receiver of the call -- which is determined by the object type followed by the variable name when the object is instantiated. For example, Tooth in "Tooth tooth = new Tooth()" or PerioTooth in "PerioTooth tooth = new PerioTooth()." From there it begins looking for a signature match by using the types of the arguments.

Method overloading requires caution. A method should not be overloaded if it and the newly created method do not mirror functionality almost exactly. It would be counterintuitive to overload one AddRestoration() to add a Restoration object to a tooth and another AddRestoration() to determine the current temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), [http://www.akadia.com/services/dotnet_polymorphism.html overriding] occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class ImageButton
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void Paint(Graphics graphics, EventArgs e) { }
}

public class ToggleButton : ImageButton
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void Paint(Graphics graphics, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the ImageButton class. ToggleButton has a method Paint() that overrides the Paint() method of ImageButton that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<ImageButton> buttons = new List<ImageButton>();

buttons.add(new ImageButton());
buttons.add(new ToggleButton());
buttons.add(new ImageButton());
</pre>

...then polymorphism allows the following actions with the displayed results (in C# syntax):

<pre>
foreach (ImageButton button in buttons)
    button.Paint(this.CreateGraphics(), new EventArgs());

// iteration 1 -- calls ImageButton's Paint()
// iteration 2 -- calls ToggleButton's Paint()
// iteration 3 -- calls ImageButton's Paint()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the Paint() method.

Whereas overloading resolution was a function of the compiler, overriding resolution is a function of the runtime environment. With overloading, any decisions about which method to call was based first on the type the object was declared to be (for example, Tooth in Tooth ptTooth = new PerioTooth()). Overriding uses [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg dynamic method invocation] to look at the actual class type (PerioTooth in the aforementioned example) to determine which override to call. In the most common object-oriented languages, the types of the arguments are not considered.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message (dynamic method invocation illustrated above) and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored!

On the other hand, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call. In the above example, languages of this type would decide that since the person argument is of type Administrator, FormatPrint::Print(Administrator) will be selected and executed at runtime.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-27T22:22:05Z

Mbsimmon: Added more outside links, replaced the first example with one from a current project, expanded the discussion on multimethods by better identifying the shortcoming of dynamic method invocation.

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to present the concepts of method '''overloading''' and method '''overriding'''. In doing so, it will contrast how method overriding is handled in common object-oriented programming languages (such as C#, Java or C++) and in multimethod languages.

== Overloading ==
Method [http://articles.techrepublic.com.com/5100-22-5074021.html overloading] occurs when there are two methods within the scope of a class that have the same name but different parameter list (and therefore different signatures). The scope of a class is not necessarily limited to the file that defines it, but it will also include methods from each superclass up the inheritance hierarchy.

The principal becomes a little more complicated when one considers the method in which the compiler uses to determine which overloaded method to activate when parameters involve subtypes. Consider the following partial class definitions taken from a national dental practice management system. In it there are Tooth objects and PerioTooth objects, which are a subclass of Tooth objects. There are also Restorations objects and PerioSplint objects, which are children of Restorations. The syntax is in C#.

<pre>
public class Tooth
{
    public bool AddRestoration(Restoration restoration) { }
}

public class PerioTooth : Tooth
{
    public bool AddRestoration(PerioSplint restoration) { }
}
</pre>

PerioTooth now has two overloaded methods AddRestoration() that add either a normal Restoration (the first definition) or a PerioSplint, which is specific to periodontal work (the second definition). They are both within the same class scope of PerioTooth.
Consider the following:

<pre>
Tooth tooth = new Tooth();
PerioTooth perioTooth = new PerioTooth();
Tooth ptTooth = new PerioTooth();

tooth.AddRestoration(new Restoration(Restorations.Amalgam, "MO", 32);
perioTooth.AddRestoration(new Restoration(Restorations.Composite, "O", 3);
ptTooth.AddRestoration(new PerioSplint("4-6");
</pre>

When the compiler sees calls to AddRestoration(), it first checks the type of the receiver of the call -- which is determined by the object type followed by the variable name when the object is instantiated. For example, Tooth in "Tooth tooth = new Tooth()" or PerioTooth in "PerioTooth tooth = new PerioTooth()." From there it begins looking for a signature match by using the types of the arguments.

Method overloading requires caution. A method should not be overloaded if it and the newly created method do not mirror functionality almost exactly. It would be counterintuitive to overload one AddRestoration() to add a Restoration object to a tooth and another AddRestoration() to determine the current temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), [http://www.akadia.com/services/dotnet_polymorphism.html overriding] occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class ImageButton
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void Paint(Graphics graphics, EventArgs e) { }
}

public class ToggleButton : ImageButton
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void Paint(Graphics graphics, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the ImageButton class. ToggleButton has a method Paint() that overrides the Paint() method of ImageButton that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<ImageButton> buttons = new List<ImageButton>();

buttons.add(new ImageButton());
buttons.add(new ToggleButton());
buttons.add(new ImageButton());
</pre>

...then polymorphism allows the following actions with the displayed results (in C# syntax):

<pre>
foreach (ImageButton button in buttons)
    button.Paint(this.CreateGraphics(), new EventArgs());

// iteration 1 -- calls ImageButton's Paint()
// iteration 2 -- calls ToggleButton's Paint()
// iteration 3 -- calls ImageButton's Paint()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the Paint() method.

Whereas overloading resolution was a function of the compiler, overriding resolution is a function of the runtime environment. With overloading, any decisions about which method to call was based first on the type the object was declared to be (for example, Tooth in Tooth ptTooth = new PerioTooth()). Overriding uses [http://books.google.com/books?id=6N3LNLR4-JAC&pg=PA212&lpg=PA212&dq=%22dynamic+method+invocation%22+overriding+runtime&source=web&ots=4qXmo_tNRm&sig=wWdg7JgweJwWw3e2RZkr7g4Rwgg dynamic method invocation] to look at the actual class type (PerioTooth in the aforementioned example) to determine which override to call. In the most common object-oriented languages, the types of the arguments are not considered.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored!

On the other hand, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call. In the above example, languages of this type would decide that since the person argument is of type Administrator, FormatPrint::Print(Administrator) will be selected and executed at runtime.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-24T23:38:56Z

Mbsimmon:

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to briefly review '''overloading''' and '''overriding''' and to compare/contrast the different way overriding is handled in ''multimethod'' programming languages (like CLOS) and ''non-multimethod'' languages (like C#, Java or C++).

== Overloading ==
Method overloading occurs when one or more methods within the scope of a class share the same name but differ in their parameter list. Parameters are differentiated by their type and not their names; parameter names can be changed at will (but of course should properly relate to the objects they represent). For example, the following class definition contains an overloaded method:

<pre>
public class Pages
{
    // add an integer to this list of pages
    public bool AddPage(int page) { }

    // parse the string argument to an int and
    // add it to this list of pages (via overloaded AddPage(int))
    public bool AddPage(string page) { }

}
</pre>

Notice that there are two methods named AddPage(), but the type of their argument differs; one method accepts an integer and adds it to an accumulator and one method accepts a string, first parsing it to an int and then adding it to an accumulator (via the AddPage(int) method). Ultimately both methods accomplish the same task -- which is a fundamental design rule when choosing to overload methods. Methods should never be overloaded unless their functionality closely mirrors that of the method(s) that it overrides. It is counterintuitive to have one AddPage() method that adds pages to an accumulator and one AddPage() method that determines the temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), overriding occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class Button
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void OnClick(object sender, EventArgs e) { }
}

public class ToggleButton : Button
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void OnClick(object sender, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the Button class. ToggleButton has a method OnClick() that overrides the OnClick() method of Button that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<Button> buttons = new List<Button>();

buttons.add(new Button());
buttons.add(new ToggleButton());
buttons.add(new Button());
</pre>

...then polymorphism allows the following actions with the displayed results:

<pre>
foreach (Button button in buttons)
    button.OnClick(this, new EventArgs());

// iteration 1 -- calls Button's OnClick()
// iteration 2 -- calls ToggleButton's OnClick()
// iteration 3 -- calls Button's OnClick()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the OnClick() method.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored!

On the other hand, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call. In the above example, languages of this type would decide that since the person argument is of type Administrator, FormatPrint::Print(Administrator) will be selected and executed at runtime.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-24T23:34:34Z

Mbsimmon:

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to briefly review '''overloading''' and '''overriding''' and to compare/contrast the different way overriding is handled in ''multimethod'' programming languages (like CLOS) and ''non-multimethod'' languages (like C#, Java or C++).

== Overloading ==
Method overloading occurs when one or more methods within the scope of a class share the same name but differ in their parameter list. Parameters are differentiated by their type and not their names; parameter names can be changed at will (but of course should properly relate to the objects they represent). For example, the following class definition contains an overloaded method:

<pre>
public class Pages
{
    // add an integer to this list of pages
    public bool AddPage(int page) { }

    // parse the string argument to an int and
    // add it to this list of pages (via overloaded AddPage(int))
    public bool AddPage(string page) { }

}
</pre>

Notice that there are two methods named AddPage(), but the type of their argument differs; one method accepts an integer and adds it to an accumulator and one method accepts a string, first parsing it to an int and then adding it to an accumulator (via the AddPage(int) method). Ultimately both methods accomplish the same task -- which is a fundamental design rule when choosing to overload methods. Methods should never be overloaded unless their functionality closely mirrors that of the method(s) that it overrides. It is counterintuitive to have one AddPage() method that adds pages to an accumulator and one AddPage() method that determines the temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), overriding occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class Button
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void OnClick(object sender, EventArgs e) { }
}

public class ToggleButton : Button
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void OnClick(object sender, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the Button class. ToggleButton has a method OnClick() that overrides the OnClick() method of Button that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt>) -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<Button> buttons = new List<Button>();

buttons.add(new Button());
buttons.add(new ToggleButton());
buttons.add(new Button());
</pre>

...then polymorphism allows the following actions with the displayed results:

<pre>
foreach (Button button in buttons)
    button.OnClick(this, new EventArgs());

// iteration 1 -- calls Button's OnClick()
// iteration 2 -- calls ToggleButton's OnClick()
// iteration 3 -- calls Button's OnClick()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the OnClick() method.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored! However, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-24T22:45:49Z

Mbsimmon: Loading from Word notes

Author: Matthew B. Simmons

== Objective ==
The objective of this document is to briefly review '''overloading''' and '''overriding''' and to compare/contrast the different way overriding is handled in ''multimethod'' programming languages (like CLOS) and ''non-multimethod'' languages (like C#, Java or C++).

== Overloading ==
Method overloading occurs when one or more methods within the scope of a class share the same name but differ in their parameter list. Parameters are differentiated by their type and not their names; parameter names can be changed at will (but of course should properly relate to the objects they represent). For example, the following class definition contains an overloaded method:

<pre>
public class Pages
{
    // add an integer to this list of pages
    public bool AddPage(int page) { }

    // parse the string argument to an int and
    // add it to this list of pages (via overloaded AddPage(int))
    public bool AddPage(string page) { }

}
</pre>

Notice that there are two methods named AddPage(), but the type of their argument differs; one method accepts an integer and adds it to an accumulator and one method accepts a string, first parsing it to an int and then adding it to an accumulator (via the AddPage(int) method). Ultimately both methods accomplish the same task -- which is a fundamental design rule when choosing to overload methods. Methods should never be overloaded unless their functionality closely mirrors that of the method(s) that it overrides. It is counterintuitive to have one AddPage() method that adds pages to an accumulator and one AddPage() method that determines the temperature in Guatemala!

== Overriding ==
Where overloading was creating methods with the same name and different arguments (and therefore a different signature), overriding occurs when a method replaces another method further up the inheritance hierarchy that has the same signature. For example, consider the following classes:

<pre>
public class Button
{
    // in C#, the keyword virtual indicates that a method can be overridden
    public virtual void OnClick(object sender, EventArgs e) { }
}

public class ToggleButton : Button
{
    // in C#, overriding is an EXPLICIT action by using the keyword override
    public override void OnClick(object sender, EventArgs e) { }
}
</pre>

The ToggleButton class inherits directly from the Button class. ToggleButton has a method OnClick() that overrides the OnClick() method of Button that was inherited. Notice that C# above mandates explicit overriding (the use of the keyword <tt>override</tt> -- other languages such as Java allow for implicit overriding, where methods with the same signature automatically override their inherited methods without the use of an <tt>override</tt> keyword.

One major advantage of overriding methods is that you get [http://msdn2.microsoft.com/en-us/library/ms173152(VS.80).aspx polymorphic behavior]. For example, if a List object was created and populated as...

<pre>
List<Button> buttons = new List<Button>();

buttons.add(new Button());
buttons.add(new ToggleButton());
buttons.add(new Button());
</pre>

...then polymorphism allows the following actions with the displayed results:

<pre>
foreach (Button button in buttons)
    button.OnClick(this, new EventArgs());

// iteration 1 -- calls Button's OnClick()
// iteration 2 -- calls ToggleButton's OnClick()
// iteration 3 -- calls Button's OnClick()
</pre>

This dynamic method invocation (the decision about which method to call being made at runtime) is the polymorphic behavior that was produced from overriding the OnClick() method.

=== CLOS (see-loss or kloss) and Multi-Method Language Overriding ===
[http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common List Object System (CLOS)] is a dynamic object oriented language that is an extension of [http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html Common Lisp]. It is a [http://c2.com/cgi/wiki?MultiMethods multi-method language]. A multi-method language is distinguishable from non multi-method languages by the decision mechanism by which overridden methods are chosen at runtime.

In more common object oriented languages (like Java or C#), the runtime decision about which overloaded is made is based on the type of the object being sent the message and NOT the type of the arguments to that message. At compile time, the type of the arguments is used to determine an appropriate method in the set of overloaded methods that match a given signature, but this action is strictly a strategy of the compiler to check for valid code. At runtime, the type of the arguments play no role.

For example, consider the following example in C#:

<pre>
public class Person
{
    public string name = string.Empty;
}

public class User : Person { }
public class Administrator : Person { }
public class Maintainer : Person { }

public class FormatPrint
{
    public void Print(User person) { MessageBox.Show("User"); }
    public void Print(Administrator person) { MessageBox.Show("Administrator"); }
    public void Print(Maintainer person) { MessageBox.Show("Maintainer"); }
}
</pre>

The following code will not run using C# because it is unable to decide which Print() method to call!

<pre>
FormatPrint formatPrint = new FormatPrint();
Person person = new Administrator();
print.Print(person);
</pre>

C# is unable to determine which method to call because it is unable to figure out what person really is because it is an argument -- the fact that it is an Administrator is ignored! However, a multi-method language such as CLOS considers the argument types at runtime and will determine which Print() method to call.

=== C# and Non Multi-Method Language Overriding ===
Unlike CLOS, C# (and other popular object oriented languages like Java) is not a multi-method language so the decision about which overridden method to call at runtime is based on the type of the object being sent the message. Consider the following modification to the above code:

<pre>
public class Person
{
    public string name = string.Empty;
    public virtual void Print() { };
}

public class User : Person
{
    public override void Print() { MessageBox.Show("User"); }
}

public class Administrator : Person
{
    public override void Print() { MessageBox.Show("Administrator"); }
}

public class Maintainer : Person
{
    public override void Print() { MessageBox.Show("Maintainer"); }
}
</pre>

Note that the following code decides which overridden method to call based on the type of argument before the message Print().

<pre>
List<Person> people = new List<Person>();
people.Add(new Administrator());
people.Add(new Maintainer());
people.Add(new User());

// prints "Administrator"
people[0].Print();

// prints "Maintainer"
people[1].Print();

// prints "User"
people[2].Print();
</pre>

== Summary ==
Overloading happens when methods in the scope of a class share the name but differ in the type of arguments passed. The methods do not share a common signature. Conversely, overriding a method happens when the method a method has the exact signature of one that the class inherited -- in which case the new method replaces the old one. Multi-method languages differ from non-multi-method languages in how they decide which of the method to invoke. Multi-method languages use the type of the arguments whereas non multi-method languages use the type of the object being sent the message.

CSC/ECE 517 Fall 2007/wiki2 8 42

2007-10-24T18:13:46Z

Mbsimmon: Beginning to import data.

Beginning to import data.

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-22T02:33:27Z

Mbsimmon: Added dynamic extention of modules by instantiated objects.

This page is a response to the following assignment:

<blockquote>
''Devise one or more practical examples of Ruby's extend method--that is, examples that serve a real need and are not contrived. (If you can find existing examples on the Web, critique their practicality.) For inspiration, you might want to read up on prototype-based languages.''
</blockquote>

The objective is to educate through example the proper use of Ruby's '''extend''' method and in doing so briefly introduce modules and the '''include''' method to illustrate how it differs from '''extend'''. The design described in this solution is based on a software system implemented by the author. As the assignment asks for originality of example, external links are minimized. However, other examples are referenced at the end of the document.

<center>----------</center>

== Introduction ==

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class definition at the class level or to an instantiated object dynamically. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

== Module ==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

<pre>
# module for encapsulating benefit calculation functionality
module BenefitCalculation

# call to get the appropriate charge for a procedure
# assume the appropriate arguments are sent in
def getPatientCharge
puts “getPatientCharge from BenefitCalculation”
end

# call to get the appropriate copay for a given procedure and insurance type
# assume the appropriate arguments are sent in
def getCopay
puts “getCopay from BenefitCalculation”
end

end
</pre>

== Extend Example ==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

<pre>
# Service is the base class for our system.
class Service

# call to get the address of the service center
def getAddress
puts “getAddress from Service”
end

end

class DentalService < Service
# added functionality for dental services
end

class MedicalService < Service
# added functionality for medical services
end

class OpticalService < Service
# added functionality for optical services
end

class HomeopathicService < Service
# added functionality for homeopathic services
end
</pre>

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

Another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three - Extend'''''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

<pre>
class DentalService < Service
# added functionality for dental services

extend BenefitCalculation
end

class MedicalService < Service
# added functionality for medical services

extend BenefitCalculation
end
</pre>

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::'''irb'''> medical = MedicalService.new

:::'''irb'''> optical = OpticalService.new

:::'''irb'''> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::'''irb'''> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::'''irb'''> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::'''irb'''> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::'''irb'''> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

Another option would be to use extend to add the functionality of the module dynamically to individual objects instead of statically to the class definitions. When doing this, the functionality can be called at the individual object level. If we return to our original definition of MedicalService (with no module extended in the class definition), we can add the module functionality to the instantiated object dynamically as follows:

:::'''irb'''> medical = MedicalService.new

:::'''irb'''> medical.extend(BenefitCalculation)

:::'''irb'''> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation</nowiki>

The software system used in this example is being developed using C# on the Microsoft .NET platform, and modules like those in Ruby are unavailable. In order to get around the problems illustrated in options one and two above, BenefitCalculation functionality is itself implemented in a class containing static methods, and in order to perform the appropriate calculations the corresponding BenefitCalculation method is called and sent the appropriate arguments, as illustrated below:

<pre>
public class Service
{
public virtual float getPatientCharge()
{
return float.MinValue; // indicates nothing was calculated
}
}

public class MedicalService : Service
{
public override float getPatientCharge()
{
return BenefitCalculation.getPatientCharge();
}
}
</pre>

Notice that there is only one copy of the benefit calculation code in the C# solution, so the problem presented by option one is avoided. Likewise, HomeopathicService simply doesn't override getPatientCharge(), so the inappropriate inheritance of functionality illustrated in option two is also avoided. The difference is that objects of type MedicalService no longer contains the functionality for calculating the patient charge, but can get to it. Static languages by nature don't allow the dynamic addition of functionality as illustrated above, so that was not an option for this project.

== Caution ==

Again take note that the use of extend lets us call module functionality at the ''class level'' if used in the context of the class definition. In this same context, were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::'''irb'''> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

<pre>
class MedicalService < Service
# added functionality for medical services

include BenefitCalculation
end
</pre>

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::'''irb'''> medical = MedicalService.new

::::'''irb'''> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::'''irb'''> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::'''irb'''> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::'''irb'''> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

== References ==

A [http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ Ruby module tutorial] illustrating of the uses of '''extend''' and '''include'''.

Another [http://www.rabbitcreative.com/2007/07/27/create-class-level-methods-when-including-a-module-in-ruby/ Ruby module tutorial] again illustrating the uses of '''extend''' and '''include'''.

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-19T18:59:55Z

Mbsimmon: Implemented most changes requested by reviewers. Added links to other examples, properly stated purpose of exercise in response to added information requests, used code blocks vs. syntax highlighting

This page is a response to the following assignment:

<blockquote>
''Devise one or more practical examples of Ruby's extend method--that is, examples that serve a real need and are not contrived. (If you can find existing examples on the Web, critique their practicality.) For inspiration, you might want to read up on prototype-based languages.''
</blockquote>

The objective is to educate through example the proper use of Ruby's '''extend''' method and in doing so briefly introduce modules and the '''include''' method to illustrate how it differs from '''extend'''. The design described in this solution is based on a software system implemented by the author. As the assignment asks for originality of example, external links are minimized. However, other examples are referenced at the end of the document.

<center>----------</center>

== Introduction ==

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

== Module ==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

<pre>
# module for encapsulating benefit calculation functionality
BenefitCalculation

# call to get the appropriate charge for a procedure
# assume the appropriate arguments are sent in
def getPatientCharge
puts “getPatientCharge from BenefitCalculation”
end

# call to get the appropriate copay for a given procedure and insurance type
# assume the appropriate arguments are sent in
def getCopay
puts “getCopay from BenefitCalculation”
end

end
</pre>

== Extend Example ==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

<pre>
# Service is the base class for our system.
class Service

# call to get the address of the service center
def getAddress
puts “getAddress from Service”
end

end

class DentalService < Service
# added functionality for dental services
end

class MedicalService < Service
# added functionality for medical services
end

class OpticalService < Service
# added functionality for optical services
end

class HomeopathicService < Service
# added functionality for homeopathic services
end
</pre>

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

Another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three - Extend'''''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

<pre>
class DentalService < Service
# added functionality for dental services

extend BenefitCalculation
end

class MedicalService < Service
# added functionality for medical services

extend BenefitCalculation
end
</pre>

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::'''irb'''> medical = MedicalService.new

:::'''irb'''> optical = OpticalService.new

:::'''irb'''> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::'''irb'''> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::'''irb'''> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::'''irb'''> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::'''irb'''> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

The software system used in this example is being developed using C# on the Microsoft .NET platform, and modules like those in Ruby are unavailable. In order to get around the problems illustrated in options one and two above, BenefitCalculation functionality is itself implemented in a class containing static methods, and in order to perform the appropriate calculations the corresponding BenefitCalculation method is called and sent the appropriate arguments, as illustrated below:

<pre>
public class Service
{
public virtual float getPatientCharge()
{
return float.MinValue; // indicates nothing was calculated
}
}

public class MedicalService : Service
{
public override float getPatientCharge()
{
return BenefitCalculation.getPatientCharge();
}
}
</pre>

Notice that there is only one copy of the benefit calculation code in the C# solution, so the problem presented by option one is avoided. Likewise, HomeopathicService simply doesn't override getPatientCharge(), so the inappropriate inheritance of functionality illustrated in option two is also avoided. The difference is that objects of type MedicalService no longer contains the functionality for calculating the patient charge, but can get to it.

== Caution ==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::'''irb'''> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

<pre>
class MedicalService < Service
# added functionality for medical services

include BenefitCalculation
end
</pre>

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::'''irb'''> medical = MedicalService.new

::::'''irb'''> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::'''irb'''> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::'''irb'''> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::'''irb'''> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

== References ==

A [http://www.juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ Ruby module tutorial] illustrating of the uses of '''extend''' and '''include'''.

Another [http://www.rabbitcreative.com/2007/07/27/create-class-level-methods-when-including-a-module-in-ruby/ Ruby module tutorial] again illustrating the uses of '''extend''' and '''include'''.

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-14T20:37:39Z

Mbsimmon: Attempt to get a TOC

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

== Module ==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

== Extend Example ==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

Another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three - Extend'''''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

== Caution ==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-14T20:18:39Z

Mbsimmon: Made a cosmetic change under Option Two

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

Another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three - Extend'''''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T20:18:45Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three - Extend'''''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T20:17:53Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

Option One

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

Option Two

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

Option Three - Extend

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T20:15:44Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T20:14:34Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but there would also be functionality common to all services in a base class.

A possible high-level design of the software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are others for which it is not. In our example, let’s consider dental and medical services to be the only services appropriate for insurance support. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times the code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a good solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this solution we solve the problems from options one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''extend''' BenefitCalculation
:'''end'''

Now that we have a clean design, let's execute some code in the IRB and see the results. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend lets us call module functionality at the ''class level''. Were we to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>

::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical = MedicalService.new

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T19:55:28Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to explain the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but surely there would be functionality that would be common to all services in a base class.

A possible design of the high-level software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are some services for which it is not. In our example, let’s consider dental and medical services to be appropriate for insurance support while optical and homeopathic services to not be appropriate for it. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this we solve problems one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

Now that we have our design requirements fulfilled, we can execute the code in the IRB and see what we get. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend let us call module functionality at the '''class level'''. Were we to try to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T19:53:22Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects, which is to say that alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to illustrate the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but surely there would be functionality that would be common to all services in a base class.

A possible design of the high-level software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are some services for which it is not. In our example, let’s consider dental and medical services to be appropriate for insurance support while optical and homeopathic services to not be appropriate for it. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this we solve problems one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

Now that we have our design requirements fulfilled, we can execute the code in the IRB and see what we get. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend let us call module functionality at the '''class level'''. Were we to try to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T19:51:43Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects. Alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to illustrate the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but surely there would be functionality that would be common to all services in a base class.

A possible design of the high-level software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are some services for which it is not. In our example, let’s consider dental and medical services to be appropriate for insurance support while optical and homeopathic services to not be appropriate for it. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this we solve problems one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

Now that we have our design requirements fulfilled, we can execute the code in the IRB and see what we get. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend let us call module functionality at the '''class level'''. Were we to try to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T19:49:46Z

Mbsimmon:

The '''extend''' method in Ruby is designed to mix in methods of a '''module''' to a class at the class level. The term ‘class level’ is synonymous with the concept of ''static'' in other popular object oriented languages such as Java or C# where static behaviors and attributes exist independently of any instance of the class.

==Module==

Before presenting an example of the '''extend''' method, it is necessary to briefly define modules and introduce a small example.

A '''module''' is a collection of functionality that cannot be used to create objects. Alone it does not define a type. It exists to group functionality that will be used by objects either at the implementation level or the class level, depending on the mechanism by which it was added.

Below is an example of a module in Ruby. Its purpose is to group benefit calculation functionality for procedures performed at a general treatment facility. It has been simplified for illustration purposes – in practice benefit calculation is immensely complicated.

:<nowiki># module for encapsulating benefit calculation functionality</nowiki>
:'''module''' BenefitCalculation

::'''def''' getPatientCharge
:::'''puts''' “getPatientCharge from BenefitCalculation”
::'''end'''

::'''def''' getCopay
:::'''puts''' “getCopay from BenefitCalculation”
::'''end'''

:'''end'''

==Extend Example==

The most effective way to illustrate the use of extending a module is through an example, so consider a full-service treatment center (like a hospital) that provides medical, dental, optical and homeopathic services. A software solution developed to support this type of organization may consist of four modules to encapsulate the functionality specific to their services, but surely there would be functionality that would be common to all services in a base class.

A possible design of the high-level software architecture follows:

:<nowiki># Service is the base class for our system.</nowiki>
:'''class''' Service

::'''def''' getAddress
:::'''puts''' “getAddress from Service”
::'''end'''

:'''end'''

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
: '''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
:'''end'''

:'''class''' OpticalService < Service
::<nowiki># added functionality for optical services</nowiki>
:'''end'''

:'''class''' HomeopathicService < Service
::<nowiki># added functionality for homeopathic services</nowiki>
:'''end'''

Now consider that there are some services for which insurance is an option, and there are some services for which it is not. In our example, let’s consider dental and medical services to be appropriate for insurance support while optical and homeopathic services to not be appropriate for it. ''Where would be a good place to encode the insurance benefit calculation?''

'''''Option One'''''

We could place it in the specific classes that accept insurance support (DentalService and MedicalService), but in doing so we would be duplicating code. Code duplication becomes a maintenance nightmare, and the difficulty grows rapidly with the number of times code is duplicated. For this reason, it would probably be a bad idea to place the needed code directly into the class definitions of DentalService and MedicalService.

'''''Option Two'''''

A another option would be to define the functionality in the base class Service. This would allow us to maintain one copy of the code so that when benefit calculation changes (as it does almost weekly), changes could be made in one place and thus maintenance time is minimized. The problem with this solution is that OpticalService and HomeopathicService also inherit the functionality. Because services of their type do not support insurance, the functionality is inappropriate for their type definitions.

'''''Option Three'' - Extend'''

Ruby provides a solution to this problem. Using the extend method, we can place the needed benefit calculation functionality inside of a module and extend that module where it is appropriate. With this we solve problems one and two illustrated above: 1) there is a single copy of the functionality in our solution and 2) the functionality is only added to the types for which it is appropriate.

Modifying our hierarchy above to fit this solution, we end up with the following:

:'''class''' DentalService < Service
::<nowiki># added functionality for dental services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''extend''' BenefitCalculation
:'''end'''

Now that we have our design requirements fulfilled, we can execute the code in the IRB and see what we get. Assume the module and all class definitions have been loaded.

:::irb> medical = MedicalService.new

:::irb> optical = OpticalService.new

:::irb> optical.getAddress
:::::<nowiki># yields 'getAddress from Service'</nowiki>

:::irb> OpticalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> OpticalService.getCopay
:::::<nowiki># yields NoMethodError (we didn’t extend)</nowiki>

:::irb> DentalService.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

:::irb> DentalService.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

==Caution==

Again take note that the use of extend let us call module functionality at the '''class level'''. Were we to try to attempt to call extended functionality at the object level we would get a NoMethodError.

::::irb> medical.getCopay
:::::<nowiki># yields NoMethodError</nowiki>

If you need to add module functionality at the object level, use '''include''' instead of '''extend'''. Consider the following new definition of the MedicalService class:

:'''class''' MedicalService < Service
::<nowiki># added functionality for medical services</nowiki>
::'''include''' BenefitCalculation
:'''end'''

Observe the behavior of the following calls executed in the IRB and the results. Compare the output listed here with the output above.

::::irb> medical.getPatientCharge
:::::<nowiki># yields 'getPatientCharge from BenefitCalculation'</nowiki>

::::irb> medical.getCopay
:::::<nowiki># yields 'getCopay from BenefitCalculation'</nowiki>

::::irb> MedicalService.getPatientCharge
:::::<nowiki># yields NoMethodError (we used include)</nowiki>

::::irb> MedicalService.getCopay
:::::<nowiki># yields NoMethodError (us used include)</nowiki>

CSC/ECE 517 Fall 2007/wiki1 8 s1

2007-09-12T19:12:15Z

Mbsimmon: