企业官网建设流程全解析

面向对象设计（OOD）这个词，我在很多人那里听过几乎同一个版本的故事：学Java或者C#入门，老师讲类、对象、封装、继承、多态，课上全听懂了，课后小练习也做出来了。可一旦面对真实项目的需求清单，就完全不知道该从哪个类开始写，写出来也觉得哪里不对劲。折腾几个星期，功能倒是都能跑，但代码越来越乱，最后干脆说服自己："先不搞设计了，把功能做完再说。"这一句"先不搞了"，就是半途而废的开始。

我想换个角度聊OOD。它其实不是一门需要专门划出三个月去"学"的功课，而是当你决定让代码"设计指导编程"时，每天都会用到的思维方式。这篇文章我会用一个购物车加订单的常见业务，把从需求到类草图、从职责拆分到应对变化、从怎么验证设计到怎么练出设计直觉的完整路径走一遍。适合那些已经掌握一门面向对象语言的基础语法、但还没找到设计和编码连接点的开发者。看完你不需要记住多少高深术语，只需要学会一套"改代码之前停下三十秒想一想"的方法。

1. 半途而废的真相：OOP语法背完了，OOD工程没跟上

1.1 学会定义类和会设计系统，完全是两件事

先说一个我见过很多次的典型画面。某个开发者朋友写出一个订单处理类，构造函数里塞了商品列表、用户信息、优惠券、库存服务、日志服务，然后一个createOrder方法里先算价格、再扣库存、再发短信、再写日志，总共三百行。你问他对不对，他有点犹豫：功能没错啊，测试也过了。

但问题就出在"功能没错"上。你写出的每一个类，语法上都是合法的面向对象程序；但从设计角度看，这个类干的事情太杂，任何一个小需求变化都会牵扯到它。这就是典型的"用面向对象语言写出了过程式代码"。面向对象编程（OOP）解决的是"代码怎么组织"的语法问题，而面向对象设计（OOD）解决的是"类长什么样、职责怎么划分、未来怎么变化"的决策问题。语法是手脚，设计是大脑。

我把这两者的关系用盖房子打比方：OOP教会你怎么砌砖、抹灰、搭脚手架，OOD则要求你动工之前先想清楚哪里是承重墙、哪里留窗户、以后加一层楼怎么衔接。没有后者，你也能把房子盖起来——只要不碰上需求变更、不接新楼层、不换装修，一切都好说。可软件项目最不缺的，恰恰就是"碰上新需求"。

1.2 "边写边设计"为什么容易翻车

很多人半途而废，不是因为没看过设计原则，而是因为他们采用了一种"边写边设计"的策略：先写完一个能跑的版本，看到哪里别扭再改哪里。这个策略在代码量小于三千行的时候很有效，但一旦项目膨胀到几万行、多个人协作，"改一处崩三处"就会频繁出现。

我举个例子。假设你写了个运费计算逻辑，最开始只有一种规则：满99包邮。你把它写在Order类的calculateShipping方法里，没什么问题。后来产品说偏远地区不包邮，你往方法里加了个判断，也行。再后来要按重量计费、按距离计费、按会员等级打折……你会发现这个方法越来越长，而每次需求变更都要小心翼翼，生怕影响旧规则。

正确的方式是什么？在写第一行代码前，或者在改动变得复杂前，先停下来问自己：运费规则今天是一个if，明天可能是一组规则，未来的变化方向是什么？如果提前识别出"规则会有多个变体"，就应该设计一个独立的概念来承载它。这就是设计指导编程的含义——你写代码的顺序，是你已经想清楚的结构决定的，而不是代码逼着你临时改结构。当然，完全没有预见性的提前设计也是臭棋，这个平衡点后面我会单独讲。

2. 动手之前先画一张"类地图"：从需求文字到类草图

2.1 用三个问题把需求拆成候选类

设计从哪里开始？不是从UML图开始，而是从需求描述里的名词和动词开始。我习惯每次拿到需求后，先不做技术选型，先问自己三个问题：

• 这个系统里有哪些核心名词？这些名词通常对应候选类或类属性。
• 谁负责持有数据？数据应该放在离它最近、且最不会变化的类里。
• 哪些动词在改变数据或触发动作？这些动词往往对应方法，而方法的归属决定了职责。

把这三个问题过一遍，你手里就有了一张粗糙的"类地图"。比如一个最简单电商订单流程，需求文字里会出现购物车、商品、折扣、订单、支付、物流通知这些词。自然地，Cart、Product、DiscountStrategy、Order、PaymentService、NotificationService就成了候选类。它们之间的动作关系——加入购物车、计算折扣、生成订单、发起支付、发送通知——就是方法和依赖的方向。

这一步的关键是"先广度后深度"：先把候选类和关系画出来，不要急着定义类的属性细节，更不要纠结继承层级。很多新手恰好相反，一上来就琢磨"Product是不是应该派生出DigitalProduct和PhysicalProduct"，结果陷入抽象的泥潭。先解决主干关系，属性细节是第二步的事。

2.2 一个购物车推导示例

假设我们要做一个课后习题级别的场景：用户把商品放进购物车，结算时根据优惠规则计算最终价格，生成订单，然后发起支付，支付成功给用户发个通知。我用Python写一个"按这个思路走的第一版类草图"对应的接口轮廓：

class CartItem: def __init__(self, product_id, unit_price, quantity): self.product_id = product_id self.unit_price = unit_price self.quantity = quantity class DiscountStrategy: def calculate(self, items, original_total): ... class Cart: def __init__(self, discount_strategy): self.items = [] self.discount_strategy = discount_strategy def add_item(self, product_id, unit_price, quantity): ... def total(self): ... class Order: def __init__(self, cart, order_no): self.cart = cart self.order_no = order_no class PaymentService: def pay(self, order, channel): ... class NotificationService: def notify_user(self, user_contact, message): ...

注意，Cart持有DiscountStrategy，而不是在Cart内部硬写折扣规则；Order只知道自己是基于哪个Cart生成的；PaymentService和NotificationService各自独立，将来替换渠道或通知方式时互不牵连。这就是类地图的价值：代码还没写，但每个类的边界和依赖方向已经清楚了。

可能有人会问：这些类一定要一上来就设计得这么细吗？我的答案是：在主干接口上需要，在内部实现上不需要。面向对象设计的第一轮，只要把"哪些类存在、它们之间谁依赖谁"定下来，就成功了一大半。剩下的属性、算法、异常处理，完全可以在实现中逐步补充。另一个角度看，这种"先搭骨架后填肉"的方式也特别适合和同事对齐思路，因为评审一个接口轮廓，比评审几百行实现要容易得多。

3. 给类"划清边界"：职责分配是最容易翻车的地方

3.1 单一职责不是"只做一件事"，而是"只有一个变化理由"

职责分配是OOD里最容易被误解的部分。很多人把单一职责原则背成"一个类只做一件事"，于是把Order类拆到只剩数据字段，逻辑全部丢给一个服务类，结果服务类变成了新的"上帝类"。这不是设计，这是把问题从一个类搬到了另一个类。

我理解的单一职责原则，真正的判断标准是：这个类有没有多个"变化的理由"？也就是说，未来需求变化时，会不会因为两个不同的原因去修改同一个类？如果会，说明这两个原因对应的逻辑应该拆开。

举个例子。一个Order类如果同时负责价格计算、库存校验和日志记录：价格规则变了要改它，库存策略变了要改它，日志格式变了还得改它。三个变化方向，三个修改理由，挤在一个类里。更麻烦的是，团队里三个人可能同时在这个类上改需求，合并冲突肉眼可见地增加。

把职责按"变化理由"拆开之后，整个结构变得清爽很多。下面这段示例里，Order不再自己执行价格计算、库存校验和日志记录，而是通过构造函数把三个独立的能力组件组装进来，将来加新逻辑时不需要修改Order本身，只需要替换对应组件。每个组件也都能独立测试、独立演化，不会因为别的模块改动而连坐。

class PriceCalculator: def calculate(self, items, discount_strategy): ... class InventoryChecker: def check(self, items): ... class OrderLogger: def log(self, order): ... class Order: def __init__(self, price_calculator, inventory_checker, order_logger): self.price_calculator = price_calculator self.inventory_checker = inventory_checker self.order_logger = order_logger

表面上看类变多了，但每个类的"变化理由"都只有一个。价格算法调整只动PriceCalculator，库存规则变化只动InventoryChecker，日志策略变化只动OrderLogger。将来给新同事安排任务，也可以直接按类分：你去改价格模块，他去改库存模块，互不踩脚。

3.2 识别"越界"职责的三个现场检查点

光知道原则还不够，你还需要能在代码里识别出"这个职责放错了地方"。我在代码走查时常用三个检查点。

第一，看方法的参数。如果一个方法里传入了大量不属于当前类上下文的对象，然后通过这些对象层层取数据做业务判断，说明这个方法很可能放错了地方。第二，看依赖的方向。如果A类频繁访问B类的内部状态，再根据这些状态去改变C类的行为，链路就很可疑。第三，看修改的牵涉面。比如你只是改了一下通知文案，结果要动的类有五个，这就说明"通知"这个职责被拆得七零八落，应该收敛成一个独立的类。

举一个典型的越界案例：订单状态变更后要发通知，有人把通知逻辑直接写在Order类里。表面看只是加一行调用的工作量，但将来通知渠道从短信换成邮件或者增加站内信，你就要动Order；订单状态机只要一变，通知逻辑也要跟着变。正确做法是把"订单状态变化"和"对状态变化做出反应"拆开，让Order只负责自身状态流转，让一个观察者机制去响应状态变化并触发通知。

写到这里，我想强调一句：职责分配没有绝对的对错，它是权衡的结果。在一个一百行的Demo里，把日志写在Order类里完全合理；但在一个十万行的业务系统里，这就是隐患。所以判断标准永远是"这个类未来会不会因为多个原因而修改"，而不是"这句话听起来像教条"。如果你能带着这个判断标准去看每一行代码，单一职责原则才算真正变成你的能力，而不是别人让你背的考点。

4. 面向变化编程：开闭原则和依赖倒置才是OOD的甜头

4.1 为什么设计非要考虑"未来会变"不可

很多人在学习阶段最抵触的就是"过度设计"：需求只有一种，为什么要为三种可能性做准备？这个抵触本身没错，但是要分清"过度设计"和"对变化方向的必要预判"。

我的经验是，大多数业务需求不管表面上千差万别，变化方向就那么几种：规则变多、渠道变多、格式变多。电商里折扣规则会越来越多，支付渠道会越来越多，报表导出格式会越来越多。如果你能识别出当前需求属于"这一类将来会变多"的变化方向，那提前用多态或策略来承载它，就不是过度设计，而是用最小的成本换取最大的稳定。

开闭原则说的就是这件事：对扩展开放，对修改封闭。翻译成大白话就是，将来要加新功能时，最好通过"加一个新类、接一个新实现"来完成，而不是回到旧类里改东改西。注意这里的"封闭"不是禁止修改，而是尽量让稳定的既有代码不被反复改动，从而降低回归风险。你想想，如果每次上线新渠道都要把核心订单流程翻一遍，出一次事故的成本，可能就比当初抽象一下的代价高得多。

4.2 用一段折扣代码演示"改一行加一个类"

我继续用购物车的折扣需求做演示。第一版需求只有"满100减20"。

class Cart: def total(self): raw_total = 0 for item in self.items: raw_total += item.unit_price * item.quantity if raw_total >= 100: return raw_total - 20 return raw_total

等到第二版需求"新用户首单打八折"来了，你在total里继续加if。等到第三版"会员满200减50"来了，又加if。这个方法会一直膨胀，而且规则之间如果叠加，判断顺序还会出bug。

换成策略模式之后，代码长这样：

class DiscountStrategy: def apply(self, order_info): raise NotImplementedError class FirstOrderDiscount(DiscountStrategy): def apply(self, order_info): if order_info.is_first_order: return order_info.raw_total * 0.8 return order_info.raw_total class FullReductionDiscount(DiscountStrategy): def __init__(self, threshold, reduction): self.threshold = threshold self.reduction = reduction def apply(self, order_info): if order_info.raw_total >= self.threshold: return order_info.raw_total - self.reduction return order_info.raw_total

新增一种规则，就是新建一个继承DiscountStrategy的子类，然后在组装时换掉传入Cart的策略对象。Cart里的total方法不用再改，已有的规则类也不动。这就是开闭原则最朴素的落地方式。写到这里你应该能感受到：OOD的价值不是让你一开始就规划所有规则，而是让你在"规则变多"这个变化方向上，只付一次性的抽象成本，之后每次扩展都只写新代码，不碰旧代码。

4.3 依赖倒置：让高层代码不依赖具体实现

与开闭原则配套的是依赖倒置原则。用大白话讲，你的核心业务逻辑不应该依赖某个具体工具、某个具体渠道，而应该依赖抽象接口。这样替换实现的时候，核心逻辑按兵不动。

我还见过一个非常典型的例子。一个订单服务在构造函数里直接new了一个某短信平台的客户端，紧接着下单流程里到处调用这个客户端的发送方法。后来公司要换成另一个推送服务，涉及修改的地方遍布十几个方法。如果一开始构造函数注入的是一个MessageSender接口，替换渠道只是替换一个实现类的问题。

依赖倒置还有个附带的好处：测试变容易了。测试Order在支付成功后的行为时，不需要真的调用一个支付渠道，只要注入一个测试用的假支付实现，就能验证逻辑。很多人在写单元测试时觉得痛苦，根源往往就是高层代码死死焊住了具体依赖，导致测试时无处下手。

依赖倒置不必上框架级别的容器，最简单的做法就是构造函数注入：在创建Order时，把需要的依赖作为参数传进去，而不是在Order内部去new。这一点我在前面3.1的代码里已经演示过了，Order的构造函数传入price_calculator、inventory_checker、order_logger，就是最轻量的依赖注入。

5. 设计结果怎么验证：测得出、改得动，才算好设计

5.1 用测试的"痛苦指数"反向检验设计

设计好不好，不需要从头到尾再评审一遍，有个很直接的检验方式：写测试时痛不痛苦。一个类如果很难被测，通常说明了三件事：它依赖了太多具体实现、它内部状态变化不可控、它承担了太多职责。

比如Order类内部直接new了一个PaymentService，而PaymentService又内部new了一个HttpClient。你测Order时，就必须让这个HttpClient真实运行，否则订单流程根本走不完。于是你不得不准备一堆测试替身、设置网络超时、处理外部服务的随机失败。这哪里是在测自己的逻辑，分明是在跟外部系统较劲。

反过来，如果Order的依赖都是通过构造函数注入的抽象接口，测试时你只需要提供简单的假实现，就能快速验证"价格计算对不对、库存校验是否触发、订单状态是否正确流转"。写测试的顺利程度，直接反映了设计时职责拆分的干净程度。所以我有个习惯：每设计完一组类，先写一个冒烟测试，看看要准备哪些假依赖。如果假依赖一大堆，我就知道边界划得太粗了。

5.2 五个常见设计坏味道自查清单

我把自己走查代码时最爱看的五个坏味道列成了一张表，你可以打印出来贴在显示器边上：

对照这张表自查的时候，不需要一次改完所有问题，按优先级来。第一步先处理"重复代码"，因为它的修复收益最直接；第二步处理"上帝对象"和"长方法"，把一个上帝类拆成几个焦点明确的类；最后再收拾"散弹式修改"和"过度耦合"，因为这两类问题通常需要重新梳理类的依赖方向，改动范围较大，适合放在重构的一整块时间里做。顺序很重要，从收益最高、风险最低的地方入手，你才容易看到正向反馈，也就更愿意继续走下去。

5.3 小步重构：每次只挪一个职责

很多人不敢动设计烂的代码，原因是"一动就炸"。我的建议是，永远不要想着一次性把一个大类重写掉，而是每次只挪一个职责，并且每挪完一步就跑一次测试。这个过程叫小步重构。

举例来说，一个Order类同时负责价格计算、库存校验、日志。你不需要一天内把它变成五个类。第一天，把日志提取成OrderLogger，从Order里挪出两行调用；测试通过。第二天，把库存校验提取成InventoryChecker；测试通过。第三天，再处理价格计算。每一步都小到心理上不害怕，逻辑上可回溯，风险被控制在一个非常小的范围内。

很多人设计学得半途而废，不是缺理念，而是缺"下手改"的勇气。小步重构就是治疗这种恐惧的良药：你不需要一次证明自己多厉害，只需要证明自己每一步都稳。等连续做上十几次小步重构再回头看，你会发现当初那个不敢动的类，早就变得结构清晰、容易扩展，而这种变化的成本，其实低得超乎想象。

6. 怎么培养一个能落地的OOD习惯：模仿、走查、推倒重来

6.1 不要一上来就设计大系统，从小模块开始

我见过不少人的学习路径出了问题：看了一本讲企业级架构的书，然后想在自己的练手项目里搞出微服务、事件驱动、领域模型全套。结果坚持了不到两星期就放弃了，因为练手项目的复杂度根本撑不起这么重的设计。

正确路径应该反过来：先在几千行的小项目里把基本功练扎实。找一个你会写的常见业务——比如记账本、待办清单、购物车——刻意用上策略、依赖注入、单一职责这些手法，然后观察代码是不是真的更容易改、更容易测。如果观察不到差异，说明你的练习场景还不够复杂，别急着上大架构。练基本功不需要题目多难，需要你反复做，做到手熟。

6.2 每天"十五分钟设计走查"：给设计直觉热身

培养直觉最有效的方法，不是看书，而是每天花十五分钟做一次设计走查：选一个已经写完的类，问自己几个问题——这个类如果明天要改，是因为什么需求？那个需求来了，我要动哪些类？有没有类正在承担两个以上不相关的变化理由？

坚持一个月之后，你会发现一个明显的变化：写代码之前会自然而然地停顿一下，想清楚依赖方向再动手。这个停顿，就是设计直觉在读秒。它不需要你背多少图、画多少层架构，只需要你对"变化的落点"保持敏感。我以前带团队时，每周五下午都会留半小时做一次集体走查，成本很低，但对新人的设计判断力提升非常明显。

6.3 亲手推倒一次自己代码，胜过看十本设计模式书

最后说一个我自己的亲身体会。我第一版练手项目，用了大概一千行写了一个订单模块，功能全通。后来我参加了一次内部代码走查，别人指出了我至少五处职责集中、耦合过深的问题。我当时的第一反应是不服：功能都跑通了还挑剔什么？但那周我还是把模块推倒重写了，这次只用了七百行，测试反而更容易写。

那次推倒重来让我明白了一个道理：面向对象设计的进步，往往不是靠新增知识，而是靠主动割舍旧习惯。你只有亲手感受到"旧设计有多别扭、新设计有多顺手"，才会真心相信OOD的价值。这件事别人劝没有用，必须自己体验一次。当然，推倒重来不是鼓励你无脑重写代码，而是建议你找那种"功能不复杂但结构很乱"的小模块来练手，用一个全新的类结构去承载同样的功能，然后对比一下两次的维护体验。

所以在文章最后我想说：别再给自己定"一个月学完OOD"这种目标了。目标应该是，这周改代码之前，先停下来想一想类边界；这个月选一个练手项目，把策略和依赖注入用一遍；这季度找一个写过的小模块，推倒重写一次。设计能力是练出来的，不是背出来的。你不需要一次变成设计大师，只需要在每次写代码前多停三十秒，就不会再半途而废。