UML Guide v2.1
Author: Rajinder Yadav
Date: Sept 21, 2007
Design by Contract
Similar to the substitution principal (discussed earlier) is the idea of interface based software design that is used to define how objects interact, and how they restrict what gets exposed. I am going to discussed what an interface is and provide UML diagrams. Since we have not discussed UML notations yet, you can return later to make sense of the diagrams. What's important now is that you understand what an interface is.
Interface Based Development
An interface is simply an agreed upon way to interact, it defines a set of methods that will be supported by an object. The method name, method parameters and method return type form a binding contact that remains static once it published and made public. For those who have worked with COM, all this will be very familary. The diagram below shows class student that is derived from class person. Since a person is not necessarily a student, because a person would be a worker, it does not make sense for class person to support(provide) the IStudent interface. Any client wishing to use a student object will need to interact with it through the IStudent interface.
Diagram 1 - interface development
If an interface needs to be changed, the software designer must create a new interface, this insures older software continues to work without change when an object is updated to provide more functionality. In the next diagram we have updated the student class to work as a TA while still taking classes. The updated student supports a new interface ITeacherAssistance, this allows old clients to continue working without modification, while new clients can take advantage of newer functionality.
Diagram 2 - interface development
|
Note: the new interface ITeacherAssistance could have also provided the same methods as IStudent so new clients would only need to acquire a single interface to interact with the student object. This is shown below, we simply have interface ITeacherAssistance inherit from interface IStudent. Since we know IStudent cannot change, we are assured interface ITeacherAssistance will not be inadvertently changed.
|
Diagram 3 - interface development
Interfaces support weak coupling
If it's not already apparent, an interface is an abstract class, it has no implementation code, only method definitions. The class providing the interface is responsible for implementing the code. When certain interaction relationship (protocols) can be extracted and isolated, it makes sense to define interfaces. By being able to do the same operation with different structures, the code is much easier to learn and understand. Take for instance the process of enumerating over a sequence of items. The basic operation are, reset, previous, next, read value. These operations can be defined by an interface and then supported by various structures. The user of the object only needs to know the definition of the interface, and without knowing or caring how items are stored or represented the user can walk over all the items contained in some structure.
Diagram 4 - interface development
Above we have class StudentDatabase and class MarketDataMgr supporting an enumeration interface. We have no idea on how items are stored in either of the structures? StudentDatabase could have items stored on a flat file or a remote database. The client doesn't have to know how to read a file, or open a database connection and use SQL to get the student list, all it needs to know is how to use the interface IEnumerator.
Copyright © 2007 Rajinder Yadav, All rights reserved
UML logo are trademarks or registered trademarks of the Object Management Group, Inc. in the United States and other countries
|
