CSC/ECE 517 Summer 2008/wiki3 8 smr

Meyer's principles. Bertrand Meyer is a prominent author in o-o design. He has developed a set of principles, many of which are embodied in the Eiffel language. Consider the principles of small interfaces, explicit interfaces, the uniform-access principle, the self-documentation principle, and the single-choice principle. What are good examples of each? Do other languages besides Eiffel support them? Is it difficult to follow these principles in certain o-o languages?

---

Meyer's Principles

Small Interfaces

Meyer’s principle of small interfaces states that if two modules must interact, then the least amount of information should be shared between them [1]. The correct implementation of this principle often depends on the programmer responsible for implementing the interface. By designing and implementing a small interface, the programmer also minimizes coupling between modules.

Below is an example of a small interface written in Java.

 public class EmployeeDb {
   public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
   public Employee getEmployee(int employeeId) { // implementation… }
   public void saveEmployee(Employee emp) { // implementation… }
 }

In this example, the EmployeeDb interface was kept relatively small, which in turn will reduces coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing too much information to clients.

 public class EmployeeDb {
   public List<Employee> findEmployees(string name, Date birthDate) { // implementation … }
   public List<Employee> findEmployees(FindCriteria criteria) { // implementation … }
   public void setDb(DbConnection db) { // implementation… }
   public DbConnection getDb() { // implementation… }
   public void setTransaction(Transaction trx) { // implementation… }
   public Transaction getTransaction() {  // implementation… }
   public Employee getEmployee(int employeeId) { // implementation… }
   public void saveEmployee(Employee emp) { // implementation… }
   public class FindCriteria {
     public FindCriteria(int employeeId, String name, Date birthDate, String phone) { // implementation… }
     public getEmployeeId() { // implementation… }
     public getName() { // implementation… }
     public getBirthDate() { // implementation… }
     public getPhone() { // implementation… }
   }
 }

The above example adds five additional operations to our interface, which in turn increases the coupling of the EmployeeDb class to its clients. This coupling hinders the ability to change the EmployeeDb class to use a different data source without affecting clients. In addition to exposing extra operations, this version of the EmployeeDb class also exposes a nested class to its clients. This again is additional information being shared that potentially counters the principle of small interfaces. It is worth noting that the Eiffel language does not support nested classes.

All object-oriented languages support the ability to abide by this principle, but they also support the ability to violate this principle. Ultimately, programmers must choose to follow the principle of small interfaces, thereby reducing coupling within their applications.

Explicit Interfaces

Meyer’s principle of explicit interfaces states that if two modules must interact, then the interaction should be plainly visible [2]. Similar to the principle of small interfaces, this principle also speaks to the degree of coupling within a system. For instance, two modules may inadvertently interact with one another through their individual interaction with a common global variable. This is an example of common coupling and violates the principle of explicit interfaces.

Most object-oriented languages will support the principle of explicit interfaces, but programmers must be sure to keep this principle in check.

Uniform-access

Meyer’s principle of uniform-access states that operations of a module must be accessible using a uniform notation. In addition, this notation should not reveal to callers whether the evaluated operation was performed by accessing storage or by a computation [3]. Languages that support the uniform-access principle allow the implementation of a storage based property to change to a computed property without requiring changes to clients.

Ruby supports the uniform-access principle as illustrated by this example.

 class Circle
   # circumference and area are calculated and stored
   attr_accessor :circumference, :area
   PI = 3.142
   
   def initialize(radius)
     @circumference = PI*radius*2
     @area = PI*radius*radius
   end
 end

 # create a new circle
 c = Circle.new(4)
 # access properties of circle
 puts c.circumference
 puts c.circumference()
 puts c.area
 puts c.area ( )

In the above example, the circumference and area properties of Circle were referenced from storage. We can easily change those properties to be computed when accessed without any changes to the client.

 class Circle
   # circumference and area are calculated and stored
   PI = 3.142
   
   def circumference()
     PI*@radius*2
   end
 
   def area()
     PI*@radius*radius
   end
   
   def initialize(radius)
     @radius = radius
   end
 end

 # create a new circle
 c = Circle.new(4)
 # access properties of circle
 puts c.circumference
 puts c.circumference()
 puts c.area
 puts c.area ( )

C# is another language that supports the uniform-access through the use of its properties language feature. Java, C, and C++ are languages that do not support the uniform-access principle because accessing a field requires a different notation than accessing functions.

Self-documentation

Meyer’s principle of self-documentation states that all information about a particular module should be included as part of that module [4]. The self-documentation principle encourages keeping documentation related to a module embedded directly within the module, thereby encouraging the documentation of module to be synchronized with its functionality. The Eiffel language does this very elegantly as shown in this example.

Java and many of the .NET language such as C#, provide special language features to promote the self-documentation principle. In Java, programmers can use the special Javadoc notation to describe classes and methods. Here is an example of that notation for describing a Stack.

 /** 
  * The Stack class represents a last-in-first-out (LIFO) stack of objects.
  */
 public class Stack {
 
   /**
    * Creates an empty Stack.
    */
   public Stack() { // implementation... }
 
   /**
    * Tests if this stack is empty.
    */
   public boolean empty() { // implementation... }
 
   /**
    *  Looks at the object at the top of this stack without removing it from the stack.
    */    
   public Object peek() { // implementation... }
   
   /**
    * Removes the object at the top of this stack and returns that 
    * object as the value of this function.
    */
   public Object pop() { // implementation... }
   
   /**
    * Pushes an item onto the top of this stack.
    */
   public Object push(Object item) { // implementation... }
 }

C# also has a special syntax for embedding XML Documentation within its modules, which is highlighted by the following example.

 /// <summary> 
 /// The Stack class represents a last-in-first-out (LIFO) stack of objects.  
 /// </summary>
 public class Stack {
 
   /// <summary>
   /// Creates an empty Stack.
   /// </summary>
   public Stack() { // implementation... }
 
   /// <summary>
   /// Tests if this stack is empty.
   /// </summary>
   public bool empty() { // implementation... }
 
   /// <summary>
   ///  Looks at the object at the top of this stack without removing it from the stack.
   /// </summary>    
   public object peek() { // implementation... }
 
   /// <summary>
   /// Removes the object at the top of this stack and returns 
   /// that object as the value of this function.
   /// </summary>
   public object pop() { // implementation... }
   
   /// <summary>
   /// Pushes an item onto the top of this stack.
   /// </summary>
   public object push(object item) { // implementation... }
 }

This principle is a dificult to follow in C++, where syntax exists for creating comments, but there are not universally accepted conventions or tools for extracting documentation from the code.

Single-choice

Meyer’s principle of single-choice states that if a system provides a set of alternatives, then the complete list of alternatives are known by only one module [5]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance. The single-choice principle has to do with separation of responsibility and encapsulation. Like the small interfaces and explicit interfaces principles, following the single-choice principle is a design decision made by the programmer. All object-oriented languages support the ability to abide by this principle, as long as the programmer follows good principles of object-oriented design.

Also See

• Wikipedia: Bertrand Meyer
• Slides: Principles of Object-Oriented Software Architecture
• Wikipedia: Eiffel Programming Language
• Bertrand Meyer And His Opinions
• Critique of Bertrand Meyer's Object Oriented Software Construction
• Object Oriented Language: Eiffel

References

1. Object Oriented Software Construction, 2nd edition, page 48
2. Object Oriented Software Construction, 2nd edition, page 50
3. Object Oriented Software Construction, 2nd edition, page 57
4. Object Oriented Software Construction, 2nd edition, page 54
5. Object Oriented Software Construction, 2nd edition, page 63