Design Patterns

https://refactoring.guru/design-patterns
Admin
Design patterns are typical solutions to common problems in software design, acting as customizable...
Tokens:399,532
Snippets:2,880
Trust Score:10
Update:3 months ago
Show doc for...
Tokens:
Raw
### Execution Result of Singleton Example

Source: https://refactoring.guru/design-patterns/singleton/go/example

This is the expected output when running the Go singleton example. It shows that the instance is created only once, and subsequent access attempts indicate that the instance already exists.

```text
Creating single instance now.
Single instance already created.
Single instance already created.


```

--------------------------------

### Execution Result of Factory Method Example

Source: https://refactoring.guru/design-patterns/factory-method/swift/example

This output shows the result of running the Swift Factory Method example, demonstrating that information is presented successfully over both WiFi and Bluetooth.

```text
Info is presented over Wifi: Very important info of the presentation
Info is presented over Bluetooth: Very important info of the presentation


```

--------------------------------

### Execution Result of Adapter Example

Source: https://refactoring.guru/design-patterns/adapter/swift/example

This output shows the console logs generated by running the Swift Adapter pattern example. It demonstrates the flow of authorization requests through both Facebook and the adapted Twitter SDK.

```text
Starting an authorization via Facebook
Facebook WebView has been shown
///
Starting an authorization via Twitter
The Adapter is called! Redirecting to the original method...
Twitter WebView has been shown. Users will be happy :)


```

--------------------------------

### Conceptual Example Output

Source: https://refactoring.guru/design-patterns/mediator/swift/example

The execution result of the conceptual Mediator pattern example, showing how components interact through the mediator.

```text
Client triggers operation A.
Component 1 does A.
Mediator reacts on A and triggers following operations:
Component 2 does C.

Client triggers operation D.
Component 2 does D.
Mediator reacts on D and triggers following operations:
Component 1 does B.

Component 2 does C.


```

--------------------------------

### Client Code: Initializing and Backing Up Configuration

Source: https://refactoring.guru/design-patterns/memento/php/example

Demonstrates the initial setup of the ConfigManager and ConfigHistory, followed by creating the first backup before any changes are made.

```php
/**
 * ============================================================================
 * CLIENT CODE - DEMONSTRATION AND USAGE EXAMPLES
 * ============================================================================
 */

echo "=== Configuration Manager with Memento Pattern Demo ===\n\n";

/**
 * Example 1: Basic configuration management with backup/restore
 */
echo "--- Example 1: Basic Configuration Management ---\n";

// Initialize configuration manager with default settings
$config = new ConfigManager([
    'maintenance_mode' => false,
    'theme' => 'light',
    'seo' => ['title' => 'My Website', 'description' => 'Welcome to my site!'],
    'debug' => false,
    'max_users' => 1000
]);

// Create history manager
$history = new ConfigHistory($config);

echo "\nInitial configuration:\n";
print_r($config->getConfig());

/**
 * Example 2: Making changes with backups
 */
echo "\n--- Example 2: Making Changes with Backups ---";

// Create backup before making changes
$history->backup();

// Update theme settings
$config->updateConfig([
    'theme' => 'dark',
    'theme_options' => ['sidebar' => 'collapsed', 'font_size' => 'large']
]);

echo "\nAfter theme update:\n";
print_r($config->getConfig());

// Create another backup
$history->backup();

```

--------------------------------

### Conceptual Example Output

Source: https://refactoring.guru/design-patterns/state/php/example

The execution result of the conceptual State pattern example, demonstrating state transitions and behavior changes.

```text
Context: Transition to RefactoringGuru\State\Conceptual\ConcreteStateA.
ConcreteStateA handles request1.
ConcreteStateA wants to change the state of the context.
Context: Transition to RefactoringGuru\State\Conceptual\ConcreteStateB.
ConcreteStateB handles request2.
ConcreteStateB wants to change the state of the context.
Context: Transition to RefactoringGuru\State\Conceptual\ConcreteStateA.

```

--------------------------------

### Client Code Setup and Execution

Source: https://refactoring.guru/design-patterns/mediator/php/example

Sets up the event dispatcher, attaches observers to events, and simulates user operations to demonstrate the pattern.

```php
$repository = new UserRepository();
events()->attach($repository, "facebook:update");

$logger = new Logger(__DIR__ . "/log.txt");
events()->attach($logger, "*");

$onboarding = new OnboardingNotification("1@example.com");
events()->attach($onboarding, "users:created");

// ...

$repository->initialize(__DIR__ . "users.csv");

// ...

$user = $repository->createUser([
    "name" => "John Smith",
    "email" => "john99@example.com",
]);

// ...

$user->delete();
```

--------------------------------

### Main Application Entry Point

Source: https://refactoring.guru/design-patterns/facade/rust/example

Sets up the WalletFacade and demonstrates its usage by adding and deducting money from the wallet.

```rust
mod account;
mod ledger;
mod notification;
mod security_code;
mod wallet;
mod wallet_facade;

use wallet_facade::WalletFacade;

fn main() -> Result<(), String> {
    let mut wallet = WalletFacade::new("abc".into(), 1234);
    println!();

    // Wallet Facade interacts with the account, code, wallet, notification and
    // ledger behind the scenes.
    wallet.add_money_to_wallet(&"abc".into(), 1234, 10)?;
    println!();

    wallet.deduct_money_from_wallet(&"abc".into(), 1234, 5)
}

```

--------------------------------

### Conceptual Example Output

Source: https://refactoring.guru/design-patterns/facade/swift/example

The execution result of the conceptual Facade example, demonstrating the simplified output provided by the Facade to the client.

```text
Facade initializes subsystems: Sybsystem1: Ready!
Sybsystem2: Get ready!

Facade orders subsystems to perform the action:
Sybsystem1: Go!
Sybsystem2: Fire!


```

--------------------------------

### Adapter Go Example

Source: https://refactoring.guru/design-patterns/go

Demonstrates the Adapter pattern in Go. Use to allow objects with incompatible interfaces to collaborate.

```go
package adapter

import "fmt"

// Target defines the domain-specific interface clients use.
type Target interface {
	Request()
}

// Adaptee defines an existing interface that needs adapting.
type Adaptee struct {
}

// SpecificRequest is the method of the Adaptee.
func (a *Adaptee) SpecificRequest() {
	fmt.Println("Adaptee: SpecificRequest() called")
}

// Adapter implements the Target interface and wraps an Adaptee.
type Adapter struct {
	adaptee *Adaptee
}

// NewAdapter creates a new Adapter.
func NewAdapter(a *Adaptee) *Adapter {
	return &Adapter{adaptee: a}
}

// Request implements the Target interface by calling the Adaptee's SpecificRequest.
func (a *Adapter) Request() {
	a.adaptee.SpecificRequest()
}

// Client code that uses the Target interface.
func ClientCode(t Target) {
	t.Request()
}

```

--------------------------------

### Execution Result of Factory Method Example

Source: https://refactoring.guru/design-patterns/factory-method/typescript/example

Shows the output generated when the conceptual example code is executed, demonstrating the interaction between creators and products.

```text
App: Launched with the ConcreteCreator1.
Client: I'm not aware of the creator's class, but it still works.
Creator: The same creator's code has just worked with {Result of the ConcreteProduct1}

App: Launched with the ConcreteCreator2.
Client: I'm not aware of the creator's class, but it still works.
Creator: The same creator's code has just worked with {Result of the ConcreteProduct2}

```

--------------------------------

### Application Initialization with Proxy

Source: https://refactoring.guru/design-patterns/proxy

Demonstrates how the application can initialize and use a proxy object instead of the real service.

```pseudocode
// The application can configure proxies on the fly.
class Application is
    method init() is
        aYouTubeService = new ThirdPartyYouTubeClass()
        aYouTubeProxy = new CachedYouTubeClass(aYouTubeService)
        manager = new YouTubeManager(aYouTubeProxy)
        manager.reactOnUserInput()
```

--------------------------------

### Execution Result of Facade Example

Source: https://refactoring.guru/design-patterns/facade/swift/example

This output shows the console logs generated when the Facade pattern example is executed, illustrating the sequence of operations.

```text
Let's set an image for the image view
Start downloading...
Handle an image...
Image has been set


```

--------------------------------

### Client Code Example

Source: https://refactoring.guru/design-patterns/abstract-factory/cpp/example

Demonstrates how client code interacts with factories and products through abstract interfaces, allowing for flexibility.

```cpp
/**
 * The client code works with factories and products only through abstract
 * types: AbstractFactory and AbstractProduct. This lets you pass any factory or
 * product subclass to the client code without breaking it.
 */

void ClientCode(const AbstractFactory &factory) {
  const AbstractProductA *product_a = factory.CreateProductA();
  const AbstractProductB *product_b = factory.CreateProductB();
  std::cout << product_b->UsefulFunctionB() << "\n";
  std::cout << product_b->AnotherUsefulFunctionB(*product_a) << "\n";
  delete product_a;
  delete product_b;
}

int main() {
  std::cout << "Client: Testing client code with the first factory type:\n";
  ConcreteFactory1 *f1 = new ConcreteFactory1();
  ClientCode(*f1);
  delete f1;
  std::cout << std::endl;
  std::cout << "Client: Testing the same client code with the second factory type:\n";
  ConcreteFactory2 *f2 = new ConcreteFactory2();
  ClientCode(*f2);
  delete f2;
  return 0;
}
```

--------------------------------

### Execution Result of State Pattern Example

Source: https://refactoring.guru/design-patterns/state/ruby/example

This output shows the sequence of state transitions and method calls when the conceptual example of the State pattern is executed.

```Text
Context: Transition to ConcreteStateA
ConcreteStateA handles request1.
ConcreteStateA wants to change the state of the context.
Context: Transition to ConcreteStateB
ConcreteStateB handles request2.
ConcreteStateB wants to change the state of the context.
Context: Transition to ConcreteStateA

```

--------------------------------

### Conceptual Example Output in Swift

Source: https://refactoring.guru/design-patterns/state/swift/example

Displays the execution result of the conceptual State pattern example. It shows the context transitions and how different states handle requests.

```text
Context: Transition to StateConceptual.ConcreteStateA
ConcreteStateA handles request1.
ConcreteStateA wants to change the state of the context.

Context: Transition to StateConceptual.ConcreteStateB
ConcreteStateB handles request2.
ConcreteStateB wants to change the state of the context.

Context: Transition to StateConceptual.ConcreteStateA

```

--------------------------------

### Client Code for Naive Singleton (Java)

Source: https://refactoring.guru/design-patterns/singleton/java/example

Example client code demonstrating the usage of the naive Singleton implementation. It shows how to retrieve the singleton instance and verifies if it's reused.

```java
package refactoring_guru.singleton.example.non_thread_safe;

public class DemoSingleThread {
    public static void main(String[] args) {
        System.out.println("If you see the same value, then singleton was reused (yay!)" + "\n" +
                "If you see different values, then 2 singletons were created (booo!!)" + "\n\n" +
                "RESULT:" + "\n");
        Singleton singleton = Singleton.getInstance("FOO");
        Singleton anotherSingleton = Singleton.getInstance("BAR");
        System.out.println(singleton.value);
        System.out.println(anotherSingleton.value);
    }
}
```

--------------------------------

### Singleton Go Example

Source: https://refactoring.guru/design-patterns/go

Demonstrates the Singleton pattern in Go. Use to ensure a class has only one instance and provide a global access point.

```go
package singleton

import (
	"sync"
)

// Singleton is the singleton object.
type Singleton struct {
	// Fields of the singleton object
}

var ( 
	sinstance *Singleton
	// Mutex to protect against race conditions during initialization.
	lock = &sync.Mutex{}
)

// GetInstance returns the singleton instance.
func GetInstance() *Singleton {
	if sinstance == nil {
		// Double-checked locking for thread safety.
		lock.Lock()
		defer lock.Unlock()
		if sinstance == nil {
			sinstance = &Singleton{}
		}
	}
	return sinstance
}

```

--------------------------------

### Execution Result of Prototype Pattern Example

Source: https://refactoring.guru/design-patterns/prototype/csharp/example

Shows the output of the conceptual C# example, illustrating the difference between shallow and deep copies after modifying the original object.

```text
Original values of p1, p2, p3:
   p1 instance values: 
      Name: Jack Daniels, Age: 42, BirthDate: 01/01/77
      ID#: 666
   p2 instance values:
      Name: Jack Daniels, Age: 42, BirthDate: 01/01/77
      ID#: 666
   p3 instance values:
      Name: Jack Daniels, Age: 42, BirthDate: 01/01/77
      ID#: 666

Values of p1, p2 and p3 after changes to p1:
   p1 instance values: 
      Name: Frank, Age: 32, BirthDate: 01/01/00
      ID#: 7878
   p2 instance values (reference values have changed):
      Name: Jack Daniels, Age: 42, BirthDate: 01/01/77
      ID#: 7878
   p3 instance values (everything was kept the same):
      Name: Jack Daniels, Age: 42, BirthDate: 01/01/77
      ID#: 666

```

--------------------------------

### Execution Result of Decorator Pattern Example

Source: https://refactoring.guru/design-patterns/decorator/ruby/example

Shows the output generated by the conceptual example, demonstrating the behavior of a simple component and a component wrapped by multiple decorators.

```Text
Client: I've got a simple component:
RESULT: ConcreteComponent

Client: Now I've got a decorated component:
RESULT: ConcreteDecoratorB(ConcreteDecoratorA(ConcreteComponent))

```

--------------------------------

### Client Code: Using the Strategy Pattern (Go)

Source: https://refactoring.guru/design-patterns/strategy/go/example

Demonstrates how a client can initialize a cache with a specific eviction strategy and dynamically change it at runtime.

```go
package main

func main() {
	lfu := &Lfu{}
	cache := initCache(lfu)

	cache.add("a", "1")
	cache.add("b", "2")

	cache.add("c", "3")

	lru := &Lru{}
	cache.setEvictionAlgo(lru)

	cache.add("d", "4")

	fifo := &Fifo{}
	cache.setEvictionAlgo(fifo)

	cache.add("e", "5")

}

```

--------------------------------

### Conceptual Example Output

Source: https://refactoring.guru/design-patterns/chain-of-responsibility/swift/example

This output shows the result of executing the conceptual Chain of Responsibility example in Swift. It demonstrates how requests are handled or passed along the chain.

```text
Chain: Monkey > Squirrel > Dog


Client: Who wants a Nut?

Squirrel: I'll eat the Nut.

Client: Who wants a Banana?

Monkey: I'll eat the Banana.

Client: Who wants a Cup of coffee?

Cup of coffee was left untouched.


Subchain: Squirrel > Dog


Client: Who wants a Nut?

Squirrel: I'll eat the Nut.

Client: Who wants a Banana?

Banana was left untouched.

```

--------------------------------

### Client Code: Setting up Observers and Triggering Events

Source: https://refactoring.guru/design-patterns/observer/php/example

This client code demonstrates how to instantiate the UserRepository, attach observers (Logger and OnboardingNotification), initialize data, and then trigger events by creating and deleting users.

```php
$repository = new UserRepository();
$repository->attach(new Logger(__DIR__ . "/log.txt"), "*");
$repository->attach(new OnboardingNotification("1@example.com"), "users:created");

$repository->initialize(__DIR__ . "/users.csv");

// ...

$user = $repository->createUser([
    "name" => "John Smith",
    "email" => "john99@example.com",
]);

// ...

$repository->deleteUser($user);
```

--------------------------------

### CSV File Content Example

Source: https://refactoring.guru/design-patterns/iterator/php/example

This is an example of the content found in a `cats.csv` file, showing the header row and subsequent data rows. Each row represents a cat with its attributes.

```Text
Name,Age,Owner,Breed,Image,Color,Texture,Fur,Size
Steve,3,Alexander Shvets,Bengal,/cats/bengal.jpg,Brown,Stripes,Short,Medium
Siri,2,Alexander Shvets,Domestic short-haired,/cats/domestic-sh.jpg,Black,Solid,Medium,Medium
Fluffy,5,John Smith,Maine Coon,/cats/Maine-Coon.jpg,Gray,Stripes,Long,Large

```

--------------------------------

### Main Function to Demonstrate Adapter Pattern

Source: https://refactoring.guru/design-patterns/adapter/go/example

Orchestrates the client, direct service, and adapted service to show collaboration.

```go
package main

func main() {

	client := &Client{}
	mac := &Mac{}

	client.InsertLightningConnectorIntoComputer(mac)

	windowsMachine := &Windows{}
	windowsMachineAdapter := &WindowsAdapter{
		windowMachine: windowsMachine,
	}

	client.InsertLightningConnectorIntoComputer(windowsMachineAdapter)
}
```

--------------------------------

### Flyweight Conceptual Example in C#

Source: https://refactoring.guru/design-patterns/flyweight/csharp/example

Illustrates the core components of the Flyweight pattern: the Flyweight class, Flyweight Factory, and the shared/unique state. This example uses System.Text.Json for serialization.

```csharp
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text.Json;
// Use Json.NET library, you can download it from NuGet Package Manager

namespace RefactoringGuru.DesignPatterns.Flyweight.Conceptual
{
    // The Flyweight stores a common portion of the state (also called intrinsic
    // state) that belongs to multiple real business entities. The Flyweight
    // accepts the rest of the state (extrinsic state, unique for each entity)
    // via its method parameters.
    public class Flyweight
    {
        private Car _sharedState;

        public Flyweight(Car car)
        {
            this._sharedState = car;
        }

        public void Operation(Car uniqueState)
        {
            string s = JsonSerializer.Serialize(this._sharedState);
            string u = JsonSerializer.Serialize(uniqueState);
            Console.WriteLine($"Flyweight: Displaying shared {s} and unique {u} state.");
        }
    }

    // The Flyweight Factory creates and manages the Flyweight objects. It
    // ensures that flyweights are shared correctly. When the client requests a
    // flyweight, the factory either returns an existing instance or creates a
    // new one, if it doesn't exist yet.
    public class FlyweightFactory
    {
        private List<Tuple<Flyweight, string>> flyweights = new List<Tuple<Flyweight, string>>();

        public FlyweightFactory(params Car[] args)
        {
            foreach (var elem in args)
            {
                flyweights.Add(new Tuple<Flyweight, string>(new Flyweight(elem), this.getKey(elem)));
            }
        }

        // Returns a Flyweight's string hash for a given state.
        public string getKey(Car key)
        {
            List<string> elements = new List<string>();

            elements.Add(key.Model);
            elements.Add(key.Color);
            elements.Add(key.Company);

            if (key.Owner != null && key.Number != null)
            {
                elements.Add(key.Number);
                elements.Add(key.Owner);
            }

            elements.Sort();

            return string.Join("_", elements);
        }

        // Returns an existing Flyweight with a given state or creates a new
        // one.
        public Flyweight GetFlyweight(Car sharedState)
        {
            string key = this.getKey(sharedState);

            if (flyweights.Where(t => t.Item2 == key).Count() == 0)
            {
                Console.WriteLine("FlyweightFactory: Can't find a flyweight, creating new one.");
                this.flyweights.Add(new Tuple<Flyweight, string>(new Flyweight(sharedState), key));
            }
            else
            {
                Console.WriteLine("FlyweightFactory: Reusing existing flyweight.");
            }
            return this.flyweights.Where(t => t.Item2 == key).FirstOrDefault().Item1;
        }

        public void listFlyweights()
        {
            var count = flyweights.Count;
            Console.WriteLine($"\nFlyweightFactory: I have {count} flyweights:");
            foreach (var flyweight in flyweights)
            {
                Console.WriteLine(flyweight.Item2);
            }
        }
    }

    public class Car
    {
        public string Owner { get; set; }

        public string Number { get; set; }

        public string Company { get; set; }

        public string Model { get; set; }

        public string Color { get; set; }
    }

}
```

--------------------------------

### Multiple Configuration Scenarios

Source: https://refactoring.guru/design-patterns/memento/php/example

Illustrates managing different configuration scenarios like SEO and performance settings, and performing rollbacks.

```php
// Scenario A: SEO Configuration
$history->backup();
echo "\nScenario A: Updating SEO settings...\n";
$config->updateConfig([
    'seo' => [
        'title' => 'Best Products Online',
        'description' => 'Find the best products at great prices!',
        'keywords' => 'products, online, shopping, deals'
    ],
    'analytics' => ['google_id' => 'GA-123456', 'facebook_pixel' => 'FB-789012']
]);

echo "SEO configuration updated:\n";
print_r($config->getConfig());

// Scenario B: Performance Settings
$history->backup();
echo "\nScenario B: Updating performance settings...\n";
$config->updateConfig([
    'cache_enabled' => true,
    'cache_duration' => 3600,
    'compression' => 'gzip',
    'max_users' => 2000
]);

echo "Performance settings updated:\n";
print_r($config->getConfig());

// Scenario C: Emergency rollback
echo "\nScenario C: Emergency rollback to SEO-only changes...\n";
$history->undo(); // Remove performance changes
echo "Rolled back performance changes:\n";
print_r($config->getConfig());
```

--------------------------------

### Demo.java: Initialization and Usage

Source: https://refactoring.guru/design-patterns/observer/java/example

Sets up the editor, subscribes listeners to events, and triggers file operations. This demonstrates how the Observer pattern is used in practice.

```java
package refactoring_guru.observer.example;

import refactoring_guru.observer.example.editor.Editor;
import refactoring_guru.observer.example.listeners.EmailNotificationListener;
import refactoring_guru.observer.example.listeners.LogOpenListener;

public class Demo {
    public static void main(String[] args) {
        Editor editor = new Editor();
        editor.events.subscribe("open", new LogOpenListener("/path/to/log/file.txt"));
        editor.events.subscribe("save", new EmailNotificationListener("admin@example.com"));

        try {
            editor.openFile("test.txt");
            editor.saveFile();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

```

--------------------------------

### Facade Go Example

Source: https://refactoring.guru/design-patterns/go

Provides a simplified interface to a library, framework, or complex set of classes.

```go
package facade

import "fmt"

// SubsystemA is part of the complex system.
type SubsystemA struct {}

func (s *SubsystemA) MethodA() {
	fmt.Println("SubsystemA: MethodA() called")
}

// SubsystemB is part of the complex system.
type SubsystemB struct {}

func (s *SubsystemB) MethodB() {
	fmt.Println("SubsystemB: MethodB() called")
}

// Facade provides a simplified interface to the subsystems.
type Facade struct {
	subsystemA *SubsystemA
	subsystemB *SubsystemB
}

func NewFacade() *Facade {
	return &Facade{
		subsystemA: &SubsystemA{},
		subsystemB: &SubsystemB{},
	}
}

// Method1 is a simplified operation provided by the facade.
func (f *Facade) Method1() {
	f.subsystemA.MethodA()
}

// Method2 is another simplified operation.
func (f *Facade) Method2() {
	f.subsystemB.MethodB()
}

// Client code that uses the facade.
func ClientCode() {
	facade := NewFacade()
	facade.Method1()
	facade.Method2()
}

```

--------------------------------

### Conceptual Example of Decorator Pattern in Swift

Source: https://refactoring.guru/design-patterns/decorator/swift/example

Illustrates the structure of the Decorator pattern, including components, concrete components, and decorators. This example focuses on the roles and relationships of these elements.

```swift
import XCTest

/// The base Component interface defines operations that can be altered by
/// decorators.
protocol Component {

    func operation() -> String
}

/// Concrete Components provide default implementations of the operations. There
/// might be several variations of these classes.
class ConcreteComponent: Component {

    func operation() -> String {
        return "ConcreteComponent"
    }
}

/// The base Decorator class follows the same interface as the other components.
/// The primary purpose of this class is to define the wrapping interface for
/// all concrete decorators. The default implementation of the wrapping code
/// might include a field for storing a wrapped component and the means to
/// initialize it.
class Decorator: Component {

    private var component: Component

    init(_ component: Component) {
        self.component = component
    }

    /// The Decorator delegates all work to the wrapped component.
    func operation() -> String {
        return component.operation()
    }
}

/// Concrete Decorators call the wrapped object and alter its result in some
/// way.
class ConcreteDecoratorA: Decorator {

    /// Decorators may call parent implementation of the operation, instead of
    /// calling the wrapped object directly. This approach simplifies extension
    /// of decorator classes.
    override func operation() -> String {
        return "ConcreteDecoratorA(" + super.operation() + ")"
    }
}

/// Decorators can execute their behavior either before or after the call to a
/// wrapped object.
class ConcreteDecoratorB: Decorator {

    override func operation() -> String {
        return "ConcreteDecoratorB(" + super.operation() + ")"
    }
}

/// The client code works with all objects using the Component interface. This
/// way it can stay independent of the concrete classes of components it works
/// with.
class Client {
    // ...
    static func someClientCode(component: Component) {
        print("Result: " + component.operation())
    }
    // ...
}

/// Let's see how it all works together.
class DecoratorConceptual: XCTestCase {

    func testDecoratorConceptual() {
        // This way the client code can support both simple components...
        print("Client: I've got a simple component")
        let simple = ConcreteComponent()
        Client.someClientCode(component: simple)

        // ...as well as decorated ones.
        //
        // Note how decorators can wrap not only simple components but the other
        // decorators as well.
        let decorator1 = ConcreteDecoratorA(simple)
        let decorator2 = ConcreteDecoratorB(decorator1)
        print("\nClient: Now I've got a decorated component")
        Client.someClientCode(component: decorator2)
    }
}

```

--------------------------------

### Command Go Example

Source: https://refactoring.guru/design-patterns/go

Turns a request into a stand-alone object that contains all information about the request.

```go
package command

import "fmt"

// Receiver is the object that performs the actual action.
type Receiver struct {}

func (r *Receiver) Action() {
	fmt.Println("Receiver: Performing action.")
}

// Command defines the interface for all commands.
type Command interface {
	Execute()
}

// ConcreteCommand implements the Command interface.
type ConcreteCommand struct {
	receiver *Receiver
}

func NewConcreteCommand(r *Receiver) *ConcreteCommand {
	return &ConcreteCommand{receiver: r}
}

func (c *ConcreteCommand) Execute() {
	c.receiver.Action()
}

// Invoker is responsible for executing commands.
type Invoker struct {
	command Command
}

func (i *Invoker) SetCommand(c Command) {
	i.command = c
}

func (i *Invoker) ExecuteCommand() {
	i.command.Execute()
}

// Client code that uses the command pattern.
func ClientCode() {
	receiver := &Receiver{}
	command := NewConcreteCommand(receiver)
	invoker := &Invoker{}

	invoker.SetCommand(command)
	invoker.ExecuteCommand()
}

```

--------------------------------

### Execution Result of Chain of Responsibility Example

Source: https://refactoring.guru/design-patterns/chain-of-responsibility/cpp/example

Shows the output generated by the C++ Chain of Responsibility conceptual example, demonstrating how requests are handled or passed along the chain.

```text
Chain: Monkey > Squirrel > Dog

Client: Who wants a Nut?
  Squirrel: I'll eat the Nut.
Client: Who wants a Banana?
  Monkey: I'll eat the Banana.
Client: Who wants a Cup of coffee?
  Cup of coffee was left untouched.

Subchain: Squirrel > Dog

Client: Who wants a Nut?
  Squirrel: I'll eat the Nut.
Client: Who wants a Banana?
  Banana was left untouched.
Client: Who wants a Cup of coffee?
  Cup of coffee was left untouched.

```

--------------------------------

### Execution Result of Strategy Pattern Example

Source: https://refactoring.guru/design-patterns/strategy/csharp/example

Shows the output generated by running the conceptual Strategy pattern example in C#. This demonstrates the interchangeable behavior of different sorting strategies.

```text
Client: Strategy is set to normal sorting.
Context: Sorting data using the strategy (not sure how it'll do it)
a,b,c,d,e

Client: Strategy is set to reverse sorting.
Context: Sorting data using the strategy (not sure how it'll do it)
e,d,c,b,a

```

--------------------------------

### Music Player Application Setup

Source: https://refactoring.guru/design-patterns/state/rust/example

Initializes the Cursive application, sets up the player and its initial state, and defines the UI with buttons for player controls.

```Rust
mod player;
mod state;

use cursive::
    event::Key,
    view::Nameable,
    views::{Dialog, TextView},
    Cursive;
use player::Player;
use state::{State, StoppedState};

// Application context: a music player and a state.
struct PlayerApplication {
    player: Player,
    state: Box<dyn State>,
}

fn main() {
    let mut app = cursive::default();

    app.set_user_data(PlayerApplication {
        player: Player::default(),
        state: Box::new(StoppedState),
    });

    app.add_layer(
        Dialog::around(TextView::new("Press Play").with_name("Player Status"))
            .title("Music Player")
            .button("Play", |s| execute(s, "Play"))
            .button("Stop", |s| execute(s, "Stop"))
            .button("Prev", |s| execute(s, "Prev"))
            .button("Next", |s| execute(s, "Next")),
    );

    app.add_global_callback(Key::Esc, |s| s.quit());

    app.run();
}

```

--------------------------------

### Prototype Go Example

Source: https://refactoring.guru/design-patterns/go

Demonstrates the Prototype pattern in Go. Use to copy existing objects without depending on their concrete classes.

```go
package prototype

import "fmt"

// Clonable interface for objects that can be cloned.
type Clonable interface {
	Clone() Clonable
}

// ConcretePrototype is a sample object that can be cloned.
type ConcretePrototype struct {
	field string
}

func (p *ConcretePrototype) Clone() Clonable {
	// Perform a deep copy if necessary, here a shallow copy is sufficient.
	return &ConcretePrototype{field: p.field}
}

// Client code that uses the prototype.
func ClientCode() {
	prototype := &ConcretePrototype{field: "initial"}
	clone := prototype.Clone()

	fmt.Println("Original:", prototype.field)
	fmt.Println("Clone:", clone.(*ConcretePrototype).field)
}

```

--------------------------------

### Execution Result of Adapter Pattern Example

Source: https://refactoring.guru/design-patterns/adapter/cpp/example

This output shows the execution result of the C++ Adapter pattern example. It demonstrates the client's interaction with both the Target and the Adaptee through the Adapter.

```text
Client: I can work just fine with the Target objects:
Target: The default target's behavior.

Client: The Adaptee class has a weird interface. See, I don't understand it:
Adaptee: .eetpadA eht fo roivaheb laicepS

Client: But I can work with it via the Adapter:
Adapter: (TRANSLATED) Special behavior of the Adaptee.


```

--------------------------------

### Demo Class for Initialization

Source: https://refactoring.guru/design-patterns/state/java/example

The main entry point for the application. It creates instances of Player and UI, then initializes the UI to start the application.

```java
package refactoring_guru.state.example;

import refactoring_guru.state.example.ui.Player;
import refactoring_guru.state.example.ui.UI;

/**
 * Demo class. Everything comes together here.
 */
public class Demo {
    public static void main(String[] args) {
        Player player = new Player();
        UI ui = new UI(player);
        ui.init();
    }
}

```

--------------------------------

### Execution Result of Prototype Example

Source: https://refactoring.guru/design-patterns/prototype/swift/example

This output shows the result of running the Swift prototype example. It confirms the original and copied page titles and the updated count of pages associated with the author.

```text
Original title: My First Page
Copied title: Copy of 'My First Page'
Count of pages: 2


```

--------------------------------

### Real-World Workflow Simulation: Step 1 & 2

Source: https://refactoring.guru/design-patterns/memento/php/example

Continues the workflow simulation by updating configuration for promotions and SEO.

```text
Step 1: Preparing for Black Friday promotion...
ConfigManager: Updating configuration with new values...
ConfigManager: Configuration updated. Current config has 8 items.

ConfigHistory: Creating backup of current configuration...
ConfigManager: Saving current configuration state...
ConfigSnapshot: Created snapshot with 8 config items.
ConfigHistory: Backup created. Total backups: 2

Step 2: Updating SEO for promotion visibility...
ConfigManager: Updating configuration with new values...
ConfigManager: Configuration updated. Current config has 8 items.
```

--------------------------------

### Decorator Pattern Conceptual Example Output in Swift

Source: https://refactoring.guru/design-patterns/decorator/swift/example

Shows the execution result of the conceptual Decorator pattern example in Swift. Demonstrates how decorators dynamically add behavior to the base component.

```text
Client: I've got a simple component
Result: ConcreteComponent

Client: Now I've got a decorated component
Result: ConcreteDecoratorB(ConcreteDecoratorA(ConcreteComponent))


```
Tokens:
Raw