面向对象编程（Object-Oriented Programming，简称 OOP）是一种以“对象”为核心的编程范式。它将数据（属性）与操作数据的方法（行为）封装在对象中，通过类（Class）来定义对象的蓝图。OOP 强调模块化、可重用性和可维护性，主要特征包括封装、继承、多态和抽象。自 20 世纪 60 年代 Simula 语言诞生以来，OOP 已成为现代软件开发的主流范式，广泛应用于企业级系统、游戏开发、GUI 框架等领域。
1 基本概念
1.1 对象
对象是面向对象编程中的基本单元，代表现实世界或概念世界中的一个实体。每个对象拥有自己独立的身份、属性和行为。
1.1.1 属性
属性（也称为字段或成员变量）是对象所拥有的数据，描述了对象的状态。例如，一个“汽车”对象的属性可能包括颜色、品牌、当前速度等。属性可以是各种数据类型（整数、字符串、引用等），并且每个对象实例的属性值通常彼此独立。
1.1.2 方法
方法（也称为成员函数）是定义在对象上的可执行操作，用于修改或访问对象的属性。方法可以接收参数、返回值，并可能产生副作用。例如，“汽车”对象可以有“加速()”、“刹车()”等方法。
1.1.3 状态与行为
状态是对象在某一时刻所有属性的集合，行为是对象通过方法对外提供的功能和响应。对象通过其状态和行为与其他对象交互，从而构建出复杂的系统。设计良好的对象往往要求状态与行为紧密关联，避免“数据对象”和“行为函数”的割裂。
1.2 类
类是创建对象的模板或蓝图。类定义了一组属性（数据）和方法（操作），所有由该类创建的对象共享相同的结构和行为，但拥有各自独立的状态。
1.2.1 类的定义
类定义通常包括类名、属性声明和方法实现。例如在 Java 中：
class Car {
String color;
int speed;
void accelerate(int increment) { speed += increment; }
}类本身不占用内存，仅作为编译时或运行时的类型描述。
1.2.2 实例化
实例化（Instantiation）是从类创建具体对象的过程，通常使用 new 关键字（或类似机制）。每个实例在内存中拥有独立的属性存储空间。例如 Car myCar = new Car(); 创建了一个 Car 类型的对象，其初始状态由构造方法决定。
1.2.3 静态成员与实例成员
静态成员（static member）属于类本身，而非类的实例。静态属性在所有实例间共享，静态方法只能访问静态成员。实例成员则属于每个对象，互不干扰。常见应用：工具方法（如 Math.max()）和单例模式中的实例持有者。
1.3 封装
封装是将对象的内部细节隐藏起来，仅通过公开接口与外界交互的机制。封装是实现信息隐藏（Information Hiding）和模块化的核心手段。
1.3.1 访问修饰符
访问修饰符控制类成员的可见性。常见的有：
public：任何地方都可访问。protected：本类及子类可访问。private：仅本类内部可访问。- 默认（包级私有，某些语言如 Java）则允许同一包内访问。
合理使用访问修饰符可保护对象内部状态不被意外修改。
1.3.2 信息隐藏与接口
信息隐藏原则强调：对象的内部实现细节不应暴露给外部调用者。封装通过提供公共方法（接口）来替代直接字段访问，例如使用 Getter/Setter 或业务方法。这样可在不改变接口的前提下修改内部实现，提升了系统的灵活性和安全性。
1.3.3 封装的好处
封装带来以下优点：
- 降低耦合度：调用者仅依赖接口，内部变化不影响外部。
- 提高可维护性：可以安全地重构内部逻辑。
- 增强安全性：防止外部代码直接篡改内部数据，例如通过校验逻辑的 Setter 控制取值范围。
1.4 继承
继承是一种从已有类（父类或基类）派生新类（子类或派生类）的机制，子类自动获得父类的非私有属性和方法，并可以扩展或修改它们。
1.4.1 单继承与多继承
- 单继承：一个子类只能有一个直接父类。Java、C# 采用此模式，避免了“菱形继承”问题（即两个父类具有相同签名方法导致冲突）。
- 多继承：一个子类可继承多个父类。C++ 支持多继承，但需小心处理命名冲突和虚继承（virtual inheritance）来避免二义性。
目前多数现代语言倾向单继承 + 接口（Interface）的方案来获得多继承的灵活性，同时规避复杂性。
1.4.2 子类与父类
子类（Subclass）继承父类（Superclass）的成员（除私有成员外）。子类可以：
- 添加新的属性和方法。
- 重写（Override）父类方法以改变行为。
- 通过
super关键字调用父类构造器或方法。
继承关系形成类层次（Class Hierarchy），典型的例子是“动物 → 哺乳动物 → 狗”。
1.4.3 重写（Override）
重写是指子类提供与父类方法签名完全相同的实现，以替换父类的行为。重写通常要求语言支持动态绑定（虚函数），以便运行时根据实际对象类型调用对应的方法。重写的方法不能拥有更严格的访问权限（如父类为 public，子类不能降为 private）。
1.4.4 继承与组合的选择
设计原则“组合优于继承”（Composition over Inheritance）认为：当需要复用功能时，优先使用组合（在一个对象中包含另一个对象）而非继承，因为继承层次不易变更且容易导致脆弱的基类问题。例如，一个“汽车”类可以通过组合拥有“发动机”对象，而非继承“发动机”的属性和方法。
1.5 多态
多态（Polymorphism）指同一操作作用于不同对象时产生不同的执行结果。多态是 OOP 灵活性的关键特征。
1.5.1 编译时多态（重载）
编译时多态主要通过方法重载（Overloading）实现：同一类中定义多个同名方法，但参数列表（个数、类型或顺序）不同。编译器根据调用时传入的参数决定调用哪个版本。重载属于静态绑定，发生在编译期。
1.5.2 运行时多态（虚函数/动态绑定）
运行时多态通过继承和虚函数（或称为 virtual 方法）实现：父类引用指向子类对象，调用虚方法时实际执行的是子类的重写版本。动态绑定（Dynamic Binding）在运行期根据对象实际类型决定调用哪个方法，从而实现了“一种接口，多种实现”。
1.5.3 接口与抽象类
接口（Interface）定义了一组方法签名，不包含实现，实现类必须实现所有接口方法。抽象类（Abstract Class）可以包含部分实现和抽象方法。两者都支持多态：变量可以声明为接口或抽象类类型，并指向任一实现类的实例。接口提供了更松散的多态契约，而抽象类则在代码复用和多态之间取得平衡。
1.6 抽象
抽象（Abstraction）指隐藏不必要的细节，只暴露与用户相关的功能。它是 OOP 四大基本特征之一，与封装紧密相关。
1.6.1 抽象类
抽象类使用 abstract 关键字声明，不能被直接实例化。它可以包含普通方法和抽象方法（无实现体）。子类必须实现所有抽象方法（除非子类也是抽象类）。抽象类常用于定义部分通用逻辑，同时强迫子类提供特定行为的实现。
1.6.2 接口
接口是一种更纯粹的抽象形式，只包含方法签名（以及可能的一些默认方法、静态方法，视语言版本而定），不包含状态。Java 8 之前接口只有抽象方法；Java 8 引入了 default 方法和 static 方法。接口可以多继承（一个类可实现多个接口），适用于定义跨类别的契约。
1.6.3 抽象与实现的分离
抽象使得程序员可以专注于“做什么”而非“怎么做”。通过分层抽象（如 MVC 架构中的 Model-View-Controller），系统不同部分可以独立开发和测试。实现细节的变化不会影响依赖于抽象的调用者，从而降低了变更成本。
2 历史与演进
2.1 起源：Simula 与 Smalltalk
面向对象思想的先驱是 1960 年代诞生的 Simula 语言，它引入了“类”和“对象”的概念，用于模拟离散事件系统。1970 年代，Alan Kay 等人设计了 Smalltalk，将 OOP 理念推向完善：一切皆对象（包括整数、类本身），并提出了消息传递（Message Passing）机制。Smalltalk 是第一个纯粹的面向对象语言，其集成开发环境（IDE）和图形界面也对后世影响深远。
2.2 发展：C++、Java、C# 等主流语言
1980 年代，Bjarne Stroustrup 在 C 语言基础上增加了类特性，创造了 C++，使 OOP 在工业界快速普及。1990 年代，Java 诞生，删除了 C++ 中易错的特性（如指针、多继承），引入垃圾回收和虚拟机，成为企业级开发的首选。2000 年代初期，微软发布 C#，结合了 Java 的简洁性与 C++ 的灵活度，并在 .NET 平台上蓬勃发展。这些语言使 OOP 成为主流范式。
2.3 当代趋势：函数式与 OOP 的融合
21 世纪以来，函数式编程（FP）特性逐渐渗透到 OOP 语言中：Java 8 引入 Lambda 表达式和 Stream API；C# 有 LINQ；JavaScript/TypeScript 结合了原型继承与函数式特征。Python 和 Ruby 本身即为多范式语言。如今开发者倾向于混合使用两种范式：利用 OOP 组织大规模系统结构，利用 FP 处理数据流和并发。设计模式如策略模式、命令模式也越来越多地使用函数式实现。
3 核心设计原则
3.1 SOLID 原则
SOLID 是由 Robert C. Martin 总结的五个面向对象设计原则的缩写，旨在使软件更易于维护和扩展。
3.1.1 单一职责原则（SRP）
一个类应当只负责一项职责。如果一个类承担了多个不相干的功能（例如既处理业务逻辑又负责数据持久化），那么任何一个职责的变化都可能影响该类。遵循 SRP 可以使类更专注、更易测试。
3.1.2 开闭原则（OCP）
软件实体（类、模块、函数）应当对扩展开放，对修改关闭。即在添加新功能时，尽量通过扩展（如创建子类、实现接口）而非修改现有代码来实现。这要求系统设计时充分考虑抽象层。
3.1.3 里氏替换原则（LSP）
子类对象必须能够替换父类对象而不改变程序的正确性。通俗地说，派生类应当强化基类的行为，而非削弱。例如，“正方形”继承自“矩形”时可能违反 LSP，因为设置宽度时会影响高度，导致父类约定不符。
3.1.4 接口隔离原则（ISP）
客户端不应依赖它不需要的接口。如果一个接口包含太多方法，实现类可能被迫实现无用的空方法。应把臃肿的接口拆分为多个小接口，让客户端只依赖它们实际需要的方法。
3.1.5 依赖反转原则（DIP）
高层模块不应依赖低层模块，二者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。典型做法是使用依赖注入（Dependency Injection），让框架或容器将具体实现注入到高层模块中，从而降低耦合。
3.2 迪米特法则（最少知识原则）
一个对象应当尽量少地了解其他对象的内部细节。具体来说，一个方法的内部不应通过链式调用（如 a.getB().getC().doSomething()）访问相隔很远的对象，而应通过直接的方法委托。该原则降低了对象间的耦合度，提高了模块独立性。
3.3 组合优于继承
继承容易形成深层次类结构，任何上层变化都可能波及下层（脆弱的基类问题）。组合通过在一个类中持有另一个类的引用来复用功能，从而保持清晰的间接口。例如，用“拥有”（Has-A）关系替代“是”（Is-A）关系，使得系统更灵活、更易修改。
4 常见设计模式
设计模式是针对常见设计问题的可复用解决方案，由 Gamma、Helm、Johnson、Vlissides（GoF）在《设计模式》一书中系统化整理。以下按三大分类列举典型模式。
4.1 创建型模式
创建型模式关注对象的创建机制，将实例化过程与客户端解耦。
4.1.1 单例模式
确保一个类只有一个实例，并提供全局访问点。常用于线程池、数据库连接池、配置管理对象。实现方式通常为私有构造器 + 静态 getInstance() 方法。需注意线程安全问题。
4.1.2 工厂模式
将对象的创建逻辑封装在工厂类或工厂方法中，客户端通过工厂获取所需对象，无需直接使用 new。简单工厂、工厂方法模式和抽象工厂模式提供了不同程度的灵活性，适用于对象创建过程复杂或需要根据条件创建不同子类的情况。
4.1.3 建造者模式
将复杂对象的构建过程与表示分离，允许用户通过步骤化的方式创建对象，最终通过 build() 方法生成完整对象。经典应用：Java 中的 StringBuilder；构建一个具有大量可选参数的配置对象时尤为有用，避免构造器参数过多。
4.2 结构型模式
结构型模式关注类与对象的组合，形成更大的结构，同时保持灵活性和效率。
4.2.1 适配器模式
将一个类的接口转换成客户端期望的另一个接口，从而解决接口不兼容的问题。适配器可以使原本不能一起工作的类协同工作。分为类适配器（继承）和对象适配器（组合）。
4.2.2 装饰器模式
动态地给一个对象添加额外的职责，比继承更灵活。装饰器模式和继承不同，它通过包装原有对象，在调用前后执行附加逻辑，且可以叠加多层。例如 Java I/O 中的 BufferedInputStream 装饰 FileInputStream。
4.2.3 代理模式
为另一个对象提供一个替身或占位符，以控制对原始对象的访问。常见类型包括虚代理（延迟加载）、保护代理（权限控制）、远程代理（RPC 调用中的本地存根）。例如 Java 中的动态代理可用于 AOP（面向切面编程）。
4.3 行为型模式
行为型模式关注对象之间的责任分配和算法交互。
4.3.1 观察者模式
定义对象间的一对多依赖关系，当一个对象（主题）状态发生变化时，所有依赖它的对象（观察者）都会得到通知并自动更新。典型应用：事件监听系统、MVC 架构中的 Model-View 绑定。
4.3.2 策略模式
定义一系列算法，把它们一个个封装起来，并且使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户端。例如支付系统中，不同的支付方式（支付宝、微信、银行卡）就是不同的策略。
4.3.3 模板方法模式
在一个方法中定义算法的骨架，而将一些步骤的实现延迟到子类中。子类可以重新定义算法的某些步骤而不改变算法结构。例如 java.util.AbstractList 中的 iterator() 方法使用了模板方法模式。
5 典型语言对比
5.1 纯面向对象语言（Java、Smalltalk）
纯面向对象语言中，一切皆为对象（包括基本类型通过“包装类”处理）。Java 虽然保留了 int 等原始类型，但总体上强调类、接口、继承和多态。Smalltalk 则更为纯粹，甚至类本身也是对象。这些语言在类型系统、垃圾回收等方面为 OOP 提供了强支撑，但也可能在函数式编程、性能调优方面有所妥协。
5.2 混合语言（C++、Python、TypeScript）
混合语言支持多种编程范式，OOP 只是其中之一。开发者可以根据场景自由选择。
5.2.1 多范式支持
C++ 除了 OOP，还支持过程式编程和泛型编程（模板）。Python 同时支持函数式特性（lambda、map/reduce）和元编程。TypeScript 作为 JavaScript 的超集，既保留了原型继承（通过 class 语法糖），又引入了接口、泛型等 OOP 特性，同时大量使用函数式风格（如 Promise、async/await）。
5.2.2 与函数式特性的结合
混合语言中 OOP 和函数式特性常共存。例如 C# 中的 LINQ 和 Lambda 表达式极大简化了集合操作；Python 支持装饰器（Decorator）这一函数式概念，常被当作 AOP 的轻量级实现。现代 TypeScript 项目也频繁使用纯函数和不可变数据，与类层次形成互补。
6 优缺点与适用场景
6.1 优点
6.1.1 代码复用与维护
通过继承和组合，可以在已有类的基础上快速构建新类，避免重复代码。封装使得内部实现变更不影响外部，降低了维护成本。
6.1.2 模块化与团队协作
OOP 鼓励将系统划分为相对独立的模块（类）。不同团队可同时开发不同类，仅需约定接口。大型项目如企业级 ERP 系统、游戏引擎普遍采用此模式。
6.1.3 扩展性与灵活性
多态和设计模式使系统可以方便地增加新功能（如新增子类实现原有接口），而无需修改现有代码。开闭原则在此发挥作用。
6.2 缺点
6.2.1 复杂性增加
对于简单问题，OOP 的类层次、接口、继承关系可能过度工程化，反而增加理解难度。新人接手时可能需要花时间梳理类图。
6.2.2 性能开销
动态绑定、虚函数表（vtable）、对象内存对齐等特性可能带来运行时开销（尤其在高性能计算领域，如游戏引擎底层常用 C 而非 C++）。此外，大量对象创建和垃圾回收也会影响性能。
6.2.3 过度设计风险
滥用继承和设计模式可能导致“巴洛克式”代码架构，为“未来可能的扩展”而预先设计过多抽象，实际却难以维护。正如谚语所说：“买来的是教训，卖出的是痛苦。”
6.3 适用场景
6.3.1 大型复杂系统
OOP 的模块化、抽象、分层思想非常适合于业务逻辑复杂、多人协作的大型软件，例如电商平台、银行系统、医疗系统。
6.3.2 GUI 与事件驱动
图形用户界面本质上是对象集合（窗口、按钮、文本框），每个控件都封装外观和行为。事件监听、回调机制也与观察者模式高度契合。几乎所有主流 GUI 框架（Qt、JavaFX、.NET WinForms）都是基于 OOP 的。
6.3.3 模拟与建模
物理仿真、游戏中的角色和地图、科学计算中的实体模型等，天然适合用对象表示。Simula 语言最初就是为此而生。OOP 的继承层次（例如“生物”→“动物”→“哺乳动物”→“长颈鹿”）可以直观反映真实世界的分类关系。
7 常见误区和“梗”
7.1 万物皆对象？不，还有原始类型
很多 OOP 语言虽然宣传“一切皆对象”，但实际底层仍保留原始类型（如 int、float）以提高性能。Java 的 int 和 Integer 之间甚至需要手动装箱拆箱，让人感叹“多此一举”。Smalltalk 和 Ruby 则真正实现了万物皆对象，但性能上有所牺牲。
7.2 “面向对象”变成“面向过程+对象”
有些开发者虽然用类来组织代码，但设计方式仍是过程式的：把类当作函数库，所有方法都写为静态方法，或者全部用 Getter/Setter，类内部没有任何封装逻辑。这种“用类写过程代码”的做法被戏称为“面向对象编程的面具”。
7.3 继承层次的“香蕉-猴子-丛林”陷阱
有一个经典的笑话：为了描述“猴子吃香蕉”这个动作，开发者设计了一个 Monkey 类继承 Animal，Banana 类继承 Fruit，接着又设计了 Jungle 类包含猴子、香蕉和丛林环境……最后整个项目变成了一个复杂的继承森林，而最简单的需求却要写几十个类。这讽刺了盲目追求继承层次导致的过度设计。
7.4 面试常考：面向对象 vs 面向切面 vs 面向接口
面试官喜欢问“三者有什么区别”。典型回答：面向对象是基础的编程范式；面向切面（AOP）是 OOP 的补充，用于横切关注点（日志、事务）；面向接口是一种设计理念，强调依赖抽象而非具体实现。有的面试者会补充说：“实际上，面向薪资编程（面向工资）才是最真实的。”——这算是一个无奈的职场梗。