Common tasks and variables

I found this which works well but am interested in people so anything a bit more interesting like setting up class and only including in the controllers that you need the functions in.

http://laravel-recipes.com/recipes/50/creating-a-helpers-file

@rosshulford things like an API key would go to the config and you pass config repository as dependency to the class, which needs that key (rather not the controller, but a class used by the controller).

The functionality you're talking about, would be encapsulated in a class(es) that you will use as a service in your controllers - it will be a controller dependency.

@JaredTkaczyk Don't use the config repository as a dependency, as that violates Inversion of Control. Use a service provider to get the config value from the repository and inject that as a constructor argument.

Bad:

class ConfigurationAwareFooService
{
    public function __construct(Configuration $config)
    {
        $this->apiKey = $config->get('foo.key');
    }
}

Good:

class DependencyInjectedFooService
{
    public function __construct($apiKey)
    {
        $this->apiKey = $apiKey;
    }
}

class FooServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind('DependencyInjectedFooService', function($app)
        {
            $key = $app['config']->get('foo.key');
            return new DependencyInjectedFooService($key);
        }
    }
}

@thepsion5 Well, I think you misundersand inversion of control then.

Do you consider a string $apikey a dependency?

If the class can't perform it's primary purpose without $apiKey, then I consider it a dependency.

@thepsion5 Elaborate on this please. How's injecting a config store violating DIP?

@JarekTkaczyk if your class has a dependency on the ConfigRepository, then everyone using that class also needs to implement the ConfigRepository even though you're only using the repository to get the $apikey. Moreover by depending on the ConfigReposirory your class also gains knowledge about your database configuration and any secret keys that are inside of your configuration.

@MarkRedeman Everyone using my class need to implement the interface? It doesn't matter whether you need something only to get the $apikey or to other things as well, it's abstraction. Speaking of gaining knowledge - not really. You're talking about particular Laravel's Config that you have knowledge about, I suppose.

You definitely have no knowledge about anything with this:

public function __construct(SomeApiConfigStore $config)

interface SomeApiConfigStore {
  public function getApiKey();
}

The secret keys that are inside of your configuration - if they are secret then they definitely shouldn't have public access.

Back to the question - how's that violating DIP principle?
Are things completely different when we talk about DbRepo instead of config?

No rant whatsoever, correct me if I'm wrong. I'm just curious about your opinions.

@JarekTkaczyk If you have an SomeApiConfigStore interface with getApiKey() then that would be okay in my opinion, however passing Laravel's Config wouldn't be. However from a practical point of view I wouldn't bother adding an extra interface just to get an api key.

@MarkRedeman Yes, you can easily pass a string instead, nothing wrong with that. On the other hand, you can easily go this path too far and keep passing other things like this, instead of abstractions, so you want to be careful.
Passing Laravel's Config would definitely break DIP, because it is not an abstraction at all.

It's not about the only true way, that I was talking about, since there is no true way. I want to know why it would be breaking DIP principle @thepsion5 ?

You're right, if we're just talking about a single interface with a single method, it's probably not a violation of DIP. If that's the case though, what do you gain from the abstraction in the first place?

If the return type from getApiKey() is a scalar, then in 99% of cases there's no difference from injecting the scalar value directly*. If the return type is a value object, why not just typehint for it in the constructor?

*The only time I could see this mattering is if The API Key can change between instantiating and using the dependent class, or if retrieving the API key is a complex and time-intensive process and you want to do it lazily. But both of those seem like really crazy edge-cases. Configuration data generally shouldn't ever meet either of those criteria.

@thepsion5 agreed - it's perfectly OK to pass the key as a string in such a case.

I wasn't referring to concrete laravel's config and single value required for the class, but rather to the general idea of dependency injection and encapsulation, because this seems to be the main concern of the OP.