共 3 篇相关文章
这篇讲的是Java面向对象编程中类与对象的核心机制。作者从Object类的方法重写说起，强调了继承中`hashCode`与`equals`必须协同重写的规范，并用`toString`的重写来解释如何让对象打印变得友好。 文章的重点在于辨析继承与接口这两种实现代码复用的方式。通过一个“小明的妈妈”既需要继承`Person`类又能烹饪的例子，作者生动地引出了`extends`单继承与`implements`多实现的语法区别与设计思路，这比单纯罗列语法要直观得多。 此外，内容还系统梳理了四种访问修饰符（`private`到`public`）的权限范围，这常常是初学者容易混淆的地方。文章并未止步于此，而是进一步延伸到了反射、抽象类和枚举`enum`这些进阶主题，特别是通过反射操作`Materfamilias`类的代码示例，让“类本身也是对象”这一抽象概念变得可感。 整体而言，这不仅仅是一章语法罗列，而是围绕“类”这个核心，将继承、多态、封装以及动态特性串联起来，构建了一个完整的认知框架。
这篇讲的是面向对象编程（OOP）可能被误解和滥用的问题。作者从一个打印操作系统信息的简单需求出发，展示了代码从最直接的“黑客方案”（一堆if-else），演进到过程化重构，再到“幼稚的”OOP（引入工厂模式），最后到“OO大师”的复杂方案（结合工厂、单例、注册表等模式）的全过程。 核心对比在于，最初的简单代码虽然直白，但随着需求增加会变得臃肿。而为了追求所谓的“消除逻辑分支”和“设计模式”，代码变得异常复杂，引入了大量接口和类。文章通过Rob Pike的评论犀利地指出，这种面向对象编程可能已经走进了死胡同——为了解决简单问题而构建了更复杂的系统。 这篇文章并非简单否定OOP，而是通过一个具体的代码演进实例，生动揭示了过度设计和模式滥用的现象。它提醒开发者，在选择编程范式和设计模式时，应警惕为了“纯粹”或“优雅”而牺牲代码的清晰性与简单性。最终，解决问题的“恰当”方式，往往比遵循某种固定的“高级”模式更重要。
这篇讲的是C#语言里一个长期存在的“遗憾设计”：当我们试图在一个类中显式实现接口定义的事件时，编译器会强制要求我们手动提供add和remove访问器的完整实现。 这打破了C#事件最常用的、便捷的`event`自动实现模式。作者从自己多年的编码体验出发，指出这种限制虽然无伤大雅，却显得多余，因为它并没有带来任何实质性的安全或功能增益，反而徒增了繁琐的样板代码。这种“细枝末节”的设计决策，也侧面反映了语言在演进过程中，某些早期设定可能成为后续难以改变的“路径依赖”。
