Do you know what Pure Dependency Injection is? Dependency Injection doesn't require use of Dependency Injection Containers. You mention Auryn, which is a container.

Nothing is inherently wrong with using a container but like all frameworks their authors are eager to let you make yourself dependent on them. Allowing that to happen to your code base has the consequence of effectively changing the language your codebase is written in. You can't advertise the job as a PHP job. It's a PHP/Auryn job. Now you have to find PHP/Auryn programmers.

Rather then let the container redefine your language you can contain it. Don't allow anything in your code base but your composition root (hopefully this is just main) even know that Auryn exists and most of your code base can be maintained by normal PHP programmers.

To build the chain I take names of classes from the config file, I instantiate them, and I arrange them in a queue. The controller is not aware of the dependencies that each module needs. Right now, there are none, because each module creates needed objects by itself (and this is what I want to change). I don't want to inject each module with the container, because this will turn into a Service locator pattern.

This sounds more like a testing/refactoring problem. Unit Testing is most expensive and least effective when introduced late. So don't expect this to be easy. It sounds like you have something that works. Do you have integration tests? It's much easier to refactor to unit testable code if you have some kind of tests in place. It's just slow because integration tests are slow.

If you're new to Auryn it's likely a good idea to practice by writing some code from scratch that works with it. Make it in the ideal form you'd like your codebase to be. See how that works.

Now you have a model of what you're going for as you refactor your existing code base and have some experience using Auryn. Next just break off small parts of your code base. Write unit tests for them and bring their construction under Auryn's responsibility. Bit by bit you'll transform your code base into something unit testable.

Keep in mind, the point of unit tests isn't to "test all the classes!". It's to help me read code. You likely have some boring glue code that has no real behavior code in it. Do not kill yourself trying to test that. I can read that code and predict it's behavior without help. But if any interesting behavior code is mixed in there move it out into something testable. Doing this is called the humble object pattern. It's the same as when people insist on moving logic out of views and into presenters.

If "interesting" seems subjective understand I'm asking you to stop thinking about the structure of your code and think about how it looks to a newbie. Give them a unit test that shows how something is used, what the scope of code that must be read to understand it, make clear what you expect it to do, and you'll have newbies that can easily find that one line of code they need to edit. Use your tests to help me read code. Please.

Do you know what Pure Dependency Injection is? Dependency Injection doesn't require use of Dependency Injection Containers. You mention Auryn, which is a container.

Nothing is inherently wrong with using a container but like all frameworks their authors are eager to let you make yourself dependent on them. Allowing that to happen to your code base has the consequence of effectively changing the language your codebase is written in. You can't advertise the job as a PHP job. It's a PHP/Auryn job. Now you have to find PHP/Auryn programmers.

Rather then let the container redefine your language you can contain it. Don't allow anything in your code base but your composition root (hopefully this is just main) even know that Auryn exists and most of your code base can be maintained by normal PHP programmers.

To build the chain I take names of classes from the config file, I instantiate them, and I arrange them in a queue. The controller is not aware of the dependencies that each module needs. Right now, there are none, because each module creates needed objects by itself (and this is what I want to change). I don't want to inject each module with the container, because this will turn into a Service locator pattern.

This sounds more like a testing/refactoring problem. Unit Testing is most expensive and least effective when introduced late. So don't expect this to be easy. It sounds like you have something that works. Do you have integration tests? It's much easier to refactor to unit testable code if you have some kind of tests in place. It's just slow because integration tests are slow.

If you're new to Auryn it's likely a good idea to practice by writing some code from scratch that works with it. Make it in the ideal form you'd like your codebase to be. See how that works.

Now you have a model of what you're going for as you refactor your existing code base and have some experience using Auryn. Next just break off small parts of your code base. Write unit tests for them and bring their construction under Auryn's responsibility. If Auryn makes this difficult at first try a pure DI solution. Either way stop the classes from building their own dependencies or you're doing this for no reason. Instead build them outside and pass them in. Bit by bit you'll transform your code base into something unit testable.

Keep in mind, the point of unit tests isn't to "test all the classes!". It's to help me read code. You likely have some boring glue code that has no real behavior code in it. Do not kill yourself trying to test that. I can read that code and predict it's behavior without help. But if any interesting behavior code is mixed in there move it out into something testable. Doing this is called the humble object pattern. It's the same as when people insist on moving logic out of views and into presenters.

If "interesting" seems subjective understand I'm asking you to stop thinking about the structure of your code and think about how it looks to a newbie. Give them a unit test that shows how something is used, what the scope of code that must be read to understand it, make clear what you expect it to do, and you'll have newbies that can easily find that one line of code they need to edit. Use your tests to help me read code. Please.

Do you know what Pure Dependency Injection is? Dependency Injection doesn't require use of Dependency Injection Containers. You mention Auryn, which is a container.

Nothing is inherently wrong with using a container but like all frameworks their authors are eager to let you make yourself dependent on them. Allowing that to happen to your code base has the consequence of effectively changing the language your codebase is written in. You can't advertise the job as a PHP job. It's a PHP/Auryn job. Now you have to find PHP/Auryn programmers.

Rather then let the container redefine your language you can contain it. Don't allow anything in your code base but your composition root (hopefully this is just main) even know that Auryn exists and most of your code base can be maintained by normal PHP programmers.

Do you know what Pure Dependency Injection is? Dependency Injection doesn't require use of Dependency Injection Containers. You mention Auryn, which is a container.

Nothing is inherently wrong with using a container but like all frameworks their authors are eager to let you make yourself dependent on them. Allowing that to happen to your code base has the consequence of effectively changing the language your codebase is written in. You can't advertise the job as a PHP job. It's a PHP/Auryn job. Now you have to find PHP/Auryn programmers.

Rather then let the container redefine your language you can contain it. Don't allow anything in your code base but your composition root (hopefully this is just main) even know that Auryn exists and most of your code base can be maintained by normal PHP programmers.

To build the chain I take names of classes from the config file, I instantiate them, and I arrange them in a queue. The controller is not aware of the dependencies that each module needs. Right now, there are none, because each module creates needed objects by itself (and this is what I want to change). I don't want to inject each module with the container, because this will turn into a Service locator pattern.

This sounds more like a testing/refactoring problem. Unit Testing is most expensive and least effective when introduced late. So don't expect this to be easy. It sounds like you have something that works. Do you have integration tests? It's much easier to refactor to unit testable code if you have some kind of tests in place. It's just slow because integration tests are slow.

If you're new to Auryn it's likely a good idea to practice by writing some code from scratch that works with it. Make it in the ideal form you'd like your codebase to be. See how that works.

Now you have a model of what you're going for as you refactor your existing code base and have some experience using Auryn. Next just break off small parts of your code base. Write unit tests for them and bring their construction under Auryn's responsibility. Bit by bit you'll transform your code base into something unit testable.

Keep in mind, the point of unit tests isn't to "test all the classes!". It's to help me read code. You likely have some boring glue code that has no real behavior code in it. Do not kill yourself trying to test that. I can read that code and predict it's behavior without help. But if any interesting behavior code is mixed in there move it out into something testable. Doing this is called the humble object pattern. It's the same as when people insist on moving logic out of views and into presenters.

If "interesting" seems subjective understand I'm asking you to stop thinking about the structure of your code and think about how it looks to a newbie. Give them a unit test that shows how something is used, what the scope of code that must be read to understand it, make clear what you expect it to do, and you'll have newbies that can easily find that one line of code they need to edit. Use your tests to help me read code. Please.