Please enable JavaScript.

Coggle requires JavaScript to display documents.

Programming Foundation: Design Patterns - Coggle Diagram

- - - - The over use of inheritance could cause issue when the super class has too many thing that the subclass don’t have. (Every time a not so fit subclass is created, the subclass will need to rewrite all the not so fit methods.
      - What about interface? (More implementation and flexible)
        
        Issues: Imagine that every new type of Duck will need to reimplement the interface again.
        
        No code reuse now...
  - - - Separate what vary: Move the quack() and fly() methods out of the original super class, and make then two interfaces
        
        Then implement their possible variations
        
        QuackBehavior interface
        
        Quack
        
        Squeak
        
        Mute
        
        FlyBehavior
        
        FlyWithWings
        
        FlyNoWay
    - - The right way to use an interface:
    - - This patten defines a family of algorithms, encapsulates each one, and makes them interchangeable. This lets the algorithm vary independently from clients that use it.
    - - :red_flag: Favor Composition over Inheritance
  - - - public abstract class PhoneCamreaApp { ShareBehavior }
        
        public class BasicCameraApp extends PhoneCameraApp { edit(); }
        
        public class CameraPlusApp extends PhoneCameraApp { public CameraPlusApp { } @Override public void edit() { System.out.println(“Edit type 1”); } }
  - - - Solves the modification of superclass all the time by creating interfaces to changing functions in superclass, and implement different methods for the change functionality interface.
      - You can add a function in the super class object to update the specific kind of functionality interface implements you want to pick
  - - - 2 .Make an interface that have an abstract function that is the same as the one in the super class that always changes
        
        Implementing the functionality interface for all existing functions
        
        In the super class, save a global interface variable for the functionality.
        
        Assigning it either (1) within the subclass constructor, or (2) a setting function that take the functionality interface implementations and update the global behaviors variables
        
        The behavior then can be used in a normally share function in the superclass without needing to change for any of the update, delete, add
- - - - So that for any test or simulator that requires a specific type of class, can consume the similar object that implements different type of interface.
    - - Dependency Inversion Principle (DIP): directly implement the interface/abstract class, and not the concrete class.
      - Open-closed Principle (OCP): open for extension and closed for modification of the super class
      - Interface Segregation Principle (ISP): interfaces are sparated
      - Single Responsibility Principle (SRP): each interface only responsible for one type of object.
  - - - For functions that need a specific type of interface object, but you only have a different original interface object.
      - The Adaptor Pattern can help you here by:
        Building an adaptor class that implements the target interface, and take the original interface object in the constructor. The adaptor will implement all the target interface functions with the desired behaviors based on the original interface object has. After calling to make a new adaptor with the original interface object feeder in the constructor of it, you will get an object that can be used for any function that required the target interface object.
    - - You first have two interfaces and two classes that implements them
        
        You have a function that only consume/take type1 interface, so you want to convert the type2 interface object to type1 in someway (hint: adaptor)
        
        The adaptor is (type2 -> type1), and implements type1 interface and all its functions. And the constructor of the adaptor takes a type2 interface object (saved globally for usage)
        
        The adaptor functions will use the function of type2 interface object, and named after the type1 interface (in any legal logics)
- - - - Now with the observer pattern, you can easily update value of a group of observer classes from one subject, as long as they implements the update() functions in the expected way.
  - - - Store the value as private global in both Subject and Observers. And the Observer will save the subject in calling the constructor with the corresponding subject.
        
        The registerObserver(this) is called in the Observer constructor
        
        The Observer.update() will be called in the Subject.updateValue(val) in the subject class object.
- - - - The decorator class will extends the main class, and add abstract functions for functionality modification (even the previously implemented functions are fine).
        
        When you want to add the decorators, just create a new decorator object, and with the main class as an argument to the constructor of it.
        
        You can save the decorator object in the main abstract class type, because the decorator extends from the abstract class that extends the main abstract class.
- - - - Create subclasses that extends the superclasses for the utility objects with each different variations.
        
        Create a Factory that have a createObject(String id) function, that takes an id and return a corresponding utility object created here.
        
        In the main subclass constructor, you take a factory object, and call it with an id that you want for the utility object. Then you will save the object (protected from super class) in the main subclass and use it’s features.