重大18_Principles of object-oriented design

1、College of Computer Science, CQU 18 Principles of object-oriented design Liu Ji 1 Outline pSRP：the single-responsibility principle pOCP：the open-closed principle pLSP：the liskov substitution principle pDIP：the dependency-inversion principle pISP：the interface segregation principle 2 References SRP p

2、In object-oriented programming, the single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. 3 SRP example pThe Rectangle c

3、lass has two responsibilities. The first responsibility is to provide a mathematical model of the geometry of a rectangle (area method). The second responsibility is to render the rectangle on a graphical user interface(draw method). This design violates the SRP. 4 pThe violation of SRP causes sever

4、al nasty problems. pFirstly, we must include the GUI in the computational geometry application. If this were a C+ application, the GUI would have to be linked in, consuming link time, compile time, and memory footprint pSecondly, if a change to the GraphicalApplication causes the Rectangle to change

5、 for some reason, that change may force us to rebuild, retest, and redeploy the ComputationalGeometryApplication. If we forget to do this, that application may break in unpredictable ways. 5 pA better design is to separate the two responsibilities into two completely different classes. This design m

6、oves the computational portions of Rectangle into the GeometricRectangle class. Now changes made to the way rectangles are rendered cannot affect the ComputationalGeometryApplication. 6 OCP pOCP states software entities (classes, modules, functions, etc.) should be open for extension, but closed for

7、 modification; that is, such an entity can allow its behaviour to be modified without altering its source code. pThis is especially valuable in a production environment, where changes to source code may necessitate code reviews,unit tests, and other such procedures to qualify it for use in a product

8、: code obeying the principle doesnt change when it is extended, and therefore needs no such effort. 7 OCP example class Shape public: virtual void Draw() const = 0; ; class Square : public Shape public: virtual void Draw() const; ; 8 class Circle : public Shape public: virtual void Draw() const; ; v

9、oid DrawAllShapes(Set i; i+) (*i)-Draw(); 9 If we want to extend the behavior of the DrawAllShapes function to draw a new kind of shape, all we need do is add a new derivative of the Shape class. The DrawAllShapes does not need to change. Thus DrawAllShapes conforms to the open-closed principle. Its

10、 behavior can be extended without modifying it. LSP pIt states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T) without altering any of the desirable properties of tha

11、t program (correctness, task performed, etc.). pMore formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstract

12、ion and hierarchy. 10 LSP example class Rectangle public: void SetWidth(double w) itsWidth=w; void SetHeight(double h) itsHeight=w; double GetHeight() const return itsHeight; double GetWidth() const return itsWidth; private: double itsWidth; double itsHeight; ; 11 class Square : public Rectangle ; v

13、oid f(Rectangle Rectangle r; Square s; f(r); / Right f(s); / Wrong 12 If we pass a reference to a Square object into this function, the Square object will be corrupted because the height wont be changed. This is a clear violation of LSP. The f function does not work for derivatives of its arguments.

14、 DIP pthe dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent o

15、f the low-level module implementation details. The principle states: nA. High-level modules should not depend on low-level modules. Both should depend on abstractions. nB. Abstractions should not depend upon details. Details should depend upon abstractions. 13 DIP example enum OutputDevice printer,

16、disk; void Copy(outputDevice dev) int c; while (c = ReadKeyboard() != EOF) if (dev = printer) WritePrinter(c); else WriteDisk(c); 14 As time goes on, and more and more devices must participate in the copy program, the “Copy” module will be littered with if/else statements and will be dependent upon

17、many lower level modules. It will eventually become rigid and fragile. 15 class Reader public: virtual int Read() = 0; ; class Writer public: virtual void Write(char) = 0; ; void Copy(Reader while(c=r.Read() != EOF) w.Write(c); 16 Now we can reuse the “Copy” class, independently of the “Keyboard Rea

18、der” and the “Printer Writer”. We can invent new kinds of “Reader” and “Writer” derivatives that we can supply to the “Copy” class. Moreover, no matter how many kinds of “Readers” and “Writers” are created, “Copy” will depend upon none of them. There will be no interdependencies to make the pro-gram

19、 fragile or rigid. And Copy() itself can be used in many different detailed contexts. It is mobile. ISP pIt is a software development principle used for clean development and is intended to help developers avoid making their software impossible to change. p If followed, the ISP will help a system st

20、ay decoupled and thus easier to refactor, change, and redeploy. pThe ISP says that once an interface has become too fat it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them. p In a nutshell, no client should be forced to depend on methods it does not use. 17 ISP example TimeOut function of TimerClient will be called when the timeout expires. 18 class TimerClient public: virtual void TimeOut() = 0; ; class Door : public TimerClient public: virtual void Lock()