从开闭原则,讲讲初级的代码设计
像所有小菜鸟一样,在看完了设计模式的6大原则以后,我以为我掌握了面向对象的绝世秘籍,迫不及待的连后面的设计模式都不愿意看了,因为我知道、书上说设计模式就是对6大原则的诠释和应用。从此~开始跌跌撞撞重构与架构之路。
=================
又是啰嗦的前景描述,着急的直接看后面的总结吧。
大概是在半年以前开始接触设计模式吧。因为被垃圾代码的维护彻底摧垮了内心,开始去思考架构设计与重构,触摸了设计模式。
我想大多数人都应该和我一样,在刚接触了设计模式,接触到了跨越式的编程思想以后,就开始了对设计模式的盲目迷信。中间也接触过一些说没有设计模式才是最好的设计模式的观点,但完全对其嗤之以鼻。好单纯~
而迷信后,就是无数的载跟头:
盲目的接口应用,却不能良好设计,大批量的回滚修改,进度停滞不前。
盲目追求更好的分层设计,集百家言,耗时良久的过细分层自己都看不下去了。
项目中怎么能没有设计模式?没有岂不太low了?想用却不知用在哪,进度严重拖拉。
不符合开闭原则,你怎么好意思敲上去?为了保证对修改关闭,冥思苦想,方案反复修改,进度严重拖拉。
在预定的完成时间到来时,看着进度早已停滞的项目,我才醒悟过来,我在做一件不可能的事!!真的是不撞南墙不会回头啊。不过这依然让我确定了一个道理:
只有经历过惨绝人寰的代码维护与重构,才能明白代码架构的重要性。
只有经历过痴心妄想的设计迷信,才能看清设计模式的本质。
很多事,一定要先做了,才能知道更多。(这才是那个道理)
于是,开始脚踏实地的参考成熟项目的分层结构,啰嗦的接口设计大面积放弃,力所能及的使用最简单的几个设计模式,先开发,之后再决定开闭原则。虽然还是会是不是陷入设计回滚的怪圈中,但最起码进度开始推进了。
恩……你想问我后来项目完成的怎么样吗?重构了一半废掉了,我换MVP架构了……(捂脸……)
跑题了,上经验总结
总结内容主要是这段失败的重构经历中,对开闭原则和代码级架构设计的理解:
只有经历了几十个类文件修改的痛苦,才能明白架构的重要。
开闭原则的对修改关闭,指得是扩展和维护中的修改,而不是开发中的修改
开发中:从无到有的过程。
扩展和维护:在稳定版本基础上的功能扩展和维护。以开闭原则为理由妄想去在初期便设计完美,是极其荒唐的。开闭原则适用中后期的软件迭代。
很难相信可以有人在最初就将未来设想完美,最为老道的架构师也不可能,他们也不会来给你做这个级别的代码设计!开闭原则是理想主义,只能追求,而追求这个原则的优势在中后期才能体现出来。初期的修改是无论如何无法避免的。
入门级的架构设计 : 消除重复。
当重复代码被集中时,可以最小化降低修改影响
空想是一件可怕的事情,做的过程中才能发现更多的问题
虽然倡导在脑中运行程序,但脚踏实地还是更好。
初级的重构:2 - 4 次代码review,清除所有超过两次以上的代码段。一段代码一旦出现超过两次,你就很难保证它在将来不会出现第三次,第四次。
等你开始违背设计模式了,那才成长了。
无论6大原则还是23个设计模式,都不是铁律。需求是一些解决方案的标杆。
“懒”是软件重构的主要驱动因素之一!!!
你应该做一个对代码有追求的“懒”程序猿。拒绝重复与耦合。
学会从逻辑控制转为数据控制。
DataBinding要比一大堆的逻辑判断更容易理解与扩展。