网站域名备案在哪里,万网主机怎么做网站,阿里巴巴网站建设要多少钱,如何在百度上搜到网站最近几年来#xff0c;人们踊跃的提倡和使用设计模式#xff0c;其根本原因就是为了实现代码的复用性#xff0c;增加代码的可维护性。设计模式的实现遵循了一些原则#xff0c;从而达到代码的复用性及增加可维护性的目的#xff0c;设计模式对理解面向对象的三大特征有很… 最近几年来人们踊跃的提倡和使用设计模式其根本原因就是为了实现代码的复用性增加代码的可维护性。设计模式的实现遵循了一些原则从而达到代码的复用性及增加可维护性的目的设计模式对理解面向对象的三大特征有很好的启发不看设计模式很难深层地体会到面向对象开发带来的好处 。在刚开始学习中很难做到将这些模式融汇贯通所以这个需要我们在编码前多思考等想充分了在开始实践编码。下面是设计模式应当遵循的七大原则 1.开闭原则Open Close Principle 定义一个软件实体如类、模块和函数应该对扩展开放对修改关闭。 开放-封闭原则的意思就是说你设计的时候时刻要考虑尽量让这个类是足够好写好了就不要去修改了如果新需求来我们增加一些类就完事了原来的代码能不动则不动。这个原则有两个特性一个是说“对于扩展是开放的”另一个是说“对于更改是封闭的”。面对需求对程序的改动是通过增加新代码进行的而不是更改现有的代码。这就是“开放-封闭原则”的精神所在 比如刚开始需求只是写加法程序很快在client类中完成后此时变化没有发生需求让再添加一个减法功能此时会发现增加功能需要修改原来这个类这就违背了开放-封闭原则于是你就应该考虑重构程序增加一个抽象的运算类通过一些面向对象的手段如继承、动态等来隔离具体加法、减法与client耦合需求依然可以满足还能应对变化。此时需求要添加乘除法功能就不需要再去更改client及加减法类而是增加乘法和除法子类即可。绝对的修改关闭是不可能的无论模块是多么的‘封闭‘都会存在一些无法对之封闭的变化既然不可能完全封闭设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类然后构造抽象来隔离那些变化。在我们最初编写代码时假设变化不会发生当变化发生时我们就创建抽象来隔离以后发生同类的变化。 我们希望的是在开发工作展开不久就知道可能发生的变化查明可能发生的变化所等待的时候越长要创建正确的抽象就越困难。开放-封闭原则是面向对象设计的核心所在遵循这个原则可以带来面向对象技术所声称的巨大好处也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出现频繁变化的那些部分做出抽象然而对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意拒绝不成熟的抽象和抽象本身一样重要。开放-封闭原则可以保证以前代码的正确性因为没有修改以前代码所以可以保证开发人员专注于将设计放在新扩展的代码上。 简单的用一句经典的话来说过去的事已成历史是不可修改的因为时光不可倒流但现在或明天计划做什么是可以自己决定(即扩展)的。 2.里氏代换原则Liskov Substitution Principle 定义1如果对每一个类型为 T1的对象 o1都有类型为 T2 的对象o2使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时程序 P 的行为没有发生变化那么类型 T2 是类型 T1 的子类型。 定义2子类型必须能够替换掉它们的父类型。 描述一个软件实体如果使用的是一个父类的话那么一定适用于其子类而且它察觉不出父类对象和子类对象的区别也就是说在软件里面把父类都替换成它的子类程序的行为没有变化例子在生物学分类上企鹅是一种鸟但在编程世界里企鹅却不能继承鸟。在面向对象设计时子类拥有父类所有非private的行为和属性鸟会飞但企鹅不会飞所以企鹅不能继承鸟类。 只有当子类可以替换掉父类软件单位的功能不受影响时父类才能真正被复用而子类也能够在父类的基础上增加新的行为正是有里氏代换原则使得继承复用成为了可能。正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展不然还谈什么扩展开放修改关闭呢 里氏替换原则通俗的来讲就是子类可以扩展父类的功能但不能改变父类原有的功能。它包含以下4层含义 1.子类可以实现父类的抽象方法但不能覆盖父类的非抽象方法。 2.子类中可以增加自己特有的方法。 3.当子类的方法重载父类的方法时方法的前置条件即方法的形参要比父类方法的输入参数更宽松。 4.当子类的方法实现父类的抽象方法时方法的后置条件即方法的返回值要比父类更严格。 看上去很不可思议因为我们会发现在自己编程中常常会违反里氏替换原则程序照样跑的好好的。所以大家都会产生这样的疑问假如我非要不遵循里氏替换原则会有什么后果 后果就是你写的代码出问题的几率将会大大增加。 3.依赖倒转原则Dependence Inversion Principle 定义高层模块不应该依赖低层模块二者都应该依赖其抽象抽象不应该依赖细节细节应该依赖抽象。即针对接口编程不要针对实现编程 依赖倒转其实就是谁也不要依靠谁除了约定的接口大家都可以灵活自如。依赖倒转可以说是面向对象设计的标志用哪种语言来编写程序不重要如果编写时考虑的都是如何针对抽象编程而不是针对细节编程即程序中所有的依赖关系都是终止于抽象类或者接口那就是面向对象的设计反之那就是过程化的设计了。如果设计的各个部件或类相互依赖这样就是耦合度高难以维护和扩展这也就体现不出面向对象的好处了。 依赖倒转原则好比一个团队有需求组开发组测试组开发组和测试组都是面对同样的需求后做自己相应的工作而不应该是测试组按照开发组理解的需求去做测试用例也就是说开发组和测试组都是直接面向需求组工作大家的目的是一样的保证产品按时上线需求是不依赖于开发和测试的。 依赖倒置原则基于这样一个事实相对于细节的多变性抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中抽象指的是接口或者抽象类细节就是具体的实现类使用接口或者抽象类的目的是制定好规范和契约而不去涉及任何具体的操作把展现细节的任务交给他们的实现类去完成。 依赖倒置原则的中心思想是面向接口编程传递依赖关系有三种方式以上的说的是是接口传递另外还有两种传递方式构造方法传递和setter方法传递相信用过Spring框架的对依赖的传递方式一定不会陌生。 在实际编程中我们一般需要做到如下3点 低层模块尽量都要有抽象类或接口或者两者都有。 变量的声明类型尽量是抽象类或接口。 使用继承时遵循里氏替换原则。 总之依赖倒置原则就是要我们面向接口编程理解了面向接口编程也就理解了依赖倒置。 4.接口隔离原则Interface Segregation Principle 接口隔离原则的含义是建立单一接口不要建立庞大臃肿的接口尽量细化接口接口中的方法尽量少。也就是说我们要为各个类建立专用的接口而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。在程序设计中依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”通过分散定义多个接口可以预防外来变更的扩散提高系统的灵活性和可维护性。 说到这里很多人会觉的接口隔离原则跟单一职责原则很相似其实不然。其一单一职责原则原注重的是职责而接口隔离原则注重对接口依赖的隔离。其二单一职责原则主要是约束类其次才是接口和方法它针对的是程序中的实现和细节而接口隔离原则主要约束接口接口主要针对抽象针对程序整体框架的构建。 采用接口隔离原则对接口进行约束时要注意以下几点 1. 接口尽量小但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实但是如果过小则会造成接口数量过多使设计复杂化。所以一定要适度。 2. 为依赖接口的类定制服务只暴露给调用的类它需要的方法它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务才能建立最小的依赖关系。 3. 提高内聚减少对外交互。使接口用最少的方法去完成最多的事情。 运用接口隔离原则一定要适度接口设计的过大或过小都不好。设计接口的时候只有多花些时间去思考和筹划才能准确地实践这一原则。 4.组合/聚合复用原则 就是说要尽量的使用合成和聚合而不是继承关系达到复用的目的该原则就是在一个新的对象里面使用一些已有的对象使之成为新对象的一部分新的对象通过向这些对象的委派达到复用已有功能的目的。 其实这里最终要的地方就是区分“has-a”和“is-a”的区别。相对于合成和聚合继承的缺点在于父类的方法全部暴露给子类。父类如果发生变化子类也得发生变化。聚合的复用的时候就对另外的类依赖的比较的少。。合成/聚合复用① 优点新对象存取成分对象的唯一方法是通过成分对象的接口 这种复用是黑箱复用因为成分对象的内部细节是新对象所看不见的 这种复用支持包装这种复用所需的依赖较少每一个新的类可以将焦点集中在一个任务上 这种复用可以在运行时动态进行新对象可以使用合成/聚合关系将新的责任委派到合适的对象。② 缺点通过这种方式复用建造的系统会有较多的对象需要管理。 继承复用① 优点 新的实现较为容易因为基类的大部分功能可以通过继承关系自动进入派生类 修改或扩展继承而来的实现较为容易。② 缺点 继承复用破坏包装因为继承将基类的实现细节暴露给派生类这种复用也称为白箱复用 如果基类的实现发生改变那么派生类的实现也不得不发生改变 从基类继承而来的实现是静态的不可能在运行时发生改变不够灵活。6.迪米特法则Law Of Demeter 迪米特法则其根本思想是强调了类之间的松耦合类之间的耦合越弱,越有利于复用一个处在弱耦合的类被修改不会对有关系的类造成影响也就是说信息的隐藏促进了软件的复用。 自从我们接触编程开始就知道了软件编程的总的原则低耦合高内聚。无论是面向过程编程还是面向对象编程只有使各个模块之间的耦合尽量的低才能提高代码的复用率。低耦合的优点不言而喻但是怎么样编程才能做到低耦合呢那正是迪米特法则要去完成的。 迪米特法则又叫最少知道原则最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲就是一个类对自己依赖的类知道的越少越好。也就是说对于被依赖的类来说无论逻辑多么复杂都尽量地的将逻辑封装在类的内部对外除了提供的public方法不对外泄漏任何信息。迪米特法则还有一个更简单的定义只与直接的朋友通信。首先来解释一下什么是直接的朋友每个对象都会与其他对象有耦合关系只要两个对象之间有耦合关系我们就说这两个对象之间是朋友关系。耦合的方式很多依赖、关联、组合、聚合等。其中我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友而出现在局部变量中的类则不是直接的朋友。也就是说陌生的类最好不要作为局部变量的形式出现在类的内部。 一句话总结就是一个对象应该对其他对象保持最少的了解。 7.单一职责原则Single Responsibility Principle 定义不要存在多于一个导致类变更的原因。通俗的说即一个类只负责一项职责应该仅有一个引起它变化的原因 说到单一职责原则很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则在设计软件时也会自觉的遵守这一重要原则因为这是常识。在软件编程中谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单并且被认为是常识但是即便是经验丰富的程序员写出的程序也会有违背这一原则的代码存在。为什么会出现这种现象呢因为有职责扩散。所谓职责扩散就是因为某种原因职责P被分化为粒度更细的职责P1和P2。 遵循单一职责原的优点有 1.可以降低类的复杂度一个类只负责一项职责其逻辑肯定要比负责多项职责简单的多 2.提高类的可读性提高系统的可维护性 3.变更引起的风险降低变更是必然的如果单一职责原则遵守的好当修改一个功能时可以显著降低对其他功能的影响。 需要说明的一点是单一职责原则不只是面向对象编程思想所特有的只要是模块化的程序设计都需要遵循这一重要原则。 转载自http://blog.csdn.net/csh624366188/article/details/7459918转载于:https://www.cnblogs.com/jiangdd/archive/2012/04/17/2454161.html
