计算机世界中的大设计
网络
提供连接性和数据传输能力，提供资源共享与远程访问能力。
驱动
系统调用是应用程序和内核之间的接口，驱动程序是内核和硬件之间的接口。
-
驱动的inbox型态和outbox型态
Inbox型态：
在inbox型态中，驱动程序从硬件设备接收输入数据，并将其传递给操作系统内核进行处理。 驱动程序负责接收设备产生的中断或输入/输出请求，并通过操作系统提供的接口将数据传递给内核进行处理。 内核根据数据的类型和来源，执行相应的处理操作，如设备初始化、数据缓冲区的管理、数据解码、错误处理等。 在inbox型态中，驱动程序扮演着数据获取和传递的角色，而内核负责实际的数据处理操作。Outbox型态：
在outbox型态中，驱动程序从内核接收处理后的数据，并将其传递给硬件设备进行输出。 驱动程序从内核获取需要输出的数据，并将其传递给设备控制器或硬件接口，以便设备能够正确地接收和处理数据。 内核在进行数据处理后，将处理结果传递给驱动程序，并由驱动程序负责将数据发送到相应的设备。 在outbox型态中，驱动程序扮演着数据传递和设备控制的角色，而内核负责数据处理和结果计算。
inbox型态和outbox型态可以根据具体的设备驱动程序和操作系统内核的设计和实现进行调整和改变。这两种通信模型的目的都是实现驱动程序与内核之间的有效数据传输和协作，以实现设备的正常工作和数据的处理。
程序设计模式
-
创建型模式（Creational Patterns）：包括单例模式（Singleton）、工厂模式（Factory）、抽象工厂模式（Abstract Factory）、建造者模式（Builder）和原型模式（Prototype）等。
-
结构型模式（Structural Patterns）：包括适配器模式（Adapter）、桥接模式（Bridge）、装饰器模式（Decorator）、外观模式（Facade）和代理模式（Proxy）等。
-
行为型模式（Behavioral Patterns）：包括观察者模式（Observer）、迭代器模式（Iterator）、策略模式（Strategy）、命令模式（Command）和模板方法模式（Template Method）等。
外观模式 建造者模式 和 模板方法模式之间的异同
相似之处：
都属于GOF设计模式中的创建型模式。
都提供了一种将创建过程进行抽象和封装的方法，以便于简化代码和提高可维护性。
都关注对象的创建和初始化过程，以及如何组织和管理对象的结构。
不同之处：
目的和使用场景不同：
外观模式（Facade Pattern）的目的是为了提供一个统一的接口，隐藏系统的复杂性，简化客户端与子系统之间的交互。它主要用于简化接口调用，提供一个高层次的接口，方便客户端使用。
建造者模式（Builder Pattern）的目的是将一个复杂对象的构建过程和表示分离，使得同样的构建过程可以创建不同的表示。它主要用于创建复杂对象，将对象的创建步骤进行组合，以便于灵活构建不同的对象。
模板方法模式（Template Method Pattern）的目的是定义一个算法的骨架，将一些步骤延迟到子类实现。它主要用于定义算法的框架，将变化的部分交给子类实现。
参与角色和关系不同：
外观模式中，外观类（Facade）提供了一个统一的接口，客户端通过调用外观类来访问子系统的功能。
建造者模式中，建造者类（Builder）负责创建产品的各个部分，并提供获取最终产品的方法，指导者类（Director）负责调用建造者的方法来创建产品。
模板方法模式中，抽象类（AbstractClass）定义一个模板方法，该方法包含了算法的骨架，还可以包含一些具体方法和钩子方法，具体的子类（ConcreteClass）实现这些具体方法和钩子方法。
关注点不同：
外观模式关注于简化接口调用，提供一个高层次的接口，隐藏系统的复杂性。
建造者模式关注于创建复杂对象，将对象的构建过程和表示分离，以便于灵活构建不同的对象。
模板方法模式关注于定义算法的框架，将变化的部分交给子类实现，保持算法的结构稳定。
总结： 外观模式、建造者模式和模板方法模式都是通过封装和抽象来简化对象的创建和使用。它们各自关注于不同的方面，解决不同的问题，并在不同的场景中有不同的应用。适用于不同的情况下选择合适的设计模式可以提高代码的可维护性和可扩展性。
设计模式的7大原则
| 设计原则 | 一句话归纳 | 目的 |
|---|---|---|
| 开闭原则 | 对扩展开放，对修改关闭 | 降低维护带来的新风险 |
| 依赖倒置原则 | 高层不应该依赖低层，要面向接口编程 | 更利于代码结构的升级扩展 |
| 单一职责原则 | 一个类只干一件事，实现类要单一 | 便于理解，提高代码的可读性 |
| 接口隔离原则 | 一个接口只干一件事，接口要精简单一 | 功能解耦，高聚合、低耦合 |
| 迪米特法则 | 不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度 | 只和朋友交流，不和陌生人说话，减少代码臃肿 |
| 里氏替换原则 | 不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义 | 防止继承泛滥 |
| 合成复用原则 | 尽量使用组合或者聚合关系实现代码复用，少使用继承 | 降低代码耦合 |