CSC/ECE 517 Fall 2009/wiki3 13 RS56

Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.

Explicit Interfaces

---

The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

Obscure Object Oriented Principle

One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on amazon.com, it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

Documentation

To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce.

Assembler language Self Documentation example:

MODULE A:
GLOBVARIN*	$RES	2	. A two byte quantity passed from Module A to Module B
MODULE B:
GLOBVAROT*	$RES	2	. A two byte quantity returned from Module B to Module A

Strong Typing

For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change. The unwitting developer would have a pleasant surprise if both module A and B are compiled together.

Require and Ensure

Eiffel goes so far to insure explicit interfaces that a language construct exists to facilitate the creation of a well defined and checked interface.

put (x: ELEMENT; key: STRING) is
			-- Insert x so that it will be retrievable through key.
		require
			count <= capacity
			not key.empty
		do
			... Some insertion algorithm ...
		ensure
			has (x)
			item (key) = x 
			count = old count + 1
		end

Conclusion

---

Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity. It has attained universal acceptance.

Glossary

---

Ensure – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the post-condition of a module.

Require – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the pre-condition of a module.

Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs.

References

---

1. Eric Freeman and Elisabeth Freeman. Head First Design Patterns. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
2. http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3