封装是什么意思？

在软件开发中，有两个相似的概念——封装和信息隐藏。有人认为这些是同义词，有人不认为，但这并不那么重要。

一段历史：David Parnassus 在 1970 年的文章“On the Criteria To Be Used in Decomposing Systems into Modules”中首次引入了信息隐藏的概念作为一个关键的设计工具。这个原则听起来是这样的：将系统分解成模块不应该基于方框图或执行流程的分析。相反，每个模块都应该在内部隐藏一些设计决策，向其客户提供最少量的有关它的信息。

这是一个小例子。

假设您正在开发一个执行重要任务的企业应用程序。任何正常的应用程序通常都需要一些配置：好吧，数据库或服务器连接参数，以及其他有价值的信息。因此，经验丰富的架构师 (*) 和同样经验丰富的客户一起被要求从配置文件中读取配置。

(*) 这不是打字错误，请勿编辑！

在与他们交谈的过程中，您了解到没有人真正知道您为什么需要从文件中读取配置、它应该具有什么格式以及应该在那里存储什么。

现在您面临一个选择：您可以在整个应用程序的偶数层中传播配置信息。每个需要一些参数的组件都将进入应用程序配置本身，从那里提取必要的数据，解析 xml 或 json 并准备好提供服务。另一方面，很明显，关于配置存储在何处以及以何种格式存储的决定在未来可能会发生变化。因此，一种更明智的解决方案是在一个模块中隐藏有关配置位置和格式的信息，例如，使用类Configuration和ConfigurationProvider. 在这种情况下，当（是的，准确地说是“何时”，而不是“如果”）需求发生变化时，只有类的实现会发生变化ConfigurationProvider该类别或配置的所有其他用户将保持不变。同样，当更改格式时，只有解析过程也会发生变化，而不会改变配置消费者。

这个例子看似牵强附会，其实不然！我们经常遇到需求的可变性，但不幸的是我们使用以下两种方法之一：

• 我们完全忽略需求变更的可能性，一切都是迎头而上或

• 我们创建了一个具有十个间接级别的超级复杂解决方案，它必须在不更改代码的情况下承受任何方向的需求变化。

一个更合理的方法位于中间的某个地方。每次我开始开发一个功能时，我都会考虑如果需求或实现细节发生重大变化，将不得不更改多少代码。话虽这么说，我不会尝试将更改数量减少到 1（好吧，就像，如果我们遵循 SRP，那么应该只有一个地方，以防需求发生变化）。我尽量让这些地方少而简单。

其实，这就是信息隐藏及其妹妹——封装的本质。

这意味着您正在与其余代码分离，并且通过更改周围代码的工作方式，封装区域保持工作状态。

通过将代码移动到一个单独的类中，您可以封装它。通过将代码移动到单独的方法或函数中，您还可以封装它。

整个实现隐藏在接口后面并通过它们工作，将第三方人员变成他们无法选择（如果语言允许）或他们可以选择的“黑匣子”，但他们明白这样做是自担风险和风险。

封装意味着隐藏。封装背后的思想是通过为用户（和程序员）提供类的接口来对用户（和程序员）隐藏类的实现。它还意味着使用访问标识符（公共、私有、受保护）隐藏数据。例如，您是一名程序员，可以访问图书馆。也就是说，你包含了某个头文件，可以访问一些类的接口，并通过这个类的方法来操作这个类的对象。这消除了破坏工作代码的可能性。像这样的东西......

有一个方法делатьСэндвич();。

实现可能非常多变：

добытьХлеб
    ржаной белый хлебРакфор
    прожарить?
    мякиш корочка
    ...

这只是挖掘基础知识。不完整的版本。
因此，至少有两个原因值得隐藏（封装，就像今天的年轻人所说）：

1. 不要用如此多样的界面吓到最终用户，因为这很吓人而且他不需要知道（简单是可用性的关键）。
2. 为了不意外和/或故意破坏三明治工厂的逻辑。