程序员七大面向对象设计原则

在没有了解到面向对象设计的7大原则前,我只是一只豆子!   但豆子终将会成长不是吗?

1.开闭原则:一个软件实体应当对扩展开放,对修改关闭。也就是说在所涉及一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为。

   在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个读库的类。

   抽象化是开闭原则的关键。

是添加新代码完成方法的重构  而不是修改源代码

声明: 本文源自

2.依赖倒转原则:高层模块不应该依赖低层模块,他们都应依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

        要针对接口编程,不要针对实现编程。
        代码要依赖于抽象的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。
        实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对

        象设计的主要手段。
        依赖倒转原则的常用实现方式之一是在代码中使用抽象类。而将具体类放在配置文件中。
        依赖注入:构造注入:通过构造函数注入实例变量      设值注入:通过Setter方法注入视力变量      接口注入:通过接口方法注入实例变量

声明: 本文源自  

3.里氏替换原则: 子类出现在父类出现的位置,且不影响程序的运行。但是反过来就是父类对象是不能替换子类对象的。

         有了里氏替换原则,才使继承复用成为可能,

         子类可以在父类的基础上添加新的行为。(子类要比父类优秀)

子类型必须能替换掉他的父类型。

Pass :了解更多

4.单一职责原则:一个对象应该只包含单一的职责,且该职责要被封装在具体的一个类中。

        即一个类只做单一的事,避免繁杂类的出现,使得类的继承和重载更加的方便。

耦合性(Coupling),也叫耦合度,是对模块间关联程度的度量。耦合的强弱取决与模块间接口的复杂性、调用模块的方式以及通过界面传送
数据的多少。模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。模块间联系越多,其耦合性越强,同时

表明其独立性越差。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则就是高内聚低耦合。

Pass :了解更多

5.接口隔离原则:客户端不应该依赖于那些他不需要的接口。

        在使用接口的时候,为客户端提供指定的接口大小,按需分配,隐藏客户端不需要的接口。

        接口隔离原则是指:不使用单一的总接口,每一个接口应承担相对独立的角色。

        类应完全依赖相应的专门的接口。

Pass:  了解更多

6.合成复用原则 :尽量使用对象组合,而不是使用继承来达到复用的目的。

        一般来说使用继承的时候,要严格遵守里氏替换原则,基类的细节对于子类是可见的,这种方式属于静态的,

      减少了程序的灵活性,如果基类发生改变,其子类也不得不随之变动。

        一般来说首先使用"组合/聚合" 降低类于类之间耦合度,减少类的变化对其他类的影响。

合成复用原则 :就是在一个新的对象里通过关联关系(包括组合关系和聚合关系)来使用一些已有的对象,使之成为新对象的一部分;新对象通过委派调用已有对象的方法达到复用功能的目的。简言之:复用时要尽量使用组合/聚合关系(关联关系),少用继承

Pass 了解更多

7.迪米特法则:一个软件实体尽可能少的和其他软件实体发生相互作用。

         减少对象与对象之间的直接交互,创建中间类, 通过中间类进行对象与对象间的间接交互,

       当我们需要增加或删除空间的时候,就只需在中间类中进行调整,无需修改已有控件的源代码。

降低程序之间的耦合度,使类于类之间呈现松散的耦合关系。程序更加的灵活。

灵活使用面向对象的准则,使我们的编程更加灵活,封装性更好,复用性更高,易于维护。

时间: 2024-10-11 12:56:23

程序员七大面向对象设计原则的相关文章

七大面向对象设计原则

一.面向对象原则综述 七大原则总脉络图: 二.常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充. . 三.以下详细分析: (一)单一职责原则(Single Responsibility Principle, SRP) 1.定义:一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中    或者:就一个类而言,应该仅有一个引起它变化的原因. 2.分析:一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于

单一职责原则详解--七大面向对象设计原则(1)

单一职责原则来源: 定义:单一职责就是一个类负责一项职责.就一个类而言,应该只专注于做一件事和仅有一个引起它变化的原因. 所谓职责,我们可以理解为功能,就是设计的这个类功能应该只有一个,而不是两个或更多.也可以理解为引用变化的原因,当你发现有两个变化会要求我们修改这个类,那么你就要考虑撤分这个类了.因为职责是变化的一个轴线,当需求变化时,该变化会反映类的职责的变化. 单一职责原则,很太简单.大多数开发人员,在设计软件时也会自觉的遵守这一重要原则,因为这是常识.在软件编程中,谁也不希望因为修改了一

里氏替换原则详解--七大面向对象设计原则(2)

里氏替换原则来源: 我们都知道面向对象有三大特性:封装.继承.多态.所以我们在实际开发过程中,子类在继承父类后,根据多态的特性,可能是图一时方便,经常任意重写父类的方法,那么这种方式会大大增加代码出问题的几率.比如下面场景:类C实现了某项功能F1.现在需要对功能F1作修改扩展,将功能F1扩展为F,其中F由原有的功能F1和新功能F2组成.新功能F由类C的子类C1来完成,则子类C1在完成功能F的同时,有可能会导致类C的原功能F1发生故障.这时就有人提出了里氏替换原则.里氏替换原则这项原则最早是在19

依赖倒置原则详解--七大面向对象设计原则(3)

依赖倒置原则来源: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口,不要依赖于具体实现.简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合. A.高层模块不应该依赖低层模块,二者都应该依赖其抽象.抽象

迪米特法则详解--七大面向对象设计原则(6)

迪米特法则的来源: 迪米特法则又叫最少知道原则,最早是在1987年由美国Northeastern University的Ian Holland提出.类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大.于是就提出了迪米特法则.通俗的来讲,就是一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息. 迪米特法则的简单定义:     只与直接的朋友通信. 首先来解

接口隔离原则详解--七大面向对象设计原则(4)

 接口隔离原则的来源: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法.因为使用多个专门的接口比使用单一的总接口要好,所以便提出了接口隔离原则. 接口隔离原则的目的: 将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 接口隔离原则的两种定义:  (1) 当把"接口"理解成一个类型所提供的所有方法特征的集合的时候,这就是一种逻辑上的概念,接口的划分

(转载)Java程序员应当知道的10个面向对象设计原则

面向对象设计原则是OOPS编程的核心, 但我见过的大多数Java程序员热心于像Singleton (单例) . Decorator(装饰器).Observer(观察者) 等设计模式,而没有把足够多的注意力放在学习面向对象的分析和设计上面.学习面向对象编程像"抽象"."封装"."多态"."继承" 等基础知识是重要的,但同时为了创建简洁.模块化的设计,了解这些设计原则也同等重要.我经常看到不同经验水平的java程序员,他们有的不知

Java程序员应当知道的10个面向对象设计原则

面向对象设计原则是OOPS编程的核心, 但我见过的大多数Java程序员热心于像Singleton (单例) . Decorator(装饰器).Observer(观察者) 等设计模式,而没有把足够多的注意力放在学习面向对象的分析和设计上面.学习面向对象编程像"抽象"."封装"."多态"."继承" 等基础知识是重要的,但同时为了创建简洁.模块化的设计,了解这些设计原则也同等重要.我经常看到不同经验水平的java程序员,他们有的不知

【转】程序员应知道这十大面向对象设计原则

面向对象设计原则是OOPS编程的核心, 但我见过的大多数Java程序员热心于像Singleton (单例) . Decorator(装饰器).Observer(观察者) 等设计模式, 而没有把足够多的注意力放在学习面向对象的分析和设计上面.学习面向对象编程像“抽象”.“封装”.“多态”.“继承” 等基础知识是重要的,但同时为了创建简洁.模块化的设计,了解这些设计原则也同等重要.我经常看到不同经验水平的java程序员,他们有的不知道这些 OOPS 和SOLID设计原则,有的只是不知道一个特定的设计