在面向对象设计里，当系统需要追加新功能时，第一个现实问题往往是这个方法该写到哪个类里面。很多代码腐化并不是因为逻辑写错，而是因为方法被安放到了错误的职责载体上，导致类之间耦合扭曲、单元测试难以编写。合理的放置方式应当让对象保持高内聚，并让依赖关系符合业务语义。
从职责与数据归属判断方法位置
最直观的判断标准是：新方法主要操作谁的数据，它就更应该贴近谁。如果一个方法大量读取或修改某个对象的状态，却写在另一个毫不相干的类里，说明你把这个类的内部细节暴露给了外部，违反了封装原则。此时应当把方法迁移到数据持有者中，或至少通过持有者提供的接口来完成。
例如电商系统中要计算订单的折扣后金额，折扣规则依赖订单中的商品明细、用户等级和促销活动。如果把这些计算硬塞进一个独立的工具类，工具类就要拿到订单全部字段，订单一旦结构调整工具类就崩。更好的做法是把核心计算放在订单对象内部，或放在订单能自然组合的折扣策略对象中。
// 不合理的放置：工具类直接拆解订单数据
public class DiscountUtil {
public static double calc(Order order, User user) {
double sum = 0;
for (Item i : order.getItems()) {
sum += i.getPrice() * i.getCount();
}
if (user.getLevel() > 2) {
sum *= 0.9;
}
return sum;
}
}
// 合理放置：职责回到订单与策略
public class Order {
private List<Item> items;
private DiscountStrategy strategy;
public double payAmount(User user) {
return strategy.calc(this, user);
}
}
跨对象协作时引入专门职责载体
当新功能本身不属于任何一个已有类的核心职责，而是协调多个领域对象完成一件事，就不该强行塞进某个实体。比如导出订单报表、同步库存、发送通知，这些属于应用层或领域服务的工作。此时引入一个服务类（Service）或用例对象，能让实体保持纯净，也符合单一职责原则。
但要注意服务类不能演变成上帝类。如果服务开始持有越来越多状态并混杂各种判断，就应该按功能拆分为更小的处理器或采用设计模式。例如使用访问者模式可以把新操作从元素类中剥离，元素只接受访问者，具体逻辑写在访问者实现里，后续加操作不需改元素类。
# 访问者模式示例：新功能作为访问者添加
class OrderElement:
def accept(self, visitor):
visitor.visit_order(self)
class DiscountVisitor:
def visit_order(self, order):
# 新功能逻辑放在访问者中
return order.total() * 0.95
order = OrderElement()
v = DiscountVisitor()
print(v.visit_order(order))
用设计原则做放置校验
方法放好后，可以用几条原则快速自检。单一职责原则要求一个类只有一个引起变化的原因；如果加了新方法后类因为不同维度的需求频繁修改，就说明放错了。迪米特法则强调对象只和朋友说话，若新方法让本不相干的类产生直接调用链，应考虑中间者或事件解耦。
另外，开闭原则提醒我们：添加新功能最好通过扩展而非修改已有类。当发现必须把方法写进某个稳定基类才能工作，往往意味着基类抽象不足。此时提取接口或组合新组件，比在旧类里堆方法更可持续。
| 判断维度 | 放错的表现 | 调整方向 |
|---|---|---|
| 数据归属 | 外部类大量读取内部字段 | 迁移到数据持有者 |
| 职责纯度 | 实体类混杂应用逻辑 | 抽离到服务或策略 |
| 变化原因 | 一类多维度频繁改 | 拆分或组合 |
结合重构逐步归位
实际项目里旧代码不可能一次理清。可以先用移动方法（Move Method）重构手法，把方法逐步搬到合适类，并补上测试保护行为。每次移动后运行测试，确认调用方通过新接口仍能工作。配合 IDE 的安全删除与查找引用，成本可控。
当团队形成共识，新增需求过来时先画一张简单的职责草图：谁拥有数据、谁该响应消息、新逻辑属于核心还是边缘，争论会少很多。方法放置不再是个人习惯，而是可复盘的设计决策。
方法放在哪里，本质上是在回答这个类在系统中扮演什么角色。角色清晰，代码才不会长歪。
object_oriented_designmethod_placementresponsibility_assignment修改时间：2026-08-09 20:39:33