Advanced Design Pattern: Design Principles

Introduction

What are design principles?

• A design principle is a guideline on top of core object-oriented concepts

• For example, favor composition over inheritance

• The results of following these design principles are design patterns

How many design principles are there?

• No standard catalog of principles

• Varies by domain

• Some have grouped principles into handy mnemonics, like SOLID

Design principles and design patterns

Creational Design Patterns

• Abstract Factory

• Builder

• Factory Method

• Prototype

• Singleton

The Principles

Encapsulate what varies

• Identify the aspects of your application that vary and separate them from what stays the same
• Is the same code changing with every new requirement?

• This design principle underlies almost all design patterns
• Strategy pattern
• Adapter pattern
• Facade pattern
• Decorate pattern
• Observer pattern
• Singleton pattern

• Look for code that changes with every new requirement

• Alter or extend the code that varies without affecting code that doesn’t

• Basics of almost every design pattern

• Pay attention to how each pattern makes use of this principle

Favor composition over inheritance

classDiagram
  Animal <|-- Duck: is-a
	Automobile <|-- Taxi: is-a

classDiagram
	direction LR
  Dog --o Owner: has-a
	Taxi --o Passenger: has-a

classDiagram
  class Coffee{
		cost()
		prepare()
	}

classDiagram
	direction TD
Coffee <|--CoffeeWithMocha
Coffee <|--CoffeeWithButter
Coffee <|--CoffeeWithMilk
  class Coffee{
		cost()
		prepare()
	}
class CoffeeWithMocha{
		cost()
		prepare()
	}
class CoffeeWithButter{
		cost()
		prepare()
	}
class CoffeeWithMilk{
		cost()
		prepare()
	}

classDiagram
  Mocha --|> Condiment
	Butter --|> Condiment
	Milk --|> Condiment
	Caramel --|> Condiment
	class Condiment {
		cost()
		prepare()
	}
class Mocha {
		cost()
		prepare()
	}
class Butter {
		cost()
		prepare()
	}
class Milk {
		cost()
		prepare()
	}
class Caramel {
		cost()
		prepare()
	}

classDiagram
	direction LR
  Coffee o--"1..*" Condiment
	class Coffee{
		Condiment[] condiments
		cost()
		prepare()
	}
	class Condiment{
		cost()
		prepare()
	}

• Instead of inheriting behavior, we can compose our objects with new behaviors

• Composition often gives us more flexibility, and even allows behavior changes at runtime

• Composition is a common technique used in design patterns

Loose coupling

• Components should be independent, relying on knowledge of other components as little as possible

• Loose coupling reduces the dependency between components

classDiagram
	direction LR
  WeatherApp --o LCDScreen
	class WeatherApp {
		LCDScreen screen
		getTemperature()
		display()
	}

public void display() {
	float temp = getTemperature();
	screen.printOnScreen(temp);
}

classDiagram
	direction LR
  WeatherApp --o DesktopWidget
	class WeatherApp {
		LCDScreen screen
		getTemperature()
		display()
	}

classDiagram
	direction TD
  LCDScreen ..|> Screen
	Widget ..|> Screen
	class Screen {
		print()
	}
	class LCDScreen {
		print()
		printOnScreen()
	}
	class Widget {
		print()
		printInWidget()
	}

//LCDScreen
public void print(float value) {
	printOnScreen(value);
}

classDiagram
	direction RL
  WeatherApp --o Screen
	class WeatherApp {
		Screen screen
		getTemperature()
		display()
	}
class Screen{
	print()
}
LCDScreen ..|> Screen
Widget ..|>Screen
class LCDScreen {
	print()
	printOnScreen()
}
class Widget {
	print()
}

//WeatherApp
public void display() {
	float temp = getTemperature();
	screen.print(temp);
}

Program to interfaces

• Where possible, components should use abstract classes or interfaces instead of a specific implementation

classDiagram
  KillerWebSystem --o CommercialDB
	class KillerWebSystem {
		CommercialDB db
	}
	class CommercialDB {
		select()
		update()
		delete()
		insert()
	}

//main
KillerWebSystem killerWebSystem = new KillerWebSystem();
killerWebSystem.db = new CommercialDB();

classDiagram
  KillerWebSystem --o AbstractDB
	class KillerWebSystem {
		AbstractDB db
	}
	CommercialDB ..|> AbstractDB
TestDB ..|> AbstractDB
class AbstractDB {
		select()
		update()
		delete()
		insert()
	}
	class CommercialDB {
		select()
		update()
		delete()
		insert()
	}
class TestDB {
		select()
		update()
		delete()
		insert()
	}

//main
KillerWebSystem killerWebSystem = new KillerWebSystem();
killerWebSystem.db = new TestDB();
//or
killerWebSystem.db = new CommercialDB();

Single responsibility principle

• A class should have only one reason to change

• Rectangle class provides 2 methods: area() and draw()

• Both Math App and Graphical App using it for calculating area and draw

• Rectangle also implements GUI

• Does this design violate the Single Responsibility Principle?

classDiagram
  class Rectangle{
		area()
		draw()
	}

• Assume that Math Lib wants to use Rectangle for calculating the area

• We will pull that Rectangle class out, we notice that it comes along with GUI. But we don’t want a GUI in the Math Lib

• Clearly, the lack of Single Responsibility is a problem here

• We have a Modem interface that provides these 4 methods
• dial() and hangup() for communication
• send() and receive() to send data

• Does this class have a single responsibility?

• Is this interface here cohesive?

• do these methods make sense together?

• We separate 2 interfaces Data and Communication

• ModemImplementation can delegate Data class and Communication class

• Do these really need to be separated?
• It depends what we need

• Look at the change in your class: are parts of it changing while other parts aren’t?

• Change only matters if it really happens

• Apply Single Responsibility when the need is real, or you’re just creating complexity

Open-closed principle

classDiagram
  class Duck{
		fly()
	}

//Duck Class
public void fly(){
	//code to flap wings, and so on
}
//Later we add more code for migrating
public void fly(){
	//code to flap wings, and so on
	// or if migrating, keep up with flock
	// or if duck is injured, don't flap wings
}

classDiagram
	direction BT
  Fly --|> FlyBehaviors
	MigrationFly --|> FlyBehaviors
	InjuredFlying --|> FlyBehaviors
	class FlyBehaviors{
		fly()
	}
	class Fly{
		fly()
	}
class MigrationFly{
		fly()
	}

classDiagram
	direction LR
  Duck --o MigrationFly
	class Duck{
		FlyBehavior fly
	}
	class MigrationFly{
		fly()
	}

• Allows new behavior without risking changes to proven code

• Improve maintainability and extensibility of a design

• Many techniques for this, including the use of the design patterns

Liskov’s substitution principle

classDiagram
  class TypeA{
		methodA()
		methodB()
	}

//main
public void doSomething(TypeA a) {
	//code does something
}
TypeA a = new TypeA();
obj.doSomething(a);

classDiagram
	direction BT
  TypeB --|> TypeA
	class TypeA{
		methodA()
		methodB()
	}

//main
public void doSomething(TypeA a) {
	//code does something
}
TypeB b = new TypeB();
obj.doSomething(b);

public void doSomething(TypeA a) {
	if (a instanceof TypeB) {
		//do something special here
	} else {
		//do something normal here
	}

}
TypeB b = new TypeB();
obj.doSomething(b);

• You should always be able to substitute subtypes for their base class

classDiagram
  class Rectangle{
		int height
		int width
		setWidth()
		setHeight()
		getWidth()
		getHeight()
		computeArea()
	}

classDiagram
  class Rectangle{
		int height
		int width
		setWidth()
		setHeight()
		getWidth()
		getHeight()
		computeArea()
	}
Square --|>Rectangle
class Square{
	setWidth()
	setHeight()
}

//Square
public void setWidth(int newWidth){
	width = newWidth;
	height = newWidth;
}
public void setHeight(int newHeight){
	width = newHeight;
	height = newHeight;
}

public void testRectangleArea(Rectangle r, int width, int height) {
	r.setWidth(width);
	r.setHeight(height);
	if ((width * height) != r.computeArea()) {
		System.out.println("Rectangle area failed");
	} else {
		System.out.println("Rectangle area passed");
	}
}

Rectangle myRect = new Rectangle();
Rectangle mySquare = new Square();
tester.testRectangleArea(myRect, 5, 5); //Pass
tester.testRectangleArea(myRect, 5, 4);//Pass
tester.testRectangleArea(mySquare, 5, 5);//Pass
tester.testRectangleArea(mySquare, 5,4);//Failed

Interface segregation principle

classDiagram
  class VendingMachine{
		takeMoney()
		brewCoffee()
	}

classDiagram
  class VendingMachine{
		takeMoney()
		brewCoffee()
		brewHotChocolate()
		brewTea()
		dispenseWater()
		dispenseSoda()
		dispenseSnack()
	}

classDiagram
	direction LR
  ClientA --o VendingMachine
	ClientB --o VendingMachine
	ClientC --o VendingMachine
	class VendingMachine{
		takeMoney()
		brewCoffee()
		brewHotChocolate()
		brewTea()
		dispenseWater()
		dispenseSoda()
		dispenseSnack()
	}

• How strong are the relationships between an interfaces’s methods?

• The SnackVendingMachine class actually only implements 2 methods in the entire vending machine interface

• It’s also same with HotBeverageVendingMachine and ColdVeverageVendingMachine class

• This is a sign that cohesion is low

• Let’s segregate the VendingMachine interface

 

 

 

 

Let’s segregate the Interfaces

• Cohesion of this class is low

//SnackVendingMachine
public class SnackVendingMachine implements VendingMachine {
	public boolean takeMoney() {
		if (successful) return true;
	}
	public void dispenseSnack(Item item){
	if (takeMoney()){
		//code to dispense item
	}
	public void brewCoffee(){
		//unimplemented, does not thing
	}
	public void brewHotChocolate(){
		//unimplemented, does not thing
	}
	public void brewTea(){
		//unimplemented, does not thing
	}
	public void dispenseWater(){
		//unimplemented, does not thing
	}
	public void dispenseSoda(){
		//unimplemented, does not thing
	}
}

classDiagram
	direction BT
  HotBeverageMachine ..|> VendingMachine
	ColdBeverageMachine ..|> VendingMachine
	SnackMachine ..|> VendingMachine
	class VendingMachine{
		takeMoney()
	}
class HotBeverageMachine{
		brewCoffee()
		brewHotChocolate()
		brewTea()
	}
class ColdBeverageMachine{
		dispenseWater()
		dispenseSoda()
	}
class SnackMachine{
		dispenseSnack()
	}

• Keep an eye on the cohesion of your interface and classes

• Highly cohesive interfaces lead to more maintainable and more flexible systems

• Segregate interfaces as necessary to keep them focused and cohesive

Dependency inversion principle

• High-level modules should not depend on low-level modules

graph TD
hlcom[Hight-Level Component]--depends on--> llcom[Low-Level Component]

graph LR
hlcom[Hight-Level Component]--depends on--> abstraction[Abstraction]
llcom[Low-Level Component] --depends on-->abstraction

classDiagram
	direction LR
  RemoteControl --o Television
	class RemoteControl {
		Television tv
		click()
	}
	class Television {
		turnTVOn()
		turnTVOff()
	}

classDiagram
	direction LR
  RemoteControl --o OnOffDevice
	Television ..|> OnOffDevice
	class RemoteControl {
		OnOffDevice device
		click()
	}
	class OnOffDevice {
		turnOn()
		turnOff()
	}
class Television {
	turnTVOn()
	turnTVOff()
}

• Frees high-level components from being dependent on the details of the low-level components

• This helps design software reusable and resilient to change

• All relationships should involve abstract classes of interfaces

References

• https://www.linkedin.com/learning/advanced-design-patterns-design-principles/take-your-design-to-the-next-level?autoplay=true

• https://www.javatpoint.com/java-oops-concepts