0

I am working a really large code base with hundreds of different classes. We initially had a main Application.php where we kind of booted up our services. Meaning to say this is where we hooked dependencies into eachother similarly to something like this:

public function loadConfig(ConfigLocatorInterface $config) 
{
    $this->config = new Config($config);
}

Etc. You probably get the idea, there are multiple of these instances that might even take 2 or more dependencies or objects that already have dependencies.

Along the way this gets unusable because you constantly have to pass these serviceproviders around to other objects, to your controller, to your connectionpool, etc.

This is the reason my fellow developers started instantiating objects in the classes themselves instead of passing them along the chain, creating tight-coupling. Even newing up objects inside constructors, making it virtually impossible to unit test these pieces of code.

Passing these dependencies along constantly might not be the solution in this case since a lot of constructors already have 3 or so arguments. And if we were to do this we would have to create chunks of pre-configured objects which is not always possible.

A container seemed like a possibly solution but this is something that was voted against because of the concern of secure configuration data leaking out from the container and showing up in a callstack or somewhere else. Besides that my fellow developers are concerned this might turn in a bloated 'god-object' where we pretty much dump everything we need that we don't want to pass around constantly.

I am at my wits end with this and even though this is not a straightforward technical question I am wondering how you guys deal with this personally. I hope this is a viable question otherwise I will find somewhere else to post this. I would love the thoughts of this community though.

Stephan-v
  • 19,255
  • 31
  • 115
  • 201
  • It is the most unusual reason against containers I ever heard. – Alex Blex Jan 20 '17 at 09:17
  • @AlexBlex care to elaborate? Of course we will suppress error messages in production but people are still scared of data leaking out if something breaks because we pass around a config object with our DB credentials, etc. in it. Or are you referring to the container getting bloated? I would love some articles or other information to persuade my colleagues. – Stephan-v Jan 20 '17 at 09:19
  • There is nothing to elaborate. Various implementations of containers suffer from cyclic dependencies, slow reflection-based wiring, etc, which can be a deal-breaker in edge cases. Rejecting containers because of security reasons or a risk to have a god-object is quite unusual and sounds more like a misuse. It might deserve its own question with examples of such problems in the container of choice. – Alex Blex Jan 20 '17 at 09:34
  • @AlexBlex Thanks I will dive a bit deeper into it. I am guessing a container is pretty much the only way to solve this problem. – Stephan-v Jan 20 '17 at 09:41

1 Answers1

-1

You are looking for singleton design pattern. Please check next example here on stackoverflow: https://stackoverflow.com/a/203359/3130183

Community
  • 1
  • 1
Boris Savic
  • 781
  • 5
  • 9
  • That is kind of a shortsighted answer. Even with the singleton pattern you can easily run into problem. Especially if you want to pass dynamic configuration along to your objects and constantly cache the instance. – Stephan-v Jan 20 '17 at 09:15