Object-Oriented Design2: Some Principles

1. Object-Oriented Design2:Some Principles Fred Kuhns fredk@cse.wustl.edu Applied Research Laboratory, Department of Computer Science and Engineering, Washington University in St. Louis

2. Open Closed Principle (OCP) Bertrand Meyer/97 • Implement classes (or any component) so they are:Open for extension but closed for modification • In other words, as requirements change you are able to add new functionality (extend) to your systems with minimal (ideally no) change to the existing implementation base. • Achieve this using runtime and compile time polymorphism along with a strategic use of indirection (codified in many design patterns). CS422 – Operating Systems Concepts

3. Liskov Substitution Principle Barbara Liskov/74 • “An instance of a derived should be able to replace any instance of its superclass” • Implement classes such that a derived class may be used anyplace the base class may be used. • In effect the base class establishes an interface and basic behavior (functionality). If a derived class violates this contract then it has most likely violated the LSP. • For example consider an ellipse base class extended by a circle derived class (Robert Martin, Design principles and design patterns, www.objectmentor.com) • while a circle may be considered to be a special case of an ellipse, if you change the foci/major axis values then it may not be a circle, etc. • Derived class methods (see design by contract): • preconditions should be no stronger then the base class method • postconditions are no weaker then the base class method CS422 – Operating Systems Concepts

4. Dependency Inversion Principle Robert Martin/95 • Depend on the abstraction, not the implementation • Or equivalently “design to interfaces” • Related to the Open-Closed principle (OCP) • OCP says you should use abstractions as an organizing principle. Extensibility is then achieved by different realizations of the abstraction • DIP says to rely on these abstractions and not the concrete objects. • The goal is to limit dependence on the aspects of a design/implementation that may change: isolation. • There are times when dependency on concrete implementations is necessary. • if the implementation is static then not a big deal • if dynamic then it may be; attempt to isolate dependencies to relatively small interfaces and classes. CS422 – Operating Systems Concepts

5. Interface Segregation Principle Bertrand Meyer/88 • “The dependency of one class to another one should depend on the smallest possible interface” • Or, “Many client specific interfaces are better than one general purpose interface”(Robert Martin/2000) • May use inheritance to provide a common service object: • it inherits “category specific” interfaces • clients then use just those methods defiend for their specific category. • Rather than changing existing interface may choose to add new interfaces to extend capability CS422 – Operating Systems Concepts

6. Design by Contract Bertrand Meyer • Contract consists of: • method preconditions: parameters meet these requirements • method postconditions: results meet these conditions • consistency checks: objects left on a consistent state • Examples member functions in C++ // may want to use #ifdef _DEBUG_ macros bool valid() const; #define ASSERT(expr) if (!expr) myabort(__FILE__, __LINE__, …) • Generally only use these tests during debugging, the final build removes the macro calls CS422 – Operating Systems Concepts

7. Other Principles • Prefer composition over inheritance • Single responsibility principle • Minimize accessibility of classes and members (use methods) CS422 – Operating Systems Concepts