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