设计模式基础

May the force be with you.

1. intro to OOP

pillars of OOP
- abstraction: attributes and behaviors
- encapsulation: interface
- inheritance: code reuse
- polymorphism: different implementation of abstract method

inheritance
implementation
association: a object interacts/communicates with another
- in general used to represent a field in a class
- 箭头 + 直线
dependency: weak variant of association, no permanent link between objects
- typically implies that an object accepts another object as a method parameter
- 箭头 + 虚线
composition: “whole-part” relationship between two objects, one is composed of one or more instances of the other (part of the container)
- filled diamond + 直线 + 箭头
aggregation: a less strict variant of composition, container only contains references
- the container doesn’t control the life cycle of the component, which can be linked to several containers at the same time
- empty diamond + 直线 + 箭头

pattern description
- intent of the pattern
- motivation
- structure of classes
- code example
idioms: basic and low-level patterns to a single programming language
architectural patterns: can be used to design the architecture of an entire application
- creation patterns: object creation mechanisms
- structural patterns: how to assemble object and classes into larger structures
- behavioral patterns: take care of effective communication and the assignment of responsibilities between objects

code reuse
- level 1: reuse class, libraries, containers, etc
- level 2: patterns, higher granularity than class reuse but less risky and investment than framework
- level 3: framework, lets programmer define customized behavior, and will call these behaviors when its your turn
extensibility
- design for change

Identify the aspects of your application that vary and separate them from what stays the same, so that we can minimize the effect caused by changes

Depend on abstractions, not on concrete classes

collaborate two classes
- determine what exactly one object needs from the other: which methods does it execute
- describe these methods in a new interface or abstract class
- make the class that is a dependency implement this interface
- make the second class dependent on the interface

extending a class in several dimensions

instead of letting class implement behaviors on their own, delegate it to other objects

Single Responsibility
- A class should have only one reason to change.
- Try to make every class responsible for a single part of the functionality provided by the software, and make that responsibility entirely encapsulated by (you can also say hidden within) the class.
Open/Closed Principle
- Classes should be open for extension but closed for modification
Liskov Substitution Principle
- when extending a class, should be able to pass objects of the subclass in place of objects of the parent class without breaking the client code
  - parameter types: match or more abstract than superclass
  - return type: match or be a subtype of the return type of the superclass
  - a method in a subclass shouldn’t throw types of exceptions which the base method isn’t expected to throw
  - pre-condition只能更宽，post-condition只能更窄
Interface Segregation Principle
- clients shouldn’t be forced to depend on methods they do not use
- try to make interfaces narrow enough
Dependency Inversion Principle
- High-level classes shouldn’t depend on low-level classes. Both should depend on abstractions. Abstractions shouldn’t depend on details. Details should depend on abstractions.
- low-level class: implement basic operations
- high-level class: contain complex business logic
- use interface to describe the function that the high level class needs first, then you can extend low level class without breaking existing classes

main modification
- subclass overrides factory method to get different products based on its own type
- make products follow the same interface
base class use abstract method without knowing the concrete type of the product

purpose: the creator class already has some core business logic related to products, the factory method helps to decouple this logic from the concrete product classes
- 通过继承，在不改变核心逻辑的情况下，将逻辑依赖的具有相同功能但有着不同实现的对象解耦出来