本周系统设计复习：
- 你应该知道的 Apache Kafka 基础
- 面向对象编程的基本支柱
- 你必须知道的 6 个顶级多线程设计模式
- C++、Java、Python 如何工作？
- 解释 9 种 API 测试类型
- REST API vs. GraphQL
面向对象编程的四大支柱
抽象、封装、继承和多态是面向对象编程的四大支柱。它们意味着什么？
1. 抽象（Abstraction）
这是隐藏实现细节并仅显示对象基本特征的过程。例如，具有抽象停止方法的 Vehicle 类。
2. 封装（Encapsulation）
它涉及将数据（字段）和方法包装在单个单元（类）中，并使用访问修饰符限制直接访问。例如，带有公共 getter 和 setter 的私有字段。
3. 继承（Inheritance）
从现有类（父类）创建新类（子类）的过程，继承属性和方法，从而促进代码重用。例如，Car 类继承自 Vehicle 类。
4. 多态（Polymorphism）
它允许方法根据它们被调用的对象表现不同。当两个类型共享继承链时，它们可以互换使用而不出错。
6 个多线程设计模式
多线程使单个程序或进程能够并发执行多个任务。每个任务是一个线程。将线程视为轻量级执行单元，共享进程的资源，如内存空间。
然而，多线程也引入了复杂性，如同步、通信和潜在的竞争条件。这就是模式帮助的地方。
1. 生产者 - 消费者模式（Producer-Consumer Pattern）
此模式涉及两种类型的线程：生成数据的生产者和处理该数据的消费者。阻塞队列充当两者之间的缓冲区。
2. 线程池模式（Thread Pool Pattern）
在此模式中，有一个 worker 线程池可以重用于执行任务。使用池消除了创建和销毁线程的开销。非常适合执行大量短寿命任务。
3. Futures 和 Promises 模式（Futures and Promises Pattern）
在此模式中，promise 是保存最终结果的对象，future 提供访问结果的方式。这非常适合并发执行长时间运行的操作而不阻塞主线程。
4. 监视器对象模式（Monitor Object Pattern）
确保一次只有一个线程可以访问或修改对象内的共享资源。这帮助防止竞争条件。当你需要保护共享数据或资源免受并发访问时，需要此模式。
5. 屏障模式（Barrier Pattern）
同步一组线程。每个线程执行直到到达代码中的屏障点并阻塞，直到所有线程到达相同的屏障。非常适合需要在开始下一阶段之前到达特定阶段的并行任务。
6. 读写锁模式（Read-Write Lock Pattern）
它允许多个线程从共享资源读取，但一次只允许一个线程写入它。非常适合管理读取比写入更频繁的共享资源。
编译语言如何工作
下图显示了编译和执行如何工作。
编译语言
编译语言由编译器编译成机器码。机器码稍后可以由 CPU 直接执行。示例：C、C++、Go。
字节码语言
像 Java 这样的字节码语言，首先将源代码编译成字节码，然后 JVM 执行程序。有时 JIT（即时）编译器将源代码编译成机器码以加速执行。示例：Java、C#。
解释语言
解释语言不编译。它们在运行时由解释器解释。示例：Python、Javascript、Ruby。
编译语言通常比解释语言运行更快。
9 种 API 测试类型
冒烟测试（Smoke Testing） 在 API 开发完成后完成。简单验证 API 是否工作，没有破坏。
功能测试（Functional Testing） 基于功能需求创建测试计划，并将结果与预期结果比较。
集成测试（Integration Testing） 此测试组合几个 API 调用以执行端到端测试。测试服务间通信和数据传输。
回归测试（Regression Testing） 此测试确保 bug 修复或新功能不应破坏 API 的现有行为。
负载测试（Load Testing） 通过模拟不同负载测试应用性能。然后我们可以计算应用的容量。
压力测试（Stress Testing） 我们故意对 API 创建高负载，测试 API 是否能够正常功能。
安全测试（Security Testing） 此测试针对所有可能的外部威胁测试 API。
UI 测试（UI Testing） 此测试 UI 与 API 的交互，以确保数据可以正确显示。
模糊测试（Fuzz Testing） 这将无效或意外输入数据注入 API 并尝试崩溃 API。通过这种方式，它识别 API 漏洞。
REST vs. GraphQL
当涉及到 API 设计时，REST 和 GraphQL 各有优缺点。
REST
- 使用标准 HTTP 方法，如 GET、POST、PUT、DELETE 进行 CRUD 操作
- 当你需要在独立服务/应用之间简单、统一的接口时工作良好
- 缓存策略易于实现
- 缺点是可能需要多次往返从独立端点组装相关数据
GraphQL
- 为客户端查询精确需要的数据提供单个端点
- 客户端在嵌套查询中指定所需的确切字段，服务器返回仅包含这些字段的优化负载
- 支持用于修改数据的 Mutations 和用于实时通知的 Subscriptions
- 非常适合从多个来源聚合数据，适用于快速演进的前端需求
- 然而，它将复杂性转移到客户端，如果未适当保护可能允许滥用查询
- 缓存策略可能比 REST 更复杂
REST 和 GraphQL 之间的最佳选择取决于应用和开发团队的具体需求。GraphQL 非常适合复杂或频繁变化的前端需求，而 REST 适合简单和一致合同首选的应用。
本文为学习目的的个人翻译，译文仅供参考。
原文链接：EP142: The Fundamental Pillars of Object-Oriented Programming。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。