CyclicDependencies

Resolving cyclic dependencies

Resolving Cyclic Dependencies

Say that your application has a few classes including a Store, a Boss, and a Clerk.

public class Store {
  	private final Boss boss;
  	//...

	@Inject public Store(Boss boss) {
 		this.boss = boss;
 		//...
	}

	public void incomingCustomer(Customer customer) {...}
	public Customer getNextCustomer() {...}
}

public class Boss {
	private final Clerk Clerk;
	@Inject public Boss(Clerk Clerk) {
		this.Clerk = Clerk;
	}
}

public class Clerk {
	// Nothing interesting here
}

Right now, the dependency chain is all good: constructing a Store results in constructing a Boss, which results in constructing a Clerk. However, to get the Clerk to get a Customer to do his selling, he'll need a reference to the Store to get those customer

public class Store {
  	private final Boss boss;
  	//...

	@Inject public Store(Boss boss) {
 		this.boss = boss;
 		//...
	}
	public void incomingCustomer(Customer customer) {...}
	public Customer getNextCustomer() {...}
}

public class Boss {
	private final Clerk clerk;
	@Inject public Boss(Clerk clerk) {
		this.clerk = clerk;
	}
}

public class Clerk {
	private final Store shop;
	@Inject Clerk(Store shop) {
		this.shop = shop;
	}

	void doSale() {
		Customer sucker = shop.getNextCustomer();
		//...
	}
}

which leads to a cycle: Clerk -> Store -> Boss -> Clerk. In trying to construct a Clerk, an Store will be constructed, which needs a Boss, which needs a Clerk again!

There are a few ways to resolve this cycle:

Eliminate the cycle (Recommended)

Cycles often reflect insufficiently granular decomposition. To eliminate such cycles, extract the Dependency Case into a separate class.

In this example, the work of managing the incoming customers can be extracted into another class, say CustomerLine, and that can be injected into the Clerk and Store.

public class Store {
  	private final Boss boss;
  	private final CustomerLine line;
  	//...

	@Inject public Store(Boss boss, CustomerLine line) {
 		this.boss = boss; 
 		this.line = line;
 		//...
	}

	public void incomingCustomer(Customer customer) { line.add(customer); }	
}

public class Clerk {
	private final CustomerLine line;

	@Inject Clerk(CustomerLine line) {
		this.line = line;
	}

	void doSale() {
		Customer sucker = line.getNextCustomer();
		//...
	}
}

While both Store and Clerk dependend on the CustomerLine, there's no cycle in the dependency graph (although you may want to make sure that the Store and Clerk both use the same CustomerLine instance). This also means that your Clerk will be able to sell cars when your shop has a big tent sale: just inject a different CustomerLine.

Break the cycle with a Provider

Injecting a Guice provider will allow you to add a seam in the dependency graph. The Clerk will still depend on the Store, but the Clerk doesn't look at the Store until he needs one.

public class Clerk {
	private final Provider<Store> shopProvider;
	@Inject Clerk(Provider<Store> shopProvider) {
		this.shopProvider = shopProvider;
	}

	void doSale() {
		Customer sucker = shopProvider.get().getNextCustomer();
		//...
	}
}

Note here, that unless Store is bound as a Singleton or in some other scope to be reused, the shopProvider.get() call will end up constructing a new Store, which will construct a new Boss, which will construct a new Clerk again!

Factory Methods to tie two objects together

When your dependencies are tied together a bit closer, untangling them with the above methods don't work. Situations like this come up when using something like a View/Presenter paradigm:

public class FooPresenter {
	@Inject public FooPresenter(FooView view) {
		//...
	}

	public void doSomething() {
		view.doSomethingCool();
	}
}

public class FooView {
	@Inject public FooView(FooPresenter presenter) {
		//...
	}

	public void userDidSomething() {
		presenter.theyDidSomething();
	}
	//...
}

Each of those objects needs the other object. Here, you can use AssistedInject to get around it:

public class FooPresenter {
	private final FooView view;
	@Inject public FooPresenter(FooView.Factory viewMaker) {
		view = viewMaker.create(this);
	}

	public void doSomething() {
	//...
		view.doSomethingCool();
	}
}

public class FooView {
	@Inject public FooView(@Assisted FooPresenter presenter) {...}

	public void userDidSomething() {
		presenter.theyDidSomething();
	}

	public static interface Factory {
		FooView create(FooPresenter presenter)
	}
}

Such situations also come up when attempting to use Guice to manifest business object models, which may have cycles that reflect different types of relationships. AssistedInject is also quite good for such cases.