英語記事調整

Author: BreadMotion

WebSite/content/other/blog_00032.en.md

@@ -8,16 +8,16 @@ recommended: true
 thumbnail: assets/img/ogp.png
 ---
 
-Hello! I'm Pan-kun.
+Hello! I'm Pan-kun.  
 
-This post covers the Builder pattern from the GoF (Gang of Four) design patterns.
-I explain it practically with sample code in C++, how to design it, when to apply it, and important caveats.
+This post covers the Builder pattern from the GoF (Gang of Four) design patterns.  
+I explain it practically with sample code in C++, how to design it, when to apply it, and important caveats.  
 
 # Introduction
 
-The Builder pattern separates the construction of a complex object from its representation, improving readability and extensibility of the creation process.
+The Builder pattern separates the construction of a complex object from its representation, improving readability and extensibility of the creation process.  
 
-I'll quote Wikipedia as a primary source:
+I'll quote Wikipedia as a primary source:  
 
 > "The intent of the Builder design pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations."  
 > (Source: [https://en.wikipedia.org/wiki/Builder_pattern](https://en.wikipedia.org/wiki/Builder_pattern))
@@ -26,7 +26,7 @@ I'll quote Wikipedia as a primary source:
 
 ## Structure (Elements)
 
-A typical composition includes:
+A typical composition includes:  
 
 - `Product`: the complex object to be constructed
 - `Builder`: defines steps like `BuildPartX()` and provides `GetResult()`
@@ -35,7 +35,7 @@ A typical composition includes:
 
 ## C++ Implementation Example
 
-Below is a minimal C++ example. This is a typical pattern that uses a `Director`.
+Below is a minimal C++ example. This is a typical pattern that uses a `Director`.  
 
 ```cpp
 // Product.h  -- the object being constructed
@@ -108,31 +108,35 @@ int main() {
 }
 ```
 
-The key point of this implementation is the separation between the construction procedure (the Director) and the concrete construction steps (the ConcreteBuilder). You can achieve variety simply by replacing `ConcreteBuilder`.
+The key point of this implementation is the separation between the construction procedure (the Director) and the concrete construction steps (the ConcreteBuilder). You can achieve variety simply by replacing `ConcreteBuilder`.  
 
 ## When to Use It
 
-Representative cases where you should consider the Builder pattern:
+Representative cases where you should consider the Builder pattern:  
 
 - When a constructor has many parameters and most of them are optional (named/optional parameters or factories can be alternatives).
 - When you need staged or complex initialization and want to separate the initialization steps (useful for incremental verification in tests).
 - When you want to produce different representations from the same construction procedure (multiple `ConcreteBuilder` implementations).
 - When building immutable objects: the Builder assembles a mutable intermediate representation and returns an immutable object at the end for readability.
 
-Alternatives:
+Alternatives:  
 
 - Language-level named/optional parameters (for concise cases).
 - `Factory Method` or `Abstract Factory` (when creation responsibilities are managed by subclasses or family groups).
 - Stepwise helper functions calling constructors (often sufficient for simple cases).
 
 ## Summary
 
-The Builder pattern is a powerful pattern intended to separate construction procedure and representation. It is effective when dealing with complex initialization or variable representations. However, Builder introduces trade-offs around mutability, integration with dependency injection, and test design. Before adopting it, evaluate the impact on creation sites, serialization, and tests.
+The Builder pattern is a powerful pattern intended to separate construction procedure and representation.   
+It is effective when dealing with complex initialization or variable representations.   
+However, Builder introduces trade-offs around mutability, integration with dependency injection, and test design. Before adopting it, evaluate the impact on creation sites, serialization, and tests.  
 
-References and sources:
+References and sources:  
 
 [!CARD](https://en.wikipedia.org/wiki/Builder_pattern)
 
-That's it for this post. Next time I'll cover another GoF pattern. The code shown here is simplified for learning purposes — when adopting patterns in production, make sure to adapt them to your project requirements.
+That's it for this post.   
+Next time I'll cover another GoF pattern.  
+The code shown here is simplified for learning purposes — when adopting patterns in production, make sure to adapt them to your project requirements.
 
 Thanks for reading — Pan-kun!

WebSite/content/other/blog_00033.en.md

@@ -10,31 +10,31 @@ thumbnail: assets/img/ogp.png
 
 Hello! I'm Pan-kun.
 
-This post covers the Adapter pattern from the GoF (Gang of Four) design patterns.
-I explain it practically, including a C++ sample, how to implement it, when to use it, pitfalls to watch out for, and a Mermaid diagram for visualization.
+This post covers the Adapter pattern from the GoF (Gang of Four) design patterns.  
+I explain it practically, including a C++ sample, how to implement it, when to use it, pitfalls to watch out for, and a Mermaid diagram for visualization.  
 
 ## Introduction
 
-The Adapter pattern provides a wrapper that connects incompatible interfaces, allowing an existing class to be adapted to the interface expected by clients.
+The Adapter pattern provides a wrapper that connects incompatible interfaces, allowing an existing class to be adapted to the interface expected by clients.  
 
-Benefits:
+Benefits:  
 - You can adapt existing code or third-party libraries to a new interface without changing their implementation.
 
-Drawbacks:
+Drawbacks:  
 - Proliferation of wrappers can scatter design responsibilities and reduce readability and maintainability.
 - The added indirection can also introduce runtime overhead.
 
 ## Use cases
 
-Common scenarios where you would create an Adapter include:
+Common scenarios where you would create an Adapter include:  
 
 - Integrating a legacy API or library into a new application interface.
 - When different modules expose incompatible interfaces but you cannot modify the existing implementation.
 - Creating a thin boundary that makes it easy to swap implementations during testing (though using mocks can be simpler when applicable).
 
 ## Structure
 
-An Adapter implements the Target interface and internally invokes the Adaptee's operations while performing any required conversions.
+An Adapter implements the Target interface and internally invokes the Adaptee's operations while performing any required conversions.  
 
 ```mermaid
 classDiagram
@@ -55,7 +55,7 @@ classDiagram
 
 ## C++ implementation example
 
-Below is a concise C++ example.
+Below is a concise C++ example.  
 
 ```cpp
 // Example: the client expects to call Target::request()
@@ -100,10 +100,10 @@ std::unique_ptr<Target> target = std::make_unique<Adapter>(adaptee);
 target->request(); // the client only knows Target
 ```
 
-Key points:
+Key points:  
 - Perform data-format conversion, error handling, and method mapping as needed.
-- There are inheritance-based and delegation-based adapters; choose according to your use case.
-  In short: inheritance-based adapters leverage class inheritance, while delegation-based adapters implement an interface and forward calls to a contained object.
+- There are inheritance-based and delegation-based adapters; choose according to your use case.  
+  In short: inheritance-based adapters leverage class inheritance, while delegation-based adapters implement an interface and forward calls to a contained object.  
 
 ## Implementation notes
 
@@ -142,16 +142,16 @@ Typical bad practices when applying this pattern:
 
 ## Conclusion
 
-The Adapter is a practical and commonly used pattern for bridging incompatible interfaces. However, careless proliferation of Adapters can complicate design. Make responsibilities explicit and localize translation logic when you use this pattern.
-Pay special attention to ownership, exception and error handling, performance, and testability when implementing an Adapter.
+The Adapter is a practical and commonly used pattern for bridging incompatible interfaces. However, careless proliferation of Adapters can complicate design. Make responsibilities explicit and localize translation logic when you use this pattern.  
+Pay special attention to ownership, exception and error handling, performance, and testability when implementing an Adapter.  
 
 References:
 
 [!CARD](https://sourcemaking.com/design_patterns/adapter)
 
 [!CARD](https://en.wikipedia.org/wiki/Adapter_pattern)
 
-That's it for now — next time I'll cover another GoF pattern.
-The examples in this article are simplified for learning purposes; evaluate them carefully against your requirements before adopting them in production.
+That's it for now — next time I'll cover another GoF pattern.  
+The examples in this article are simplified for learning purposes; evaluate them carefully against your requirements before adopting them in production.  
 
 Thanks for reading — Pan-kun!

WebSite/content/other/blog_00034.en.md

@@ -0,0 +1,215 @@
+---
+title: GoF Design Patterns - Bridge
+date: 2026-02-11
+category: Coding
+description: A practical guide to the Bridge pattern from the GoF collection：concepts, when to use it, a C++ implementation example, caveats, and references.
+tags: [Coding, DesignPattern]
+recommended: true
+thumbnail: assets/img/ogp.png
+---
+
+Hello! This is Pan-kun.  
+
+This article covers the Bridge pattern from the GoF (Gang of Four) design patterns.  
+I explain it practically, including sample code (C++), how to build it, when to use it, and important caveats.  
+
+## Introduction
+
+The Bridge pattern separates an abstraction from its implementation so the two can vary independently.  
+When you use class inheritance, abstraction and implementation often become tightly coupled.  
+The Bridge pattern provides a flexible alternative that lets you change either side without affecting the other.  
+
+> The Bridge pattern is a software design pattern defined by the Gang of Four. It decouples an abstraction from its implementation so that the two can vary independently.  
+>  
+> Source: [Bridge pattern - Wikipedia](https://en.wikipedia.org/wiki/Bridge_pattern)
+
+[!CARD](https://en.wikipedia.org/wiki/Bridge_pattern)
+
+## Use Cases
+
+Here are some typical situations where you might consider applying the Bridge pattern:  
+
+**When you do not want to permanently bind abstraction and implementation.**  
+  Useful if you need to select or switch implementations at runtime.  
+**When you need to extend both the abstraction hierarchy and the implementation hierarchy.**  
+  Keeps the number of classes under control by managing extension at independent layers.  
+**When you want implementation changes to have minimal impact on clients.**  
+  Hides implementation details and can minimize recompilation scope (in C++ this is related to the Pimpl idiom).  
+**When many classes share similar implementation with small variations.**  
+  Splitting the feature hierarchy from the implementation hierarchy reduces code duplication.  
+
+## Structure
+
+To implement the Bridge pattern you typically create four roles of classes:  
+
+1. **Abstraction**
+   - The top-level class in the feature hierarchy.
+   - Holds a reference to an `Implementor` and delegates work to it.
+2. **RefinedAbstraction**
+   - Inherits from `Abstraction` and adds or refines behavior.
+   - Defines concrete combinations of feature behavior.
+3. **Implementor**
+   - The top-level interface (or abstract class) for the implementation hierarchy.
+   - Defines the low-level API used by `Abstraction`.
+4. **ConcreteImplementor**
+   - Implements the `Implementor` interface concretely.
+   - Contains platform-specific or library-dependent code.
+
+Below is a UML representation. Notice the separation between the feature (abstraction) class hierarchy and the implementation class hierarchy — they are literally bridged.  
+
+```mermaid
+classDiagram
+    class Abstraction {
+        -impl : Implementor
+        +operation()
+    }
+
+    class RefinedAbstraction {
+        +operation()
+        +extendedOperation()
+    }
+
+    class Implementor {
+        <<interface>>
+        +operationImpl()
+    }
+
+    class ConcreteImplementorA {
+        +operationImpl()
+    }
+
+    class ConcreteImplementorB {
+        +operationImpl()
+    }
+
+    Abstraction <|-- RefinedAbstraction
+    Abstraction o-- Implementor
+    Implementor <|.. ConcreteImplementorA
+    Implementor <|.. ConcreteImplementorB
+```
+
+## C++ Implementation Example
+
+Here we use a drawing example.  
+We separate the abstract concept of a "shape" from a concrete "drawing API" implementation.  
+
+This lets you add new shapes (e.g., rectangles, circles) on the shape side or add new drawing methods (e.g., OpenGL, DirectX) on the implementation side without changing the other.  
+
+```cpp
+// Drawing API interface
+class DrawingAPI {
+public:
+    virtual ~DrawingAPI() = default;
+    virtual void drawCircle(double x, double y, double radius) = 0;
+};
+
+// Concrete Drawing API 1
+class DrawingAPI1 : public DrawingAPI {
+public:
+    void drawCircle(double x, double y, double radius) override {
+        std::cout << "API1.circle at " << x << ":" << y << " radius " << radius << std::endl;
+    }
+};
+
+// Concrete Drawing API 2
+class DrawingAPI2 : public DrawingAPI {
+public:
+    void drawCircle(double x, double y, double radius) override {
+        std::cout << "API2.circle at " << x << ":" << y << " radius " << radius << std::endl;
+    }
+};
+
+// Abstract shape class
+class Shape {
+protected:
+    DrawingAPI* drawingAPI; // holds reference to Implementor
+
+public:
+    Shape(DrawingAPI* api) : drawingAPI(api) {}
+    virtual ~Shape() = default;
+
+    virtual void draw() = 0; // high-level operation
+    virtual void resizeByPercentage(double pct) = 0; // high-level operation
+};
+
+// Concrete shape: circle
+class CircleShape : public Shape {
+private:
+    double x, y, radius;
+
+public:
+    CircleShape(double x, double y, double radius, DrawingAPI* api)
+        : Shape(api), x(x), y(y), radius(radius) {}
+
+    void draw() override {
+        // Delegate actual drawing to the drawingAPI implementation
+        drawingAPI->drawCircle(x, y, radius);
+    }
+
+    void resizeByPercentage(double pct) override {
+        radius *= (1.0 + pct / 100.0);
+    }
+};
+
+int main() {
+    DrawingAPI1 api1;
+    DrawingAPI2 api2;
+
+    // Same conceptual "circle" but instantiated with different drawing APIs
+    CircleShape circle1(1, 2, 3, &api1);
+    CircleShape circle2(5, 7, 11, &api2);
+
+    circle1.resizeByPercentage(10);
+    circle2.resizeByPercentage(10);
+
+    std::cout << "--- Circle 1 with API 1 ---" << std::endl;
+    circle1.draw();
+
+    std::cout << "--- Circle 2 with API 2 ---" << std::endl;
+    circle2.draw();
+
+    return 0;
+}
+
+// Output
+// --- Circle 1 with API 1 ---
+// API1.circle at 1:2 radius 3.3
+// --- Circle 2 with API 2 ---
+// API2.circle at 5:7 radius 12.1
+```
+
+In this example, `Shape` holds a pointer to a `DrawingAPI`.  
+When `CircleShape::draw` is invoked, the actual drawing logic is delegated to the `DrawingAPI` implementation.  
+
+## Advantages / Disadvantages
+
+### Advantages
+
+- **Implementation hiding and reduced dependencies**  
+  Client code needs to know only the abstraction (`Abstraction`) and not the implementation details. This can shorten compile times and enable looser coupling.  
+- **Improved extensibility**  
+  You can extend the feature hierarchy and the implementation hierarchy independently. Adding a new feature doesn't affect implementation classes, and adding a new implementation doesn't affect feature classes.  
+- **Runtime implementation switching**  
+  By replacing the `Implementor` object at runtime you can change behavior dynamically.  
+
+### Disadvantages
+
+- **Increased design complexity**  
+  For small systems where simple inheritance is sufficient, Bridge can increase the number of classes and unnecessarily complicate the structure.  
+- **Potentially reduced readability**  
+  Because behavior is delegated from the abstraction to implementation classes, understanding the full behavior may require navigating multiple classes, which can make the code less intuitive.  
+
+## Conclusion
+
+The Bridge pattern is a powerful technique to keep systems flexible by separating feature extension from implementation extension.  
+It truly shines in large projects where future change requirements are unclear.  
+However, it can be overengineering for small projects; a good rule is to introduce it when you actually see class explosion or when refactoring for clearer separation.  
+
+References:
+
+[!CARD](https://en.wikipedia.org/wiki/Bridge_pattern)
+
+That's all for now — next time I'll cover another GoF pattern.  
+The sample implementations shown here are simplified for learning purposes. Evaluate carefully before adopting them in production.  
+
+Thanks for reading — Pan-kun!