笔者的 SAP 技术交换群里，有敌人发问：
我想问一个很根底的问题，为什么类要有 friend 啊
反正我工作这些年，在 SAP 生产代码里没用过友元，只是在生产代码的单元测试代码里用过，起因也就是让单元测试代码可能拜访到被测试的生产类的公有属性。
代码如下：
SAP ABAP 的帮忙文档：
在面向对象编程中，封装是一个重要的概念，它能够将代码组织成一些独立的模块，从而进步代码的可维护性、可复用性和可扩展性。封装的核心思想是暗藏对象的实现细节，只暴露出必要的接口供其余对象应用。在这种状况下，对象之间的交互只能通过裸露的接口来进行，从而实现了对象之间的隔离和爱护。
然而，在理论的开发过程中，咱们有时须要在对象之间共享一些公有信息，以便更好地实现一些性能。这时，就能够应用 friend 机制来解决这个问题。friend 机制是一种面向对象的设计模式，它容许对象之间共享公有信息，并且只有指定的对象能力拜访这些信息。具体来说，friend 机制容许一个类将另一个类或函数申明为其友元，从而容许友元拜访其公有成员。
在 friend 机制中，一个类将另一个类或函数申明为友元，意味着它容许该类或函数拜访其公有成员。这意味着友元类或函数能够冲破封装的限度，间接拜访另一个对象的公有成员，这可能会毁坏封装性。此外，因为 friend 机制是一种非凡的机制，它不遵循惯例的面向对象编程规定，因而应用它可能会导致代码更加难以了解和保护。
然而，尽管 friend 机制在某种程度上毁坏了封装性，但它也提供了一些益处。它容许一些密切相关的对象共享公有信息，从而更好地实现一些性能。例如，如果一个类和另一个类严密耦合，它们须要共享一些公有信息以便更好地实现一些性能，那么 friend 机制能够提供一种解决方案。此外，friend 机制还能够进步代码的可读性，因为它能够帮忙开发者更清晰地理解对象之间的关系。
只管 friend 机制有一些长处，但在大多数状况下，应该防止应用它。如果对象之间须要共享一些公有信息，通常最好的办法是通过公共接口来实现。如果两个对象必须彼此晓得对方的实现细节，这可能意味着它们之间存在适度耦合的问题，须要进行从新设计。此外，friend 机制的应用可能会导致代码更加难以了解和保护。
在面向对象设计畛域中，封装是一种将数据和操作它们的办法组合在一起的形式，目标是暗藏对象外部的实现细节。封装实际上是一种信息暗藏伎俩，它有助于进步代码的可维护性、可扩展性和可重用性。然而，当引入 friend 机制时，这种封装性可能会受到影响。接下来，咱们将从多个方面探讨 friend 机制如何影响面向对象设计的封装性，以及在某些状况下如何衡量这种影响。
首先，让咱们理解什么是 friend 机制。在某些面向对象编程语言（如 C ++）中，friend 关键字用于申明一个类或函数能够拜访另一个类的公有成员和爱护成员。通常，公有成员和爱护成员只能被类的成员函数拜访，然而通过将一个类或函数申明为另一个类的友元，咱们能够容许这些内部实体拜访类的外部成员。
确实，friend 机制在肯定水平上毁坏了封装性。容许内部实体拜访类的公有成员和爱护成员可能导致类的实现细节泄露，使得代码更难保护和扩大。在大型软件我的项目中，这可能导致潜在的不稳定性和平安危险。
然而，只管 friend 机制可能会减弱封装性，但在某些状况下，它依然是有用的。在以下场景中，应用 friend 机制可能是无益的：
- 当两个或多个严密相干的类须要共享某些数据或性能时。在这种状况下，友元类或友元函数能够作为一种更简洁、更间接的形式来实现这些共享性能，而不是通过公共接口裸露过多的实现细节。
- 当须要实现高效的代码时。有时，为了进步性能，咱们须要让某些类或函数可能间接拜访另一个类的外部成员。通过应用 friend 机制，咱们能够防止创立额定的接口，从而进步代码的执行效率。
- 当用于测试时。在软件测试中，咱们可能须要拜访类的公有成员来验证其正确性。通过将测试类或测试函数申明为待测类的友元，咱们能够更容易地拜访这些公有成员，从而编写更全面的测试用例。
总之，尽管 friend 机制可能会毁坏面向对象设计的封装性，但在某些特定状况下，它依然是一个有用的工具。
Jerry:
gof 23 种设计模式里，并没有一种采取 friend 实现，这自身也能阐明问题了。
friend 关键字通常在 C++ 中应用，用于申明友元类或友元函数，以便在类之间共享公有成员。这个概念在其余编程语言中可能有不同的实现形式，例如 C# 中的 internal 关键字。
然而，在 23 种设计模式中，有些模式可能会用到友元类或友元函数的概念。例如，Mediator（中介者）模式中，类之间的通信会通过一个中介者对象进行。这种状况下，友元类或友元函数能够用来限度对各个类的拜访，只容许中介者对象拜访它们的公有成员。不过，这并不是 GoF 设计模式的核心内容，而是具体实现时的一种可选计划。
总之，GoF 23 种设计模式并没有间接借助面向对象的 friend 机制来实现。然而，在理论利用这些设计模式时，依据具体需要和编程语言的特点，friend 机制能够作为一种实现形式。
在 Gof 23 种设计模式中，并没有间接借助面向对象的 friend 机制实现的设计模式。然而，有一些设计模式波及到了访问控制和对象间的合作，能够通过相似于 friend 机制的形式实现。
例如，观察者模式（Observer Pattern）中，一个对象（称为 Subject）保护了一系列观察者对象（Observers），并在状态产生扭转时告诉这些观察者。通常状况下，Subject 对象须要将本身的状态信息通知 Observer 对象，以便 Observer 对象可能获取到相干的信息。在这种状况下，能够将 Observer 对象设置为 Subject 对象的 friend 类型，使得 Observer 对象能够间接拜访 Subject 对象的公有状态，而不须要通过公共接口来拜访。
此外，还有一些相似于访问控制和对象间合作的设计模式，如门面模式（Facade Pattern）和中介者模式（Mediator Pattern），都须要协调不同的对象之间的关系。在这些模式中，对象之间须要进行合作，然而又须要放弃封装性。能够通过相似于 friend 机制的形式来实现对象之间的合作和信息共享，同时放弃封装性。
总之，尽管没有间接借助面向对象的 friend 机制实现的设计模式，然而一些设计模式波及到了访问控制和对象间的合作，能够通过相似于 friend 机制的形式来实现。这也阐明了，在面向对象设计中，适合的访问控制和对象间合作是十分重要的。