Software Engineering Design & Construction

Transcription

1 Summer Semester 2015 Software Engineering Design & Construction Dr. Michael Eichberg Fachgebiet Softwaretechnik Technische Universität Darmstadt Dependency-Inversion Principle

2 2 Dependency-Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. Agile Software Development; Robert C. Martin; Prentice Hall, 2003

3 Introduction by Example A Small Design Exercise Behavior of Button: The button is capable of sensing whether it has been activated/ deactivated by the user. Once a change is detected, it turns the Lamp on, respectively off. Button Issues? Lamp +TurnOn() +TurnOff() 3

4 A Dependency-Inversion Principle Compliant Solution Button Switchable «interface» +activate() +deactivate() Lamp 4

5 The Rationale behind the Dependency-Inversion Principle High-level, low-level modules. Good software designs are structured into modules. High-level modules contain the important policy decisions and business models of an application The identity of the application. Low-level modules contain detailed implementations of individual mechanisms needed to realize the policy. 5

6 The Rationale behind the Dependency-Inversion Principle High-level, low-level modules. Good software designs are structured into modules. High-level modules contain the important policy High-level Policy The abstraction that underlies the application; the truth that does not vary when details are changed; the system inside the system; the metaphor. decisions and business models of an application The identity of the application. Low-level modules contain detailed implementations of individual mechanisms needed to realize the policy. 6

7 all well-structured object-oriented architectures have clearly defined layers, with each layer providing some coherent set of services through a well-defined and controlled interface -Grady Booch 7

8 8 all well-structured object-oriented architectures have clearly defined layers, with each layer providing some coherent set of services through a welldefined and controlled interface An Interpretation The higher the module is positioned in a layered architecture, the more general the function it implements. Policy The lower the module, the more detailed the function it implements. Mechanism Utility -Grady Booch

9 s and Dependencies Inverted Dependencies Policy Policy «interface» Policy Service Interface Mechanism Clients own the interface - if at all! Mechanism «interface» Mechanism Service Interface Utility Utility 9

10 Naïve Heuristic for Ensuring DIP DO NOT DEPEND ON A CONCRETE CLASS. All relationships in a program should terminate on an abstract class or an interface. No class should hold a reference to a concrete class. No class should derive from a concrete class. No method should override an implemented method of any of its base classes. 10

11 11 Dependency-Inversion Principle Traditional structural programming creates a dependency structure in which policies depend on details. (Policies become vulnerable to changes in the details.) High-level modules should not depend on low-level modules. Both should depend on abstractions. Object-orientation enables to invert the dependency: Abstractions should not depend on details. Details should depend on abstractions. Policy and details depend on abstractions. Service interfaces are owned by their clients. Inversion of dependency is the hallmark of good objectoriented design. (Implies an inversion of interface ownership.) Agile Software Development; Robert C. Martin; Prentice Hall, 2003