Systems Analysis & Design Methods VII OOD-principles

2 Systems Analysis & Design Methods, VII OOD-principles Books UML for JAVA Programmers UML for JAVA Programmers (Robert C. Martin © Copyright 2003.) A book you should read, even if it is not necessary for this course. UML distilled UML distilled Martin Fowler

3 Systems Analysis & Design Methods, VII OOD-principles OOD principles Single Responsibility Single Responsibility Liskov Substitution Liskov Substitution Dependency Inversion Dependency Inversion

4 Systems Analysis & Design Methods, VII OOD-principles OOD principle: Single Responsibility A class should only have one reason to change significantly. Why ?: Simplicity. Suppose a class combines non related functionality and different goals: Clients who are interested in only one aspect, are overwhelmed with methods they don’t need. Clients who are interested in only one aspect, are overwhelmed with methods they don’t need. If one method changes, the client has to recompile, and –more importantly- worry whether his old code will still run as before. If one method changes, the client has to recompile, and –more importantly- worry whether his old code will still run as before.

5 Systems Analysis & Design Methods, VII OOD-principles Single Responsibility: counter example Don’t do this: Problem: A client of Employee who doesn’t need persistence is overloaded with persistence methods it doesn’t care about > Persistent Employee Company

6 Systems Analysis & Design Methods, VII OOD-principles Single Responsibility: Solution Do this: Solution: Code involving persistence is now moved to its own class. ( A client who thinks he is working with an Employee, can still be given a PersistentEmployee without him knowing nor caring about it. ) > Persistent Employee PersistentEmployee

7 Systems Analysis & Design Methods, VII OOD-principles OOD principle: Liskov’s Substitution If in a client X of a class Y, the class Y is replaced by a subclass Z of Y, the client code in X should still run as expected. Why? Avoid unforseen bugs. Suppose we violate this principle, because of a special subclass Z: The client code has to be adapted to cope with the special case. The client code has to be adapted to cope with the special case. The client will have to test the dynamic type of the used class. The client will have to test the dynamic type of the used class.

8 Systems Analysis & Design Methods, VII OOD-principles Liskov’s Substitution: counter example Don’t do this: Don’t do this: > Employee PayedEmployee Volunteer +calculateSalary:double {A}

9 Systems Analysis & Design Methods, VII OOD-principles Liskov’s Substitution: counter example (continued) Inside PayedEmployee, we have: Inside PayedEmployee, we have: public double calculateSalary(){ … return … ;// real salary > 0 } Inside Volunteer, we have: Inside Volunteer, we have: public double calculateSalary(){ public double calculateSalary(){ return 0; // fake salary == 0 }

10 Systems Analysis & Design Methods, VII OOD-principles Liskov’s Substitution: counter example (continued) A client: A client: public float getSumSalaries( List salaries ){ public float getSumSalaries( List salaries ){ Employee emp; Employee emp; float sum = 0; float sum = 0; for(int i = 0; i < salaries.size(); i++){ for(int i = 0; i < salaries.size(); i++){ emp = (Employee) salaries.get(i); emp = (Employee) salaries.get(i); sum += emp.calculateSalary(); sum += emp.calculateSalary(); } return sum; return sum; }

11 Systems Analysis & Design Methods, VII OOD-principles Liskov’s Substitution: counter example (continued) On first sight, the previous slide looks like a nice example of polymorphisme. BUT ‘Paying a salary of zero’ is not the same as ‘not paying a salary’. ‘Paying a salary of zero’ is not the same as ‘not paying a salary’. example: Imagine an embarassing situation of a volunteer receiving a letter ‘Your month’s pay’ with a big zero on it. example: Imagine an embarassing situation of a volunteer receiving a letter ‘Your month’s pay’ with a big zero on it. The client of Employee has to tests the dynamic type to see whether calling the method ‘give paycheck’ or ‘calculateSalary’ are applicable. These kinds of tests are exactly what polymorphism tries to avoid. The client of Employee has to tests the dynamic type to see whether calling the method ‘give paycheck’ or ‘calculateSalary’ are applicable. These kinds of tests are exactly what polymorphism tries to avoid. Calling calculateSalary should not be allowed for objects of type Volunteer. That’s why we opt for the following solution: Calling calculateSalary should not be allowed for objects of type Volunteer. That’s why we opt for the following solution:

12 Systems Analysis & Design Methods, VII OOD-principles Liskov’s Substitution: Solution > Employee PayedEmployee Volunteer +calculateSalary: double Do this: +calculateSalary:double {A}

13 Systems Analysis & Design Methods, VII OOD-principles Dependency Inversion The principle should have been called instead: The principle should have been called instead: ‘Depend on Abstract’ The name originate from the following rule: The name originate from the following rule: Concrete classes should depend on abstract classes (or interfaces) and not the other way around. Concrete classes should depend on abstract classes (or interfaces) and not the other way around. Why ?: Why ?: Concrete classen change a lot. These classes influence your work if you depend on them (meaning: if you are their client). Concrete classen change a lot. These classes influence your work if you depend on them (meaning: if you are their client). Note: It may be okay to depend on concrete classees that aren’t likely to change anywhere soon, e.g. Date, HashMap, etc…. But you never know:.VB6 -> VB.net Note: It may be okay to depend on concrete classees that aren’t likely to change anywhere soon, e.g. Date, HashMap, etc…. But you never know:.VB6 -> VB.net

14 Systems Analysis & Design Methods, VII OOD-principles Dependency Inversion: counter example Don’t do this: Problem: If the MicroToolsCoolForm changes its default properties, then you have to accept that, or change them 58 times in my application. MicroToolsCoolForm MyAccountingApplication 58

15 Systems Analysis & Design Methods, VII OOD-principles Dependency Inversion: First improvement MyForm Improvement: If the MicroToolsCoolForm changes, say, color, you can still overwrite that color ONES in MyForm. 58 MicroToolsCoolForm MyAccountingApplication

16 Systems Analysis & Design Methods, VII OOD-principles Dependency Inversion: Second Improvement: ‘depend on abstract’ MyConcreteForm MyForm > Improvement: IfMicroToolsCoolForm changes, then the MyAccoutingApplication code doesn’t even have to know. It is a client of the MyForm which is abstract (in the case of Java, it is an interface ) MyAccountingApplication MicroToolsCoolForm 58