Structural Design Patterns: Adapter

A design pattern that reduces memory consumption by sharing common parts of objects. It reduces object count to save memory.

A design pattern where an object acts on behalf of another object, hiding the implementation details from the client.

These are components of the Flyweight pattern. Flyweight is the abstract class, Concrete Flyweight is a class of reusable flyweights that contains a shared part of the original object, Unshared Concrete Flyweight contains the unique parts.

Proxy patterns should be used for remote objects, large objects, objects with complex history requirements, or for managing the lifecycle of objects.

Use the Proxy pattern when parts of a drone need to utilize resources elsewhere (e.g., a controlling computer or a remote server).

A design pattern that allows objects with incompatible interfaces to work together.

Used when you need to use an existing class but its interface doesn't match your code.

A design pattern that decouples an abstraction from its implementation.

Used when you have multiple variants of functionality or when you need to switch implementations at runtime.

A design pattern that treats individual objects and groups of objects uniformly.

Used when you want to hide the complex structure of a collection from clients and/or reduce code duplication when traversing a collection.

Patterns that explain how objects or classes are assembled into larger structures.

Design patterns that define communication between objects. (Recap)

A design pattern that lets you add new behaviors to existing objects dynamically at runtime without altering their structure.

Used when extending an object's behavior using inheritance is not practical or desirable.

A design pattern that provides a simplified interface to a complex subsystem.

Use it when you have a complex subsystem and need a simple interface for clients.

Ideal for applications where memory is a key constraint and many similar objects need to be created.

A fundamental part in the composite design pattern. A leaf or composite object.

A structural design pattern explains how to assemble objects and classes into larger structures while keeping these structures flexible and efficient.

Use the Facade pattern when you have a complex subsystem and need a streamlined interface for clients, especially for limited functionality.

Use when an existing class has an incompatible interface or when you need to reuse several subclasses lacking common functionality.

Use the Flyweight pattern when your application needs to manage a large number of objects that could overwhelm available RAM.

Use when you have variations in functionality, need to switch implementations at runtime, or want to extend a class in multiple dimensions.

Use when you want to hide complex data structures, reduce traversal code duplication, or handle unknown data structures.

A reusable solution to a common software design problem. It's not code, but a template that describes how to solve a recurring design issue.

A creational design pattern that defines an interface for creating objects, but lets subclasses decide which specific class to instantiate.

Use the Factory Method when you don't know the exact objects your code needs, want to extend library components, or reuse objects instead of rebuilding them.

A creational design pattern that provides an interface for creating families of related objects without specifying their concrete classes.

A creational design pattern that separates the construction of a complex object from its representation.

A creational design pattern that specifies the kinds of objects to create using a prototypical instance.

A creational design pattern that ensures a class has only one instance and provides a global point of access to it.

A list of commonly used design patterns, organized by their purpose (creational, structural, behavioral).

A creational design pattern that specifies the kinds of objects to create using a prototypical instance. It allows you to copy existing objects to create new ones, avoiding the need to re-create them from scratch.

Use the Prototype pattern when your code shouldn't depend on concrete classes of objects you need to copy or when you want to reduce the number of subclasses that differ only in initialization.

A creational design pattern that ensures a class has only one instance and provides a global point of access to it. It guarantees that only one object of that class is created.

Use the Singleton pattern when a class should have just one instance available to all clients, like a database object, or when you need stricter control over global variables.

The Singleton pattern is implemented by making the default constructor private, creating a static creation method that acts as a constructor, and providing a static instance variable.

Provides an interface for creating families of related objects without specifying their concrete classes. It's like having a factory that produces different sets of products.

Use it when you need to work with various families of related products but don't want your code to depend on specific implementations.

Separates the construction of complex objects from their representation, allowing the same construction process to create different variations.

Use it to avoid long constructor parameter lists, create different versions of a complex object, or construct complex tree-like structures.

It hides concrete classes from clients, allowing for more flexibility and easier changes to the code.

It allows for more flexible and controlled object construction, leading to cleaner and more organized code.