昆明建设工程质量备案在哪个网站,出口跨境电商有哪些平台,常见的管理信息系统有哪些,官网网站系统1、面向对象的SOLID
1.1 概述 SOLID是5个设计原则开头字母的缩写#xff0c;其本身就有“稳定的”的意思#xff0c;寓意是“遵从SOLID原则可以建立稳定、灵活、健壮的系统”。5个原则分别如下#xff1a;
Single Responsibility Principle#xff08;SRP#xff09;其本身就有“稳定的”的意思寓意是“遵从SOLID原则可以建立稳定、灵活、健壮的系统”。5个原则分别如下
Single Responsibility PrincipleSRP单一职责原则。 一个类只做一件事并把这件事做好其只有一个引起它变化的原因。Open Close PrincipleOCP开闭原则。Liskov Substitution PrincipleLSP里氏替换原则。Interface Segregation PrincipleISP接口隔离原则。Dependency Inversion PrincipleDIP依赖倒置原则。 SOLID最早由Robert C. Martin在2000年的论文“Design Principles and Design Patterns”中引入。在2004年前后Michael Feathers提醒Martin可以调整一下这些原则的顺序那么它们的首字母的缩写就可以排列成SOLID。这个新名字的确促进了SOLID思想的传播再一次证明了命名 的重要性。
1.2 关系 SOLID原则之间并不是相互孤立的彼此间存在着一定关联一个原则可以是另一个原则的加强或基础违反其中的某一个原则可能同时违反了其他原则。
设计目标开闭原则和里氏代换原则。设计方法单一职责原则、接口分隔原则和依赖倒置原则。 1.3 职责单一原则SRP-Single Responsibility Principle 任何一个软件模块中应该有且只有一个被修改的原因。 SRP要求每个软件模块职责要单一衡量标准是模块是否只有一个被修改的原因。职责越单一被修改的原因就越少模块的内聚性Cohesion就越高被复用的可能性就越大也更容易被理解。
示例
非SRP 例如有一个Rectangle类如图1-1所示该类包含两个方法一个方法用于把矩形绘制在屏幕上另一个方法用于计算矩形的面积。 1-1 按照SRP的定义Rectangle类是违反了SRP原则的。因为Rectangle类具有至少两个职责不管是改变绘制逻辑还是面积计算逻辑都要改动Rectangle类。
SRP-贫血 为了遵从SRP原则我们需要把两个职责分离出来放在两个不同的类中这样就可以互相不影响了。最简单的解决方案是将数据与函数分离如图1-2所示。设计两个用来做逻辑处理的类每个类只包含与之相关的函数代码互相不可见这样就不存在互相依赖的情况了。 1-2
SRP-充血 1-2的方式有点“贫血”模式的味道。我们也可以采用面向对象的做法把重要的业务逻辑与数据放在一起然后用Rectangle类来调用其他没那么重要的函数如图1-3所示。 1-3 另外SRP不仅在模块和类级别适用在函数级别同样适用。
函数单一职责 下面是一个给员工发工资的简单方法
public void pay(ListEmployee employees){for (Employee e: employees){if(e.isPayDay()){Money pay e.calculatePay();e.deliverPay(pay);}}
}
做了3件事情
遍历所有雇员检查是否该发工资支付薪水。
按照SRP的原则以下面的方式改写更好
//遍历所有雇员
public void pay(ListEmployee employees) {for (Employee e : employees) {payIfNecessary(e);}
}//检查是否该发工资
private void payIfNecessary(Employee e) {if (e.isPayDay()) {calculateAndDeliverPay(e);}
}// 支付薪水
private void calculateAndDeliverPay(Employee e) {Money pay e.calculatePay();e.deliverPay(pay);
} 虽然原来的方法并不复杂但按照SRP分解后的代码显然更加容易让人读懂这种拆分是有积极意义的。基本上遵循SRP的函数都不会太长再配上合理的命名就不难得到我们想要的短小的函数。
1.4 开闭原则(OCP-Open Close Principle) 其核心的思想是模块是可扩展的而不可修改的。也就是说对扩展是开放的而对修改是封闭的。
对扩展开放意味着有新的需求或变化时可以对现有代码进行扩展以适应新的情况。对修改封闭意味着类一旦设计完成就可以独立完成其工作而不要对类进行任何修改。这样可以保证稳定性和延续性。 OCP 建议我们应该对系统进行重构那么以后再进行同样改动只需添加新代码而不必改动已正常运行的代码。 在很多方面OCP 都是面向对象设计的核心所在可增强灵活性、可重用性、可维护性等。 OCP 的关键是抽象其背后的主要机制是抽象和多态。模块应该依赖于一个固定的抽象体因此它对于更改可以是关闭的同时通过从这个抽象体派生也可以扩展此模块的行为。 实际上很多的设计模式都以达到OCP目标为目的。例如装饰者模式可以在不改变被装饰对象的情况下通过包装Wrap一个新类来扩展功能策略模式通过制定一个策略接口让不同的策略实现成为可能适配器模式在不改变原有类的基础上让其适配Adapt新的功能观察者模式可以灵活地添加或删除观察者Listener来扩展系统的功能。
注意 当然要想做到绝对地“不修改”是比较理想主义的。因为业务是不确定的没有谁可以预测到所有的扩展点因此这里需要一定的权衡如果提前做过多的“大设计”可能会犯YAGNIYou Ain’t Gonna NeedIt的错误。
1.5 里氏替换原则LSP-Liskov Substitution Principle 软件工程大师罗伯特·马丁Robert C. Martin把里氏代换原则最终简化为一句话“Subtypes must be substitutable for their base types”。也就是子类必须能够替换成它们的基类。即子类应该可以替换任何基类能够出现的地方并且经过替换以后代码还能正常工作。 另外不应该在代码中出现 if/else 之类对子类类型进行判断的条件。里氏替换原则 LSP 是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。 注意 一般而言无论模块是多么的“封闭“都会存在一些无法对之封闭的变化没有对于所有的情况都贴切的模型。所以必须有策略地对待这个问题。 设计人员必须对他所设计的模块应该对哪种变化封闭做出选择必须先猜测出最有可能发生的变化种类然后构造抽象来隔离那些变化。但大多数情况猜测都是错误的。后续即使不使用这些抽象也必须去支持和维护它们这不是一件好事所以通常我们会一直等到确实需要那些抽象时再去进行抽象。 1.6 接口隔离原则ISP-Interface Segregation Principle 不能强迫用户去依赖那些他们不使用的接口。换句话说就是使用多个专门的接口比使用单一的总接口要好。 举个例子我们对电脑有不同的使用方式比如写作、通讯、看电影、打游戏、上网、编程、计算和数据存储等。如果我们把这些功能都声明在电脑的抽象类里面那么我们的上网本、PC 机、服务器和笔记本的实现类都要实现所有的这些接口这就显得太复杂了。所以我们可以把这些功能接口隔离开来如工作学习接口、编程开发接口、上网娱乐接口、计算和数据服务接口这样我们的不同功能的电脑就可以有所选择地继承这些接口。 同时小接口更容易实现提升了灵活性和重用的可能性。由于很少的类共享这些接口相应接口的变化而需要变化的类数量就会降低增加了鲁棒性。
1.7 依赖倒置原则DIS-Dependency Inversion Principle 高层模块不应该依赖于底层模块高层与低层是相对而言也就是调用者与被调用者的关系二者都应该依赖于抽象。抽象不应该依赖于细节细节应该依赖于抽象。 举个例子墙面的开关不应该依赖于电灯的开关实现而是应该依赖于一个抽象的开关的标准接口。 这样当我们扩展程序的时候开关同样可以控制其它不同的灯甚至不同的电器。也就是说电灯和其它电器继承并实现我们的标准开关接口而开关厂商就可以不需要关于其要控制什么样的设备只需要关心那个标准的开关标准。这就是依赖倒置原则。
2、其他
2.1 DRY 原则Don’t Repeat Yourself DRY原则可理解为不要写重复的代码。简单来讲写代码的时候如果出现雷同片段就要想办法把他们提取出来成为一段独立的代码。 DRY 是一个最简单的法则也是最容易被理解的但它也可能是最难被应用的因为要做到这样我们需要在泛型设计上做相当的努力这并不是一件容易的事。它意味着当在两个或多个地方发现一些相似代码的时候我们需要把它们的共性抽象出来形成一个唯一的新方法并且改变现有地方的代码让它们以一些合适的参数调用这个新的方法。 代码重复有三种典型情况
实现逻辑重复 重复的代码被敲了两遍或者简单复制粘贴一下代码。功能语义重复 功能重复。代码可能不同但是实现的功能是相同的。 例如两个同事写的同一个工具方法。代码执行重复。 例如多个地方对同样的参数做参数校验。
2.2 YAGNI原则You Ain’t Gonna Need It 你是否有个这样的经历臆想某个功能以后可能会用到然后就顺手把它实现了实际到了后面并没用上反而造成了代码冗余。 这个原则只考虑和设计必须的功能避免过度设计。只实现目前需要的功能在以后你需要更多功能时可以再进行添加。如无必要勿增复杂性。软件开发是一场 取舍trade-off的博弈。 因此我们不能闭门臆想需要的功能但是在架构上又要洞察趋势。
2.3 Rule of Three Rule of Three也被称为“三次原则”是指当某个功能第三次出现时就有必要进行“抽象化”了。这也是软件大师Martin Fowler在《重构》一书中提出的思想。 三次原则指导我们可以通过以下步骤来写代码。
第一次用到某个功能时写一个特定的解决方法。第二次又用到的时候复制上一次的代码。第三次出现的时候才着手“抽象化”写出通用的解决方法。 这3个步骤是对DRY原则和YAGNI原则的折中是代码冗余和开发成本的平衡点。同时也提醒我们反思是否做了很多无用的超前设计、代码是否开始出现冗余、是否要重新设计。软件设计本身就是一个平衡的艺术我们既反对过度设计Over Design也绝对不赞成无设计No Design。
2.4 KISS 原则Keep It Simple, Stupid 保持每件事情都尽可能的简单用最简单的解决方案来解决问题。 KISS 原则在设计上可能最被推崇在家装设计、界面设计和操作设计上复杂的东西越来越被众人所鄙视了而简单的东西越来越被人所认可。
宜家简约、高效的家居设计和生产思路微软“所见即所得”的理念谷歌简约、直接的商业风格无一例外地遵循了“KISS”原则。而苹果公司的 iPhone 和 iPad 将这个原则实践到了极至。 也正是“KISS”原则成就了这些看似神奇的商业经典。
2.5 好莱坞原则Hollywood Principle 好莱坞原则就是一句话“don’t call us, we’ll call you.”。意思是好莱坞的经纪人不希望你去联系他们而是他们会在需要的时候来联系你。也就是说所有的组件都是被动的所有的组件初始化和调用都由容器负责。 简单来讲就是由容器控制程序之间的关系而非传统实现中由程序代码直接操控。 这也就是所谓“控制反转”的概念所在
不创建对象而是描述创建对象的方式。在代码中对象与服务没有直接联系而是容器负责将这些联系在一起。控制权由应用代码中转到了外部容器控制权的转移是所谓反转。 好莱坞原则就是IoCInversion of Control 或DIDependency Injection]的基础原则。
3、总结
原则是指导我们写出更好的代码但不要教条任何东西都是适用场景的。原则不是目的实现业务逻辑才是目的不要本末倒置。原则是降低复杂度不是增加复杂度。
