CSC/ECE 517 Summer 2008/wiki3 8 smr: Difference between revisions
| Line 55: | Line 55: | ||
=== Uniform-access === | === 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 [http://en.wikipedia.org/wiki/Uniform_access_principle]. 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. | |||
[http://en.wikipedia.org/wiki/ | 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 <code>circumference</code> and <code>area</code> properties of <code>Circle</code> 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 [http://en.wikipedia.org/wiki/Property_%28programming%29 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 === | === Self-documentation === | ||
Revision as of 23:13, 26 July 2008
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
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 principle of explicit interfaces maintains that all communications between modules must be visible. This means that as well as minimizing the number of interfaces and the amount of communication, all communications must also be clearly represented in the system: In the following diagram we can see that a tightly coupled relationship exits between module A and module B, as they are both reliant on variable x. In order to adhere to the criteria of decomposability, composibilty, continuity and understandability the data relationship between A and B must be clearly marked:
It is not disirable that A can change the value of x without this being visible in its code. Similarly, B’s interests in x must also be clearly visible" [2].
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
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" [4].
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?