CSC/ECE 517 Fall 2009/wiki3 13 ncs

From Expertiza_Wiki
Revision as of 01:04, 17 November 2009 by NCS (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

Bertrand Meyer's principle of explicit interface states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

Interface (Implicit vs Explicit)

A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

Code example

Let us consider the automobiles car and truck. We can either define all the shared methods and behaviors implicitly as methods within the class

class Automobile { public String getMake() {...} public String getModel() {...} public String getYear() {...} public String getLicensePlate() {...} public String getLicenseExpiration(){...}

public void turn(){...} public void accelerate(){...} public void stop(){...}

public String getSpeed(){...} public String getRPM(){...} public String getFuelLevel(){...} }

Alternatively define behaviors explicitly and have the car and truck class implement them.

public interface Autospec{ public String getMake(); public String getModel(); public String getYear(); public String getLicensePlate(); public String getLicenseExpiration();

}

public interface OperateAuto { public void turn(); public void accelerate(); public void stop(); }

public interface AutoDashboard{ public String getSpeed(); public String getRPM(); public String getFuelLevel(); }

class Automobile implements Autospec, OperateAuto, AutoDashboard{ // AutoSpec public String getMake(){...} public String getModel(){...} public String getYear(){...} public String getOwner() {...} public String getLicensePlate(){...} public String getLicenseExpiration(){...}

// OperateAuto public void turn(){...} public void accelerate(){...} public void stop(){...}

// AutoDash public String getSpeed(){...} public String getRPM(){...} public String getFuelLevel(){...} }

Advantages of using explicit interface

Let us consider the advantages of having explicit interfaces

Understandability

The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

Continuity

It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

Composability and Decomposability

It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.


Disadvantages of using explicit interfaces

Not really any

The only case it might not make sense is if the class itself has only one


Conclusion

Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.