Interface Oriented Design By Ken Pugh

Just now i completed reading Interface Oriented Design

Nice book written by Ken Pugh.I strongly believe this book is for programmers new to OOPS or new to java.

I wanted to share few important points i found from this book.

1) Using the same interface but with potentially different implementations is the central concept of polymorphism.

2) The Three Laws of Interfaces

One way to express one of the facets of the contract for an interface is with three principles inspired by the Three Laws of Robotics. Isaac Asimov first presented these laws in 1950 in his short-story collection,Robot.1 Since computer programs often act like robots, this analogy of the laws seems appropriate.

a. An Interface’s Implementation Shall Do What Its Methods Says It Does

Liskov Substitution Principle
The first law corresponds to the Liskov Substitution Principle (LSP), which states that a subtype should be indistinguishable in behavior from the type from which it is derived. For object design, methods in a base class should be applicable to derived classes. In another words, a derived class should obey the contract of the base class. Thus, any object of a derived class is “substitutable” as an object of the base class. Barbara Liskov and Jennette Wing introduced this principle in their paper “Family Values: A Behavioral Notion of Subtyping.”

The full discussion is at
http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-562b.pdf.

b. An Interface Implementation Shall Do No Harm
In particular, an implementation should not hog resources. Resources in this case might include time, memory, file handles, database connections,and threads. For example, if the implementation requires connecting to a database that has limited connections, it should disconnect as soon as the required database operation is complete.

c. If An Implementation Is Unable to Perform Its Responsibilities, It Shall Notify Its Caller.

3) We can list the operations involved in an interface, including preconditions,postconditions, parameters and their types, return values, and errors signaled. But you need more than just how to use operations and when to use each operation. You also need to know the protocol to the interface—the set of allowable sequences of method calls. The preconditions often imply a sequence, but they may not. The protocol can also show the callbacks that an interface may create, events that are generated, or observers that are called.

4) The Design Patterns book states, “Design to an interface, not an implementation.”
A parallel guideline exists in testing. “Test to an interface, not an implementation”. This is termed black box testing.16 You test an interface without looking inside to see how it is coded. With more services being provided remotely, you probably will not have access to the code. Therefore, you can test only to the interface.

5) A UML sequence diagram shows a sequence of interactions between modules. The interactions take the form of messages or method calls. The modules may be instances of classes or implementations of interfaces. A box and dotted line represent a module. The name is within the box. The name may represent an actual module or an unspecified implementation of an interface. To show the latter, you use a colon before the name of the interface. The dotted line represents the “life” of themodule. For example, for an object, the line represents how long the object exists.You show calls to a method by drawing a line between the caller and the callee and giving the name of the method. Lines in the reverse direction show return values from methods.When an implementation is “active” (that is, doing something rather than just existing), the lifeline shows up as a rectangle,rather than a dotted line.

A state diagram shows states and how method calls (or other events) cause transitions between states. The diagram has an initial state marked by a line from a filled circle. A rounded rectangle represents each state. Lines with method names represent the transitions between states. A circle with a dot in itmarks the termination of the state transition.

Showing transitions for all methods for each state can complicate a diagram. Accompanying text can explain whether methods not shown on a transition line are ignored or cause an implicit transition that terminates the state diagram.

6) Things to Remember

An implementation of an interface should obey the three laws:

• Do what its methods say it does.
• Do no harm.
• Notify its caller with meaningful errors if unable to perform its responsibilities.

Establish a contract for each interface (either formally or informally):

• Indicate the preconditions and postconditions for each method.
• Specify the protocol—the sequence of allowable method calls.
• Optionally, spell out nonfunctional aspects such as performance or quality of implementation.
• Create tests to check that an implementation performs according to its contract and that it obeys the three laws.

7) Stateless versus Stateful Interfaces
An interface implementation can either contain state (stateful) or not contain state (stateless). In a stateful interface, the methods operate differently based on the current state, which is changed by the sequence of method invocations. In a stateless interface, the behavior is not dependent on the history of method invocations. Its behavior is always the same.

8) The oft-quoted guideline for object-oriented programming is that classes should be cohesive and loosely coupled.

9) Cohesiveness

Methods in an interface should be cohesive. They should provide services that revolve around a common concept.1 The problem is that the definition of commonness is relative.

10) Coupling

Coupling measures how one module depends on the implementation of another module. A method that depends upon the internal implementation of a class is tightly coupled to that class. If that implementation changes, then you have to alter the method. Too much coupling—especially when it’s not necessary—leads to brittle systems that are hard to extend and maintain.

But if you rely on interfaces instead, then it’s difficult to tightly couple a method to another implementation. A method that just calls the methods in another interface is loosely coupled to that interface. If you simply use a reference to an interface implementation without calling any methods, then the two are considered really loosely coupled.

11) The relationship between the derived and base class is referred to as “is-a” or more specifically as “isa-kind-of.” For example, a mammal “is-a-kind-of” animal. Inheritance creates a class hierarchy.

12) How do you determine which interface is assigned which responsibility?
Here are a few general guidelines:

• Put together cohesive interfaces. The responsibilities should be ones that seem like they go together.

• Decouple interfaces—separate responsibilities that may be implemented differently.

• Divide into more interfaces to simplify the testing of each interface.

About the Author

Ken Pugh has worked on software and hardware projects for over thirty years, from requirements gathering through testing and maintenance. He has a wide variety of experience with numerous operating systems, languages, and development processes. He has developed software systems extending from long-baseline interferometry to real-time goat serum process control, and embedded systems for signal processing to networked file storage.

As a teacher and mentor, he has trained thousands of students in subjects ranging from object-oriented design to UNIX operating system internals. He has presented at numerous conferences seminars on software development processes, programming techniques, and system architecture. Ken has written four books on programming and operating systems.

Hope you enjoy reading this book.