|
|
| Line 1: |
Line 1: |
| '''<font size=4>Single choice principle'''</font> | | '''<font size=4>Single choice principle'''</font> |
| <br>Bertrand Meyer is the author of the book, "Object Oriented Software Construction", which is considered a foundational text of object-oriented programming book. In this book, he has mentioned about the five principles which explain modularity requirements. This wiki will explore through the Single Choice Principle in particular and its usage. | | <br>Bertrand Meyer is the author of the book, "Object Oriented Software Construction", which is considered a foundational text of object-oriented programming book. In this book, he has mentioned about the five principles which explain modularity requirements. This wiki will explore through the Single Choice Principle in particular and its usage. |
|
| |
| = Single Choice Principle =
| |
| This article explains in detail about the single choice principle which is one of the five modularity principles.
| |
|
| |
|
| == Modularity == | | == Modularity == |
| Modular Programming is used to break up a large program into small sub programs like functions and subroutines. These broken up pieces are called as modules.
| |
|
| |
| == Insight ==
| |
| The various '''fundamental requirements''' resulting from a "modular" design method are :
| |
|
| |
| <ul>
| |
| <li>'''DECOMPOSABILITY'''<br>
| |
| Meyer defined decomposability as :
| |
| <pre>
| |
| " A software construction method satisfies Modular Decomposability if : it helps in the task of decomposing a software problem into a small number of less complex sub problems, connected by a simple structure, and independent enough to allow further work to proceed separately on each of them."
| |
| </pre>
| |
| [[Image:Criteria1-decomposability.JPG]]
| |
| </li>
| |
| <li>'''COMPOSABILITY'''
| |
| <br>[[Image:Criteria2-composability.JPG]]</li>
| |
| <li>'''UNDERSTANDABILITY'''
| |
| <br>
| |
| [[Image:Criteria3-understandability.JPG]]</li>
| |
| <li>'''CONTINUITY'''
| |
| <br>
| |
| [[Image:Criteria4-continuity.JPG]]</li>
| |
| <li>'''PROTECTION'''
| |
| <br>
| |
| [[Image:Criteria5-protection.JPG]]</li>
| |
| </ul>
| |
|
| |
| In order to ensure modularity the following five rules must be followed:
| |
| <ul>
| |
| <li>Direct mapping</li>
| |
| <li>Small interfaces(weak coupling)</li>
| |
| <li>Explicit interfaces</li>
| |
| <li>Information Hiding</li>
| |
| <li>Few interfaces</li>
| |
| </ul>
| |
|
| |
| There are five principles of software construction which are to be followed along with the above stated requirements and rules. They are:
| |
| <table width=100%>
| |
| <tr>
| |
| <td><b>The Linguistic Modular Units principle</b>
| |
| </td>
| |
| <td> <b> : </b> </td>
| |
| <td> </td>
| |
| <td>
| |
| This principle states that modules must correspond to syntactic units in the language used.
| |
| </td>
| |
| </tr>
| |
|
| |
| <tr>
| |
| <td>
| |
| <b>The self-documentation principle</b>
| |
| </td>
| |
| <td> <b> : </b> </td>
| |
| <td> </td>
| |
| <td>
| |
| This principle states that the designer of a module should strive to make all information about the module part of the module itself.
| |
| </td>
| |
| </tr>
| |
|
| |
| <tr>
| |
| <td>
| |
| <b>The uniform access principle</b>
| |
| </td>
| |
| <td> <b> : </b> </td>
| |
| <td> </td>
| |
| <td>
| |
| This principle states that all services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.
| |
| </td>
| |
| </tr>
| |
|
| |
| <tr>
| |
| <td>
| |
| <b>The open-closed principle</b>
| |
| </td>
| |
| <td> <b> : </b> </td>
| |
| <td> </td>
| |
| <td>
| |
| This principle states that the modules should be both open and closed.
| |
| </td>
| |
| </tr>
| |
|
| |
| <tr>
| |
| <td>
| |
| <b>The single choice principle</b>
| |
| </td>
| |
| <td> <b> : </b> </td>
| |
| <td> </td>
| |
| <td>
| |
| This principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.
| |
| </td>
| |
|
| |
| </tr>
| |
|
| |
| </table>
| |
|
| |
| == In detail ==
| |
| This principle is a consequence of both the open closed principle and the information hiding rule.
| |
| Consider the following example:
| |
| Assume you are building a system to manage a library. Considering Publications of a library, this type can be represented as follows in Pascal-Ada syntax:
| |
| <pre language="ADA">
| |
| type PUBLICATION =
| |
| record
| |
| author, title: STRING;
| |
| publication_year: INTEGER
| |
|
| |
| case pubtype: (book, journal, conference_proceedings) of
| |
| book: (publisher: STRING);
| |
| journal: (volume, issue: STRING);
| |
| proceedings: (editor, place: STRING) -- Conference proceedings
| |
| end
| |
| </pre>
| |
|
| |
| This particular form uses the Pascal-Ada notion of “record type with variants” to describe sets of data structures with some fields (here author, title, publication_year) common to all instances, and others specific to individual variants.
| |
|
| |
| The use of a particular syntax is not crucial here; Algol 68 and C provide an equivalent mechanism through the notion of union type. A union type is a type T defined as the union of pre-existing types A, B,... : a value of type T is either a value of type A, or a value of type B,...
| |
|
| |
| Record types with variants have the advantage of clearly associating a tag, here book, journal, conference_proceedings, with each variant.
| |
|
| |
| Let A be the module that contains the above declaration or its equivalent using another mechanism. As long as A is considered open, you may add fields or introduce new variants. To enable A to have clients, however, you must close the module; this means that you implicitly consider that you have listed all the relevant fields and variants. Let B be a typical client of A. B will manipulate publications through a variable such as
| |
|
| |
| <pre>p: PUBLICATION</pre>
| |
|
| |
| and, to do just about anything useful with p, will need to discriminate explicitly between the various cases, as in:
| |
| <pre>
| |
| case p of
| |
| book: ...Instructions which may access the field p l publisher...
| |
| journal: ...Instructions which may access fields p l volume, pl issue...
| |
| proceedings: ...Instructions which may access fields p l editor, pl place...
| |
| end
| |
| </pre>
| |
|
| |
| The case instruction of Pascal and Ada comes in handy here; it is of course on purpose that its syntax mirrors the form of the declaration of a record type with variants. Fortran and C will emulate the effect through multi-target goto instructions (switch in C).
| |
|
| |
| In these and other languages a multi-branch conditional instruction <pre>if ...then ...elseif ...elseif ...else ...end</pre> will also do the job.
| |
|
| |
| Aside from syntactic variants, the principal observation is that to perform such a discrimination every client must know the exact list of variants of the notion of publication supported by A. The consequence is easy to foresee. Sooner or later, you will realize the need for a new variant, such as technical reports of companies and universities. Then you will have to extend the definition of type PUBLICATION in module A to support the new case. Fair enough: you have modified the conceptual notion of publication, so you should update the corresponding type declaration. This change is logical and inevitable. Far harder to justify, however, is the other consequence: any client of A, such as B, will also require updating if it used a structure such as the above, relying on an explicit list of cases for p. This may, as we have seen, be the case for most clients.
| |
|
| |
| What we observe here is a disastrous situation for software change and evolution: a simple and natural addition may cause a chain reaction of changes across many client modules.
| |
|
| |
| The issue will arise whenever a certain notion admits a number of variants. Here the notion was “publication” and its initial variants were book, journal article, conference proceedings; other typical examples include:
| |
| <ul>
| |
| <li> In a graphics system: the notion of figure, with such variants as polygon, circle,ellipse, segment and other basic figure types.</li>
| |
| <li> In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion, global replacement of a word by another.</li>
| |
| <li>In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.</li>
| |
|
| |
| In any such case, we must accept the possibility that the list of variants, although fixed and known at some point of the software’s evolution, may later be changed by the addition or removal of variants. To support our long-term, software engineering view of the software construction process, we must find a way to protect the software’s structure against the effects of such changes.
| |
|
| |
| Hence the Single Choice principle:
| |
|
| |
| <pre>
| |
| By requiring that knowledge of the list of choices be confined to just one module, we prepare the scene for later changes:
| |
| if variants are added, we will only have to update the module which has the information — the point of single choice.
| |
| All others, in particular its clients, will be able to continue their business as usual.</pre>
| |
|
| |
| Once again, as the publications example shows, traditional methods do not provide a solution; once again, object technology will show the way, here thanks to two techniques connected with inheritance: polymorphism and dynamic binding. No sneak preview in this case, however; these techniques must be understood in the context of the full method.
| |
|
| |
| == Characteristics ==
| |
| The Single Choice principle prompts a few more comments:
| |
| <ul>
| |
| <li>The number of modules that know the list of choices should be, according to the principle, exactly one. The modularity goals suggest that we want at most one module to have this knowledge; but then it is also clear that at least one module must possess it. You cannot write an editor unless at least one component of the system has the list of all supported commands, or a graphics system unless at least one component has the list of all supported figure types, or a Pascal compiler unless at least one component “knows” the list of Pascal constructs.
| |
| </li>
| |
| <li>Like many of the other rules and principles studied in this chapter, the principle is about distribution of knowledge in a software system. This question is indeed crucial to the search for extendible, reusable software. To obtain solid, durable system architectures you must take stringent steps to limit the amount of information available to each module. By analogy with the methods employed by certain human organizations, we may call this a need-to-know policy: barring every module from accessing any information that is not strictly required for its proper functioning.</li>
| |
|
| |
| <li>You may view the Single Choice principle as a direct consequence of the Open-Closed principle. Consider the publications example in light of the figure that illustrated the need for open-closed modules: A is the module which includes the original declaration of type PUBLICATION; the clients B, C,... are the modules that relied on the initial list of variants; A' is the updated version of A offering an extra
| |
| variant (technical reports).
| |
| </li>
| |
|
| |
|
| <li>You may also understand the principle as a strong form of Information Hiding. The designer of supplier modules such as A and A' seeks to hide information (regarding the precise list of variants available for a certain notion) from the clients.
| | == Conceptual Analysis == |
| </li>
| |
|
| |
|
| </ul>
| | == Examples == |
|
| |
|
| == Conclusion == | | == Conclusion == |
|
| |
|
| == References == | | == References == |
| [1] Object Oriented Software Construction by Bertrand Meyer, Second Edition.
| |