我正在尝试用继承来重构一些重复代码，正好与这本书的第二章内容产生了强烈共鸣。这一章读下来，感觉就像是给我的编程习惯做了一次“大扫除”。
1. 重复的邪恶（DRY原则）—— 一次痛苦的领悟
“不要重复你自己”（DRY原则）是本书最核心的原则之一。书上说，重复是“邪恶”的，我举双手赞同！上学期用C++写数据结构作业时，我写过两个不同的链表操作，它们都有一个几乎相同的printList函数。当时没觉得有什么，直到需求变了，输出格式要调整，我居然忘了改第二个，导致了诡异的bug。这就是无意的重复，是维护的噩梦。
2. 正交性的艺术—— 让修改局部化
“正交性”这个词听起来很数学，但书中用“消除无关事物之间的影响”来解释就非常清晰了。这和我们Java老师强调的“高内聚、低耦合”完全是一回事！
从C到C++/Java的演进： 在C语言中，数据和函数是分离的。一个数据结构变了，所有操作它的函数都可能要检查，缺乏正交性。而C++的类和Java的类将数据和对数据的操作绑定在一起，提高了内聚性。一个Student类的修改，其影响大部分被限制在类内部。
Java中的具体体现： 我们最近学的接口就是实现正交性的利器。比如，我设计了一个DataStorage接口，有save和load方法。我的业务逻辑只依赖这个接口，而不关心底层是用文件、数据库还是网络存储。这样，如果我哪天想从文件存储切换到数据库存储，我只需要写一个新的DatabaseStorage类来实现这个接口，业务逻辑代码完全不需要改动！这就是正交性带来的巨大好处——易于变化和测试。
3. 可撤销性—— 我给项目留的“后路”
“最终决策”是鸵鸟的心态，而“可撤销性”是务实的智慧。这直接影响了我的迷你图书管理系统设计。最初，我为了方便，直接把书籍数据保存在内存的ArrayList里。但想到“可撤销性”，我决定即使第一个版本不实现持久化，也要让数据存储层与业务逻辑分离。
总结与联想：
这一周，我仿佛手握DRY和正交性两把利器。以前写代码只想着“实现功能”，现在会下意识地思考“如何设计才能让未来修改时更轻松”。这就像从“盖茅草屋”转向学习“盖钢筋混凝土大厦”的思维转变。虽然一开始会多花一点设计时间，但长期来看，代码的健壮性和可维护性是指数级提升的。
