 |
VOOZH | about |
|
VOOZH | about |
Design patterns are reusable and proven solutions to common software design problems. They provide a structured approach for building flexible, maintainable, and scalable applications while helping developers write cleaner code and make better architectural decisions.
Design patterns provide proven and reusable solutions to common software design problems. They help developers write clean, maintainable, and well-structured code while promoting best practices. They also improve flexibility, scalability, and communication among developers.
While algorithms and design patterns both offer solutions for recurring problems, their difference lies in their purpose:
Design Principles are guidelines followed during software design, such as SOLID, which focus on making software more scalable, extensible, and maintainable. These principles apply to the entire development process and programming practices.
Design Patterns, however, are predefined solutions to specific design problems. They are ready-to-use solutions that can be customized based on specific needs. For example, Factory, Singleton, and Strategy patterns are solutions for specific issues that arise during software development.
Three main types of Design Patterns are as follows
There are many advantages of using Design Patterns
The following are five types of Creational Patterns:
The types of Structural patterns are as follow :
The types of Behavioral Patterns are as follow:
Some of the design patterns used in Java's JDK library include:
BufferedReader and BufferedWriter.Runtime and Calendar classes to ensure only one instance exists.Integer.valueOf() for converting strings to integers.AWT and Swing for UI event management.Examples: Decorator Pattern: BufferedReader wraps a FileReader to add buffering functionality without modifying FileReader.
The SOLID Principles are five design principles developers use to write clean, maintainable, and scalable code:
The four authors who published the book Design Patterns Elements of Reusable Object-Oriented Software are known as Gang of Four. The name of four authors are Erich Gamma, Ralph Johnson, Richard Helm, and John Vlissides.
The Singleton Pattern ensures that a class has only one instances and provides a global point of access to that instance. It is used when we want to limit creation of an object to only one instance. It ensures controlled access to a resource.
Example:
Use:
Use the Singleton pattern when:
The Factory Method Pattern defines an interface for creating objects because it allows subclasses to alter the type of objects that will be created. This pattern helps in assigning the object creation to subclasses that enables flexibility and extensibility.
Use the Factory Method Pattern when:
Example:
The Adapter pattern allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.
Use the Adapter Pattern when:
Example:
The Command pattern is preferable you want to encapsulate a request as an object with additional metadata such as the request's originator or ability to queue commands for later execution. It allows you to undo/redo operations, queue them for execution or log them.
Imagine a remote control for multiple devices (TV, lights, fan). Each button on the remote represents a command. The Command Pattern allows you to treat each button's action as a command object, which can be queued, executed, or undone. This is more complex than simply switching algorithms and involves additional metadata (such as the device's state or the command's origin).
The Strategy Pattern focuses on encapsulating interchangeable algorithms where there is no need for metadata about the request itself.
The SRP defines that one class should have just a single reason to change i.e it should have only one responsibility or task. This principle ensures that one class is dedicated to a single concern and is not overloaded with several unrelated responsibilities.
The Observer pattern establishes a one-to-many relationship between objects such that one object (the subject) keeps a list of its dependents (observers) and informs them of changes to the state. The observers are updated automatically whenever the subject's state is changed.
Example:
The Open/Closed Principle (OCP) defines that software entities (classes, modules, functions) must be open for extension but closed for modification. This implies you can extend the functionality without changing existing code.
Design patterns such as Strategy and Decorator Patterns enable new behavior to be added by inheriting existing classes or modules instead of modifying them. This follows the OCP by avoiding modifications to the fundamental code while still allowing additional behavior.
Example: Using the Strategy Pattern, new algorithms can be introduced by creating new strategy classes without modifying the existing context code.
Example: Bridge separates a remote control abstraction from device implementations like TV and radio, whereas Adapter allows a legacy device to work with a new control interface.
Example: In the Strategy or Factory Pattern, the client depends on an interface, allowing new implementations to be added without modifying existing code.
A common real-world example of using the Singleton Pattern is the Runtime class in Java. The Runtime class is a Singleton that provides access to the runtime environment of the Java application. It ensures that only one instance of the runtime is used throughout the application.
Example:
Runtime runtime = Runtime.getRuntime();This guarantees that the runtime environment is being accessed in a controlled fashion without instantiating multiple objects.
The Strategy Pattern enables a class to alter its behavior (or algorithm) at runtime. An example would be sorting algorithms. You may employ various sorting strategies based on data size or type.
Example:
Design patterns should be avoided when they add unnecessary complexity to a problem that can be solved with a simpler approach. Overusing patterns can lead to rigid, hard-to-maintain code and reduced readability.
Example: Using the Strategy Pattern for tax calculation when there is only one fixed tax rule adds unnecessary classes and complexity. A simple method is sufficient, and the pattern should be introduced only if multiple tax algorithms are needed in the future.
Design patterns help manage dependencies by structuring interactions through abstractions instead of direct class-to-class references.
Example: In a large microservices-based system, Factory and Dependency Injection patterns manage object creation and wiring without spreading dependency logic across the codebase.
The Decorator Pattern can be employed to extend an object dynamically without modifying its structure. A typical example is in text processing software, where you would like to include facilities such as spell-checking, formatting, or encryption in a text editor.
Example:
Inversion of Control (IoC) is a design principle in which the management of object creation and control is moved from the program to a container or framework. It is often applied in dependency injection frameworks, where objects are injected into classes instead of being instantiated within them. This decouples things and enhances flexibility.
Example: In Spring, objects are created and injected by the container instead of being instantiated directly using new.
The Command Pattern may be applied in a UI framework to encapsulate user actions (such as button clicks) into command objects. These commands can be executed, undone, or stored in a history for features like undo/redo.
Example: Every user action (e.g., button click) is wrapped into a command object, which is then run by the UI framework. To implement undo/redo, prior commands are saved and replayed appropriately.
Design patterns, classes, their relationships, and interactions are visualized using UML (Unified Modeling Language) diagrams. They facilitate clear communication of design ideas, making it simple to comprehend the structure of the pattern and how it would be placed within a system.
Example: A UML diagram for the Observer Pattern shows the Subject, Observer interface, and concrete observers with their relationships, making the pattern easier to grasp.
Design patterns offer proven solutions to recurring design issues. While refactoring code, you can spot areas where these patterns can be applied in order to enhance code structure, maintainability, and flexibility. which eliminates code duplication and makes the system easier to scale.
Example: A large conditional block can be refactored into the Strategy Pattern, where each condition becomes a separate strategy class.
Design patterns offer proven solutions to common issues in software development. They encourage best practices, improve code maintainability, and increase software scalability, and this makes the codebase easier and more flexible to maintain over the long term.
Example: Using the Factory Pattern for object creation decouples client code from concrete classes, making the system easier to extend and maintain.
The Builder Pattern solves the problem of creating complex objects with many optional parameters, where constructors become difficult to manage and understand.
Example: While creating a Computer object with optional fields like RAM, SSD, and GPU, a builder allows setting only required parts using chained methods instead of passing many parameters to a constructor.
The Prototype Pattern focuses on creating new objects by copying existing ones, while Java’s clone() is a low-level mechanism for object copying.
Example: In a game, different enemy objects can be created by copying a prototype enemy. The Prototype Pattern ensures proper deep copying, whereas using clone() directly may accidentally share internal objects like weapons or health state.
The Abstract Factory Pattern should be preferred when you need to create families of related or dependent objects without specifying their concrete classes.
Example: In a UI toolkit, Abstract Factory can create Windows buttons and menus or Mac buttons and menus together, while Factory Method would handle only one product at a time.
The Singleton Pattern can introduce hidden design and testing problems despite ensuring a single instance.
Example: A Singleton database connection can make unit testing difficult because tests cannot easily replace it with a mock or create isolated instances.
Lazy Initialization in the Singleton Pattern delays object creation until it is actually needed, instead of creating it at class loading time.
Example: A logging service singleton is created only when the application first logs a message, not when the application starts.
Composition focuses on building behavior by combining objects, while inheritance relies on extending classes to reuse behavior.
Example: In the Strategy Pattern, a class uses composition to delegate behavior to a strategy object, instead of inheriting different behavior through subclasses.
Encapsulation helps behavioral design patterns by hiding how behavior is implemented and exposing only what the client needs to use.
Example: In the Command Pattern, encapsulation wraps a request inside a command object, so the caller does not know how the request is executed.
The Facade Pattern provides a single, unified interface that hides the complexity of multiple interacting subsystems.
Example: In a home theater system, a facade exposes methods like watchMovie(), while internally coordinating the projector, sound system, and lights.
The Flyweight Pattern is most effective when a system needs to handle a large number of similar objects efficiently by sharing common state.
Example: In a text editor, character objects share font and style data using Flyweight, while position and content are stored separately.
The Proxy Pattern controls access to an object, while the Decorator Pattern adds new behavior to an object dynamically.
Example: A Proxy may check user permissions before accessing a file, whereas a Decorator may add logging or compression to file access without restricting it.
The Chain of Responsibility Pattern solves the problem of coupling a request sender to a specific request handler by passing the request through a chain of handlers.
Example: In an approval system, a request passes through manager, director, and CEO handlers until one of them approves it.
The Mediator Pattern reduces coupling by centralizing communication logic between objects into a single mediator.
Example: In a chat application, users send messages through a chat mediator rather than communicating with each user directly.
The Observer Pattern defines a one-to-many dependency so that when one object changes state, all its dependents are notified automatically.
Example: In a stock price system, the stock acts as the subject and multiple displays act as observers that get updated whenever the price changes.
The Strategy Pattern supports the Open/Closed Principle by allowing new behaviors to be added without modifying existing code.
Example: A payment system can add new payment methods like UPI or crypto by creating new strategy classes, without changing the checkout logic.
The context in the Strategy Pattern is responsible for holding a reference to a strategy and delegating the behavior to it.
Example: In a payment system, the checkout class acts as the context and delegates payment processing to a selected strategy like card, UPI, or net banking.
The Visitor Pattern is useful when you need to add new operations to a stable object structure without modifying the existing classes.
Example: In a compiler, Visitor is used to perform operations like type checking or code generation on syntax tree nodes without changing the node classes.
The State Pattern changes an object’s behavior based on its internal state, while the Strategy Pattern changes behavior by swapping algorithms externally.
Example: In a vending machine, behavior changes automatically based on states like no-coin, has-coin, or sold, whereas Strategy would require the client to choose the behavior.
The Command Pattern encapsulates a request as an object, allowing it to be stored, executed, and reversed later.
Example: In a text editor, typing or deleting text is stored as command objects, enabling undo and redo by reversing or re-executing those commands.
The Template Method Pattern defines the skeleton of an algorithm in a base class, while the Strategy Pattern defines interchangeable algorithms.
Example: In a data processing flow, Template Method fixes the steps but allows subclasses to change certain steps, whereas Strategy allows selecting different processing algorithms dynamically.
The Singleton Pattern is commonly used in logging frameworks to ensure a single, shared logging instance across the application.
Example: A Logger singleton is used by different classes to log messages to the same file or console without creating multiple logger objects.
Anti-patterns are common solutions to recurring problems that are ineffective or harmful, while design patterns are proven best practices for solving recurring design problems.
Example: Using God Object is an anti-pattern where one class does too much, whereas applying patterns like Facade or Strategy helps distribute responsibilities properly.
Design patterns help achieve loose coupling by reducing direct dependencies between classes and relying on abstractions instead.
Example: In the Observer Pattern, subjects do not depend on concrete observers, allowing observers to be added or removed without changing the subject.
Yes, multiple design patterns are often combined to solve complex design problems more effectively.
Example: In an MVC architecture, Observer is used for view updates, Strategy for interchangeable business logic, and Factory for creating objects.
Choosing a design pattern requires understanding the problem context and long-term impact on the system.
Example: Using Singleton may seem simple for shared configuration, but considering testing and scalability needs might lead to choosing Dependency Injection instead.
Design patterns improve testability by promoting loose coupling and separation of responsibilities.
Example: In the Strategy Pattern, different strategies can be tested independently by injecting mock strategies into the context.
Design patterns evolve by being adapted, combined, or replaced as software requirements and constraints change over time.
Example: Early systems used Singleton for shared resources, but modern applications often evolve toward Dependency Injection frameworks as scalability and testability requirements grow.
The Null Object Pattern replaces null references with a non-functional object that implements the same interface.
Example: Instead of checking if a Logger is null, a NullLogger is used that performs no operation when log() is called.
Static factory methods are simple methods that return objects, while the Factory Pattern is a structured design approach for object creation using abstraction.
Example: A static createUser() method returns a User object directly, whereas a Factory Pattern allows creating different User types without changing client code.
The Iterator Pattern supports encapsulation by allowing clients to traverse a collection without exposing its internal structure.
Example: In a custom data structure, an iterator lets clients loop through elements without knowing whether the data is stored in an array, list, or tree.
The Memento Pattern is preferred when an object’s state needs to be saved and restored without exposing its internal details.
Example: In a text editor, the document state is saved as mementos so the user can undo changes without directly accessing internal fields.