OO principle

合集下载

面向对象编程的五大原则

面向对象编程的五大原则

面向对象编程的五大原则面向对象编程(Object-Oriented Programming,OOP)是一种常用的编程范式,其核心思想是将现实世界的事物抽象为对象,并通过对象间的关系和交互来完成程序的设计和实现。

在面向对象编程中,有五个重要的原则,也被称为“SOLID”原则,它们是:单一职责原则(Single Responsibility Principle,SRP)、开放封闭原则(Open-Close Principle,OCP)、里氏替换原则(Liskov Substitution Principle,LSP)、接口隔离原则(Interface Segregation Principle,ISP)和依赖倒置原则(Dependency Inversion Principle,DIP)。

1.单一职责原则(SRP)单一职责原则要求一个类只负责一项职责。

换句话说,一个类应该有且只有一个引起它变化的原因。

这个原则的核心思想是将类的职责分解为更小的粒度,使得每个类都能保持简单和高内聚性。

如果一个类承担了过多的职责,就会导致代码的复杂性增加,难以理解和维护。

例子:假设有一个图书管理系统,其中的Book类负责图书的管理和展示,同时也负责借书和还书的操作。

根据单一职责原则,应该将借书和还书的操作封装到另外一个类中,避免Book类承担过多的职责。

2.开放封闭原则(OCP)开放封闭原则要求软件实体(类、模块、函数等)应该对扩展开放,对修改封闭。

也就是说,当需求发生变化时,应该通过扩展已有的实体来实现,而不是修改已有的代码。

这样可以保证代码的稳定性和可维护性。

例子:假设有一个用于计算圆形面积的程序,其中定义了一个Circle类。

如果需要新增一个计算矩形面积的功能,应该通过扩展已有的代码来实现,而不是直接修改Circle类。

可以通过定义一个Rectangle类来实现计算矩形面积的功能,这样就符合了开放封闭原则。

3.里氏替换原则(LSP)里氏替换原则要求使用基类的地方必须能够使用其派生类而不会产生错误或异常。

oop的6个设计原则

oop的6个设计原则

oop的6个设计原则
OOP的6个设计原则如下:
1.开闭原则:软件对象(类、模块、方法等)应该对于扩展是开放的,对修改
是关闭的。

当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现。

编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则。

2.里氏替换原则:代码共享,减少创建类的工作量,每个子类都拥有父类的方
法和属性;子类替换父类(可以用父类对象的任何地方都可以用子类对象代替)。

3.依赖倒置原则:程序要依赖于抽象接口,不要依赖于具体实现。

相对于细节
的多变性,抽象的东西要稳定的多。

以抽象为基础搭建的架构比细节为基础搭建的架构要稳定的多。

4.接口隔离原则:不要在一个接口里放很多的方法,这样会显得这个类很臃肿。

接口尽量细化,一个接口对应一个功能模块,同时接口里面的放荡发应该尽可能少,使接口更加灵活轻便。

客户端不应该依赖它不需要的接口,类间的依赖关系应该建立在最小的接口上。

5.合成/聚合复用原则:设计者首先应当考虑复合/聚合,而不是继承。

6.迪米特法则:迪米特法则或最少知识原则。

迪米特法则的核心观念:类间解
耦,弱耦合,只有弱耦合了以后,类的复用率才能提高。

如果两个类不必彼此通信,那么这两个类就不应当发生直接的相互作用。

如果一个类需要调用另一个类的某一个方法,可以通过第三者转发这个调用。

奥姆剃刀定律

奥姆剃刀定律

奥卢姆剃刀定律(Occam's Razor),也被称为奥卢姆的剃刀、奥姆剃刀原理,是一种科学和哲学原则,提出了一个简单性原则:在解释某个现象或问题时,应该选择最简单、最经济、最少假设的解释。

奥姆剃刀定律的核心思想是,当面临多种可能性的解释时,应该优先选择最简单的解释,而不是过度复杂或引入无必要的假设。

这是因为简单的解释更容易被理解、验证和推断,并且具有更高的可靠性。

奥姆剃刀定律并不意味着简单就一定正确,但它提供了一种思考问题的方法,以减少不必要的复杂性和猜测。

在科学研究、推理和问题解决中,奥姆剃刀定律常被用作指导原则,以避免过度复杂化和虚构的解释。

然而,需要注意的是,奥姆剃刀定律并非绝对规则,而是一种启发式原则。

在某些情况下,问题可能涉及到多个因素、复杂的关系或不同的领域知识,此时可能需要更复杂的解释或模型来解决问题。

因此,在具体应用奥姆剃刀定律时,需要根据具体情况进行权衡和判断。

oop规约

oop规约

oop规约
面向对象编程(OOP)规约是一组指导程序员编写有效和高质量OOP
代码的规则。

这些规约通常涵盖代码结构、类设计、继承、多态性、封装、抽象化和数据封装等方面。

以下是常见的OOP规约:
1.单一职责原则:每个类应该只有一个职责,即只负责一个功能。

2.开闭原则:对扩展开放,对修改关闭。

在不修改现有代码的情况下,通过扩展代码来实现新的功能。

3.里氏替换原则:子类可以替换其父类而不影响程序的正确性。

即子
类可以扩展父类的功能,但不能限制或修改其原有功能。

4.接口隔离原则:要求接口要尽量小,并且要专门化。

每个接口应该
只包含必要的方法。

5.依赖倒置原则:高层模块不应该依赖低层模块,而是应该通过抽象
层来互相依赖。

6.迪米特法则:一个对象应该对其他对象有尽可能少的了解。

即模块
之间应该尽量避免直接依赖,而是通过中间层来间接依赖。

7.组合/聚合重用原则:建议使用组合和聚合来实现对象的复用,而
不是继承。

通过遵守这些规约,程序员可以提高代码的可读性、可维护性和可重
用性,从而更有效地构建高质量的面向对象软件。

oop的六大原则

oop的六大原则

oop的六大原则
1. 单一责任原则(Single Responsibility Principle,SRP):一个类应该只有一个引起它变化的原因,即一个类应该只负责一项职责。

2. 开放封闭原则(Open-Closed Principle,OCP):软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改的。

也就是说,在修改需求时,应该尽量通过扩展已有的代码来实现新的功能,而不是直接修改已有代码。

3. 里氏替换原则(Liskov Substitution Principle,LSP):子类型必须能够替换它们的父类型。

在代码中,父类出现的地方必须能够被子类替换,而程序执行的结果不能出现异常或错误。

4. 依赖倒置原则(Dependency Inversion Principle,DIP):高层模块不应该依赖于低层模块,二者都应该依赖于抽象。

抽象不应该依赖于具体实现,具体实现应该依赖于抽象。

5. 接口隔离原则(Interface Segregation Principle,ISP):一个类不应该强迫其它类依赖于它们不需要使用的接口。

接口应该小而精炼,客户端只应该依赖于它们需要的接口。

6. 迪米特原则(Law of Demeter,LoD):一个对象应该对其他对象有尽可能少的了解。

一个类应该只与它的直接朋友进行交互,而不需要了解朋友的朋友。

这样可以降低类之间的耦合性,提高可维护性和可扩展性。

oop概念的基本原则

oop概念的基本原则

oop概念的基本原则嘿,朋友!咱们今天来聊聊OOP 概念的基本原则,这可有意思啦!你知道吗,OOP 就像是一个魔法盒子,里面藏着好多神奇的宝贝。

那啥是 OOP 呢?OOP 就是面向对象编程,它的基本原则就像是这个魔法盒子的使用说明书。

首先说封装,这就好比你有个百宝箱,里面装满了你的宝贝,但是你把它锁起来,只露出几个按钮让别人操作。

别人不知道里面具体是怎么运作的,但能通过你给的按钮来使用它。

这不就省了好多麻烦?也不用担心别人乱动你的宝贝,把一切弄得乱糟糟。

比如说一个银行账户的类,你把账户的各种操作和数据封装起来,外部只需要调用存款、取款的方法,而不需要知道具体的实现细节。

难道这不好吗?接着是继承,这就像你从父母那里继承了一些优良基因一样。

在编程里,一个子类可以继承父类的属性和方法。

比如说有个“动物”的父类,然后“狗”“猫”就是子类,它们继承了动物的一些共同特征,比如都能移动、都有生命。

这样是不是很省事?不用每个子类都重新去写那些相同的东西,多妙啊!然后是多态,这就像是孙悟空能七十二变,同一个东西在不同的情况下有不同的表现。

比如说一个“形状”的类,有“圆形”“方形”等子类。

当你调用计算面积的方法时,不同的形状会有不同的计算方式。

这难道不神奇吗?再说说抽象,这就好比你画一幅画,先勾勒出大致的轮廓,而不关注细节。

在编程里,你先定义一个抽象的类,描述一些大致的特征和行为,然后具体的子类去实现细节。

比如说有个“交通工具”的抽象类,然后“汽车”“飞机”去具体实现。

这是不是让事情变得更清晰明了?OOP 的这些基本原则,就像一个完美团队里的各个角色,相互配合,共同完成一项伟大的任务。

封装保护着内部的秘密,继承传递着优秀的基因,多态展现着多样的魅力,抽象勾勒出清晰的框架。

总之,掌握了 OOP 概念的基本原则,就像是拥有了一把神奇的钥匙,能打开编程世界的更多奇妙之门,让我们在代码的世界里更加游刃有余!你难道不想试试这把神奇的钥匙吗?。

GRASP设计模式

GRASP设计模式

面向对象设计的原则指南–概要篇我们在进行面向对象设计(OOD)时应该怎样进行,遵循什么原则呢?我们或许听说过设计模式,那是针对特定的问题提出的特定的解决方法。

面向对象的设计从提出到现在经过很多人的经验和实践,也总结出了很多原则。

在设计开发中,如果能有意识地向这些原则靠拢,对我们的系统设计与开发会有很大的帮助,也是构筑具有稳定性,扩展性的系统的一个保障:- 是否遵守了那些基本原则- 如果违反了基本原则,是否存在合适的理由这些被大师们总结出来的基本原则包括了:1,类的设计原则2,包的设计原则2.1 包的内部关系方面(聚合性)的原则2.2 包之间的关系方面(耦合性)的原则类设计原则The Single Responsibility Principle (SRP) - OO设计的单一职责原则There should never be more than one reason for a class to change.永远不要让一个类存在多个改变的理由。

The Open-Closed Principle (OCP) - 面向对象软件设计的开闭原则Software entities (classes, modules, function, etc.) should be open for extension, but closed for m odification.软件实体(模块,类,方法等)应该对扩展开放,对修改关闭。

The Liskov Substitution Principle (LSP) - OO设计的里氏替换原则Functions that use pointers or references to base classes must be able to use objects of derived cl asses without knowing it.所有引用基类的地方必须能透明地使用其子类的对象。

ocp原则

ocp原则

ocp原则
开放-封闭原则(Open-Closed Principle,OCP)是面向对象程序设计中最基础的原
则之一,指对象(类、模块、函数等)在设计时需遵循“对扩展开放,对修改关闭”的原则。

开放-封闭原则是程序设计中的一项基本原则,它定义了一种创建可维护、可扩展、
可替换、可复用的软件设计的基本理念,开发者应当关注于一个系统的扩展而不是修改。

开放-封闭原则是“对扩展开放,对修改关闭”的缩写,即在不修改原有的元素的情
况下,应该可以通过添加新的元素来扩展系统的功能,而不是修改或改变原有的元素。

在面向对象程序设计中,开放-封闭原则旨在建立稳定、可维护的系统。

当遇到系统
更新、需求改变时,应当尽量避免修改原有的代码,而是通过添加新的代码来实现你的目的,不要修改已有的逻辑核心,而是增加新的功能。

开放-封闭原则的实现,需要良好的抽象,如抽象类或接口。

抽象类或接口能起到把
复杂的现实抽象成简单的、不具体的形式。

这意味着,任何实现了抽象类或接口的类,都
可以起到替换其他实现类的效果。

如果无需更新已有的类,就可以实现变更,那么就实现
了开放-封闭原则。

采用开放-封闭原则,可以很好的维护和扩展软件系统。

当遇到需求改变时,可以根
据需求新增功能而不必去修改原来的代码,这样就可以保证系统的可维护性;在未来新增
功能时也可以根据新需求新增或扩展软件系统的功能,从而保证软件系统的可扩展性。

开放-封闭原则与代码复用的关系也是非常重要的,它的实现也可以帮助我们实现代
码的有效复用,这就意味着程序员可以很快的开发出软件,而且程序的运行稳定可靠。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

面向对象设计原则:面向对象设计(OOD)原则疯狂代码 / ĵ:http://SoftwareEngineering
/Article35337.html
单职责原则(SRP):个类应当只有个改变原因类只需要知道件事情它们应当有个单独职责要点就是当个类需要改变时应当只有个原因
开放-封闭原则(OCP):软件Software实体(类、模块、等)应当为扩展而开放又为修改而封闭这个原则有个相当详细定义但是个简单意思是:你应当能够改变个模块周边环境而无须改变模块本身
Liskov替换原则(LSP):子类型(subtypes)必须是为它们基类型(base types)可替代
依存关系倒置原则(DIP) :A.高层模块应当不依赖低层模块它们应当依赖于抽象
B.抽象应当不依赖于细节细节应当依赖于抽象
更好描述是:不要依赖那些容易变化具体类如果你要继承个类从个抽象类继承吧如果你要持有个类引用从个抽象类引用吧如果你要个从个抽象吧
接口隔离原则(ISP):客户不应当依赖那些它们根本不用思路方法
整理总结:
5个简单原则是:
1、SRP--个类应当只有个发生变化原因
2、OCP――应当能够改变个类环境而无须改变类本身
3、LSP――避免造成派生类思路方法非法或退化个基类用户应当不需要知道这个派生类
4、DIP ――用依赖于接口和抽象类来替代依赖容易变化具体类
5、ISP――给个对象每个用户个接口这个接口仅有用户需要思路方法
正如牛顿 3大定律在经典力学中位置样“开-闭”原则(Open-Closed Principle)是面向对象可复用设计(Object Oriented Design或OOD)基石其他设计原则(里氏代换原则、依赖倒转原则、合成/聚合复用原则、迪米特法则、接口隔离原则)是实现“开-闭”原则手段和工具
、“开-闭”原则(Open-Closed Principle,OCP)
1.1“开-闭”原则定义及优点
1)定义:个软件Software实体应当对扩展开放对修改关闭( Software entities should be open for extension,but closed for modication.)即在设计个模块时候应当使这个模块可以在不被修改前提下被扩展
2)满足“开-闭”原则系统优点
a)通过扩展已有软件Software系统可以提供新行为以满足对软件Software新需求使变化中软件Software系统有定适应性和灵活性
b)已有软件Software模块特别是最重要抽象层模块不能再修改这就使变化中软件Software系统有定稳定性和延续性
c)这样系统同时满足了可复用性和可维护性
1.2如何实现“开-闭”原则
在面向对象设计中不允许更改是系统抽象层而允许扩展是系统实现层换言的定义个劳永逸抽象设计层允许
尽可能多行为在实现层被实现
解决问题关键在于抽象化抽象化是面向对象设计第个核心本质
对个事物抽象化实质上是在概括归纳整理总结它本质抽象让我们抓住最最重要东西从更高层去研究这降低了研究复杂度我们不用同时考虑那么多东西换言的我们封装了事物本质看不到任何细节
在面向对象编程中通过抽象类及接口规定了具体类特征作为抽象层相对稳定不需更改从而满足“对修改关闭”;而从抽象类导出具体类可以改变系统行为从而满足“对扩展开放”[Page]
对实体进行扩展时不必改动软件Software源代码或者 2进制代码关键在于抽象
1.3对可变性封装原则
“开-闭”原则也就是“对可变性封装原则”(Principle of Encapsulation of Variation EVP)即找到个系统可变原因将的封装起来换言的在你设计中什么可能会发生变化应使的成为抽象层而封装而不是什么会导致设计改变才封装
“对可变性封装原则”意味着:
a)种可变性不应当散落在代码许多角落而应当被封装到个对象里面同可变性区别表象意味着同个继承等级结构中具体子类因此此处可以期待继承关系出现继承是封装变化思路方法而不仅仅是从般对象生成特殊对象 b)种可变性不应当和另种可变性混合在起作者认为类图继承结构如果超过两层很可能意味着两种区别可变性混合在了起
使用“可变性封装原则”来进行设计可以使系统遵守“开-闭”原则
即使无法百分的百做到“开-闭”原则但朝这个方向努力可以显著改善个系统结构
2、里氏代换原则(Liskov Substitution Principle, LSP)
2.1概念
定义:如果对每个类型为T1对象O1都有类型为T2 对象O2使得以T1定义所有P在所有对象O1都代换为O2时P行为没有变化那么类型T2是类型T1子类型
即个软件Software实体如果使用是个基类话那么定适用于其子类而且它觉察不出基类对象和子类对象区别也就是说,在软件Software里面,把基类都替换成它子类,行为没有变化
反过来代换不成立如果个软件Software实体使用是个子类话那么它不定适用于基类
任何基类可以出现地方子类定可以出现
基于契约设计、抽象出公共部分作为抽象基类设计
2.2里氏代换原则和“开-闭”原则关系
实现“开-闭”原则关键步骤是抽象化基类和子类的间继承关系就是抽象化体现因此里氏代换原则是对实现抽象化具体步骤规范标准
违反里氏代换原则意味着违反了“开-闭”原则反的未必
3、 依赖倒转原则(dependence inversion principle, DIP)
3.1概念
依赖倒转原则就是要依赖于抽象不要依赖于实现(Abstractions should not depend upon details. Details should depend upon abstractions.)要针对接口编程不要针对实现编程(Program to an erface, not an implementation.)
也就是说应当使用接口和抽象类进行变量类型声明、参数类型声明、思路方法返还类型介绍说明以及数据类型转换等而不要用具体类进行变量类型声明、参数类型声明、思路方法返还类型介绍说明以及数据类型转换等要保证做到这点个具体类应当只实现接口和抽象类中声明过思路方法而不要给出多余思路方法
传统过程性系统设计办法倾向于使高层次模块依赖于低层次模块抽象层次依赖于具体层次倒转原则就是把这个依赖关系倒转过来 2008-12-13 21:55:28
疯狂代码 /。

相关文档
最新文档