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?
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 who is responsible for keeping their interfaces small, thereby decreasing coupling between modules. The principle of small interfaces can be somewhat subjective because there is not a widely accepted test to determine whether the principle has been violated.
Here is an example of a small interface 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 reduce coupling with clients. Using this same example, we can violate the principle of small interfaces by exposing more 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 that 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 its 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 languages 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, it is up to programmers 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 [*]. 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 via 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 it is up to the programmer 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 [2]. 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 [*]. 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 [*]. The single-choice principle limits the number of modules that must maintain the list of alternatives to one, thereby simplifying maintenance.