1. Principles of Object Oriented Design
- John Teague & Mahendra Mavani

2. High Cohesion Low Coupling
Old Standards
for Object Oriented Programming

3. Problems Solved Maintainability Easier to Test
Less Resistance to Change
Fear to Change Code Leads to Old Stinky Code
Reduces Repetition (DRY)
Don’t Cut and Paste!!!!
Allows For Continuous Improvement
Essential for Agile Development

4. Topics To Discuss Single Responsibility Principle
Dependency Inversion Principle
Open Closed Principle
Interface Segregation Principle
Law of Demeter
Liskov Substitution Principle

5. Single Responsibility Principle
What is Responsibility?
Reason for change
Find how many reason you can think of for you class/method to change
If more than one, then your design violates SRP

6. Single Responsibility Principle
Requirement : Send monthly account statement to the customer <demo>

7. Single Responsibility Principle
Problem:-
we have more than one responsibility
reading transaction record
Formatting
Sending
Different user may want different format
IT Dept. may decide to change how data is stored
Bank might want to start using third party sending utility.

8. Single Responsibility Principle
Refactor
public class TransactionRepository {…. }
public class HTMLMailFormater {….}
public class Service {…….. }
Demo

9. Dependency Inversion Depend upon abstraction
High level module should not depend upon low level module implementation, rather depend upon abstraction
Template pattern

10. Dependency Inversion
Naïve Example Demo

11. Dependency Inversion Problem:-
All the client must use text file to store transaction
Sends in HTML format only
Code in BankAccount class, doesn’t depend upon storage but still can’t be tested in isolation.

12. Open Closed Principle
Classes should be Open to Extensibility and Closed to Modifications
To Change behavior, you want to add new code instead of modifying existing Code.
May not have access to code

13. Why Keep Code Closed To Modifications
Changing Existing Code is Risky.
Can be Time Consuming in a Non-Refactored code base.

14. Code Not Designed on OCP
private string SetDefaultEditableText() { StringBuilder editableText = new StringBuilder(); switch ( SurveyManager.CurrentSurvey.TypeID ) case 1: editableText.Append("<p>Text for Survey Type 2 Goes Here</p>"); case 2: case 3: default: editableText.Append("<p>Text for Survey Type 3 Goes Here</p>"); } return editableText.ToString();

15. Desigined For Extensibility
Strategy Pattern (Composition focused)
interface ISurvey Formatter{
string GetDefaultEditableText(); }
public SurveyType1 Formatter : ISurvey Formatter{
public string GetDefaultEditableText(){
return "<p>Text for Survey Type 1 Goes Here</p>";
public SurveyType2 Formatter : ISurvey Formatter{
public string GetDefaultEditableText(){
return "<p>Text for Survey Type 2 Goes Here</p>";
public SurveyType3 Formatter : ISurvey Formatter{
return "<p>Text for Survey Type 3 Goes Here</p>";

16. Strategy Pattern Cont’d
public class Survey{ I Formatter _ Formatter; public Survey(I Formmater Formater){ _ Formatter = Formatter; } public string Get DefaultText(){ return _ Formatter.GetDefaultEditableText();

17. Designed for Extensibility Template Pattern (Inheritance)
public abstract Survey{ protected abstract string GetDefaultEditableText(); public string Get Text() { … string defaultText = GetDefaultEditableText(); return somthingHere; } public SurveyType1{ protected string GetDefaultEditableText() return "<p>Text for Survey Type 1 Goes Here</p>";

18. Extensibility Only Goes So far
Change is going to occur and you can’t keep everything from changing
Must use judgment on which parts of your application are more likely to change and focus extensibility there.

19. Law of Demeter Don’t Talk To Strangers Methods Should Only Talk To:
Methods and fields on the Object
Parameters passed into the method
Objects Created within the method
Only one “dot”
foo.bar.baz (bad)

20. Demeter
Breaking this principle breaks encapsulation, and tightens coupling.
Refactoring much more difficult
Test Setup becomes much more difficult

21. Demeter
public class Wallet { double Cash{get;set;} } public class Customer Wallet Wallet{get;set;} public class Paperboy public double AmountCollected{get;set} public void CollectMoney(Customer customer, double amount){ if(customer.Wallet.Cash < amount) throw new InsufficientFundsException(); customer.Wallet.Cash -= amount; AmountCollected += customer.Wallet.Cash;
The higher the degree of coupling between classes, the higher the odds that any change you make will break something somewhere else. This tends to create fragile, brittle code.

22. Demeter
The fix:
public class Wallet {
double Cash{get;set;}
public double Withdraw(double amount){
if(Cash < amount)
throw new InsufficientFundsException();
Cash -= amount;
return amount; }
public class Customer
Wallet Wallet{get;set;}
public double Pay(double amount)
Wallet.Withdraw(amount);
public class Paperboy
public double AmountCollected{get;set}
public void CollectMoney(Customer customer, double amount)
AmountCollected += customer.Pay(amount);

23. Interface Segregation Princple
Clients shouldn't be forced to implement interfaces they don't use

24. Interface Segregation Princple
Example of FAT or Polluted Interface
Try implementing custom Membership Provider in ASP.NET 2.0.
You just need to implement 27 methods/properties

25. Interface Segregation Princple
Interface Idoor {
void Lock();
void UnLock();
bool IsOpen(); }
Public Class Door : Idoor
public void Lock() {}
public void UnLock(){}
bool IsOpen(){}
<Demo>

26. Interface Segregation Princple
Consider one implementation as security door which need to ring alarm if door is kept open for longer duration.
Interface Idoor {
void Lock();
void UnLock();
bool IsOpen();
void Timeout(); }
public class SecurityDoor : Idoor
void Lock() {}
void UnLock() {}
bool IsOpen() {}
void Timeout() {}
<Demo>

27. Interface Segregation Princple
Problem
All type of door are not timed
By adding Timeout into IDoor we are polluting our interface

28. Interface Segregation Princple
public interface ITimerClient { void TimeOut(); } public class SecurityDoor : IDoor, ITimerClient public void TimeOut() {…….}

29. Liskov Substitution Principle
All sub-classes must be substitutable for their base class.

30. Liskov violation Structural Behavior
You should not have to explicitly cast a base object to it’s subclass to do something.
Behavior
Subtypes should behave in a consistent manner in terms of their clients

31. Liskov Example
public class LinkedList { public void copyInto(LinkedList dest) { dest.clear(); int n = getLength(); for(int i = 0; i < n; ++i){ dest.addElement(getElementAt(i)); } public class Set : LinkedList { ... /** * Adds element to this set, provided * element is not already in the set */ public void addElement(Object element) { if(!hasElement(element)) super.addElement(element);
A later assignment asks the student to develop a set abstract data type. The student thinks, since a set is a list of non-duplicated elements, the set class could inherit from the linked list class saving lots of work and reusing code that already works. The only change would be to override the addElement method to provide the non-duplicated element requirement. Here is the student's set class:

32. Liskov Behavior of CopyInto will not always be consistent
Set To Set is okay
LinkedList to LinkedList is okay
Set to LinkedList is okay
LinkedList to Set behaves differently
Linked List with {1, 2, 3, 2, 1} becomes {1, 2, 3}

33. Bottom line … SRP DIP OCP LSP LoD ISP Only one reason to change
“Don’t call me, I’ll call you”
OCP
Open for extension, Closed for modification
LSP
Sub types should be substitutable for their bases types
LoD
“Don’t talk to strangers”
ISP
Clients should not be forced to depend on methods they do not use

34. Remember…
Always code as if the guy maintaining your code would be a violent psychopath and he knows where you live.

35. References Uncle Bob’s blog
Los Techies Topic of the Month