面向对象理解

OO三大特性

封装,继承,多态

OO五大原则

SOLID
(1)单一职责SRP
一个类仅有一个引起他变化的原因
(2)开闭原则OCP
对扩展开放,对修改封闭
(3)里氏替换LSP
子类可以替换父类
(4)接口隔离ISP
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好
(5)依赖倒置DIP
具体实现类依赖抽象类和接口

过程编程

数据,关注算法

结构编程

数据,算法,关注函数,自上而下

对象编程

数据,算法,关注数据(类),自下而上

面向对象的理念

是设计,与问题相对应的数据格式

类用来描述这种数据格式
对象
对象是这种数据格式构造的特定数据结构
关系
类相对于对象,就像类型相对于变量

泛型

强调独立于类型的代码

函数原型对于函数,就是变量声明对于变量

广义的委托

自己处理
调用者根据被调用者的返回,自己执行操作

委托处理
调用者自己不去执行操作,委托其他对象去执行操作
调用者,就是指结构化编程中的主控程序
其他对象,就是指其他类

委托随处可见
类A委托类B,类B可能进一步委托类C,这就形成了分层设计

分层设计
类A可能在第一层,第二层是类B,第三层是类C

单一职责

减少关注点,降低耦合度,单一职责

再谈委托
委托,把责任给其他类去处理

请记住,责任的转移
生活中这样想,能不能把这烦恼的事抛出去

对象

是具有责任的东西

狭义的理解
就是封装了数据和操作数据的方法

寻找对象间的关系。

我们通常解决问题,是大问题化小问题,小问题化更小问题,最后就解决了。

可是,这会有个问题,这个问题就是,我们一上来就去考虑问题的解决方案,准确的说是,一上来就陷入解决方案的实现。很少有人会去抽象问题,泛化问题,考虑问题的抽象本质。

比如,

面向对象的真正威力并不是来自继承,而是来自封装。

模式背后的基本原则和动机。

设计模式并不是孤立存在的。

我们是否有过这样的体验,我们创建了很多类来隔离问题域,但是,当我们需要把这些类优雅的组合起来,却困难重重?

我曾经喜欢将问题域都隔离到单独各自的service类,虽然问题被隔离了,可是设计却是一塌糊涂,因为这些service类,要组合起来形成一个软件系统,组合过程困难重重,设计糟糕至极。

模式本是天然形成的,绝非生搬硬套。

不要过早的开始实现。

软件最重要的是什么,是模型。

编程最重要的是什么,抽象的能力。

类定义了相似对象的一般特性。

抽象类定义了相似类的一般特性。

接口只是单纯的确保类(可以相似,可以不相似)的特性。

特化,泛化,is a,can do

抽象类的出发点是重用,内在意义是隐藏,思考则应符合概念。

父类,接口,内在意义,都有隐藏的意思。

隐藏的目的是什么,是封装,封装好了,就是高内聚,外部通信就简单。

数据库,对象状态的持久化。

有了对象,对象与数据库交互,数据层只是对象状态的持久化。

在写代码时,类,对象,概念层次。正在写的这行代码,是否造成代码宿主类对你写的代码的强依赖???

写抽象的程序,抽象的代码。

虚方法不应该访问到私有成员,因为重写就可能破坏

(1)代码依赖性

方法高內聚,可重用的片段,单一职责。

高内聚,低耦合,单一职责

低耦合,模块之间肯定需要通信,不过通信,应该依赖于设计良好的不易变化的抽象的接口。

每个模块都不应该了解另一个模块的实现细节而与其通信。

一个有助于实现高内聚,低耦合的原则是,分离关注点。

面向对象让你,把程序想象成一系列相互交互的对象,对象有自己的数据和行为。

首先关注的是概念,也就是抽象,而不是一开始就去关注实现,细节。

依赖抽象,依赖接口。

基于接口编程,而不是依赖实现编程。

里氏替换,是指我们在设计子类型时,要考虑子类型可以替换父类型。

数据迁移对象DTO

领域业务对象domainmodel

数据库映射实体entity

设计对象,首先要区分,公共接口方法,私有成员方法。

封装其实就是信息隐藏。

继承应该从概念层次出发,而不是从重用的角度。

dry原则,do.notrepeatyourself

回调,委托,事件,action,func,泛型

DRY原则

你可能感兴趣的:(面向对象理解)