Friend Dependency Removal Refactoring

In the realm of software development, friend declarations can introduce tight coupling and maintenance issues. This guide provides a detailed roadmap for refactoring a friend dependency properly, transforming your codebase into a more maintainable and resilient structure.

Unveiling the Need for Refactoring

Consider the following scenario: ClassA and ClassAAccessor share a friend dependency, granting ClassAAccessor access to protected members of ClassA. While this may seem convenient, it poses several drawbacks:

• UML 2.2 has deprecated the friend stereotype.
• Most coding guidelines discourage friend usage due to the excessive dependency it creates.
• It can lead to maintenance nightmares.

Refactoring Step-by-Step

Step 1: Introduce an Abstract Interface

Replace the friend declaration with a class interface called InternalInterface, splitting the friend relationship into a direct dependency and a call dependency on InternalInterface.

Step 2: Move Operations to the Interface

Identify the operations constituting the call dependency and move them from ClassA to InternalInterface, extending InternalInterface with a protected constructor and marking ClassA's generalization association to InternalInterface as protected.

Step 3: Connect the Components

ClassAAccessor needs a reference to InternalInterface. Implement an additional method, attachAccessor(), in ClassA and use it to pass a reference to InternalInterface to ClassAAccessor via setInternalInterfaceRef(). This method will be called when ClassA::attachAccessor() is invoked.

C Implementation

// ClassAAccessor definition
class ClassAAccessor {
public:
    ClassAAccessor(ClassA& classA);
    void setInternalInterfaceRef(InternalInterface &newValue);
private:  
    InternalInterface* internalInterfaceRef;
};

// Method to set the reference to InternalInterface
ClassA::attachAccessor(ClassAAccessor &accessor) {
    accessor.setInternalInterfaceRef(*this);
}

Optional Enhancement: Introducing an InternalClientInterface

To further decouple the implementation, consider introducing another InternalClientInterface as an intermediary between ClassA and ClassAAccessor.

Conclusion

By following these steps, you can effectively refactor a friend dependency, enhancing code stability, maintainability, and adherence to coding best practices. Remember to carefully evaluate the potential drawbacks associated with this approach before implementing it in your own codebase.