软件测试 | 设计原则与设计模式有什么区别,如何学习?
更多技术文章分享及测试资料点此获取
设计模式与设计原则
很多人听过设计模式,这是代码编程的最佳实战,是前辈对编写代码的宝贵经验。设计模式就像高级公式,理解复杂,但动手简单,理解了原理和使用方法,即可套用在项目中。假设下面高级公式通过输入 x (面积)即可计算出水的体积 y 。这个公式比较复杂, f(x) 代表简单公式,y = f(x) + 2x + 5
理解需要花费很多精力。设计模式就像高级公式,理解 复杂但运用简单,只需输入 x (面积) 即可得到水的体积。
注意:公式纯属虚构。
而设计原则正好相反,它是设计模式的指导思想,设计原则就像基础公式,理解简单,但动手复杂。下面公式代表 y 与 x 是线性关系,因为公式太抽象,即使理解了原理,也无从下手。设计原则就像简单公式,概念简单但不知如何运用。
如果要排重要程度,个人认为:设计原则 > 设计模式 ,毕竟下层基础决定上层建筑,理解基础公式后,复杂公式可以一步步推导。这两个技能都可以指导我们写出易复用,易扩展的代码,但一般情况下,代码易复用,易扩展都是要牺牲可读性,如果一味的优化代码,会造成晦涩难懂的尴尬境地。在使用设计原则,设计模式之前,一定要避免过渡优化。所谓小赌怡情,大赌伤身。
设计原则学习方法
设计原则分为:SOLID、KISS、YAGNI、DRY、LOD 等,这些字母都是简写,后面会逐一讲解。其实设计原则概念都不难,只要认真读几次,都能看懂。但很多人学个一知半解就去实战,生搬硬套到项目中,最终把项目搞的异常复杂,比如一个简单的用户类根据接口隔离原则各种拆分,虽然提高了可扩展性,但可读性大大降低,相当于你去买菜,本来小推车就可以满足需求,非要研究战斗机。
学习设计原则要多思考少动手,看到一段代码要考虑是否职责过多,使用继承时要考虑确认是否违背迪米特法则,但不要立刻动手,因为代码好与坏非常难衡量。就像书法,有人觉得美妙,有人觉得丑到爆,这就需要持之以恒的思考才能维持这个度。如果你刚学设计原则,避免不了生搬硬套,我刚学的时候也会这样做,但我会思考很久才下手,主要原因有三个:
- 一是因为避免频繁修改代码引来的 bug 。
- 二是因为腐旧代码会依赖非常多的类,冒然修改牵一发而动全身。
- 三是因为第一想法通常不是最好方案,最好方案要经过反复揣摩。
所以我建议初学者要反复思考再下手,思考设计原则就像咀嚼牛皮筋,需要反复咬,如果咬少了,东西不烂不好下咽,如果咬多了,腮帮子又疼。这是个非常有趣的过程,痛并快乐着。
设计模式学习方法
常见的设计模式有 23 种,这里就不列举了。前面讲过,设计模式是编程最佳实战,是大家反复思考+实战,得出比较合适的编程方法。很多人存在错觉,设计模式只支持完美的面向对象编程语言(比如 java ,c++),在其它语言上不能实现,比如在 python 这种对多态,抽象类和接口类支持不好的语言上,就不能实现设计模式。
这句话其实不对, java 语言使用群体较多,语言的历史久远,其教材也就多,但 python 也可以实现设计模式,我在后续的内容会展示 python 的实现方式。其实设计模式的很多方法都可以方便的与面向对象相特性结合,比如利用接口实现工厂类,使用类控制单一实例等等,不得不感叹面向对象语言的优美,但不能完美支持面向对象的语言也可以用设计模式,最初发明设计模式就是无关语言的,这也是它经久不衰的原因。
由于设计模式概念复杂,学习时要先主后深,即先掌握所设计模式每个方法的概念和使用场景后,再深入研究每个设计模式。深入学习后你会发现,在代码层面上,每个模式非常像,很难区分一段代码运用了工厂模式还是策略模式,是桥接模式还是代理模式。只有结合了业务,明白了场景,才会恍然大悟。
所以学习设计模式,可以先搞清概念和使用场景,再深入研究。我开始学习时,一头扎入各种模式不能自拔,想了很久都不明白职责链模式和观察者模式有啥区别,但结合项目后才恍然大悟,原来两个模式的代码本来就差不多,根本没必要纠结代码,理解场景才最重要的。
总结
本篇文章介绍了设计原则和设计模式,讲了学习过程的误区。
- 设计原则:理解复杂,但动手简单,学习时要多思考少动手。
- 设计模式:理解复杂,但动手简单,学习时要先主后深。
设计原则和设计模式用于优化代码,一般情况下,代码易复用,易扩展都是要牺牲可读性,如果一味的优化代码,会造成晦涩难懂的尴尬境地。在使用设计原则,设计模式之前,一定要避免过渡优化。