CSC/ECE 517 Fall 2009/wiki3 17 am

Single Choice Principle

Introduction

Single Choice 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. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the Linguistic Modular Units Principle, the Self- Documentation Principle, the Uniform- Access Principle, and the Open- Closed Principle. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing Eiffel.This principle is a particular case of the Don't repeat yourself principle.

Violation of SCP

Consider a type used to manage a declared in Pascal-Ada syntax :

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

Let B be a typical client of A. B will manipulate publications through a variable such as p:PUBLICATION and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:

	case p of 
		book:...Instructions which may access the field p.publisher
		journal:...Instructions which may access fields p.volume,p.issue
		proceedings:...Instructions which may access fields p.editor,p.place
	end

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p. What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

• In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.

For example old style procedural code to print different "shape" objects might read:

 if (type==CIRCLE)
   print "Circle.  r=" + radius;
 else if (type==Square)
   print "Square.  sides=" + sideLength;
 else if (type==Rectangle)
   print "Rect.  h=" + height + " w=" + width;
 endif

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

• In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
• In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

Implementation of SCP

Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of polymorphism and Dynamic binding provide the solution to this problem.

The graphics system given above can be reimplemented in the Object Oriented Manner as:

class SHAPE
  display_details
  end
end

class CIRCLE < SHAPE
  display_details
    print "Circle.  r=" + radius;
  end
end

class SQUARE < SHAPE
  display_details
    print "Square.  sides=" + sideLength;
  end
end

class RECTANGLE < SHAPE
  display_details
    print "Rect.  h=" + height + " w=" + width;
  end
end  
 

Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

Other Highlights

1. According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that at most one module should have this knowledge.
2. The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
3. SCP is a direct consequence of the Open Closed Principle.
4. SCP is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

Conclusion

The single choice principle is a principle of imperative computer programming.It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to polymorphism and aims at achieving high cohesion and low coupling, one of the most important aspects of Modular Programming.

References

1. Object-Oriented Software Construction Second Edition, Bertrand Meyer pgs 62-64.
2. Single Choice Principle