关于做网站的ppt湖南建设监理员报名网站

当前位置： 首页 > news >正文

关于做网站的ppt,湖南建设监理员报名网站,php做网站目录结构,北京做网站周云帆设计模式 15 Decorator Pattern 装饰器模式 1.定义 Decorator Pattern 装饰器模式是一种结构型设计模式#xff0c;它允许在运行时给对象添加新的行为或职责#xff0c;而无需修改对象的源代码。这种模式通过创建一个包装对象#xff0c;也称为装饰器#xff0c;来包裹原…设计模式 15 Decorator Pattern 装饰器模式 1.定义 Decorator Pattern 装饰器模式是一种结构型设计模式它允许在运行时给对象添加新的行为或职责而无需修改对象的源代码。这种模式通过创建一个包装对象也称为装饰器来包裹原始对象装饰器对象与原始对象有相同的接口因此可以在不改变客户端代码的情况下增加或修改对象的功能。 装饰器模式的优点包括 动态地给对象添加新的行为而无需修改对象的源代码或继承结构。 可以独立地增加对象的功能因为每个装饰器都是独立的类。 保持了类的单一职责使得代码更易于维护和扩展。 装饰器模式通常用于添加非核心功能如日志、性能追踪、缓存等而不会影响对象的核心行为。 2.内涵 Decorator Pattern 的主要组成部分 Component组件这是定义对象接口的抽象类或接口。所有可以装饰的对象都必须实现这个接口这样装饰器才能与它们互换。Concrete Component具体组件这是 Component 接口的实现是将要被装饰的对象。它定义了实际的行为和职责。Decorator装饰器这是 Component 接口的实现它持有一个 Component 对象的引用。装饰器可以是抽象的也可以包含具体的行为。装饰器对象可以添加新的行为或修改 Component 对象的行为。Concrete Decorator具体装饰器这是 Decorator 的具体实现它给 Component 添加新的行为或职责。每个 Concrete Decorator 都可以添加不同的功能也可以堆叠多个 Decorator 来增强对象的功能。 组件之间的调用图如下图所示 ————| Component  |————|| 继承/实现V————–|  Decorator   |————–|| 继承/实现V——————-| Concrete Decorator|——————-|| 持有V——————-| Concrete Component|——————- 每个模块的作用如下 Component Interface定义了公共接口使得装饰器和组件可以互相协作。Concrete Component实现了 Component 接口定义了具体的行为和状态是被装饰的对象。Decorator作为抽象装饰器持有 Component 的引用实现 Component 接口以保持与组件的兼容性。Concrete Decorator具体实现了装饰器的逻辑添加或修改了 Concrete Component 的行为。可以有多个 Concrete Decorator每个实现不同的增强功能。 3.使用示例 #include iostream #include stringusing namespace std;// Component interface - defines the basic ice cream // operations. class IceCream { public:virtual string getDescription() const 0;virtual double cost() const 0; };// Concrete Component - the basic ice cream class. class VanillaIceCream : public IceCream { public:string getDescription() const override{return Vanilla Ice Cream;}double cost() const override { return 160.0; } };// Decorator - abstract class that extends IceCream. class IceCreamDecorator : public IceCream { protected:IceCream* iceCream;public:IceCreamDecorator(IceCream* ic): iceCream(ic){}string getDescription() const override{return iceCream-getDescription();}double cost() const override{return iceCream-cost();} };// Concrete Decorator - adds chocolate topping. class ChocolateDecorator : public IceCreamDecorator { public:ChocolateDecorator(IceCream* ic): IceCreamDecorator(ic){}string getDescription() const override{return iceCream-getDescription() with Chocolate;}double cost() const override{return iceCream-cost() 100.0;} };// Concrete Decorator - adds caramel topping. class CaramelDecorator : public IceCreamDecorator { public:CaramelDecorator(IceCream* ic): IceCreamDecorator(ic){}string getDescription() const override{return iceCream-getDescription() with Caramel;}double cost() const override{return iceCream-cost() 150.0;} };// 测试案例分析调用 int main() {// Create a vanilla ice creamIceCream* vanillaIceCream new VanillaIceCream();cout Order: vanillaIceCream-getDescription() , Cost: Rs. vanillaIceCream-cost() endl;// Wrap it with ChocolateDecoratorIceCream* chocolateIceCream new ChocolateDecorator(vanillaIceCream);cout Order: chocolateIceCream-getDescription() , Cost: Rs. chocolateIceCream-cost() endl;// Wrap it with CaramelDecoratorIceCream* caramelIceCream new CaramelDecorator(chocolateIceCream);cout Order: caramelIceCream-getDescription() , Cost: Rs. caramelIceCream-cost() endl;delete vanillaIceCream;delete chocolateIceCream;delete caramelIceCream;return 0; } 4.注意事项 在使用 Decorator Pattern 时需要注意以下几点 性能影响装饰器可能会增加对象的创建和管理成本特别是在需要大量创建和销毁对象的场景下。因此需要权衡装饰器带来的灵活性和可能的性能损失。代码复杂性如果过度使用装饰器可能会导致代码结构变得复杂难以理解和维护。确保每个装饰器都有明确的职责并保持代码的简洁性。类型检查和强类型语言在强类型语言中装饰器可能会隐藏原始对象的类型这可能导致类型检查问题。使用类型注解或接口可以帮助解决这个问题。一致性确保所有装饰器的行为与组件接口保持一致否则可能会导致客户端代码出错或行为不一致。可组合性虽然装饰器可以堆叠但过多的装饰器可能导致代码难以理解和调试。考虑使用组合模式来组合多个功能而不是一次性添加多个装饰器。状态管理如果组件的状态对行为有影响确保装饰器正确处理和传递这些状态以避免意外的行为。设计时的考虑在设计系统时提前考虑是否需要使用装饰器因为它可能影响到类的设计和接口的定义。在开始编码之前充分理解需求和扩展性要求以便做出最佳决策。 5.最佳实践 该模式最佳实践包括以下这些点 保持装饰器和组件接口一致装饰器应该与组件有相同的接口这样客户端代码可以透明地使用装饰后的对象而无需知道它是装饰器还是原始组件。避免深度装饰虽然可以堆叠多个装饰器但过多的装饰可能导致代码复杂性增加。如果需要添加大量功能可能需要考虑其他设计模式如组合模式或使用类的继承。使用接口而非具体类装饰器模式通常与接口一起使用因为接口允许更灵活的替换和扩展。如果使用具体类可能会限制装饰器的通用性。明确职责每个装饰器应专注于添加或修改特定的行为而不是试图一次性处理所有额外功能。这样可以保持代码的清晰和可维护性。使用装饰器来扩展功能装饰器模式最适合用于添加非核心功能如日志、缓存、权限控制等这些功能可以独立于核心业务逻辑存在。避免与继承混淆装饰器模式是作为继承的替代方案特别是当需要动态地添加或移除行为时。如果新的行为是静态的并且适用于所有对象那么继承可能更合适。测试和文档确保为装饰器编写测试用例并在文档中明确说明装饰器的作用以便其他开发者理解其功能和使用方式。 6.总结 该模式在使用时可能存在以下“坑”类型混淆装饰器可能会隐藏原始对象的类型导致类型检查问题。例如在强类型语言中如果装饰器没有正确地保持原始类型信息可能会在编译时或运行时遇到错误。例如Java 中的 InputStream 和其装饰器如果不注意类型转换可能会导致类型安全问题。此外性能开销也是需要考虑的地方。