借鉴:
1. 单一职责原则
单一职责原则 (Single Responsibility Principle,SRP) 指出,每个方法或类应当有且仅有
一个改变的理由。这意味着每个方法或类应当做一件事情,或者只有一项职责。在所有的
SOLID 原则中,这是大多数开发人员感到最能完全理解的一条。严格来说,这也可能是违
反最频繁的一条原则了。
 
2. 开放/ 封闭原则
开放/封闭原则(Open/Close Principle,OCP)是指软件(方法、类等)应当开放扩充且关闭
修改。如果觉得它非常类似于继承的OOP 原则,那就对了。它们之间的关系非常密切。事
实上,在 .NET 中OCP 就是依赖于继承的。
OCP 的要点在于:作为开发人员,别人偶尔会向我们提供基类,偶尔也会为其他开发人
员生成基类框架,供其使用。这些使用者应当仅能使用这些基类,但不能对其进行修改。
这一点是必要的,因为其他使用者也可能依赖于由基类提供的功能。如果允许使用者修改
这些基类,可能会导致连锁反应,不仅会影响到应用程序中的各方面,还会影响到企业内
的应用程序。还有一个问题,使用者有时可能会收到基类的升级版本。使用者在升级之前,
必须找出一种方法用来处理其对该基类先前版本中所做的自定义。
于是,问题变为:“那么,如果我需要修改这个基类的工作方式,那应当怎么做呢?”
OCP 的另一部分中给出这一答案;基类应当开放,可进行扩充。在这里,扩充是指创建一
个由此基类继承而来的派生类,它可以扩充或重载基类功能,以提供使用者所需要的特定
功能。这样,使用者就能使用类的修改版本,而不会影响到类的其他使用者。使用者还可
以在将来更轻松地使用基类的升级版本,因为他们不用担心丢失自己的修改内容。
 
3. 里氏替换原则
继承对于OCP,就相当于多态性对于里氏替换原则(Liskov Substitution Principle,LSP)。
LSP 规定:用超类代替应用程序中使用的对象时,应当不会破坏应用程序。这通常也被称
为“契约式设计(design by contract)”。
回想前面的多态性示例,ComputePay 方法使用了Employee 类型的列表,其中Employee
就是基类型(超类型)。Salary、Hourly 和Seasonal 类都是从Employee 继承而来,因此它们
是Employee 的子类型。
根据LSP,即使已经将列表声明为Employee 的列表,也仍然可以用Salary、Hourly
和Seasonal 的具体实例来填充它。因为有了继承,它们都支持Employee 声明的相同契约(公
共的方法集或API)。应用程序可以对该列表进行迭代,并调用那些在列表中各个项目的
Employee 上定义的方法,不需要知道或特别关心它们都是什么类型。如果它们支持契约,
该调用就是合法的。
 
4. 接口分离原则
到目前为止,已经在示例中使用了基于类的继承,但还没有过多地讨论接口。回想一
下,接口就是在代码中定义的契约,而类同意实现这一契约。这份协议要求类来为接口中
定义的所有方法提供实现。至于如何实现方法,则由这个类来决定,只要它遵守契约,支
持接口中的定义即可。接口是.NET 中功能非常强大的功能;它们对继承和多态的支持方式
与类相同。
接口分离原则(Interface Segregation Principle,ISP)规定,不应当强制客户端依赖于其
不使用的接口。例如,银行系统可能有一个用于评估信用申请的服务。为便于讨论,假定
该服务不仅处理有质押信用(车船贷款、抵押),也处理无质押信用(信用卡、信用证、股票
信用额度)。如果正在开发一个客户端,用于帮助从事汽车代理的金融专员为其客户获得汽
车贷款,则只需要关注汽车贷款的申请即可,无需考虑有关这一服务的任何其他事情。如
果没有 ISP,应用程序可能必须了解其他方法。尽管乍看起来这并没有什么,
但它至少是增加了应用程序的复杂性,因为据以进行开发的 API 中会有许多方法,远远超
出所需要的。这样可能会导致混淆,调用错误的方法还
可能会导致潜在的错误。还有一种可能, API 中未被应用程序用到的部分可能会改变,而
这又会导致对终端的改变。这样,因为没用到、没想用、甚至是根本就不关心的一些功能,
而增加了应用程序的维护成本。这种情况还存在安全风险。该应用程序是专用于汽车贷款
的。如果不道德的开发人员利用这个过于庞大的 API 来允许利用这一申请担保其他类型的
信用,又该怎么办呢?这种问题的严重性就不仅仅是代码瘫痪、不可维护那么简单了。
这一问题的解决方案就是专门针对客户端的需要,为该服务创建几个更小的、更精细
的接口。对于该示例应用程序,专门设计一个针对汽车贷款的接口是比较适当的做法。应
用程序可以用同一实现访问同一个类,但这一次它使用了一个特定的接口,其中仅有实际
服务的一部分方法。这样就降低了复杂性,将应用程序与 API 其他部分的修改隔离开来,
还有助于堵塞安全漏洞。
 
5. 依赖倒置原则
在完美世界里,应用程序的组件之间没有耦合关系或绑定关系。开发人员也能够改变
自己希望改变的任何东西,而不需要担心在应用程序的其他地方出现缺陷,或者“不希望
存在的负面影响”。令人悲伤的是,我们并不是生活在完美世界里。因此,组件需要相互
绑定在一起,或者在某一点耦合,以构成实际应用程序。
依赖倒置原则(Dependency Inversion Principle,DIP)规定:代码应当取决于抽象概念,
而不是具体实现;这些抽象不应当依赖于细节;而细节应当依赖于抽象。类可能依赖于其
他类来执行其工作(Employee 服务可能依赖于数据访问组件向数据存储中保存和检索员工
信息)。但是,它们不应当依赖于该类的特定具体实现,而应当是它的抽象。也就是说,
Employee 服务不知道(或不关心)正在使用哪个具体的数据访问组件——
只有它的抽象或代码契约(或接口)支持那些用于保存和检索员工所需要的方法。显然,
这一概念会大大提高系统的灵活性。如果类只关心它们用于支持特定契约而不是特定类型的组件,
就可以快速而轻松地修改这些低级服务的功能,同时最大限度地降低对系统其余部分的影响。

SOLD原则的更多相关文章

  1. javascript的api设计原则

    前言 本篇博文来自一次公司内部的前端分享,从多个方面讨论了在设计接口时遵循的原则,总共包含了七个大块.系卤煮自己总结的一些经验和教训.本篇博文同时也参考了其他一些文章,相关地址会在后面贴出来.很难做到 ...

  2. 让姑姑不再划拳 码农也要有原则 : SOLID via C#

    “姑娘,别这样.我们是有原则的.” “一个有原则的程序猿是不会写出 “摧毁地球” 这样的程序的,他们会写一个函数叫 “摧毁行星”而把地球当一个参数传进去.” “对,是时候和那些只会滚键盘的麻瓜不同了, ...

  3. java面向对象六原则一法则

    1. 单一职责原则:一类只做它该做的事. 2. 里氏替换原则:子类必须能够替换基类(父类),否则不应当设计为其子类. 3. 依赖倒换原则:设计要依赖于抽象而不是具体化. 4. 接口隔离原则:接口要小而 ...

  4. SOLID 设计原则

    SOLID 原则基本概念: 程序设计领域, SOLID (单一功能.开闭原则.里氏替换.接口隔离以及依赖反转)是由罗伯特·C·马丁在21世纪早期 引入的记忆术首字母缩略字,指代了面向对象编程和面向对象 ...

  5. Java程序员应该了解的10个面向对象设计原则

    面向对象设计原则: 是OOPS(Object-Oriented Programming System,面向对象的程序设计系统)编程的核心,但大多数Java程序员追逐像Singleton.Decorat ...

  6. Atitit.研发团队的管理原则---立长不立贤与按资排辈原则

    Atitit.研发团队的管理原则---立长不立贤与按资排辈原则 1. 组织任命原则概述1 2. 历史的角度看,大部分组织使用的立长不立贤原则1 3. 论资排辈 立长不立贤原则1 3.1. 资格和辈分是 ...

  7. DIP原则、IoC以及DI

    一.DIP原则 高层模块不应该依赖于底层模块,二者都应该依赖于抽象. 抽象不应该依赖于细节,细节应该依赖于抽象. 该原则理解起来稍微有点抽象,我们可以将该原则通俗的理解为:"依赖于抽象&qu ...

  8. Lesson 19 Sold out

    Text 'The play may begin at any moment,' I said. 'It may have begun already,' Susan answered. I hurr ...

  9. TDD原则

    TDD 介绍 测试驱动开发,或者叫 TDD,是一个敏捷方法,通过确保在代码是先前手动编写测试用 例,用测试来驱动开发,从而翻转开发生命周期(它不只是作为一种校验工具). TDD 的原则很简单的: 只有 ...

随机推荐

  1. 修改Linux的SSH远程连接端口 技巧

    将SSH终端服务的端口由 22 修改为别的端口以防攻击黑客直接猜解您的服务器密码 首先修改配置文件 vi /etc/ssh/sshd_config 找到 #Port 22 一段,这里是标识默认使用 2 ...

  2. Android实现页面跳转及传递参数的方法

    简单的示例 实现的效果是这样的: 第一个页面有一个按钮,一个文本框,点击按钮,将文本框的内容传递到第二个页面,并显示在第二个页面中. 首先是在给按钮添加点击事件 setOnClickListener( ...

  3. word20161215

    name / 名称 name mapping / 名称映射 name resolution / 名称解析 name server (NS) resource record / 名称服务器资源记录 na ...

  4. AngularJS ui-router (嵌套路由)

    http://www.oschina.net/translate/angularjs-ui-router-nested-routes AngularJS ui-router (嵌套路由) 英文原文:A ...

  5. MySQL 5.7 学习:安全相关特性

    背景: 继上次介绍 初识 MySQL 5.6 新功能.参数完之后,刚好MySQL 5.7又GA了,在官方测试里看到,MySQL5.7在功能.性能.可用性.安全和监控上又提升了很高.现在看看和MySQL ...

  6. SQL创建字段信息(表值函数)

    ALTER FUNCTION [dbo].[fnt_SplitString] ( @p1 varchar(Max), ) ) RETURNS @Table_Var TABLE ( c1 varchar ...

  7. .NET LINQ 相等运算

    相等运算      如果两个序列的对应元素相等且这两个序列具有相同数量的元素,则视这两个序列相等. 方法 方法名 说明 C# 查询表达式语法 Visual Basic 查询表达式语法 更多信息 Seq ...

  8. jQuery 名称冲突

    jQuery 名称冲突 jQuery 使用 $ 符号作为 jQuery 的简介方式. 某些其他 JavaScript 库中的函数(比如 Prototype)同样使用 $ 符号. jQuery 使用名为 ...

  9. cisco-log

    每个日志消息被关联一个严重级别,用来分类消息的严重等级:数字越低,消息越严重.严重级别的范围从0(最高)到7(最低).  日志消息的严重级别,使用logging命令可以用数字或者名称来指定严重性.  ...

  10. Linux系统virtualbox + ubuntu + xshell 问题与注意事项

    序言:ubuntu闭源软件太多,一般不推荐使用:没钱可以使用centos.debian:有钱使用redhat 目前主流和常用的Linux版本主要有:1.Redhat 版本5.5和6.0最新:培训.学习 ...