A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Categories
GoF book presents the 3 categories of the design patterns:
- Creational
- Behavioral
- Structural
How to implement the design pattern in the code?
- Please read about the patterns, implement them along the way, read existing code, and start recognizing them (create with the frameworks and libraries you use).
- The common mistake of developers is coming up with a ready solution for the problem and trying to fit the pattern you just learned.
- Come up with the raw solution first, and then try to recognize the pattern use case if the implementation becomes painful.
[Behavioral] Observer
Observer pattern – defines one-to-many relationship between objects in such a way, that when the object changes his state, then all of his dependent objects are notified and updated — GoF book
Intent
Observer is a behavioral design pattern that allows creating a structure that allows objects (observers subjects or publishers) to inform about their state to change other objects (observers or subscribers or subjects) in a loosely coupled way.
Problem
- Imagine that you have two types of objects: a
Customerand aStore. The customer is very interested in a particular brand of product (say, it’s a new model of the iPhone) which should become available in the store very soon. - The customer could visit the store every day and check product availability. But while the product is still en route, most of these trips would be pointless.
Solution
- The object that has some interesting state is often called subject, but since it’s also going to notify other objects about the changes to its state, we’ll call it publisher.
- All other objects that want to track changes to the publisher’s state are called subscribers.
- The Observer pattern suggests that you add a subscription mechanism to the publisher class so individual objects can subscribe to or unsubscribe from a stream of events coming from that publisher.
[Creational] Singleton
Intent
- Singleton is a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance.
Problem
- Ensure that a class has just a single instance. Why would anyone want to control how many instances a class has? The most common reason for this is to control access to some shared resource—for example, a database or a file.
- Provide a global access point to that instance. Remember those global variables used to store some essential objects? While they’re very handy, they’re also very unsafe since any code can potentially overwrite the contents of those variables and crash the app.
Solution
- Make the default constructor private, to prevent other objects from using the
newoperator with the Singleton class. - Create a static creation method that acts as a constructor. Under the hood, this method calls the private constructor to create an object and saves it in a static field. All following calls to this method return the cached object.
- Special consideration for Kotlin:
- Kotlin’s representation of a Singleton class requires the
objectkeyword only - An
objectclass can contain properties, functions and theinitmethod. - The constructor method is NOT allowed.
- An object cannot be instantiated in the way a class is instantiated.
- An object gets instantiated when it is used for the first time providing lazy initialization.
Objectdeclaration’s initialization is thread-safe.
- Kotlin’s representation of a Singleton class requires the
