购物网站建设方案书,福州最好的网站建设,北京工程信息交易网,wordpress 站长主题一、前言不知道大家是否有这样的体会#xff0c;就是在学习设计模式的时候#xff0c;看了很多书籍#xff0c;也照着很多示例把每个模式挨个敲了几遍#xff0c;但过了一段时间后#xff0c;就会忘了一大半。或者有的朋友尝试在业务编码中使用#xff0c;却越用越复杂就是在学习设计模式的时候看了很多书籍也照着很多示例把每个模式挨个敲了几遍但过了一段时间后就会忘了一大半。或者有的朋友尝试在业务编码中使用却越用越复杂本来一个类几个方法能搞定的业务套用模式后会多出好多接口和类所以用着用着就放弃了。我说的比较直接点很多教材或博客中使用Animal、Fruit、Car这些例子来教设计模式初衷是好的但真没多大用甚至会误人子弟。最近笔者再次学习了设计模式不知道是这些年的第多少次了突然有了些感悟。我尽量用最简单通俗的语言描述出我想表达的有的观点可能比较偏激或不太适合所有人但如果大家能从这篇文章中GET到一两个点那也值了哈哈。 下面我先以我个人的想法简单粗暴地理解一下设计模式的六大原则。Show Time!二、六大原则2.1、单一职责原则官方解释单一职责原则SRPSingle responsibility principle又称单一功能原则面向对象五个基本原则SOLID之一。它规定一个类应该只有一个发生变化的原因。大白话一个类只有一个发生变化的原因我只能说在业务编码中不太可能或很维做到。其实大家不必纠结于有几个让类发生变化的原因。个人建议你想实践单一职责原则最好先养成良好的编码规范如果你平时写代码一个类里不管什么业务方法都往里塞一个方法里嵌套着各种判断再好的原则也帮不也你。实践和类名不相关的业务不要放在这个类里和方法名不相关的代码请拆成单独的子方法。还有当你在定义一个接口、类或方法的时候从业务的角度用心地多想一下这段代码放这里真的合适吗2.2、里氏替换原则官方解释里氏替换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏替换原则中说任何基类可以出现的地方子类一定可以出现。LSP是继承复用的基石只有当衍生类可以替换掉基类软件单位的功能不受到影响时基类才能真正被复用而衍生类也能够在基类的基础上增加新的行为。大白话这个原则其实还是很好理解的主要是约束子类的行为要求其行为和基类保持一致如果替换为子类后程序运行不正常则说明子类没有按基类的预期实现业务或者说子类不适合继承这个基类对不起请找适合的基类继承。实践如果子类从一个基类继承后实现基类定义的虚方法时感觉很别扭痛苦的时候请考虑一下是否一定要从这个基类继承。2.3、依赖倒置原则官方解释依赖倒置原则Dependence Inversion Principle是程序要依赖于抽象接口不要依赖于具体实现。简单的说就是要求对抽象进行编程不要对实现进行编程这样就降低了客户与实现模块间的耦合。大白话多用接口和抽象类少用实现类工具类除外。大家看框架源码的时候应该能感觉到大神在实现框架的时候到处都是接口或抽象类而自己的代码却是一大片的实现类其实直接用实现类是没有问题的。架构方法中有一句叫可扩展性其实接口和抽象类就是实现可扩展性的基石。当需要扩展原有逻辑的时候别人用接口和抽象类的直接加个新子类继承下你用实现类的到处一大片一大片的改请回答我有没有实践写代码的时候多考虑扩展性如果这段代码以后扩展或变化的可能性很高请用接口或抽象类封装下抽象出不变的接口将变化的部分留给不同的实现类。2.4、接口隔离原则官方解释接口隔离原则Interface Segregation Principle,使用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的。大白话这个原则和单一职责原则有点象好吧其实很难区分的。主要区分点在“职责”和“隔离”两个词上。职责要求按类的功能单一性定义接口、类、方法。隔离要求最细化的定义接口尽量避免大而全的接口不然接口一改所以的实现类一片报红请回答我有没有实践情愿让类实现多个单一接口也不要实现一个大而全的接口。2.5、迪米特原则官方解释迪米特法则Law of Demeter又叫作最少知识原则Least Knowledge Principle 简写LKP一个类对于其他类知道的越少越好就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信不和陌生人说话。 大白话电视剧经常有这个台词“你知道的太多了”然后一枪被崩了。这个原则也是这个道理就是一个类尽量减少和其他类组合这样能减少类之间的耦合如果实现要关联可以通过第三者朋友。门面模式和中介者模式就是这个原则的体现。实践一个类里尽量减少与太多的类接触如果不可避免可以用一个中介类代替。2.6、开闭原则官方解释在面向对象编程领域中开闭原则规定“软件中的对象类模块函数等等应该对于扩展是开放的但是对于修改是封闭的”这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的在这种环境中改变源代码需要代码审查单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变因此无需上述的过程。大白话其实这个原则实操性不强。如果这个原则是思想的话上面的五个原则就是这个思想的实践如果我们代码真的能做到职责单一、面向抽象编程且清爽的编码规范则会很容易实现开闭原则。但现实情况是我们的代码模块与模块类与类高度耦合、很难见到接口或抽象类、甚至全是面向过程编码。所以在实际业务中我们改一点代码都要涉及很多项目、类、方法。改完很自信地说我改动不大不会影响线上业务的不用测试直接上线。请回答我有没有实践尽量避免修改原有的代码一点不改也不太可能前期编码的时候留好扩展点使用继承增加新子类的方式修改原有业务。三、总结在学习设计原则和模式的时候请先保证自己写出的代码是整洁且符合规范的不然再好的原则和模式也拯救不了你那一大坨一大坨的类和方法最起码的读你写的某一个方法的时候不用拖滚动条。真正的理解你所在公司的业务和需求先在产品和文档级别上简化业务、理清编码的思路这样更准确地找出业务的变化点和扩展点。设计模式其实就是封装变化所以编码的时候多用心变化点有变化了就考虑抽象出接口或抽象类。当然在实际业务中多是增删改查如果一昧的到处定义接口也会增加复杂度这些可以自己权衡或按团队的编码规范实施。不要刻意地去背这些模式或者照着敲几遍没用的实际业务编码中发现业务变化或扩展点后再去找适合的模式。
