In a PHP project, what patterns exist to store, access and organize helper objects?

I would avoid the Singleton approach suggested by Flavius. There are numerous reasons to avoid this approach. It violates good OOP principles. The google testing blog has some good articles on the Singleton and how to avoid it:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

Alternatives

1. a service provider

   http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2. dependency injection

   http://en.wikipedia.org/wiki/Dependency_injection

   and a php explanation:

   http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

This is a good article about these alternatives:

http://martinfowler.com/articles/injection.html

Implementing dependency injection (DI):

• I believe you should ask what is needed in the constructor for the object to function: new YourObject($dependencyA, $dependencyB);

• You can provide the needed objects (dependencies) manually ($application = new Application(new MessageHandler()). But you can also use a DI framework (the wikipedia page provides links to PHP DI frameworks).

  Important is that you only pass in what you actually use (call an action on), NOT what you simply pass to other objects because they need it. Here's a recent post from 'uncle Bob' (Robert Martin) discussing manual DI vs using framework.

Some more thoughts on Flavius's solution. I don't want this post to be an anti-post but I think it's important to see why dependency injection is, at least for me, better than globals.

Even though it is not a 'true' Singleton implementation, I still think Flavius got it wrong. Global state is bad. Note that such solutions also use difficult to test static methods.

I know a lot of people do it, approve it and use it. But reading Misko Heverys blog articles (a google testability expert), rereading it and slowly digesting what he says did alter the way I see design a lot.

If you want to be able to test you application, you'll need to adopt a different approach to designing your application. When you do test-first programming, you'll have difficulty with things like this: 'next I want to implement logging in this piece of code; let's write a test first that logs a basic message' and then come up with a test that forces you to write and use a global logger that can't be replaced.

I am still struggling with all the information I got from that blog, and it's not always easy to implement, and I have many questions. But there's no way I can go back to what I did before (yes, global state and Singletons (big S)) after I grasped what Misko Hevery was saying :-)

Dmitry Malyshenko answered what I needed to hear. "It's obvious that this token must be cached, not stored in configuration. How it would be cached - it totally up to you..."

Examples of valid solutions:

• store in some file
• store in a database
• store just in memory (as a property of your class)
• store in some key-value storage (redis, memcache)

I would have used CacheComponent but I am currently not developing in Symfony 3.1 so I decided to store in a database which felt most naturally. First I created a table with username, password and tokens in a mysql-database. Then I created a service dedicated to that table. It looks something like this simplified code:

class ExternalSiteService
{
    public function  getUsername() {
        ...
    }

    public function getPassword() {
        ...
    }

    public function getAccessToken() {
        ...
    }

    public function setAccessToken($newAccessToken) {
        ...
    }

    public function getRefreshToken() {
        $query="SELECT "
            . "eapi.refreshtoken "
            . "FROM external_api eapi";
        $connection = $this->em->getConnection();
        $statement = $connection->prepare($query);
        $statement->execute();
        $results = $statement->fetchAll();
        if ( $results ) {
            return $results;
        }
        return false;
    }

    public function setRefreshToken($newRefreshToken) {
        $query="UPDATE external_api "
            . "SET refreshtoken = :new_refreshtoken "
            . "WHERE id=1;";
        $connection = $this->em->getConnection();
        $statement = $connection->prepare($query);
        $statement->bindValue('new_refreshtoken', $newRefreshToken);
        $statement->execute();
    }
}

Then I made some logic in the controller that says if access token not valid use refresh token, and if refresh token not valid do a new login attempt. This code in the controller also stores the tokens in the database if we have to get new ones.

    $eapiService    = $this->get('mybundle.service.externalapi');
    $reqPara     = ['body' =>["accessToken" => $at, "department" => $department, "location" =>$location]];

    $req = $client->request("POST", "https://httpbin.org/employees/atwork", $reqPara);
    $response = json_decode($req->getBody()->getContents());

    if ($response->serverErrorMessage == "Invalid access token.") {
        $req = $client->request('POST', "https://httpbin.org/getnewtokens", ['body' => ['refreshToken' => $refreshToken]]);
        $response = json_decode($req->getBody()->getContents());

        if ($response->serverErrorMessage == "Invalid refresh token.") {
            $req = $client->request('POST', 'https://httpbin.org/login', ['body' => ['user' => $user, 'pw' => $pw]]);
            $response = json_decode($req->getBody()->getContents());
            foreach ($response->content as $contentItem) {
                $eapiService->setAccessToken($contentItem->accessToken);
                $eapiService->setRefreshToken($contentItem->refreshToken);
            }
        } else {
            foreach ($response->content as $contentItem) {
                $eapiService->setAccessToken($contentItem->accessToken);
                $eapiService->setRefreshToken($contentItem->refreshToken);
            }
        }
    }
    return array('usersatwork' => $response);

I will probably also make something to catch exceptions from guzzle.

Design patterns are supposed to provide a structure in which problems can be solved. When solving a real problem, you have to consider many tiny variations of a solution to that problem to see whether any fits a design pattern. In particular, you will probably need to generalise your problem, or its solution, in order to make a design pattern fit.

The answer is, it's an art. Knowing the design patterns is certainly an important step. One way to get used to this sort of thing is to study applications of design patterns, not just the patterns. Seeing many different applications of one pattern can help you over time to get better at mapping a task onto a pattern.