共 2 篇相关文章
这篇讲的是面向对象编程（OOP）可能被误解和滥用的问题。作者从一个打印操作系统信息的简单需求出发，展示了代码从最直接的“黑客方案”（一堆if-else），演进到过程化重构，再到“幼稚的”OOP（引入工厂模式），最后到“OO大师”的复杂方案（结合工厂、单例、注册表等模式）的全过程。 核心对比在于，最初的简单代码虽然直白，但随着需求增加会变得臃肿。而为了追求所谓的“消除逻辑分支”和“设计模式”，代码变得异常复杂，引入了大量接口和类。文章通过Rob Pike的评论犀利地指出，这种面向对象编程可能已经走进了死胡同——为了解决简单问题而构建了更复杂的系统。 这篇文章并非简单否定OOP，而是通过一个具体的代码演进实例，生动揭示了过度设计和模式滥用的现象。它提醒开发者，在选择编程范式和设计模式时，应警惕为了“纯粹”或“优雅”而牺牲代码的清晰性与简单性。最终，解决问题的“恰当”方式，往往比遵循某种固定的“高级”模式更重要。
这篇文章探讨的是面向对象设计中一个经典的选择困境：扩展类的功能时，应该优先使用组合还是继承？ 作者从设计模式为何有效的根本问题出发，将模式作为生动的案例，来阐释“多用组合、少用继承”这条重要原则。文章的核心观点是，继承看似直接，实则暗藏多个风险：它会强制子类接受父类所有公开和受保护的方法，可能引入无用甚至冲突的功能；容易导致类体系的无限膨胀；并且在编译期就固定了类型关系，缺乏运行时灵活性。 文中通过一个具体而有趣的例子来印证这些观点：我们需要一个既能像HashMap那样通过key取值，又能像ArrayList那样按顺序取值的“ListMap”。作者首先展示了一个继承自HashMap的实现，它虽然简单，但朋友使用时因未重写`values()`方法而得到了混乱的顺序，直接暴露了继承“全盘接受”的危害。随后，文章给出了一个基于组合（内部持有HashMap和ArrayList）的改写方案，它更安全、更可控，只暴露必要的方法。 最后，文章引入了Adapter模式和Decorator模式作为例证，展示了组合如何优雅地解决多重继承限制和类爆炸问题，尤其是Decorator模式通过对象组合动态添加职责，其设计思路令人叫绝。整篇文章通过从问题到代码实践，再到模式印证的清晰脉络，让“优先组合”这一原则变得具体可感。
