。

然而#xff0c;真正的挑战在于如何在实际项目中灵活、恰当地运用这些知识。

这一节#xff0c;我们将探讨设计模式的综…第五部分总结与进阶

恭喜你学习完前面三大类设计模式后你已经对设计模式有了坚实的基础。

然而真正的挑战在于如何在实际项目中灵活、恰当地运用这些知识。

这一节我们将探讨设计模式的综合应用帮助你从“知道”模式到“会用”模式。

在项目中应用设计模式不是为了用而用而是为了解决特定的问题提升代码质量。

识别和选择模式通常遵循以下思路

理解问题本质分析痛点

痛点1你想在客厅、卧室、书房都装上灯但每个房间的灯的类型吊灯、壁灯、台灯和开关控制方式可能不同。

如果直接硬编码每次换灯或增加新的灯类型都会很麻烦。

识别这里涉及到“创建不同类型的对象”并且“具体类型可能变化或扩展”。

可能模式工厂方法模式为不同房间创建灯的工厂、抽象工厂模式如果灯具和开关等需要成套搭配。

痛点2你有很多电器电视、空调、音响每个都有自己的遥控器操作复杂。

你想要一个统一的面板来控制它们。

识别这里涉及到“简化复杂系统的接口”。

可能模式外观模式一个智能家居控制面板作为外观。

痛点3你希望房子的装修风格例如现代简约、中式古典可以整体切换包括家具、窗帘、墙纸等。

识别这里涉及到“创建一系列相关的对象产品族”并且“可以切换整个产品族”。

可能模式抽象工厂模式一个“现代风格工厂”生产现代沙发、现代窗帘一个“中式风格工厂”生产中式家具、中式窗帘。

回顾设计原则

设计模式是设计原则的体现。

当你发现代码违反了某个原则时通常可以考虑使用相应的设计模式来改进。

违反单一职责厨师Chef不仅要做菜还要负责点单、收银、打扫卫生。

这样厨师会很累效率低下任何一个环节出问题都会影响其他环节。

改进思路引入服务员Waiter负责点单和部分服务收银员Cashier负责收银清洁工Cleaner负责打扫。

关联模式虽然这不是直接的设计模式应用但职责分离的思想是很多模式的基础。

例如命令模式将“点单”这个请求封装成对象解耦厨师和服务员。

违反开闭原则你的菜单经常需要增加新菜品。

如果每次增加新菜都要修改核心的点餐系统代码风险很高。

改进思路点餐系统应该对扩展开放增加新菜品对修改关闭核心逻辑不变。

可能模式工厂方法模式每个菜系或菜品类型一个工厂、策略模式如果烹饪方法或优惠活动是可变的算法。

每个设计模式都有其特定的“意图”Intent和“适用场景”Applicability。

这是选择模式最直接的依据。

模式意图“在不破坏封装性的前提下捕获一个对象的内部状态并在该对象之外保存这个状态。

”选择备忘录模式。

需求2用户可以给文本添加多种格式如加粗、斜体、下划线并且这些格式可以组合。

模式意图“动态地给一个对象添加一些额外的职责。

”选择装饰器模式。

.txt,

模式意图“定义一个用于创建对象的接口让子类决定实例化哪一个类。

”选择工厂方法模式为每种文件格式提供一个处理器工厂。

没有银弹。

每个模式在解决一些问题的同时也可能引入新的复杂性或限制。

选择策略模式将不同的推荐算法如基于协同过滤、基于内容、基于热门商品封装成独立的策略。

这使得切换和增加新算法很容易。

优点灵活性高符合开闭原则。

缺点/考虑如果策略非常多管理策略类本身可能会变得复杂。

客户端需要知道存在哪些策略或者通过某种方式选择策略。

从简单到复杂逐步演进

不要一开始就试图应用最复杂的模式。

可以从简单的结构开始随着需求的明确和问题的出现再考虑引入设计模式进行重构。

初期可能用户、文章、评论之间的关系很简单直接通过简单的类和方法调用就能实现。

发展期当用户量增加需要引入消息通知功能例如新评论通知作者新文章通知订阅者。

这时你可能会发现用户和文章之间的通知逻辑变得复杂且耦合。

演进可以考虑引入观察者模式让文章成为“主题”订阅者成为“观察者”。

在实际项目中设计模式很少单独使用往往是多个模式协同工作共同构成一个优雅的解决方案。

MVC

本身不是一个设计模式而是一种架构模式但它内部大量使用了多种设计模式。

Model

(模型)厨房里的厨师和食材。

厨师负责准备和烹饪菜品数据处理和业务逻辑。

食材是数据的来源。

可能涉及模式工厂模式厨师根据菜单制作不同菜品、单例模式可能某些调料或秘方是唯一的。

View

(视图)你的餐桌、菜单、菜品呈现。

这是用户能直接看到和交互的界面。

可能涉及模式组合模式菜单项可以有子菜单形成树形结构、观察者模式当厨房通知菜品做好时服务员更新你的餐桌状态。

Controller

(控制器)服务员。

服务员接收你的点单请求用户输入告诉厨房去做与模型交互然后把做好的菜端给你更新视图。

可能涉及模式命令模式你的点单可以看作一个命令对象服务员是调用者厨师是接收者、策略模式如果服务员有多种处理特殊请求的策略。

观察者模式Model

可以使用不同的策略来响应用户输入或处理业务逻辑。

组合模式View

Model

场景员工提交一个报销申请。

申请金额不同审批级别也不同小组长审批500元以下部门经理审批500-2000元财务总监审批2000元以上。

命令模式将“报销申请”封装成一个命令对象

(ReimbursementCommand)包含申请金额、事由等信息。

责任链模式审批者小组长、部门经理、财务总监构成一个责任链。

每个审批者都是链上的一个节点。

GroupLeaderHandler:

处理500元以下的申请否则传递给下一个处理者部门经理。

DepartmentManagerHandler:

处理500-2000元的申请否则传递给下一个处理者财务总监。

CFOHandler:

组合效果客户端创建一个报销命令然后将其传递给责任链的第一个处理者。

命令沿着链传递直到被某个处理者处理。

装饰器

场景咖啡店提供基础咖啡如浓缩、美式顾客可以添加各种调料如牛奶、糖、巧克力酱、奶油。

基础产品Coffee

接口具体产品

Espresso、Americano。

装饰器模式调料是装饰器。

CondimentDecorator

抽象类具体装饰器

MilkDecorator、SugarDecorator、ChocolateDecorator。

工厂模式如果创建一杯“加奶加糖的浓缩咖啡”的过程比较固定或者希望对客户端隐藏具体的装饰过程可以使用工厂。

createMocha()内部实现

组合效果工厂负责创建被装饰器层层包裹的基础咖啡对象客户端只需要调用工厂方法即可得到最终定制好的咖啡而无需关心具体的装饰步骤。

建造者

CPU、兼容主板、推荐内存。

每个工厂负责创建一系列兼容的“产品族”CPU、主板、内存。

建造者模式电脑的组装过程是固定的安装CPU

安装内存

GamingComputerBuilder可能使用抽象工厂来获取高性能的部件并按照游戏电脑的配置顺序组装。

OfficeComputerBuilder可能使用抽象工厂来获取性价比高的部件并按照办公电脑的配置顺序组装。

组合效果建造者负责指导电脑的构建过程步骤和顺序而构建过程中需要的具体零件产品则由抽象工厂来提供确保了零件之间的兼容性和产品线的整体性。

(Over-engineering

虽然设计模式是好东西但滥用或不当使用会导致“过度设计”(Over-engineering)反而使系统更复杂、更难维护。

为不存在的问题设计预见到未来可能发生的各种变化并为这些“可能”的变化引入了大量复杂的模式而这些变化最终并未发生。

生活例子你只是想建一个简单的狗窝但你担心未来可能需要把它改造成能防熊、防龙卷风、带空调和自动喂食的豪华狗别墅于是你一开始就用了造航空母舰的架构和材料。

结果狗窝复杂无比成本高昂而且你的狗可能只需要一个能遮风挡雨的地方。

模式的生搬硬套不考虑具体场景看到某个问题“有点像”某个模式的描述就强行套用结果得不偿失。

生活例子你学会了用锤子然后看什么都像钉子。

即使只是需要拧个螺丝你也非要用锤子砸。

不必要的抽象层次为了使用某个模式引入了过多的接口、抽象类和间接层使得代码难以理解和调试。

喝。

过度设计后可能变成创建一个“喝水请求对象”通过“喝水管理器”提交给“水资源分配策略器”再由“动作执行器”调用“手臂控制器”和“嘴巴控制器”…

增加复杂性引入模式不可避免地会增加类的数量和对象间的交互从而增加系统的整体复杂性。

对于简单问题直接实现可能更清晰。

性能考虑某些模式如涉及大量小对象、间接调用或动态绑定可能会对性能产生一定影响。

例如装饰器模式层层包裹可能会增加方法调用链的深度。

学习曲线理解和正确使用设计模式需要一定的学习成本和经验积累。

并非万能设计模式解决的是特定类型的设计问题它们不能解决所有问题也不是高质量软件的唯一保证。

可能掩盖糟糕的底层设计有时过度依赖设计模式去“修补”一个本身设计就很糟糕的模块不如重新审视和重构底层设计。

KISS

Stupid)保持简单除非真的有必要否则不要引入复杂的模式。

YAGNI

(You

It)不要为臆想的未来需求编写代码。

只实现当前需要的功能。

演进式设计从简单的设计开始随着需求的变化和对问题理解的深入逐步进行重构和优化在真正需要的时候引入设计模式。

权衡利弊在选择一个模式前仔细评估它带来的好处是否大于其引入的复杂性和成本。

团队沟通确保团队成员对所使用的模式有共同的理解避免因理解不一致导致误用或维护困难。

生活例子总结学习开车设计模式能让你去更远的地方构建复杂系统。

但如果你只是想去街角的便利店简单问题走路或骑自行车简单直接的实现可能更合适。

开着坦克去买菜过度设计不仅浪费资源还可能造成交通拥堵系统复杂难以维护。

记住设计模式是工具不是目标。

目标是构建可维护、可扩展、高质量的软件。

明智地选择和使用工具才能更好地达成目标。