Best way to reference the plugin object in an external class?

*read

 

mazentheamazin Pfft, don't know what you're on about.

*corrects post*

 

I read sticky posts. D=

 

Who doesn't?

 

(Coming in late)

I think I'd argue this:

Code:java

public class A {
 
    private final B bee;
 
    public A() {
        this.bee = new B(this);
    }
 
}

Code:java

public class B {
 
    private final A ayy;
 
    public B(A ayy) {
        this.ayy = ayy;
    }
 
}

Of course that leaves you with the A class as the initializing dependency, but no need for counter maneuvering around using constructors. (There is also the whole passing of "this" before the 'bee' var can be set, but it already has the reference to itself, so in a more complex design it would be set much later in a constructor).

Also re: The constructor argument bloat, while possibly outside the scope of the question would be the Builder pattern

 

You have to be extremely cautious when using this kind of approach!

First of all, as you said, class A now has the responsibility of instantiating a reference to the object of B that it needs (something that could be a sign of code smell in some cases), which only solves the problem if a reference to that specific object isn't needed anywhere else. Otherwise, you now need a getter in A to solve the circular dependency problem and still maintain the flexibility of external instantiators (something that is required in Builder). In fact, if the reference the B object inside of A is not needed elsewhere, you don't necessarily have to consider B an entity of its own, since it just constitutes part of A's state and has no "life" of its own. Besides, if you aren't careful, you'll quickly end up with stack overflows if you let both classes instantiate their own dependencies.

Secondly, this kind of approach quickly opens up a can of inconsistency worms. When you pass this in a constructor, you are passing an incomplete object to the constructor or method of another class. The purpose of a constructor is to instantiate an object so that after instantiation, it is a complete and valid object of the given class. This is not the case when you pass this inside the constructor, and it leaves your object in an inconsistent state that may lead to unexpected behavior. Consider this extended example:

Code:java

public class A {
    private final B b;
    private final String x;
 
    public A(String x) {
        this.b = new B(this);
        this.x = x;
    }
 
    public String getX() {
        return x;
    }
}
 
public class B {
    private final A a;
    private final String y;
 
    public B(A a) {
        this.a = a;
        this.y = a.getX();
    }
}

What is the value of B.y when A has been constructed? Indeed, the guarantees of the final keyword completely disappear (very bad if you're trying to write an immutable class) unless the sequence of statements in A's constructor are ordered carefully with respect to B - something that may not actually be viable. The trouble doesn't stop here, though. Here's a pretty good write-up that covers some potential issues (check out the Don't pass the "this" reference during construction section).

While Builder is a very nice pattern, especially for constructing Composite pattern objects (think tree structures like the ones found in e.g. XML and YAML files), its intent is not to solve the circular dependency problem, and indeed may not be able to "on its own". Builder is essentially just a way to loosen the construction process for a single object via multiple setters or adders, so in the case of the circular dependency problem, it's just an overcomplicated way to implement setter injection. Another way to deal with constructor bloat is Abstract Factory, but it also doesn't solve the circular dependency problem.