一问一答 (基础知识)
面向对象设计原则概述
| 面向对象设计原则 | 缩写 | 全称 | 简述 | 理解 |
|---|---|---|---|---|
| 单一职责原则 | SRP | Single Responsibility Principle | 在一个类中，只有一个职责，而且职责十分明确 | 公平, 公平, 还是他妈的公平 |
| 开闭原则 | OCP | Open Closed Principle | 当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下， 可以扩展模块的功能，使其满足新的需求 | 老代码不改的同时还能完成新的需求 |
| 里氏替换原则 | LSP | Liskov Substitution Principle | 子类可以扩展父类的功能，但不能改变父类原有的功能 | 子类不会因为实现了自己独有的方法而显得和父类有些许不同 |
| 接口隔离原则 | ISP | Interface Segregation Principle | 在不影响其他类的情况下，提取出公共的接口 | 并不是所有人买手机的人都需要前置摄像头 |
| 依赖倒置原则 | DIP | Dependence Inversion Principle | 在程序运行时，不应该依赖于其他类，而应该依赖于抽象 | 如果所有类用上了接口 |
| 以上就是 | SOLID | |||
| 迪米特法则 | LKP | Least Knowledge Principle | 只与你的直接朋友交谈，不跟“陌生人”说话 | |
| 合成复用原则 | CRP | Composite Reuse Principle | 尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现 |
设计模式概述
| 设计模式 | 简述 | 归纳 | 目的 | 案例 |
|---|---|---|---|---|
| 工厂模式 (Factory Pattern) | 不同条件下创建不同实例 | 产品标准化, 生产更高效 | 封装创建细节 | 实体工厂 |
| 单例模式 (Singleton Pattern) | 保证一个类仅有一个实例, 并提供全局访问点 | 世上只有一个我 | 保证独一无二 | 配置 |
| 原型模式 (Prototype Pattern) | 创建一个对象拷贝, 并允许修改拷贝 | 超多重影分身 | 高效创建对象 | 预制体 |
| 建造者模式 (Builder Pattern) | 用来创建复杂的复合对象 | 高中低配置 | 开放性个性配置步骤 | 选配 |
| 以上就是创建型设计模式 | 简单来说就是用来创建对象的 | |||
| 代理模式 (Proxy Pattern) | 为其他对象提供一直代理以控制对这个对象的访问 | 没有资源没时间，得找别人来帮忙 | 增强职责 | 媒婆 |
| 外观模式 (Facade Pattern) | 对外提供一个统一的接口用来访问子系统 | 打开一扇门，通向全世界 | 统一访问入口 | 前台 |
| 装饰器模式 (Decorator Pattern) | 为对象添加新功能 | 他大舅他二舅都是他舅 | 灵活扩展、同宗同源 | 煎饼 |
| 享元模式 (Flyweight Pattern) | 使用对象池来减少重复对象的创建 | 优化资源配置，减少重复浪费 | 共享资源池 | 全国社保联网 |
| 组合模式 (Composite Pattern) | 将整体与局部（树形结构）进行递归组合， 让客户端能够以一种的方式对其进行处理 | 人在一起叫团伙，心在一起叫团队 | 统一整体和个体 | 组织架构树 |
| 适配器模式 (Adapter Pattern) | 将原来不兼容的两个类融合在一起 | 万能充电器 | 兼容转换 | 电源适配 |
| 桥接模式 (Bridge Pattern) | 将两个能够独立变化的部分分离开来 | 约定优于配置 | 不允许用继承 | 桥 |
| 以上就是结构型设计模式 | 关注类和对象的组合 | |||
| 模板模式 (Template Method Pattern) | 定义一套流程模板，根据需要实现模板中的操作 | 流程全部标准化，需要微调请覆盖 | 逻辑复用 | 把大象装进冰箱 |
| 策略模式 (Strategy Pattern) | 封装不同的算法，算法之间能互相替换 | 条条大道通罗马，具体哪条你来定 | 把选择权交给用户 | 选择支付方式 |
| 责任链模式 (Chain of Responsibility Pattern) | 拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。 将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。 | 各人自扫门前雪，莫管他们瓦上霜 | 解耦处理逻辑 | 踢皮球 |
| 迭代器模式 (Iterator Pattern) | 提供一种方法顺序访问一个聚合对象中的各个元素 | 流水线上坐一天，每个包裹扫一遍 | 统一对集合的访问方式 | 逐个检票进站 |
| 命令模式 (Command Pattern) | 将请求封装成命令，并记录下来，能够撤销与重做 | 运筹帷幄之中，决胜千里之外 | 解耦请求和处理 | 遥控器 |
| 状态模式 (State Pattern) | 根据不同的状态做出不同的行为 | 状态驱动行为，行为决定状态 | 绑定状态和行为 | 订单状态跟踪 |
| 备忘录模式 (State Pattern) | 保存对象的状态，在需要时进行恢复 | 失足不成千古恨，想重来时就重来 | 备份、后悔机制 | 草稿箱 |
| 中介者模式 (Mediator Pattern) | 允许对象组合实现与继承相同的代码重用，负责任务的调用和分配 | 联系方式我给你，怎么搞定我不管 | 统一管理网状资源 | 朋友圈 |
| 解释器模式 (Interpreter Pattern) | 给定一个语言，定义它的语法表示，并定义一个解释器， 这个解释器使用该标识来解释语言中的句子 | 我想说”方言“，一切解释权都归我 | 实现特定语法解析 | 摩斯密码 |
| 观察者模式 (Observer Pattern) | 状态发生改变时通知观察者，一对多的关系 | 到点就通知我 | 解耦观察者与被观察者 | 闹钟 |
| 访问者模式 (Visitor Pattern) | 稳定数据结构，定义新的操作行为 | 横看成岭侧成峰，远近高低各不同 | 解耦数据结构和数据操作 | KPI考核 |
| 委派模式 (Delegate Pattern) | 允许对象组合实现与继承相同的代码重用，负责任务的调用和分配 | 这个需求很简单，怎么实现我不管 | 只对结果负责 | 授权委托书 |
| 以上就是行为型设计模式 | 关注对象之间的通信 |
TCP/IP
第一次握手: 客户端向服务端发送同步请求包(syn). -> 此时客户端仅知道自己可以发送包, 但不知道能不能发成功. 第二次握手: 服务端会回复一个粘包(syn+ask). -> 如果客户端接收到了, 说明自己确实可以发送包. 但!服务端并不知道自己发送的包对方收不收得到. 第三次握手: 客户端也回复一个(ask). -> 告知服务端, 他发的包是可以收到的.