（对象原则篇）百分之90的人要深入掌握的PHP知识
发布时间：2022-09-22 11:20:49 所属栏目：PHP教程 来源：
导读： 类和对象
全等运算符只有在数据类型和值相同时才会返回true
抽象类可以是空类
访问任意全局类，都可以使用\限定名称，如\Exception，\strlen()，任意合法的PHP代码都可以包含在命名空间
全等运算符只有在数据类型和值相同时才会返回true
抽象类可以是空类
访问任意全局类，都可以使用\限定名称，如\Exception，\strlen()，任意合法的PHP代码都可以包含在命名空间
|
类和对象 全等运算符只有在数据类型和值相同时才会返回true 抽象类可以是空类 访问任意全局类，都可以使用\限定名称，如\Exception，\strlen()，任意合法的PHP代码都可以包含在命名空间中，只有类、函数、常量受到命名空间的影响 常量__NAMESPACE__是当前命名空间的字符串，或者是空字符串 单一职责，接口隔离，开放封闭，依赖倒置，里氏替换 类是定义一系列属性和操作的模板，而对象则把属性进行具体化，然后交给类处理。 对象就是数据，对象本身不包含方法。 但是对象有一个“ 指针” 指向一个类， 这个类里可以有方法。 方法描述不同属性所导致的不同表现。 类和对象不可分割的，有对象就必定有一个类和其对应，否则这个对象也就成了没有亲人的孩子（ 但有一个特殊情况存在， 就是由标量进行强制类型转换的object， 没有一个类和它对应。 此时，PHP中一个称为“ 孤儿” 的 stdClass 类 就会收留这个对象） 为很长的标识符创建一个别名，提高源代码的可读性 PHP的命名空间和java的包，要解决的是同一个事情 面向对象的特征是什么？封装性，抽象性，继承性 抽象，忽略一个主体中与当前目标无关的方面，注意与当前目标有关的方面。不解决所有问题，只选择其中一部分。过程抽象，数据抽象。 继承，一个新类可以从现有的类派生，类继承。可以继承方法和实例变量，子类可以增加新的方法适合需要 封装，将客观事物抽象成类，对方法和数据进行保护，只让可信的类或者对象操作，不可信的隐藏 多态，允许不同类的对象对同一消息做出响应。参数化多态和包含多态，解决了函数同名的问题。 类的组合和继承，复合方式 组合就是一个类包含另一个类的对象，还有一种就是继承 用::访问一个非静态成员，其实会有E_STRICT级别的错误，但是没有显示，可以在php.ini设置error_reporting=E_ALL|E_STRICT;diplay_error=On 设置开启 继承是一种是、像的关系，组合是一种需要的关系，组合偏向于整体和局部，继承偏向于父与子的关系 如果两个类具有很多相同的代码和方法，可以从这两个了类抽象一个父类，提供公共方法，两个类作为子类，提供个性方法 组合之间的类关系很小，甚至没有关系 什么时候用组合什么时候用继承，这就引用了一个低耦合的概念 耦合是一个软件结构内不同模块之间互连程度的度量，也就是不同模块之间的依赖关系。低耦合指模块与模块之间，尽可能地使模块间 独立存在；模块与模块之间的接口尽量少而简单。 现代的面向对象的思想不强调为真实世界建模，变得更加理性化一些，把目标放在解 耦上。 解耦是要解除模块与模块之间的依赖。 低耦合就是模块与模块之间的依赖关系尽量简单 1.继承破坏封装性 定义鸟类为父类具有飞翔方法，天鹅，鸭子为子类，他们可以无区别的使用飞翔这个方法，破坏了封装性 2.继承是紧耦合的 继承使得子类和父类捆绑在一起，组合仅通过唯一接口和外部进行通信，耦合度低于继承 3.继承扩展复杂 随着继承层数的增加和子类的增加，涉及大量方法重写。使用组合，可根据类型约束，实现动态组合，减少代码 4.不恰当的使用继承可能违反现实世界中的逻辑 人作为父类，雇员、经理和学生作为子类，经理一定是雇员，学生也可能是雇员。而继承一个类就没法拥有多个角色 组合不是没有缺点，创建组合对象时，组合需要创建局部对象，会增加一些代码，继承不需要这一步，子类自动有了父类的方法 组合的优点大于缺点，继承最大的优点是扩展简单，缺点大于优点，该怎么使用继承呢？ 精心设计专门被继承的类，继承树的抽象层应该比较稳定，不要多于3层 不是专门被继承的类，禁止其被继承，用final修饰，防止重要方法被重写，又能给编译器寻找优化机会 优先考虑使用组合关系提高代码的可重用性 子类是一种特殊的类型，而不仅仅是父类的一个角色 子类扩展，而不是覆盖或使得父类的功能失效 底层代码多用组合，顶层/业务层代码多用继承。底层组合可以提高效率，避免对象臃肿。顶层代码多用继承可以提高灵活性，让业务使用更方便 多态的含义就是 同一类的对象收到相同消息时，会得到不同的结果，而这个消息是不可预测的。多态就是多种状态，多种结果。 重载不是面向对象的东西，但也是多态一种表现形式。 多态性是一 种通过多种状态或阶段描述相同对象的编程方式。 它的真正意义在于：实际开发中，只要关心一个接口或基类的编程， 而 不必关心一个对象所属于的具体类。 调用了相同的函数，返回不同的结果，就是多态 多态指同一类对象在运行时的具体化 面向接口编程 接口定义一个规范，描述一个物的功能，要求如果现实中的物变为可用，就必须实现这些基本功能。 对于实现我的类，看起来应该都像我现在这个样子 接口为抽象而生，接口中全是抽象方法和常量，接口是一个强制规范和契约的作用，只能按接口的约定办事 接口作为一种规范和契约存在，作为规范，接口应保证可用性，作为契约，接口应保证可控性。 接口只是一个声明，用interface关键字，就应该实现它。接口本身什么都不做，但是它可以告诉我们它能做什么。 PHP中的接口存在两个不足，一是没用契约限制，二是缺少足够多的内部接口 接口其实很简单，但是接口的应用很灵活，设计模式中也有很大一部分是围绕着接口的 创建型模式，行为型模式，结构型模式 ·创建 型 模式 包括： 单 例 模式（ Singleton）、 构建 模式（ Builder）、 原型 模式（ Prototype）、 抽象 工厂 模式（ Abstract Factory）、 工厂 方法 模式（ Factory Method）。 ·行为 型 模式 包括： 策略 模式（ Strategy）、 状态 模式（ State）、 责任 链 模式（ Chain of Responsibility）、 解释器 模式（ Interpreter）、 命令 模式（ Command）、 观察者 模式（ Observer）、 备忘录 模式（ Memento）、 迭代 器 模式（ Iterator）、 模板 方法 模式（ Template Method）、 访问者 模式（ Visitor）、 中介 者 模式（ Mediator）。 ·结构 型 模式 包括： 装饰者 模式（ Decorator）、 代理 模式（ Proxy）、 组合 模式（ Composite）、 桥 连接 模式（ Bridge）、 适配器 模式（ Adapter）、 蝇 量 模式（ Flyweight）、 外观 模式（ Facade）。 发展 到 现在， 设计 模式 已经 不止 23 种了， 维 基 百科 上 已经 有 40 多种 设计 模式， 但是 被 广泛 接受 的 仍是 GoF 最早 提出 的 那 23 种。 本章 并不 就 具体 的 设计 模式 展开 讨论， 而是 会 讨论 一些 基本 的 设计 原则，并给 出 一些 小的 实例。 最后php面向对象编程教程， 作为 前 两 章 的 总结， 探讨 下 PHP 中 面向 对象 的 一些 问题。 面向 对象 设计 的 五大 原则 分别 是 单一 职责 原则、 接口 隔离 原则、 开放- 封闭 原则、 替换 原则、 依赖 倒置 原则。 这 五大 原则 也是 23 种 设计 模式 的 基础[ 1]。 单一职责，让一个工人什么都干，结果什么都做不出来php面向对象编程教程，但是让一个工人只干这一项，上级的工人再干另一项，分工明确，那么效率可以得到十倍的提升 一个 是 避免 相同 的 职责 分散 到 不同 的 类 中， 另一个 是 避免 一个 类 承担 太多 职责。 那 为什么 要 遵守 SRP 呢？ （1） 可以 减少 类 之间 的 耦合 如果 减少 类 之间 的 耦合， 当 需求 变化 时， 只 修改 一个 类， 从而 也就 隔离 了 变化； 如果 一个 类有 多个 不同 职责， 它们 耦合 在一起， 当 一个 职责 发生 变化 时， 可能 会 影响 其他 职责。 （2） 提高 类 的 复 用性 修理 电脑 比 修理 电视机 简单 多了。 主要原因 就在于就在于 电视机 各个 部件 之间 的 耦合 性 太高， 而 电脑 则 不同， 电脑 的 内存、 硬盘、 声卡、 网卡、 键盘 灯 部件 都可以 很容易 地 单独 拆卸 和 组装。 某个 部件 坏了， 换上 新的 即可。 工厂 模式（ Factory） 允许 你在 代码 执行 时 实例 化 对象。 它 之所以 被称为 工厂 模式 是因为 它 负责“ 生产” 对象。 设计 模式 里面 的 命令 模式 也是 SRP 的 体现， 命令 模式 分离“ 命令 的 请求者” 和“ 命令 的 实现 者” 方面 的 职责。 举 一个 很好 理解 的 例子， 就是 你去 餐馆 吃饭， 餐馆 存在 顾客、 服务员、 厨师 三个 角色。 作为 顾客， 你 只要 列出 菜单， 传给 服务员， 由 服务员 通知 厨师 去 实现。 作为 服务员， 只需 要 调用 准备 饭菜 这个 方法（ 对 厨师 大喊“ 该 炒菜 了”）， 厨师 听到 要 炒菜 的 请求， 就 立即 去 做饭。 在这里， 命令 的 请求 和 实现 就 完成 了解 耦。 模拟 这个 过程， 首先 定义 厨师 角色， 厨师 进行 实际 的 做饭、 烧 汤 的 工作。 SRP 是最 简单 的 原则 之一， 也是 最难 做好 的 原则 之一。 我们 会很 自然地 将 职责 连接 在一起。 找到 并且 分离 这些 职责 是 软件 设计 需要 达到 的 目的。 一些 简单 的 应该 遵循 的 做法 如下： ·根据 业务 流程， 把 业务 对象 提炼 出来。 如果 业务业务 流层 的 链路 太 复杂， 就把 这个 业务 对象 分离 为多 个 单一 业务 对象。 当 业务 链 标准化 后， 对 业务 对象 的 内部 情况 做 进一步 处理。 把 第一次 标准化 视为 最高层 抽象， 第二次 视为 次 高层 抽象， 以此类推， 直到“ 恰如其分” 的 设计 层次。 ·职责 的 分类 需要 注意。 有 业务 职责， 还要 有 脱离 业务 的 抽象 职责， 从 认识 业务 到 抽象 算法 是一 个 层层 递进 的 过程。 就好 比 命令 模式 中的 顾客， 服务员 和 厨师 的 职责， 作为 老板（ 即 设计师） 的 你 需要 规划 好 各自 的 职责 范围， 既要 防止 越俎代庖， 也要 防止 互相 推诿。 强迫一个类去实现接口中的所有方法，还要编写哑方法，这样的接口就是胖接口 所以需要接口隔离，接口隔离就是提供定制化服务设计的原则 开放封闭原则，对抽象编程，而不对具体编程 Open模块的行为必须是开放的、支持扩展的，而不是僵化的 Closed在对模块的功能进行扩展时，不应该影响或大规模的影响已有的程序模块 因为 抽象 相对 稳定。 让 类 依赖于 固定 的 抽象， 这样 的 修改 就是 封闭 的； 而 通过 面向 对象 的 继承 和 对 多 态 机制， 可以 实现 对 抽象 体 的 继承， 通过 覆 写 其 方法 来 改变 固有 行为， 实现 新的 扩展 方法， 所以 对于 扩展 就是 开放 的。 1） 在 设计 方面 充分 应用“ 抽象” 和“ 封装” 的 思想。 一方面 也就是 要在 软件 系统 中 找出 各种 可能 的“ 可变 因素”， 并将 之 封装 起来； 另一方面， 一种 可变性 因素 不应 当 散落 在 多个 不同 代码 模块 中， 而 应当 被 封装 到 一个 对象 中。 2） 在 系统 功能 编程 实现 方面 应用 面向 接口 的 编程。 当 需求 发生 变化 时， 可以 提供 该 接口 新的 实现 类， 以求 适应 变化。 面向 接口 编程 要求 功能 类 实现 接口， 对象 声明 为 接口 类型。 在 设计 模式 中， 装饰 模式 比较 明显 地 用到 了 OCP。 替换原则，里氏替换原则，子类必须能够替换成他们的基类 LSP，指出： 子类 型 必须 能够 替换 掉 它们 的 父 类型、 并 出 现在 父 类 能够 出现 的 任何 地方。 ·父 类 的 方法 都要 在 子类 中 实现 或者 重写， 并且 派生 类 只 实现 其 抽象 类 中 声明 的 方法， 而 不应 当 给出 多余 的 方法 定义 或 实现。 ·在 客户 端 程序 中 只 应该 使用 父 类 对象 而 不应 当 直接 使用 子类 对象， 这样 可以 实现 运 行期 绑 定（ 动态 多 态）。 如果 A、 B 两个 类 违反 了 LSP 的 设计， 通常 的 做法 是 创建 一个 新的 抽象 类 C， 作为 两个 具体 类 的 超 类， 将 A 和 B 的 共同 行为 移动 到 C 中， 从而 解决 A 和 B 行为 不完全 一致 的 问题。 LSP 中 代换 的 不仅仅是 功能， 还包括 语意。 试 思考： 白马 可以 代换 马， 而 牛 同样 作为 劳力， 可 代换 马 否？ 高跟鞋 也是 鞋子， 男人 穿 高跟鞋 又 是否 能接受？ 在前面 的 多 态， 继承 这 几 节 的 内容 里， 已经 涉及 LSP， 包括 使用 多 态 实现 隐藏 基 类 和 派生 类 对象 的 区别， 以及 使用 组合 的 方式 解决 继承 中的 基 类 与 派生 类（ 即 子类） 中的 不符合 语意 的 情况。 PHP 对 LSP 的 支持 并不 好， 缺乏 向上 转型 等 概念， 只能 通过 一些 曲折 的 方法 实现， 此处 不再 赘述。 依赖 倒置 原则 ·上层 模块 不应该 依赖于 下层 模块， 它们 共同 依赖于 一个 抽象（ 父 类 不能 依赖 子类， 它们 都要 依赖 抽象 类）。 ·抽象 不能 依赖于 具体， 具体 应该 要 依赖于 抽象。 很多 文章 里 提到 IOC（ Inversion Of Control） 概念， 实际上， IOC 是 依赖 倒置 原则（ Dependence Inversion Principle， DIP） 的 同义词。 而在 提 IOC 的 时候， 你 可能 还会 看到 有人 提起 DI 等 概念。 DI， 即 依赖 注入， 一般 认为， 依赖 注入（ DI） 和 依赖 查找（ DS） 是 IOC 的 两种 实现。 如何 满足 DIP： ·每个 较高 层次 类 都为 它 所需 要的 服务 提出 一个 接口 声明， 较低 层次 类 实现 这个 接口。 ·每个 高层 类 都 通过 该 抽象 接口 使用 服务。 所以 现在 比较 流行 的 还 是以 类 为主 的 开放 方式， 即 抛弃 或 精简 经典 的 MVC 理论， 很 少用 和 几乎 不用 设计 模式， 以 类 加 代码 模块 的 方式 进行 代码 组织。 ·PHP 只是 一个 脚本 语言、 一门 工具 而已。 （编辑：云计算网_韶关站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330456号