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?
Introduction
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
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?
"The designer of a module should strive to make all information about the module part of the module itself" [3].
Single-choice
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?