🌵
Christian's Wiki
/
🎨
SOLID OOP
🎨

SOLID OOP

‣
🔪 What is the Single Responsibility Principle (SRP)?
‣
Every software component should have one and only one responsibility. A software component can be a class method or module
image
  • SRP Example: Swiss Army Knife vs. Knife
    • image

What is cohesion?

‣
♻️ Cohesion
Cohesion is the degree to which the various parts of a software component are related of relation
image
  • Top: Unsegregated trash. It is low cohesion
  • Bottom: Notice the yellow bin. The bottles are not alike. However, the contents of the yellow bin have a common relation - they are all made of plastic. It is high cohesion
‣
How would you describe the methods of this class Square in the context of the SRP
  1. calculateArea() and calculatePerimeter() methods have high degree of cohesion / relation
  2. draw() and rotate() methods also have high degree of cohesion / relation
  • However, #1 and #2 do not.
‣
How would you refactor class Square to increase cohesion?
‣
class Square refactor to class Square and class SquareUI
💡
class Square Responsibility: Measurements of squares
export class Square {
  constructor(public side: number) {}

  public calculateArea(): number {
    return this.side * this.side;
  }

  public calculatePerimeter(): number {
    return this.side * 4;
  }
}
💡
class SquareUI Responsibility: Rendering of squares
class SquareUI {
  public draw(): void {
    if (this.highResolutionMonitor) {
      //render a high res image of a square
    } else {
      //render a low res image of a square
    }
  }
  public rotate(degree: number): void {
    // rotate image clockwise
  }
}
‣
What is the the (single) responsibility of class Square and class SquareUI?
💡
class Square Responsibility: Measurements of squares
export class Square {
  constructor(public side: number) {}

  public calculateArea(): number {
    return this.side * this.side;
  }

  public calculatePerimeter(): number {
    return this.side * 4;
  }
}
💡
class SquareUI Responsibility: Rendering of squares
class SquareUI {
  public draw(): void {
    if (this.highResolutionMonitor) {
      //render a high res image of a square
    } else {
      //render a low res image of a square
    }
  }
  public rotate(degree: number): void {
    // rotate image clockwise
  }
}
🔑
High Cohesion helps attain better adherence to the SRP

Coupling

‣
🚂 Train Example: Coupling
Coupling is defined as the level of interdependency between various software components
image
  • Standard Gauge Rail (1.4 m wide) vs Broad Gauge Rail (1.6 m wide)
  • The trains are tightly coupled to their track
‣
How would you describe the methods of this class Student in the context of the SRP?
  • Tightly coupled with the database layer
  • Student class should not be cognizant of the low level details related to dealing with the database
‣
How would you refactor class Student to decrease coupling? What would this refactor allow?
  • Tightly coupled with the database layer
  • Student class should not be cognizant of the low level details related to dealing with the database
‣
Refactor
  • This would allow us the flexibility to change our database operations details without changing our student class, or switch out our underlying database if we wanted to
‣
What is the (single) responsibility of class Student and class StudentRepository?
💡
The class Student has the single responsibility of handling core student related data
class Student {
  private studentId: string;
  private dob: Date;
  private address: string;

  public save(): void {
    (new StudentRepository).save(this)
  }
  public getStudentId(): string {
    return this.studentId;
  }
  public setStudentId(studentId: string): void {
    this.studentId = studentId;
  }
	...
	...
	...
}
💡
The class StudentRepository has the single responsibility of handling database operations

An alternative interpretation

‣
What is another way of describing the SRP?
Every software component should have one and only one reason to change.
‣
How would you test for low cohesion and high coupling? Alternatively, how do you identify violations of the SRP?
  • Ask yourself, how many reasons a piece of code has to change, and make refactors based on that
‣
How would you fix code that violates the SRP?
  • Refactor, and aim for high cohesion, and low coupling.
‣
What are the reasons this code would need to change?
  1. Change to student id format
  2. Change in the student name format
  3. A change to the database
💡
#1 and #2 can be combined because they're closely related. So you can say there are two reasons: 1. Changes to student profile 2. Change to backend
‣
🎮 What is the Open/Closed Principle (OCP)?
Software components should be closed for modification but open for extension
image
💡
The Wii was designed in such a way that it is closed for modification, but open for extension
‣
What does closed for modification mean?
  • New features getting added to the software component, should NOT have to modify existing code.
‣
What does open for extension mean?
  • A software component should be extendable to add a new feature or to add a new behavior to it.
‣
💸 Example: Suppose you have a system that calculates insurance premium discounts for health insurance customers implemented like so
class InsurancePremiumDiscountCalculator {
	public caculateDiscount(customer: HealthInsuranceCustomerProfile): number {
		if(customer.isLoyalCustomer()) {
			return 20
		}
		return 0
	}
}

class HealthInsuranceCustomerProfile {
	public isLoyalCustomer(): boolean {
		return true; //or false
	}
}
  • Now, suppose you would like to change this system to be able to caclulate discounts for another kind of customer like below:
class VehicleInsuranceCustomerProfile {
	public isLoyalCustomer(): boolean {
		return true;//or false
	}
}
‣
How could you refactor the above? Which one should you choose and why?
  1. You could implement another method that will make the same calculation, but for the class VehicleInsuranceCustomerProfile
  2. You could define an interface interface CustomerProfile that both our customer profile classes could implement, and change the method signature to reflect the newly defined interface.
    3. interface CustomerProfile {
	public isLoyalCustomer(): boolean;
}

You should choose option 2.

👎 Option 1 repeats code, and would force you to modify the discount calculator class for any new kind of customer profile.

👍Option 2 would allow you to extend the functionality of the discount calculator for any customer profile that implements CustomerProfile

‣
👍 What are the key benefits of OCP?
  • Ease of adding new features.
  • Leads to minimal cost of developing and testing software.
  • Open Closed Principle often requires decoupling, which, in turn, automatically follows the Single Responsibility Principle.
‣
What should you be wary of when following SRP+OCP?
  • You could end up with too many classes and overly complicated design.
‣
How do you identify violations of the OCP?
  • When you need to modify and or repeat existing code to accommodate additional features that have similar functionality.
‣
How do you fix violations of the OCP?
  • Interfaces! Usually helps improve reusability of code for different kinds/types of input.
‣
🛒 What is Liskov Substitution Principle (LSP)?
Objects should be replaceable with their subtypes without affecting the correctness of the program
‣
Which of the following violate the LSP? Why?
image

The ostrich "is-a" bird, but ostriches can't fly. So any function that takes an argument of type Bird (or a subtype of bird) that calls the fly method will throw an error for instances of the Ostrich class.

image
💡
Unimplemented methods in child classes are indicative of a design flaw according to LSP, and SRP
‣
The following statement is often associated with LSP:
If it looks like a duck and quacks like a duck but it needs batteries, you probably have the wrong abstraction!

As such, the LSP requires a test standard that is more strict than the "is-a" test.

image
💡
Racing cars do not have cabins
‣
How & why does the following code violate the Liskov Substitution Principle? And how would you fix it?
image
  • It breaks because getCabinWidth() is not implemented on Racing Cars (because racing cars don't have cabins). And, since class RacingCar is a subtype of Car, but breaks when an a Car instance breaks under, it fails under LSP.
  • Break the hierarchy - You implement a parent superclass that both classes will extend:
image
‣
How do you fix code that violates the Liskov Substitution Principle?
  1. Break the hierarchy - Specifically, you could implement a parent superclass that the offending class and the original parent class inherit from
  2. Tell-don't-ask - Rather than asking an object for data and acting on that data, we should instead tell an object what to do. (e.g. if (product instanceof InHouseProduct) { product.applyExtraDiscount()} versus implementing the check and the "extra discount" in the discount() method on the class InhouseProduct)

https://martinfowler.com/bliki/TellDontAsk.html

‣
How do you identify violations of the Liskov Substitution Principle?

You can try to replace an object class with an instance of it's subtype.

‣
How & why does the following code violate the Liskov Substitution Principle? And how would you fix it?
image
  • This code fails to obey LSP because the behavior of the code changes depending on the (sub)-type of the product.
  • You could fix it by implementing the Ask-dont-tell principle via inverting class ProductUtils dependency on the product (sub)type by overriding the getDiscount() method on the class InHouseProduct and applying the extra discount there.
image
‣
📰 What is Interface Segregation Principle (ISP)?
No client should be forced to depend on methods it does not use
‣
Suppose you're designing a system that will allow developers to interact with a collection of printers and scanners. And to do so, you define interface IMultiFunction to the system that will be implemented by class XeroxWorkCenter, class HPPrinterScanner, and class CanonPrinter like so:
image
image

What is wrong with this code? Why is this a problem?

  • This code violates the Interface Segregation Principle, because both the HP PrinterScanner class and the Canon Printer class' implementations depend on the IMultiFunction interface with methods they do not use.
  • It's a problem because if a developer (user for our system) comes and uses our system to fax, he or she could cause the system to break down by calling the fax() method on the HP PrinterScanner class or the Canon Printer class
‣
Suppose you have designed an API that allows developers to interact with a collection of printers and scanners. And to do so, you define class XeroxWorkCenter, class HPPrinterScanner, and class CanonPrinter that implement the interface IMultiFunction like below.

Which design principle is this implementation violating? How would you fix it?

image
image
  • The ISP
  • You could fix it by splitting the big interface into smaller + higher cohesion interfaces, and the interfaces the printer/scanner classes implement.
  • Additionally, you could define a parent interface (e.g. interface Exportable) that can be extended with additional methods in interface IScan, interface IPrint , and interface IFax
image
image
‣
How do you identify violations of the Interface Segregation Principle?
  1. Fat Interfaces
  2. Interfaces With Low Cohesion
  3. Empty Method Implementations
‣
How do you fix violations of the Interface Segragation Principle?
  • Split the fat interface into leaner and higher cohesion interfaces. You could also define a parent interface that these leaner interfaces will extend.
‣
What is Dependency Inversion Principle (DIP)?
High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details (concrete implementations) should depend upon abstractions.

A Ecommerce web app

💡
High level modules and low level modules are relative
image
‣
The following implements the ProductCatalog class and a SQLProductRepository for an eCommerce Web Application. What is wrong with the code? And how would you fix it?
image
  • The class ProductCatalog (the high level module) depends on class SQLProductRepository (the low level module) and thus violates the DIP
  • You can fix it by inverting the dependency, and refactoring the implementation of class ProductCatalog to depend on class ProductFactory , an abstraction
    • In this instance, you would want to define an interface ProductRepository that the class SQLProductRepository will implement.
      • 💡
      This means that both class ProductCatalog and class SQLProductRepository will now depend on the interface ProductRepository
    • Additionally, we would not want our class ProductCatalog to directly instantiate the SQLProductRepository isntance. Instead, we would want define a class ProductFactory which will return an instance of the SQLProductRepository class
      • 💡
      This means that the implementation of class ProductCatalog now depends on the abstraction class ProductFactory
      image
‣
How do you identify violations of DIP? (High-level modules should not depend on low-level modules. Both should depend on abstractions.)
  • If a high level module is directly aware of the details of a low level class.
‣
How do you fix violations of DIP?

Defining interfaces that both the high level and low level will depend on

Additionally defining classes that abstract implementation details of lower level modules and provide them to the higher level module via dependency injection.

‣
The following implements a ProductCatalog class, a ProductRepository interface, and a SQLProductRepository that implements the Product repository interface for an eCommerce Web Application. What is wrong with the code? And how do we fix it?
image
  • As we can see, we use the factory method in order to provide an instance of the SQLProductRepository object.
💡
Which means that the concrete implementation details of class ProductCatalog depends on the abstraction class ProductFactory
❗
Ideally, however, we don't want the ProductCatalog class to have to worry about when and how instances of classes that implement the ProductRepository interface should be created.
  • Dependency Injection: So, instead we can provide the instance of the class implementing the interface ProductRepository to the class ProductCatalog when it is being instantiated. As such we implement another class Main that will inject that dependency, and take care of instantiation logic.
image
‣
What is dependency injection?

It is a method of applying the dependency inversion principle to classes by providing instances of dependencies. 

export class Square {
  constructor(public side: number) {}

  public calculateArea(): number {
    return this.side * this.side;
  }

  public calculatePerimeter(): number {
    return this.side * 4;
  }

  public draw(): void {
    if (this.highResolutionMonitor) {
      //render a high res image of a square
    } else {
      //render a low res image of a square
    }
  }
  public rotate(degree: number): void {
    // rotate image clockwise
  }
}
export class Square {
  constructor(public side: number) {}

  public calculateArea(): number {
    return this.side * this.side;
  }

  public calculatePerimeter(): number {
    return this.side * 4;
  }

  public draw(): void {
    if (this.highResolutionMonitor) {
      //render a high res image of a square
    } else {
      //render a low res image of a square
    }
  }
  public rotate(degree: number): void {
    // rotate image clockwise
  }
}
class Student {
  private studentId: string;
  private dob: Date;
  private address: string;

  public save(): void {
    const query = JSON.stringify(this);
    let connection: Connection = null;
    let statement: Statement = null;
    try {
      connection = db.connect("mysql://localhost:3306");
      statement = connection.createStatement();
      connection.execute(`INSERT INTO STUDENT VALUES ${query}`);
    } catch {
      console.error();
    }
  }
  public getStudentId(): string {
    return this.studentId;
  }
  public setStudentId(studentId: string): void {
    this.studentId = studentId;
  }
	...
	...
	...
}
class Student {
  private studentId: string;
  private dob: Date;
  private address: string;

  public save(): void {
    const query = JSON.stringify(this);
    let connection: Connection = null;
    let statement: Statement = null;
    try {
      connection = db.connect("mysql://localhost:3306");
      statement = connection.createStatement();
      connection.execute(`INSERT INTO STUDENT VALUES ${query}`);
    } catch (Error) {
      console.error(Error.message);
    }
  }
  public getStudentId(): string {
    return this.studentId;
  }
  public setStudentId(studentId: string): void {
    this.studentId = studentId;
  }
	...
	...
	...
}
class Student {
  private studentId: string;
  private dob: Date;
  private address: string;

  public save(): void {
    (new StudentRepository).save(this)
  }
  public getStudentId(): string {
    return this.studentId;
  }
  public setStudentId(studentId: string): void {
    this.studentId = studentId;
  }
	...
	...
	...
}

class StudentRepository {
	public save(student: Student): void {
    const query = JSON.stringify(this);
    let connection: Connection = null;
    let statement: Statement = null;
    try {
      connection = db.connect("mysql://localhost:3306");
      statement = connection.createStatement();
      connection.execute(`INSERT INTO STUDENT VALUES ${query}`);
    } catch (Error) {
      console.error(Error.message);
    }
}

class StudentRepository {
	public save(student: Student): void {
    const query = JSON.stringify(this);
    let connection: Connection = null;
    let statement: Statement = null;
    try {
      connection = db.connect("mysql://localhost:3306");
      statement = connection.createStatement();
      connection.execute(`INSERT INTO STUDENT VALUES ${query}`);
    } catch (Error) {
      console.error(Error.message);
    }
}
class Student {
  private studentId: string;
  private dob: Date;
  private address: string;

  public save(): void {
    const query = JSON.stringify(this);
    let connection: Connection = null;
    let statement: Statement = null;
    try {
      connection = db.connect("mysql://localhost:3306");
      statement = connection.createStatement();
      connection.execute(`INSERT INTO STUDENT VALUES ${query}`);
    } catch (Error) {
      console.error(Error.message);
    }
  }
  public getStudentId(): string {
    return this.studentId;
  }
  public setStudentId(studentId: string): void {
    this.studentId = studentId;
  }
	...
	...
	...
}