Variables globales et phylosophie

Tu n'aurais pas envie que ça soit disponible dans une classe ? Du genre :

<?php 
class Configuration
{
    private $configurations = [];

    // Pour le principe, on met le constructeur à private, pour le singleton.
    private function __construct() 
    {
        $this->configurations['maVariable'] = 'maValeur';
        $this->taVariable = 'maValeur';
        // Tu vas chercher tout ce qu'il te faut dans la base de données.
    }

    // Ton implémentation d'un singleton, tu pourrais utiliser un trait
    // public static function getInstance() { /* ... */ }

    public function get($nomVariable) 
    {
        $valeur = $this->configurations[$nomVariable];

        if(!isset($valeur)) {
            return false; // Ou même un exception ! :-)
        }

        return $valeur;
    }
}

$config = Configuration::getInstance();
echo $config->get('maVariable');
echo $config->taVariable;

Tu pourrais aussi utiliser un trait pour éviter de définir la méthode get et/ou set. Si tu veux, tu pourrais même directement ajouter des variables à ta classe... en utilisant les deux fonctions magiques (get et set) pour valider ce qui est initialisé ou récupérer dans l'instance de ta classe.

Mouais, selon moi, les singletons ne volent pas beaucoup plus haut que les variables globales...

personnellement pour les petits sites from scratch j'utilise une class de config aussi .

elle contient mes donnees de dite comme le nom, l'url, les meta etc

La classe gérant la config est une bonne idée, mais la faire une singleton n'est pas génial, AMHA.

Bonjour à tous, je vais opter pour la classe, ce sera le plus simple pour moi et mes petites connaissances.
Merci à tous pour la qualité de vos réponses.

La classe gérant la config est une bonne idée, mais la faire une singleton n'est pas génial, AMHA.

En quoi ce n'est pas génial ? En fait, assurez-vous ne pas avoir plus d'une instance à l'exécution de votre application, après on s'en fou. :-)

Non, on s'en fout pas. Une des bases de la POO est le principe de Single Responsability : une classe ne devrait gérer qu'une seul chose. Avoir une classe qui gère x et s'occupe de elle même en même temps casse cette règle.

Je t'invite à chercher singleton php antipattern sur ton moteur de recherche préféré pour plus de raisons contre les singletons.

De toute façon, le Singleton n'est pas formellement un anti-pattern. Certaines personnes soulève en effet que s'en est un, mais ce n'est pas forcément un problème d'utiliser le Singleton. Pour ton info, un design pattern est une solution standard à un problème. Pour tout dire, les design pattern ont été créés puisque plusieurs programmeurs sont arrivés à des solutions communes. Un jeune programmeur, qui n'aurait jamais entendu parlé des DP, pourrait même trouvé un solution semble à ce qui est proposé dans un DP !

À l'inverse un anti-pattern est une technique de programmation qui peut causer certains problèmes. Par exemple, le copier/coller est un excellent anti-pattern ! Je sais aussi que dans un contexte de multi programmation, le singleton peut avoir certaines limites, cependant dans un code où une structure n'est pas en place, ou plus ou moins, ce n'est pas important qu'il soit utilisé ou non.

Cela dit, je suis d'accord avec toi au sujet du principe qui dit qu'une classe doit gérer une seule chose, mais ce n'est pas un design pattern, il s'agit seulement d'une bonne pratique de programmation, ça n'a rien à voir avec l'existance du singleton.

Faut pas faire plus d'effort qui faut pour utiliser les design pattern... certaines personnes les utiliseront naturellement puisqu'il leur permettent de régler un problème, comme le fait d'avoir une seule instance (en PHP !!!) ! Je pense que Hexa peut oublier l'injection de dépendance pour l'instant... c'est mieux qu'il sente le besoin de l'utiliser qu'on lui dise de l'utiliser.

Comment veux-tu formaliser une telle chose ? Je sais, une organisation à but non lucratif qui gère les designs patterns...

Je suis d'accord avec toi sur le fait qu'un design pattern est une solution, le problème est qu'une solution n'est jamais parfaite.

<?php

# Je veux une fonction qui me retourne le carré du paramètre.
square(5);

# Une solution pourrait être
function square($input) {
    return 25;
}

Bien entendu, la solution n'est pas parfaite. C'est comme tout design pattern, il répond à une attente, pas à toutes les attentes. Le pattern singleton semble convenir aux premiers abords, mais quand on avance, on réalise qu'il a un/des problème(s) majeur(s).

Cela dit, je suis d'accord avec toi au sujet du principe qui dit qu'une classe doit gérer une seule chose, mais ce n'est pas un design pattern, il s'agit seulement d'une bonne pratique de programmation, ça n'a rien à voir avec l'existance du singleton.

Ce n'est pas un design pattern, c'est un principe de base de la POO. [SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design). Ça à donc à voir avec n'importe quelle code qui comporte x >= 1 classe(s).

Je pense que Hexa peut oublier l'injection de dépendance pour l'instant... c'est mieux qu'il sente le besoin de l'utiliser qu'on lui dise de l'utiliser.

Il faut arrêter de voir un DIC comme quelque chose de complexe, les termes utilisées sont les seuls choses de complexes. La forme la plus basique de pattern :

class Container
{
    public function router()
    {
        return new Router($_GET['uri']);
    }
}

Pour avoir une non-factory :

class Container
{
    protected $router;

    public function router()
    {
        return $this->router ? $this->router : new Router($_GET['uri']);
    }
}

Personnellement, j'utilise un modèle un poil plus complexe, qui supporte les regexs (code). Il a une API très simple :

use Utils\Extensions\Arr;
use Utils\Extensions\Is;

require('vendor/autoload.php');

$c = new Storage\Container(new Arr, new Is);

$c->set('foo', function () {
    echo 'building';
    return 'bar';
});

$c->get('foo');
$c->get('foo');
# A affiché 'building' une fois.

$c->set('foo', function () {
    echo 'building';
    return 'bar';
}, true);

$c->get('foo');
$c->get('foo');
# A affiché 'building' deux fois.

$c->set(['fo(.)', 'Arg$1'], function ($name, $matches) {
    return [$name, $matches];
});

$c->get('foA'); // => ['ArgA', ['A']]

$c->exists('fob') //=> true

Je ne conseille pas à Hexa d'utiliser cette implémentation du pattern (il le peut bien entendu si il le souhaite), je suis d'accord avec toi, il doit tracer son chemin.

En gros, ma remarque voulait juste dire, que je pense, que les singletons ne devraient être sur le chemin de personne, surtout pas les débutants (no offense Hexa, bro).