Rating:
Date added: 13.2.2015
475 739
FB2PDFEPUB
This is the fourth of my Engineering Notebook columns for The C++ Report. The articles that will appear in this column will focus on the use of C++ and OOD, and will address issues of software engineering. I will strive for articles that areMoreThis is the fourth of my Engineering Notebook columns for The C++ Report. The articles that will appear in this column will focus on the use of C++ and OOD, and will address issues of software engineering. I will strive for articles that are pragmatic and directly useful to the software engineer in the trenches. In these articles I will make use of Boochs and Rumbaughs new unified Modeling Langage (UML Version 0.8) for documenting object oriented designs. The sidebar provides a brief lexicon of this notation.My last column (May 96) I discussed the principle of Dependency Inversion (DIP). This principle states that modules that encapsulate high level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions. To be more succinct and simplistic, abstract classes should not depend upon concrete classes- concrete classes should depend upon abstract classes. A good example of this principle is the TEMPLATE METHOD pattern from the GOF book. In this pattern, a high level algorithm is encoded in an abstract base class and makes use of pure virtual functions to implement its details. Derived classes implement those detailed virtual functions. Thus, the class containing the details depend upon the class containing the abstraction.In this article we will examine yet another structural principle: the Interface Segregation Principle (ISP). This principle deals with the disadvantages of fat interfaces. Classes that have fat interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus some clients use one group of member functions, and other clients use the other groups.The ISP acknowledges that there are objects that require non-cohesive interfaces- however it suggests that clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive interfaces. Some languages refer to these abstract base classes as interfaces, protocols or signatures.In this article we will discuss the disadvantages of fat or polluted interfaces. We will show how these interfaces get created, and how to design classes which hide them. Finally we will present a case study in which the a fat interface naturally occurs, and we will employ the ISP to correct it.CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE. The Interface Segregation Principle by Robert C. Martin