依赖注入疑问：为何不采用Getter传递数据实现解耦？

你提到的Getter方案确实能实现一定程度的解耦，但依赖注入的价值在于更彻底的职责划分、封装性和代码内聚性，咱们从几个实际场景拆解：

1. 职责单一与内聚性 #

Product的核心职责是管理产品的属性（名称、价格）和自身行为（比如打印自身信息）。依赖注入的方式下，Product.print()是一个完整的行为——它自己决定要把哪些数据传给Printer，用户只需要调用prod.print()就能完成打印，逻辑内聚在Product内部。

如果用Getter方案，你得在外部写：

data = prod.get_data()
printer.print(data)

这相当于把Product的打印行为拆到了外部代码里，外部必须同时知道Product的内部数据结构和Printer的用法，反而增加了耦合点。万一Product后来加了库存字段，需要打印库存，依赖注入只需要修改Product里的tab=[self.name, self.price, self.stock]；而Getter方案要修改所有调用get_data()的外部代码，把库存加进去，维护成本陡增。

2. 封装性：不暴露内部细节 #

依赖注入时，Product不需要把自己的内部属性暴露给外部——它只需要把Printer需要的数据组装好传过去，至于内部有哪些字段，外部完全不用关心。

但Getter方案必须暴露get_name()、get_price()或者get_data()，等于把Product的内部结构公开了。如果后续Product的属性名改了（比如把price改成unit_price），所有依赖Getter的外部代码都要跟着改，这就破坏了封装原则。

3. 可测试性 #

依赖注入的方式下，测试Product的打印逻辑非常简单：你可以注入一个MockPrinter，验证它是否收到了正确的数据：

class MockPrinter(Printer):
    def __init__(self):
        self.received_data = None
    def print(self, data):
        self.received_data = data

def test_product_print():
    mock_printer = MockPrinter()
    prod = Product("prod1", "22", mock_printer)
    prod.print()
    assert mock_printer.received_data == ["prod1", "22"]

而Getter方案的测试，你得先验证get_data()返回的内容，再验证外部代码是否正确调用了Printer，测试范围被扩大到了外部逻辑，无法单独测试Product的打印行为。

4. 代码简洁性与易用性 #

对调用方来说，依赖注入的方式更直观：创建Printer，传给Product，调用prod.print()就完事了。而Getter方案需要调用方额外处理数据传递，代码更繁琐，也更容易出错——比如调用方可能漏传某个字段，或者组装数据的格式不符合Printer的要求。

总结来说，Getter方案只是把Product和Printer的耦合转移到了外部，并没有真正实现“完全解耦”；而依赖注入是基于抽象（Printer基类）的耦合，既保留了Product的封装性和内聚性，又能灵活替换Printer实现，这才是它的核心意义。

内容的提问来源于stack exchange，提问作者andrew