You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

桥接模式与装饰器模式的差异辨析(含装饰器模式代码示例)

Bridge Pattern vs Decorator Pattern: Core Differences

Great question! Let’s break down the key distinctions between these two patterns, using your provided Decorator code and official definitions as a reference—especially since you’re working with an existing concept implementation.

1. Core Intent (The "Why" Behind Each Pattern)

  • Decorator Pattern: As the definition clearly states:

    Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
    Its entire purpose is to add or enhance behavior of an existing object without altering its core structure. Your decoratorA and decoratorB are perfect examples—they wrap the original concept instance and tack on extra actions ("with his dog", "in the rain") while keeping the Iconcept interface fully intact.

  • Bridge Pattern: From its official definition:

    Decouple an abstraction from its implementation so that the two can vary independently.
    This pattern is all about separation of concerns between what something does (the abstraction) and how it does it (the implementation). If you applied Bridge to your concept, you’d split the "what" (e.g., a high-level ActionConcept abstraction) from the "how" (e.g., your original walking implementation, plus new ones like running or jumping). The abstraction would work with any implementation without needing changes.

2. Object Relationship & Execution Flow

  • Decorator: Uses a wrapping (composition) relationship where decorators implement the same interface as the object they decorate. Each decorator holds a reference to the underlying Iconcept instance, delegating to it before or after running its own logic. You can even nest decorators (e.g., new decoratorB(new decoratorA(concept)).action() would output "walking with his dog in the rain") to mix and match behaviors.

  • Bridge: Uses a delegation relationship between an abstraction and its implementation layer. The abstraction doesn’t depend on concrete implementations—it relies on an implementation interface. For example, a Bridge refactor of your code might look like this:

    // Abstraction (what we do)
    abstract class ActionConcept {
        protected IActionImplementation _implementation;
        public ActionConcept(IActionImplementation implementation) {
            _implementation = implementation;
        }
        public abstract void PerformAction();
    }
    
    // Implementation interface (how we do it)
    interface IActionImplementation {
        void Execute();
    }
    
    // Original implementation
    class WalkingImplementation : IActionImplementation {
        public void Execute() { Console.WriteLine("walking "); }
    }
    
    // New independent implementation
    class RunningImplementation : IActionImplementation {
        public void Execute() { Console.WriteLine("running "); }
    }
    

    Here, the abstraction (ActionConcept) can work with any IActionImplementation, and you can add new implementations or tweak the abstraction without breaking the other.

3. What They Let You Vary Independently

  • Decorator: Lets you vary the behavior of individual objects at runtime. You can mix and match decorators to create unique combinations of features for the same core object. It’s all about extending existing functionality.

  • Bridge: Lets you vary abstractions and implementations separately. You can build new abstractions (e.g., a FastActionConcept that modifies how the action is triggered) and new implementations (e.g., JumpingImplementation) without either layer affecting the other. It’s all about separating "what" from "how".

4. When to Choose Which

  • Pick Decorator if you want to:

    • Add optional, modular features to objects dynamically (think adding toppings to a pizza one by one).
    • Avoid a bloated class hierarchy where every combination of features would require a new subclass.
  • Pick Bridge if you want to:

    • Separate high-level logic from low-level implementation details (like a remote control abstraction that works with TVs, speakers, and projectors).
    • Enable both abstractions and implementations to evolve independently without tight coupling.

内容的提问来源于stack exchange,提问作者Lijin Durairaj

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.15 08:51:48