Benefits of using software design patterns and when to use design pattern

What is Design Pattern?
● A design pattern is a generic reusable solution to a commonly occurring
problem in software design.
● It is not a specific piece of code, but rather a template or blueprint that can be
used to solve different problems
● It is not specific to a particular programming language but can be applied
across different languages

Metaphor of Design Pattern
● Think of design pattern like a recipe for cooking
● Design patterns are "recipes" for solving specific software problems.
● It outlines the key ingredients (objects, relationships, functionalities) and steps
involved

Benefits of Design Pattern
Reusability:
Design patterns are proven solutions to common problems, eliminating the need to
"reinvent the wheel"
Scalability:
Design patterns promote flexibility to accommodate future growth without major
code rewrites.

Maintainability:
Design patterns often lead to modular code that is easy to understand and modify.
This helps in maintenance and bug fixes.
Readability and Understandability:
Design patterns often come with well-known names and structures that are widely
recognized in the development community.

Performance Optimization:
Certain design patterns can contribute to better performance. Example, the
Singleton can help manage resources efficiently.
Testability:
Pattern-based code often has well-defined interfaces and dependencies, making it
easier to write unit and integration tests. This improves code quality.

Drawbacks of Design Pattern
Choosing the wrong pattern:
Applying a pattern without understanding its purpose can lead to over-complicated
code that don't address the actual problem.
Blindly following patterns:
Patterns are not one-size-fits-all solutions. Applying them rigidly without
considering the specific context can hinder flexibility and creativity.

Overhead and Complexity:
Applying design patterns can introduce additional layers of abstraction and
complexity to the codebase. This might be unnecessary for simpler applications.
Overengineering:
Overusing design patterns or using them inappropriately can lead to over
engineered solutions.

Performance Concerns:
While abstraction is valuable, too many layers of abstraction can add processing
overhead and impact performance.
Rigidity:
Over-reliance on design patterns can make the codebase rigid and less adaptable
to change.

When to use Singleton pattern?
● Managing a single instance of a resource.
● Example: database connection, logger, configuration manager

When to use Builder pattern?
● When the entity has numerous optional parameters to create an object
● Complex object construction.
● Building hierarchical structures like trees or composite objects.
● Deferring object creation until all necessary data is available.
● Implementing validation logic during object construction.

When to use Facade pattern?
● When dealing with a subsystem containing numerous intricate interfaces.
● Decouple clients by providing an abstraction layer
● Implement access control and authorization mechanisms
● Centralized logging and auditing operations
● When common operations involve interacting with multiple components

When to use Adapter pattern?
● When two incompatible interfaces to work together seamlessly.
● If we intend to reuse existing code with different interfaces in multiple
contexts.
● Standardize access to various database systems with their unique APIs.
● Interact with devices having different communication protocols through a
common interface.

When to use Decorator pattern?
● Dynamically enhance object behavior at runtime
● GUI component customization using decorators without changing the
component itself
● Extending Functionality using filters, interceptors etc
● Build modular and easily extendable middleware

When to use Strategy pattern?
● Integrate with different payment gateways via interchangeable strategy
objects.
● Different sorting algorithms (mergesort, quicksort) based on user preference.
● Isolate different data access strategies (e.g., JDBC, ORM) behind a common
interface for easier switching.
● Implement various logging strategies for different environments (dev, prod).
● We need to extend the system's functionality without breaking existing clients.

When to use State pattern?
● The shopping cart can be in different states like "Empty", "Items Added",
"Checkout Started", "Payment Completed".
● Based user roles, states like "Logged Out", "Regular User", "Admin" can
dynamically limit different functionality.
● When we have workflow states like "Submitted", "In Review", "Approved",
"Rejected"
● System and Component Life Cycles

Design Pattern usage in Address Forms
The official class syntax is currently not part of the core React library. In our
address form, we tried to use the concepts of multiple design patterns.
● Strategy Pattern
● Decorator pattern
● State pattern

Decorator Pattern in Address Forms

Strategy Pattern in Address Forms

Benefits of using software design patterns and when to use design pattern

Recommended

More Related Content

What's hot (20)

Similar to Benefits of using software design patterns and when to use design pattern (20)

Recently uploaded (20)

Benefits of using software design patterns and when to use design pattern