从开闭原则，讲讲初级的代码设计

从开闭原则，讲讲初级的代码设计

像所有小菜鸟一样，在看完了设计模式的6大原则以后，我以为我掌握了面向对象的绝世秘籍，迫不及待的连后面的设计模式都不愿意看了，因为我知道、书上说设计模式就是对6大原则的诠释和应用。从此~开始跌跌撞撞重构与架构之路。

=================
又是啰嗦的前景描述，着急的直接看后面的总结吧。

大概是在半年以前开始接触设计模式吧。因为被垃圾代码的维护彻底摧垮了内心，开始去思考架构设计与重构，触摸了设计模式。

我想大多数人都应该和我一样，在刚接触了设计模式，接触到了跨越式的编程思想以后，就开始了对设计模式的盲目迷信。中间也接触过一些说没有设计模式才是最好的设计模式的观点，但完全对其嗤之以鼻。好单纯~

而迷信后，就是无数的载跟头：

• 盲目的接口应用，却不能良好设计，大批量的回滚修改，进度停滞不前。

• 盲目追求更好的分层设计，集百家言，耗时良久的过细分层自己都看不下去了。

• 项目中怎么能没有设计模式？没有岂不太low了？想用却不知用在哪，进度严重拖拉。

• 不符合开闭原则，你怎么好意思敲上去?为了保证对修改关闭，冥思苦想，方案反复修改，进度严重拖拉。

在预定的完成时间到来时，看着进度早已停滞的项目，我才醒悟过来，我在做一件不可能的事！！真的是不撞南墙不会回头啊。不过这依然让我确定了一个道理：

只有经历过惨绝人寰的代码维护与重构，才能明白代码架构的重要性。

只有经历过痴心妄想的设计迷信，才能看清设计模式的本质。

很多事，一定要先做了，才能知道更多。（这才是那个道理）

于是，开始脚踏实地的参考成熟项目的分层结构，啰嗦的接口设计大面积放弃，力所能及的使用最简单的几个设计模式，先开发，之后再决定开闭原则。虽然还是会是不是陷入设计回滚的怪圈中，但最起码进度开始推进了。

恩……你想问我后来项目完成的怎么样吗？重构了一半废掉了，我换MVP架构了……（捂脸……）

跑题了，上经验总结

总结内容主要是这段失败的重构经历中，对开闭原则和代码级架构设计的理解：

• 只有经历了几十个类文件修改的痛苦，才能明白架构的重要。

• 开闭原则的对修改关闭，指得是扩展和维护中的修改，而不是开发中的修改

  开发中：从无到有的过程。
  扩展和维护：在稳定版本基础上的功能扩展和维护。

• 以开闭原则为理由妄想去在初期便设计完美，是极其荒唐的。开闭原则适用中后期的软件迭代。

  很难相信可以有人在最初就将未来设想完美，最为老道的架构师也不可能，他们也不会来给你做这个级别的代码设计！开闭原则是理想主义，只能追求，而追求这个原则的优势在中后期才能体现出来。初期的修改是无论如何无法避免的。

• 入门级的架构设计 ： 消除重复。

  当重复代码被集中时，可以最小化降低修改影响

• 空想是一件可怕的事情，做的过程中才能发现更多的问题

  虽然倡导在脑中运行程序，但脚踏实地还是更好。

• 初级的重构：2 - 4 次代码review，清除所有超过两次以上的代码段。一段代码一旦出现超过两次，你就很难保证它在将来不会出现第三次，第四次。

• 等你开始违背设计模式了，那才成长了。

  无论6大原则还是23个设计模式，都不是铁律。需求是一些解决方案的标杆。

• “懒”是软件重构的主要驱动因素之一！！！

  你应该做一个对代码有追求的“懒”程序猿。拒绝重复与耦合。

• 学会从逻辑控制转为数据控制。

  DataBinding要比一大堆的逻辑判断更容易理解与扩展。