Can You Remove Friend Dependencies Without Sacrificing Functionality?

Rethinking the Friend Dependency for Concurrent Access Management

Introduction

In this article, we delve into a challenge faced when attempting to remove a "friend" dependency between two classes responsible for managing synchronized read/write access to a shared resource. The friend dependency was introduced as a means to provide ClassAAccessor with access to the protected methods of ClassA, ensuring that clients would only interact with ClassA through ClassAAccessor and its lifecycle behavior.

Understanding the Friend Dependency

The original design relied on a friend dependency between ClassA and ClassAAccessor. This dependency allowed ClassAAccessor to access the protected methods of ClassA, enabling it to manage the locking and unlocking of shared resources. However, using friend dependencies is discouraged for various reasons, including their potential to introduce maintenance issues.

Refactoring Process

To remove the friend dependency, we follow a three-step process:

1. Introducing an Abstract Interface: We create an abstract interface, InternalInterface, to represent the operations that were previously accessible via the friend declaration. ClassA is made an implementation of InternalInterface, but the generalization is made protected to maintain encapsulation.
2. Moving Operations to the Interface: The operations that created the "call" dependency (previously represented by the friend) are moved from ClassA to InternalInterface. This establishes a clear and explicit relationship between the interface and the implementation.
3. Glueing Implementation: In the implementation, we provide a way for ClassAAccessor to obtain a reference to the InternalInterface, enabling it to access the necessary operations. This is achieved through a method in ClassA that allows ClassAAccessor to set its internalInterfaceRef variable.

Advantages and Disadvantages

This approach has advantages such as:

• Removal of the problematic friend dependency
• Improved maintainability and reduces coupling

However, there are also some disadvantages to consider:

• Increased code complexity due to the introduction of an abstract interface
• Potential for reduced performance compared to using friend declarations (though this can be mitigated by careful implementation)

Conclusion

By following the outlined steps, we have successfully refactored the design to remove the friend dependency while maintaining the desired functionality. This refactor introduces several advantages, including improved maintainability, while also highlighting the potential trade-offs involved in such changes.

The above is the detailed content of Can You Remove Friend Dependencies Without Sacrificing Functionality?. For more information, please follow other related articles on the PHP Chinese website!