您可以在不牺牲功能的情况下消除朋友依赖吗？

重新思考并发访问管理的好友依赖

简介

在本文中，我们深入研究在尝试删除负责管理对共享资源的同步读/写访问的两个类之间的“友元”依赖关系时所面临的挑战。引入友元依赖关系是为了向 ClassAAccessor 提供对 ClassA 受保护方法的访问，确保客户端只能通过 ClassAAccessor 及其生命周期行为与 ClassA 进行交互。

了解友元依赖关系

最初的设计依赖于 ClassA 和 ClassAAccessor 之间的友元依赖关系。这种依赖关系允许 ClassAAccessor 访问 ClassA 的受保护方法，从而使其能够管理共享资源的锁定和解锁。然而，由于各种原因，不鼓励使用友元依赖项，包括它们可能会引入维护问题。

重构过程

要删除友元依赖项，我们遵循三个-步骤过程：

1. 引入抽象接口：我们创建一个抽象接口InternalInterface，来表示之前可以通过友元声明访问的操作。 ClassA 是 InternalInterface 的实现，但泛化受到保护以保持封装性。
2. 将操作移至接口： 创建“调用”依赖项的操作（之前由friend）从 ClassA 移至InternalInterface。这在接口和实现之间建立了清晰明确的关系。
3. 粘合实现：在实现中，我们为 ClassAAccessor 提供了一种方法来获取对 InternalInterface 的引用，使其能够访问必要的操作。这是通过 ClassA 中的一个方法实现的，该方法允许 ClassAAccessor 设置其内部InterfaceRef 变量。

优点和缺点

这种方法具有以下优点：

• 删除有问题的友元依赖
• 提高可维护性并减少耦合

但是，也有一些缺点需要考虑：

• 由于引入抽象接口而增加了代码复杂性
• 与使用友元声明相比，性能可能会降低（尽管这可以通过仔细实现来缓解）

结论

通过遵循概述的步骤，我们成功地重构了设计，以删除好友依赖性，同时保持所需的功能。此重构引入了多个优点，包括提高了可维护性，同时也强调了此类更改中涉及的潜在权衡。

以上是您可以在不牺牲功能的情况下消除朋友依赖吗？的详细内容。更多信息请关注PHP中文网其他相关文章！