Last Updated: 26 Oct 2023

   |   

Author: 111.225.149.17

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
backend-tech:design-pattern-quick-reference [Oct 26, 2023 11:00 PM]
111.225.149.17 removed 		— (current)
Line 1: Line 1:
-= Design Pattern Quick Reference = 
  
-Short descriptions of common design patterns. This only scratches the surface of what's available (or even what's commonly used); add more in the comments if your favorite pattern isn't here. 
- 
-* **Singleton**: A pattern which only allows one of itself to be instantiated. Somewhat controversial, and frequently used like a 'global' variable. 
-* **Multiton**: A singleton-like pattern which takes a key, and allows itself to be instantiated once per key. Often used in situations where you might need to maintain a library of information, e.g. data on specific servers in a configuration management system. 
-* **Proxy**: A proxy sits in front of an object and intercepts calls, etc. to that object. It can record, modify or redirect those calls before sending them on to the destination object. Especially useful for logging. 
-* **Façade**: A façade pattern is similar to a proxy; it sits in front of an object or objects and handles interaction with them. Typically façade is used in front of multiple objects to simplify the interface to those objects. A good example is an API call; you may need to authenticate with one object, call the API with a second and decode the results with a third. A façade pattern would handle all of that internally, so the calling function only has one object to deal with. 
-* **Decorator**: A decorator allows you to modify the behavior of an object at run-time. From a behavior standpoint, it is similar in concept to inheritance. Just as a child class can extend a parent class, a decorator can //decorate// an object, adding additional functionality not present in the base object. However, since it does this decoration at run-time, it is more flexible than inheritance. 
-* **Factory**: The factory pattern is used to create an instance of another object. Typically, a factory has some logic built into it, so that it can create the appropriate type of object given some input. For example, it might create a User object if debug mode is off, but a DummyUser object if debug mode is on. 
-* **Observer**: The observer pattern //observes// an object for some event to take place, and then takes action if it does. Typically used in event based systems.  
-* **Publish/Subscribe**: Similar to observer, except instead of the observer monitoring a single object, it monitors a queue of events from monitored objects, and takes action if an certain event fires. Slightly more complex than observer, but means that each observer does not have to manually observe each monitored object.