Prototype Design Pattern [Creational]

The prototype pattern should be used when the construction of new instances is inefficient. When the initialization of an object is expensive, you should consider using the prototype pattern.

• The prototype pattern creates clone instances from a prototype object.
• The clones are created by copying all the properties of the prototype instance.
• The clones are independent objects.
• Modifying the clone does not affect the prototype and vice versa.
• Value types get ultimately copied upon assignment, whereas we need to implement the copying for reference types, that is for classes.
• The prototype pattern creates new objects by copying a prototype object. Use this pattern if initializing an object is expensive.
• Value types make implementing the prototype pattern very easy because they are automatically copied upon assignment.
• The cloning of objects stands at the core of the prototype pattern.
• To correctly clone objects, we must understand the difference between the shallow and the deep copy. I am going to provide code examples for that too.
• Prototype: creation through delegation. Factory Method: creation through inheritance.

The prototype pattern creates new objects by copying a prototype object. Use this pattern if initializing an object is expensive.

Example: AddressBook – while creating a new contact of an employee in an organization the details like Basic Info, Address, Employment details, Notes & links will have empty prefills.

Click on this link to understand Deep vs Shallow copy.

Summary: The prototype pattern creates new instances by cloning a prototype object and copying all its properties, instead of constructing new objects. The copied instance is an independent object. Changing its properties doesn’t affect the cloned object. Use this pattern when creating new instances of a given type is inefficient.

Singleton Design Pattern [Creational]

Motivation: When you need a unique object

Be Careful: In case of accessing it in multiple threads

• The singleton pattern ensures the uniqueness of an object.
• You implemented the pattern correctly if only one instance of the given type can be created and that instance cannot be cloned.
• The singleton instance must be thread-safe since many different components might access it concurrently.
• You must implement protection against concurrent use for the initialization phase of the singleton and any access to its public properties or methods.

The singleton pattern ensures only one instance of a given type exists, and that instance cannot be copied or cloned. The singleton must be thread-safe since the shared instance can be concurrently accessed by several threads.

The aim is to create a class which can have exactly one instance. But it also requires attention when implementing it. We must prohibit the copying or cloning of the singleton instance. We can only use reference types, that is classes since value types are copied upon assigning them to a new variable. The singleton instance represents a shared resource that can be used by all components that depend on the given type. These components may access the singleton instance concurrently from different threads. Therefore, the singleton class must be thread-safe. We must protect against concurrent access, its instantiation, and any access to its public members and methods.

Examples of Singleton:

• File manager
• Logger system
• Analytics system

Design Patterns: Importance and its Limitations

Advantages of Design patterns:

• Reusability in countless projects to solve problems with a common pattern
• Spend less time figuring out how to solve a particular issue
• Spend a safe time on implementing the solution and improve the quality of the software product
• Provides more value for the money
• Proven solution – Extending or enhancing a software system that relies on well-established design patterns is easier
• Refactoring your code base also means that you introduce new bugs
• Reduces the risk of implementing solutions that only work in the short-term.
• Lessen the need for frequent changes by using design patterns

Limitations

• Whether or not to use a design pattern can be a tough decision.
• Due to their generic nature, design patterns may not be able to address specific issues. In such cases, you will need to adapt them and change their implementation to fit your particular needs.
• A certain level of expertise is required to implement design patterns correctly.
• Unexperienced teams may fail to implement them properly, which can lead to bugs and unexpected delays.  

Design patterns series

I am refreshing my design patterns knowledge and this series will have nearly 20+ blog posts. Each post will be about a single design pattern. The post will contain a gist of when, where to use the pattern and essence of the pattern with a brief explanation of examples to understand.

Here’s the list of Design patterns, categorized into 3 types:

Creational patterns

1. Singleton
2. Prototype
3. Builder
4. Factory
5. Abstract factory

Structural patterns

1. Adapter
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy

Behavioural patterns

1. Chain of responsibility
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10. Template
11. Visitor

Sourcemaking website has listed out the Thumb Rules for:

• Creational design patterns
• Structural design patterns
• Behavioral design patterns

Please share your thoughts, comments and suggestions here or on my twitter handle.

This series and all other blogs are written while I learnt these and post it as just a cheat-sheet or a gist for my future references, hoping it will help you and other readers too.