Dependency injection on user classes stuck in an indefinite loop in L4.2?

Question

I am changing my controllers and helper classes to use dependency injection, and it looks like I have helper classes stuck in an infinite loop.

Below is my custom ServiceProvider and two examples of helper classes. As you can see, they introduce each other, so they continue to move forward and backward.

What is the solution to this problem? What error do I seem to be making? . What can I do so that I can run tests on helper classes like General and Person while taunting helper classes called internally

One way that I think might work is through my ServiceProvider, follow these steps:

 if (isset($appmade->General)) { // inject the General app that already instantiated } else { $abc = app::make('\Lib\MyOrg\General'); $appmade->General = $abc; } 

Is it correct?

 // /app/providers/myorg/MyOrgServiceProvider.php namespace MyOrg\ServiceProvider; use Illuminate\Support\ServiceProvider; class MyOrgServiceProvider extends ServiceProvider { public function register() { $this->app->bind('\Lib\MyOrg\General', function ($app) { return new \Lib\MyOrg\General( $app->make('\Lib\MyOrg\Person'), $app->make('\App\Models\User') ); }); $this->app->bind('\Lib\MyOrg\Person', function ($app) { return new \Lib\MyOrg\Person( $app->make('\Lib\MyOrg\General'), $app->make('\App\Models\Device') ); }); } } // /app/libraries/myorg/general.php namespace Lib\MyOrg; use App\Models\User; use Lib\MyOrg\Person; class General { protected $model; protected $class; public function __construct(Person $personclass, User $user) { } } // /app/libraries/myorg/person.php namespace Lib\MyOrg; use App\Models\Device; use Lib\MyOrg\General; class Person { protected $model; protected $class; public function __construct(General $generalclass, Device $device) { } } 

Answer 1

Your helper classes have a case of cyclic dependency which when mixed with injection dependencies makes them unintuitive ... and there is no good way to make them work and be easy to test.

There are several ways to hack:

• You can use the installer injection by introducing the dependency in setter when the helper is used, and not in the constructor when it is created. This has many shortcomings, among them the main exam. (See http://symfony.com/doc/current/components/dependency_injection/types.html )

• In Laravel 5, you can use the injection method , especially if the dependency refers to only one or two methods. (See http://mattstauffer.co/blog/laravel-5.0-method-injection )

• You can do an existence check, as you suggest above, or something with an event listener. But all this disguises the fact that ...

A circular dependency usually indicates that a design change is in order , and it’s best to decide by reviewing how your classes interact with each other.

• If your personal and general classes are completely dependent on each other, then perhaps they share one responsibility and should be combined into one class.

• If, however, they rely on a subset of each other's functions, that is, probably, a separate class with their own responsibility is hiding somewhere, and then the best solution would be to bring the general functionality to the 3rd class. Thus, rather than class A relying on class B and class B relying on class A, both Class A and B instead relying on class C. You can safely create them all and they all remain easily verifiable.

How can you easily understand what your new C class should contain? A big rule of thumb comes from http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/ ... "List all the methods in your class A that are used by class B , and all the methods in your class B used by class A. In short of the two lists is your hidden class C. "