Some Principles Stphane Ducasse Stephane Ducasseunivsavoie fr http

  • Slides: 21
Download presentation
Some Principles Stéphane Ducasse Stephane. Ducasse@univ-savoie. fr http: //www. listic. univ-savoie. fr/~ducasse/ Stéphane Ducasse

Some Principles Stéphane Ducasse Stephane. Ducasse@univ-savoie. fr http: //www. listic. univ-savoie. fr/~ducasse/ Stéphane Ducasse --- 2005 S. Ducasse 1

License: CC-Attribution-Share. Alike 2. 0 http: //creativecommons. org/licenses/by-sa/2. 0/ S. Ducasse 2

License: CC-Attribution-Share. Alike 2. 0 http: //creativecommons. org/licenses/by-sa/2. 0/ S. Ducasse 2

Open-Close • • S. Ducasse Software entities (classes, modules, functions, etc. ) should be

Open-Close • • S. Ducasse Software entities (classes, modules, functions, etc. ) should be open for extension, but closed for modification. 3

The open-closed principle • Software entities (classes, modules, functions, etc. ) should be open

The open-closed principle • Software entities (classes, modules, functions, etc. ) should be open for extension, but closed for modification. • Existing code should not be changed – new features can be added using inheritance or composition. S. Ducasse 4

One kind of application struct Square { Shape. Type _type; double _side; Point _top.

One kind of application struct Square { Shape. Type _type; double _side; Point _top. Left; }; void Draw. Square(struct Square*) void Draw. Circle(struct Circle*); enum Shape. Type {circle, square}; struct Shape { Shape. Type _type; }; struct Circle { Shape. Type _type; double _radius; Point _center; }; S. Ducasse 5

Example (II) void Draw. All. Shapes(struct Shape* list[], int n) { int i; for

Example (II) void Draw. All. Shapes(struct Shape* list[], int n) { int i; for (i=0; i<n; i++) { struct Shape* s = list[i]; switch (s->_type) { case square: Draw. Square((struct Square*)s); break; case circle: Draw. Circle((struct Circle*)s); break; } } } Adding a new shape requires adding new code to this method. S. Ducasse 6

Correct Form class Shape { public: virtual void Draw() const = 0; }; class

Correct Form class Shape { public: virtual void Draw() const = 0; }; class Square : public Shape { public: virtual void Draw() const; }; class Circle : public Shape { public: virtual void Draw() const; }; void Draw. All. Shapes(Set<Shape*>& list) { for (Iterator<Shape*>i(list); i; i++) (*i)->Draw(); S. Ducasse 7

Some Principles • • • S. Ducasse Dependency Inversion Principle Interface Segregation Principle The

Some Principles • • • S. Ducasse Dependency Inversion Principle Interface Segregation Principle The Acyclic Dependencies Principle 8

Dependency Inversion Principle • High level modules should not depend upon low level modules.

Dependency Inversion Principle • High level modules should not depend upon low level modules. Both should depend upon abstractions. • Abstractions should not depend upon details. Details should depend upon abstractions. S. Ducasse 9

Example void Copy() { int c; while ((c = Read. Keyboard()) != EOF) Write.

Example void Copy() { int c; while ((c = Read. Keyboard()) != EOF) Write. Printer(c); } S. Ducasse 10

Cont. . . Now we have a second writing device – disk enum Output.

Cont. . . Now we have a second writing device – disk enum Output. Device {printer, disk}; void Copy(output. Device dev) { int c; while ((c = Read. Keyboard()) != EOF) if (dev == printer) Write. Printer(c); else Write. Disk(c); } S. Ducasse 11

Solution class Reader { public: virtual int Read() = 0; }; class Writer {

Solution class Reader { public: virtual int Read() = 0; }; class Writer { public: virtual void Write(char)=0; }; void Copy(Reader& r, Writer& w) { int c; while((c=r. Read()) != EOF) w. Write(c); } S. Ducasse 12

Some Principle S. Ducasse 13

Some Principle S. Ducasse 13

Interface Segregation Principle • The dependency of one class to another one should depend

Interface Segregation Principle • The dependency of one class to another one should depend on the smallest possible interface. • Avoid “fat” interfaces S. Ducasse 14

Examples S. Ducasse 15

Examples S. Ducasse 15

Solutions • • One class one responsibility Composition? • Design is not simple S.

Solutions • • One class one responsibility Composition? • Design is not simple S. Ducasse 16

The Acyclic Dependency Principle • The dependency structure between packages must not contain cyclic

The Acyclic Dependency Principle • The dependency structure between packages must not contain cyclic dependencies. S. Ducasse 17

Example. . . Ez S. Ducasse 18

Example. . . Ez S. Ducasse 18

Solutions • • S. Ducasse Layering? Separation of domain/applicatin/UI 19

Solutions • • S. Ducasse Layering? Separation of domain/applicatin/UI 19

Packages, Modules and other • • S. Ducasse The Common Closure Principle • Classes

Packages, Modules and other • • S. Ducasse The Common Closure Principle • Classes within a released component should share common closure. That is, if one needs to be changed, they all are likely to need to be changed. The Common Reuse Principle • The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all. 20

Summary Build your own taste Analyze what you write and how? S. Ducasse 21

Summary Build your own taste Analyze what you write and how? S. Ducasse 21