CSC/ECE 517 Summer 2008/wiki3 8 smr: Difference between revisions
| Line 8: | Line 8: | ||
=== Small Interfaces === | === 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 [http://www.amazon.com/Object-Oriented-Software-Construction-Prentice-Hall-International/dp/0136291554/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1217110101&sr=8-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 === | === Explicit Interfaces === | ||
Revision as of 22: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
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?
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?