Using a custom provider class to remove tight coup

Question

I have a custom framework where i have a class/method which uses my own Cache class.

Currently it is tightly coupled. So a method instantiates the Cache class like this:

public function someMethod ( )
{
    $cache = new Cache\HHCache();
}

I want ro remove the tight coupling but that's actually where i'm a bit stuck.

I thought it would be a good idea to create some sort of ServiceProvider class. But i'm not sure if this is really the right approach.

To start i have HHConfig file which has a static property in which a cache class is defined. In short:

class HHConfig
{
    static $_cacheClass = '\Core\Cache\HHCache';
}

So basically i have a class like this, which is part of the Core functionality of my framework:

interface IHHServiceProvider
{
    public function getService ( );
}

Then i have another class which implements this interface.

class HHCacheProvider implements IHHServiceProvider
{
    public static function getService ( )
    {
        $class = HHConfig::$_cacheClass;
        return new $class();
    }
}

So now someMethod can use the HHCacheProvider class to get an instance of a Cache class.

public function someMethod ( )
{
    $cache = HHCacheProvider::getService ( );
}

My IHHServiceProvider isn't really like the typical Provider class since you can't really register any Services to it. It simply looks in the HHConfig class what "class" to load and returns in instance of that.

So somehow this method doesn't feel right to me, but i do think it shows what i want to achieve. In what ways can i improve this?

---

Please note that i'm not looking for a simple Dependency Injection pattern for this. Because i don't want to inject my Cache class to every constructors class. I need a non tight coupling way of getting an instance of the HHCache class somehow from within a method.

Some sort of provider class that can be part of my framework seems like the right direction.

Answer 1

As per OP request

Especially since it will be part of the framework, you should inject the Cache. A DI Container is the best solution here, you can config the actually Cache implementation as a singleton. Your proposed solution is tightly coupled to some service and hard to test in isolation. Actually it looks more of a service locator pattern rather than provider.

If you're using a Factory that won't replace the DI Container. THe point of DI is that the code shouldn't be coupled to an outside static service. Unless you have a very good reason, any object should use only the injected (via constructor or as method argument) dependencies.

Answer 2

_{Note: "provider" means nothing. There is not pattern by that name.}

Instead of making some magical "privider", you should take a look at factory pattern. Basically the idea is a follows:

1. You inject a factory in classes that will use some services (assuming that Cache is not the only form of service that you aim for).

2. The class request from factory the service that it needs:

   • if service has been already initialized once, it just returns an instance to your
   • else it creates new instance, stores it and returns you to "consumer"

The simplest code example would be something like this:

class ServiceFactory
{
    private $storage = [];

    public function create( $name )
    {
        if ( false === array_key_exists( $name, $this->storage ))
        {
            $instance = new $name;
            $this->storage[$name] = $instance;
        }

        return $this->storage[$name];
    }

}

This is an extremely simplified example, but even in this case, if you inject an instance of this factory in any number of objects, they all will have access to same pool of instances.

If you ever decide to look into concept of DI Containers, then factories are also the place where it is appropriate to utilize them, without degrading them to as service locator anti-pattern.

.. and few lectures that you might find valuable:

• The Clean Code Talks - Don't Look For Things!
• The Clean Code Talks - Global State and Singletons