Object-Oriented Design Lecture 12: Object-Oriented Principles - PowerPoint PPT Presentation

Object-Oriented Design Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Department of Computer Engineering

Open Closed Principle (OCP) • Classes should be open for extension but closed for modification. • OCP states that we should be able to add new features to our system without having to modify our set of preexisting classes. • One of the tenets of OCP is to reduce the coupling between classes to the abstract level. • Instead of creating relationships between two concrete classes, we create relationships between a concrete class and an abstract class or an interface. 2 Sharif University of Technology

Open Closed Principle (OCP) Example 3 Sharif University of Technology

Open Closed Principle (OCP) Solution 4 Sharif University of Technology

Liskov Substitution Principle (LSP) • Subclasses should be substitutable for their base classes. • Also called the substitutability principle. 5 Sharif University of Technology

Dependency Inversion Principle (DIP) • Depend upon abstractions. Do not depend upon concretions. • The Dependency Inversion Principle (DIP) formalizes the concept of abstract coupling and clearly states that we should couple at the abstract level, not at the concrete level. • DIP tells us how we can adhere to OCP. 6 Sharif University of Technology

Dependency Inversion Principle (DIP) 7 Sharif University of Technology

Dependency Inversion Principle (DIP) • let's assume the Manager class is quite complex, containing very complex logic. • Now we have to change it in order to introduce the new SuperWorker • Solution: • Manager class doesn't require changes when adding SuperWorkers. • Minimized risk to affect old functionality present in Manager class since we don't change it. • No need to redo the unit testing for Manager class. 8 Sharif University of Technology

Dependency Inversion Principle (DIP) 9 Sharif University of Technology

Interface Segregation Principle (ISP) • Many specific interfaces are better than a single, general interface. • Any interface we define should be highly cohesive. 10 Sharif University of Technology

Composite Reuse Principle (CRP) • Favor polymorphic composition of objects over inheritance. • One of the most catastrophic mistakes that contribute to the demise of an object-oriented system is to use inheritance as the primary reuse mechanism. • Delegation can be a better alternative to Inheritance. 11 Sharif University of Technology

Composite Reuse Principle (CRP) • Delegation can be seen as a reuse mechanism at the object level, while inheritance is a reuse mechanism at the class level. • suppose an Employee class has a method for computing the employee's annual bonus: class Employee { Money computeBonus() { /* skimpy default bonus */ } // etc.} • Different subclasses of Employee: Manager, Programmer, Secretary, etc. • may want to override this method to reflect the fact that some types of employees (managers) get more generous bonuses than others (secretaries and programmers): class Manager extends Employee { Money computeBonus() { /* gerenous bonus */ } // etc.} • There are several problems with this solution. 12 Sharif University of Technology

Composite Reuse Principle (CRP) • All programmers get the same bonus. What if we wanted to vary the bonus computation among programmers? • Would we need to introduce a special subclass of Programmer? class SeniorProgrammer extends Programmer { Money computeBonus() { /* gerenous bonus */ } // etc.} • Note also that this leads to code duplication. • What if we wanted to change the bonus computation for a particular employee? • For example, what if we wanted to promote Smith from programmer to senior programmer? Would this require us to recompile any code? • What if we decided to give all programmers the same generous bonus that managers get? What changes would we need to make? • Should "generous bonus" become the new default algorithm that is overridden in the Secretary class with the skimpy bonus algorithm? • Should we copy and paste the "generous bonus" algorithm from manager to Programmer? 13 Sharif University of Technology

Composite Reuse Principle (CRP) • Now different employees can have different bonus calculators, regardless of the class they instantiate. • Even better, the bonus calculator used by a particular employee can be changed dynamically. 14 Sharif University of Technology

Principle of Least Knowledge (PLK) • For an operation O on a class C, only operations on the following objects should be called: itself, its parameters, objects it creates, or its contained instance objects. • Also called the Law of Demeter . • The basic idea is to avoid calling any methods on an object where the reference to that object is obtained by calling a method on another object ( Transitive Visibility ). • The primary benefit is that the calling method doesn’t need to understand the structural makeup of the object its invoking methods upon. 15 Sharif University of Technology

Principle of Least Knowledge (PLK) • LoD (or Principle of Least Knowledge): Each module should have only limited knowledge about other units: only units "closely" related to the current unit • In particular: Don’t talk to strangers! • For instance, no a.getB().getC().foo() • Motivated by low coupling 16 Sharif University of Technology

GRASP • Acronym stands for General Responsibility Assignment Software Patterns. • A set of 9 Patterns introduced as a learning aid by Craig Larman. • Describe fundamental principles for object-oriented design and responsibility assignment, expressed as patterns. • The skillful assignment of responsibilities is extremely important in object design. • Determining the assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming. 17 Sharif University of Technology

GRASP: Patterns 1. Information Expert 2. Creator 3. Low Coupling 4. High Cohesion 5. Controller 6. Polymorphism 7. Indirection 8. Pure Fabrication 9. Protected Variations 18 Sharif University of Technology

GRASP: Information Expert  As a general principle of assigning responsibilities to objects, assign a responsibility to the information expert:  i.e. the class that has the information necessary to fulfill the responsibility. 19 Sharif University of Technology

GRASP: Information Expert  Given an object o, which responsibilities can be assigned to o?  Expert principle says – assign those responsibilities to o for which o has the information to fulfill that responsibility.  They have all the information needed to perform operations, or in some cases they collaborate with others to fulfill their responsibilities. 20 Sharif University of Technology

GRASP: Example for Expert  Assume we need to get all the videos of a VideoStore.  Since VideoStore knows about all the videos, we can assign this responsibility of giving all the videos can be assigned to VideoStore class.  VideoStore is the information expert. 21 Sharif University of Technology

GRASP: Another Example for Expert  Who should be responsible for knowing the grand total of a sale? 22 Sharif University of Technology

GRASP: Creator • Assign class B the responsibility to create an instance of class A if one or more of the following is true: • B aggregates A objects. • B contains A objects. • B records instances of A objects. • B closely uses A objects. • B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A). • B is a creator of A objects. • If more than one option applies, prefer a class B which aggregates or contains class A. 23 Sharif University of Technology

GRASP: Creator • “Container” object creates “contained” objects. • Decide who can be creator based on the objects association and their interaction. • Consider VideoStore and Video in that store. • VideoStore has an aggregation association with Video. i.e, VideoStore is the container and the Video is the contained object. • So, we can instantiate video object in VideoStore class 24 Sharif University of Technology

GRASP: Low Coupling • Assign a responsibility so that coupling remains low. • A class with high (or strong) coupling relies on many other classes. Such classes may be undesirable; some suffer from the following problems: • Changes in related classes force local changes. • Harder to understand in isolation. • Harder to reuse because its use requires the additional presence of the classes on which it is dependent. 25 Sharif University of Technology

GRASP: Low Coupling • Two elements are coupled, if • One element has aggregation/composition association with another element. • One element implements/extends other element. 26 Sharif University of Technology

GRASP: Low Coupling 27 Sharif University of Technology

GRASP: High Cohesion • Assign a responsibility so that cohesion remains high. • A class with low cohesion does many unrelated things, or does too much work. • Such classes are undesirable; they suffer from the following problems: • hard to comprehend • hard to reuse • hard to maintain • Delicate: constantly affected by change 28 Sharif University of Technology

GRASP: High Cohesion 29 Sharif University of Technology