做网站开发这行，我算是老骨头了。这十五年来，见过太多新手程序员，一上来就喜欢在一个类里直接 new 另一个类的对象。看着代码跑通了，心里美滋滋，觉得挺牛。结果呢？项目稍微大一点，维护起来简直是一场噩梦。今天咱们不聊虚的，就聊聊“一个类引用另一个类的方法”到底该怎么搞，才能让你少加几天班，多活几年。

很多新人觉得，我在 A 类里想调用 B 类的方法，直接 new B() 不就完了吗？简单，粗暴，有效。确实，对于那种只有几行代码的小脚本，这么干没问题。但如果你是在做一个正经的企业级项目，或者一个稍微复杂点的网站后台，这种做法简直就是埋雷。

为啥？因为耦合度太高了。

什么叫耦合？就是 A 类死死地绑在 B 类上。如果 B 类改了名字，或者 B 类的构造函数变了，A 类也得跟着改。要是 B 类出了 bug，A 类也跟着报错。这种代码，就像是用502胶水把两块砖粘在一起，你想拆开看里面啥样，得把砖都砸碎。

我见过一个客户，找我来救火。他的网站后台，订单模块直接 new 了支付模块，支付模块又 new 了短信模块。后来短信服务商换了接口，参数变了。结果呢？整个订单系统全崩了。修这个 bug 花了三天，因为根本不知道哪里引用了哪里。这就是典型的“一个类引用另一个类的方法”没处理好，导致牵一发而动全身。

那正确姿势是啥？

第一，用接口。

别直接引用具体类，要引用接口。比如，定义一个 IPayment 接口，让 PayPal 和 Alipay 都去实现它。在订单类里，我只需要依赖 IPayment 接口。这样，不管底层换什么支付渠道，订单类都不用动。这就是所谓的“依赖倒置原则”。听起来高大上，其实道理很简单：你要的是“能付款”这个功能，而不是非要“支付宝”这个具体实现。

第二，依赖注入。

这是解决“一个类引用另一个类的方法”最优雅的方式。别在类里面 new 对象，而是通过构造函数或者 Setter 方法，把对象传进去。

举个例子：

`java

public class OrderService {

private IPayment payment;

// 通过构造函数注入

public OrderService(IPayment payment) {

this.payment = payment;

}

public void createOrder() {

// 调用引用类的方法

payment.process();

}

}

`

这么写，OrderService 根本不知道 payment 具体是谁，它只关心对方有没有 process 这个方法。测试的时候，你可以随便传一个假的 MockPayment 进去，不用真连数据库，不用真调接口，测试起来飞快。

第三，别怕麻烦。

我知道，很多人觉得写接口、搞注入太麻烦了，代码量变多了。但你要算笔账。前期多写两行代码，后期维护省下的时间，足够你喝好几杯星巴克了。特别是当你的团队有五六个人一起开发的时候，这种解耦的方式，能减少至少 50% 的沟通成本和冲突。

我见过太多人，为了赶工期，代码写得像一坨浆糊。上线第一天风风光光，第二天半夜电话被打爆。那种焦虑感，谁懂？

所以，记住我的话。在处理“一个类引用另一个类的方法”时，永远优先考虑解耦。用接口，用注入，别偷懒。这不仅是为了代码好看，更是为了你的职业生涯稳定。

最后说句掏心窝子的话，编程这东西，就像做饭。新手喜欢把菜全扔进一个锅里乱炖，看着热闹，吃着难受。高手都是讲究火候，讲究搭配，讲究食材之间的独立性。你的代码，就是你的作品。别让它变成一堆烂泥。

如果你还在用 new 到处乱建对象，赶紧停下来。试试依赖注入，你会发现新世界的大门打开了。虽然刚开始有点不适应，但一旦习惯了，你就再也回不去了。

别等出了线上事故，才想起来找我救火。那时候，我的出场费可是很贵的。