mirror of
https://github.com/Estom/notes.git
synced 2026-04-09 22:09:28 +08:00
设计模式完成
This commit is contained in:
@@ -13,7 +13,7 @@
|
||||
默认构造(无参) T()
|
||||
|
||||
拷贝构造 T(const T& )
|
||||
移动构造 T()
|
||||
移动构造 T(T&&)
|
||||
|
||||
拷贝赋值 T& operator=(T& )
|
||||
移动赋值 T& operator=(T&& )
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
## 1 继承
|
||||
|
||||
### 定义基类
|
||||
```
|
||||
```c++
|
||||
class Quote{
|
||||
public:
|
||||
Quote() = default;
|
||||
@@ -21,7 +21,7 @@ protected:
|
||||
};
|
||||
```
|
||||
### 定义派生类
|
||||
```
|
||||
```c++
|
||||
class Bulk_quote:public Quote{
|
||||
public:
|
||||
Bulk_quote()=default;
|
||||
@@ -93,7 +93,7 @@ protected:
|
||||
|
||||
### 编译时名字查找
|
||||
|
||||
* 引用或指针的静态类型决定了该对象有哪些成员是可见的。一个基类的引用和指针只能访问基类的成员。即是动态对象是其派生类。
|
||||
* 引用或指针的静态类型决定了该对象有哪些成员是可见的。一个基类的引用和指针只能访问基类的成员。即使动态对象是其派生类。
|
||||
|
||||
### 名字冲突与继承
|
||||
* 派生了重用定义在直接基类或间接基类中的名字,会屏蔽定义在外层作用域基类中的名字
|
||||
|
||||
@@ -66,7 +66,7 @@ int main(){
|
||||
```
|
||||
### 实现条件
|
||||
运行时多态的条件:
|
||||
* 必须是j继承关系
|
||||
* 必须是继承关系
|
||||
* 基类中必须包含虚函数,并且派生类中一定要对基类中的虚函数进行重写。
|
||||
* 通过基类对象的指针或者引用调用虚函数。
|
||||
|
||||
@@ -96,7 +96,7 @@ public:
|
||||
|
||||
### 虚函数的原理
|
||||
* 除了构造函数的非静态函数都可以是虚函数。
|
||||
* 关键字virtual智能出现在类内部的声明语句之前。不能出现在类外部的函数定义。
|
||||
* 关键字virtual只能出现在类内部的声明语句之前。不能出现在类外部的函数定义。
|
||||
* 如果把一个函数声明成虚函数,则该函数在派生类中也是隐式的虚函数。(即派生类的派生类,也需要重写次函数)
|
||||
* 派生类可以不用重写虚函数。
|
||||
* 派生类可以在它重写的虚函数前使用**virtual关键字**
|
||||
|
||||
@@ -21,8 +21,8 @@ int main()
|
||||
int s1[]={1,2,3,4,5,6,7,8};
|
||||
int s2[3]={4,5,6};
|
||||
int* s3 = new int(999);
|
||||
test1(s3);
|
||||
test2(s3);
|
||||
test3(s3);
|
||||
test1(s1);
|
||||
test2(s1);
|
||||
test3(s1);
|
||||
return 0;
|
||||
}
|
||||
20
a.cpp
20
a.cpp
@@ -2,9 +2,20 @@
|
||||
#include<vector>
|
||||
|
||||
using namespace std;
|
||||
|
||||
// 重载运算符。返回流本身,用于链式法则。如果需要访问私有变量
|
||||
// 需要声明为友元。一般不需要声明为友元。
|
||||
ostream & operator<<(ostream &os, const vector<int> temp)
|
||||
{
|
||||
for(auto a : temp){
|
||||
os<<a<<" ";
|
||||
}
|
||||
os<<endl;
|
||||
return os;
|
||||
}
|
||||
int main(){
|
||||
vector<int> arr{-1, 3, -3, 4,5};
|
||||
cout<<arr<<endl;
|
||||
|
||||
vector<int> temp(arr.size()+1,0);
|
||||
for(int i=0;i<arr.size();i++){
|
||||
if(arr[i]<arr.size()+1 && arr[i]>0){
|
||||
@@ -18,4 +29,9 @@ int main(){
|
||||
cout<<i<<endl;
|
||||
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
// 测试一下友元
|
||||
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
### 知识复习——语言
|
||||
* [ ] C++
|
||||
* [x] 基础知识
|
||||
* [ ] 标准库
|
||||
* [ ] 面向对象
|
||||
* [x] 标准库
|
||||
* [x] 面向对象
|
||||
* [ ] 设计模式
|
||||
* [ ] 并行编程(并发和多线程)
|
||||
* [ ] 网络编程
|
||||
|
||||
@@ -105,6 +105,7 @@
|
||||
5. 行为型类模式使用继承描述算法和控制流;
|
||||
6. 行为型对象模式描述一组对象怎样写作完成单个对象无法完成的任务;
|
||||
|
||||
> 设计模式依赖于特定的语言和场景。这23中大部分都是基于java语言产生的设计模式。向在Python中,迭代器模式可以通过简单的__next()__函数实现,原型模式可以定义__prototype__直接实现。所以实现方法在不同的语言中差别较大。装饰器模式可以通过定义@derector类实现类装饰器,动态添加功能。
|
||||
## 2 设计模式之间的关系
|
||||
|
||||

|
||||
|
||||
@@ -10,6 +10,8 @@
|
||||
|
||||
- 如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化。对于某一职责的更改可能会损害类满足其他耦合职责的能力。这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏。
|
||||
|
||||
- **低耦合高内聚**
|
||||
|
||||
### 是什么
|
||||
|
||||
> 一个类应该有且只有一个变化的原因。
|
||||
|
||||
@@ -87,7 +87,7 @@ public class Singleton {
|
||||
}
|
||||
```
|
||||
|
||||
#### Ⅱ 饿汉式-线程安全
|
||||
### Ⅱ 饿汉式-线程安全
|
||||
|
||||
* 线程不安全问题主要是由于 uniqueInstance 被实例化多次,采取直接实例化 uniqueInstance 的方式就不会产生线程不安全问题。
|
||||
|
||||
@@ -97,7 +97,7 @@ public class Singleton {
|
||||
private static Singleton uniqueInstance = new Singleton();
|
||||
```
|
||||
|
||||
#### Ⅲ 懒汉式-线程安全
|
||||
### Ⅲ 懒汉式-线程安全
|
||||
|
||||
* 只需要对 getUniqueInstance() 方法加锁,那么在一个时间点只能有一个线程能够进入该方法,从而避免了实例化多次 uniqueInstance。
|
||||
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 工厂方法
|
||||
**别名**
|
||||
|
||||
- 虚构造器 (Virtual Constructor)
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 生成器
|
||||
**意图**
|
||||
|
||||
将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
|
||||
## 原型模式
|
||||
**别名**
|
||||
|
||||
- Clone
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 适配器模式
|
||||
**别名**
|
||||
|
||||
- 包装器(Wrapper)
|
||||
@@ -60,9 +61,7 @@ Adapter
|
||||
目的是将接口部分和实现部分分离,从而对它们可以较为容易也相对独立的加以改变。而
|
||||
Adapter 则意味着改变一个已有对象的接口。
|
||||
|
||||
- Decorator 模式增强了其他对象的功能而同时又不改变它的接口。因此 Decorator
|
||||
对应用程序的透明性比 Adapter 要好。结果是 Decorator 支持递归组合,而 Adapter
|
||||
无法实现这一点。
|
||||
- Decorator 模式增强了其他对象的功能而同时又不改变它的接口。因此 Decorator对应用程序的透明性比 Adapter 要好。结果是 Decorator 支持递归组合,而Adapter无法实现这一点。
|
||||
|
||||
- Proxy 模式在不改变它的接口的条件下,为另一个对象定义了一个代理。
|
||||
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 桥接
|
||||
**别名**
|
||||
|
||||
- Handle
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
## 组合模式
|
||||
|
||||
**意图**
|
||||
|
||||
将对象组合成树形结构以表示 “部分-整体” 的层次结构。
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 装饰器模式
|
||||
**别名**
|
||||
|
||||
- 包装器(Wrapper)
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 享元模式
|
||||
**意图**
|
||||
|
||||
运用共享技术有效地支持大量细粒度的对象。
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 责任链模式
|
||||
**意图**
|
||||
|
||||
使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
|
||||
## 访问者模式
|
||||
**意图**
|
||||
|
||||
表示一个作用于某对象结构中的各元素的操作。
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 命令模式
|
||||
**别名**
|
||||
|
||||
- Action
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
## 备忘录模式
|
||||
**别名**
|
||||
|
||||
- Token
|
||||
|
||||
0
设计模式/E MVC设计模式.md
Normal file
0
设计模式/E MVC设计模式.md
Normal file
74
设计模式/面试总结.md
Normal file
74
设计模式/面试总结.md
Normal file
@@ -0,0 +1,74 @@
|
||||
### 创建型
|
||||
单例模式:某个类只能有一个实例,提供一个全局的访问点。
|
||||
|
||||
简单工厂:一个工厂类根据传入的参量决定创建出那一种产品类的实例。
|
||||
|
||||
工厂方法:定义一个创建对象的接口,让子类决定实例化那个类。
|
||||
|
||||
抽象工厂:创建相关或依赖对象的家族,而无需明确指定具体类。
|
||||
|
||||
生成器模式:封装一个复杂对象的构建过程,并可以按步骤构造。
|
||||
|
||||
原型模式:通过复制现有的实例来创建新的实例。
|
||||
|
||||
### 结构型
|
||||
> 这几个都很相似,实现方法基本一致。但是功能略微有区别,应用场景不太一样。
|
||||
|
||||
适配器模式:将一个类的方法接口转换成客户希望的另外一个接口。
|
||||
* 为了适应某些接口。依赖当前对象,生成新的接口。
|
||||
|
||||
|
||||
桥接模式:将抽象部分和它的实现部分分离,使它们都可以独立的变化。
|
||||
* 与策略模式完全一致。接口与实现分离。
|
||||
|
||||
|
||||
组合模式:将对象组合成树形结构以表示“”部分-整体“”的层次结构。
|
||||
* 树节点的典型表示。但每个节点可以有自己不同的属性,可以是不同的子类。
|
||||
|
||||
|
||||
装饰模式:动态的给对象添加新的功能。
|
||||
* 动态添加功能。原来的接口不变。Python中的derector。想在工程中使用这个功能的。但是通过桥接模式、适配器模式两层结构也解决了问题。在服务提供端,提供了抽象的算法接口。然后依赖一个实例化的类,适配grpc的接口。在服务访问端,使用代理模式,提供相同的接口访问远程对象。grpc本身应道反射机制。桥接模式本质上与策略模式一致。
|
||||
|
||||
|
||||
代理模式:为其他对象提供一个代理以便控制这个对象的访问。
|
||||
* 远程接口。
|
||||
|
||||
~~亨元(蝇量)模式:通过共享技术来有效的支持大量细粒度的对象。~~
|
||||
|
||||
|
||||
外观模式:对外提供一个统一的方法,来访问子系统中的一群接口。
|
||||
|
||||
### 行为型
|
||||
|
||||
~~模板模式:定义一个算法结构,而将一些步骤延迟到子类实现。~~
|
||||
|
||||
~~解释器模式:给定一个语言,定义它的文法的一种表示,并定义一个解释器。~~
|
||||
|
||||
策略模式:定义一系列算法,把他们封装起来,并且使它们可以相互替换。
|
||||
* 一个算法有多种实现方式。例如排序。可以通过快排、归并排序等不同的策略实现。
|
||||
|
||||
|
||||
状态模式:允许一个对象在其对象内部状态改变时改变它的行为。
|
||||
* 典型的有限状态机机制。在每种状态的时候,有不同的状态转移方法。可以参考力扣上状态机的题。重新理解一下。
|
||||
|
||||
|
||||
观察者模式:对象间的一对多的依赖关系。
|
||||
* 典型的事件响应机制。在一个对象上,注册多个观察者(订阅者)。当发生事件的时候,通知观察者执行相关的操作。
|
||||
|
||||
|
||||
备忘录模式:在不破坏封装的前提下,保持对象的内部状态。
|
||||
|
||||
中介者模式:用一个中介对象来封装一系列的对象交互。
|
||||
* 多对多模式网状依赖关系结构。使得多个对象依赖同一个对象,完成操作。
|
||||
|
||||
|
||||
命令模式:将命令请求封装为一个对象,使得可以用不同的请求来进行参数化。
|
||||
* 典型的回调机制。但是是一个回调对象。传递给另一个对象,另一个对象执行过程中,在某些特定时机调用该回调对象。
|
||||
|
||||
访问者模式:在不改变数据结构的前提下,增加作用于一组对象元素的新功能。
|
||||
|
||||
责任链模式:将请求的发送者和接收者解耦,使的多个对象都有处理这个请求的机会。
|
||||
* 典型的request、response处理过程。多种不同的request分步解析处理。分发给不同的人。
|
||||
|
||||
迭代器模式:一种遍历访问聚合对象中各个元素的方法,不暴露该对象的内部结构。
|
||||
* 编程可迭代对象。不同的语言实现方法,都差不多。
|
||||
Reference in New Issue
Block a user