Pour le développement de Pyxoo je suis souvent confronté à la création de classes qui ne doivent proposer qu’une seule instance d’elles-même. La solution du Singleton semble bien évidemment la plus pertinente pour répondre à ce problème.

Malgré les différentes solutions trouvées sur la toile ici ou là, un problème persiste en python : il est impossible de rendre privé un contructeur de classe comme en java.

Pour celà, un petit hack existe :

class MaClasse:
    __instance = None
    class __PRIVATE:pass

    @classmethod
    def getInstance(cls):
        if cls.__instance is None: cls.__instance = MaClasse(cls.__PRIVATE)
        return cls.__instance

    def __init__(self, privateAccess):
        if privateAccess is not self.__PRIVATE:
            raise Exception("Contructeur privé")

#Pour recuperer l'instance de la classe :
o = MaClasse.getInstance()

Nous venons de voir une manière simple de rendre privé le constructeur d’une classe et donc par la même occasion le design pattern Singleton qui, je le rappelle, fait partie de la famille “Création”.

Un avantage de cette méthode est la méthode statique getInstance() qui permet au premier coup d’oeil de comprendre qu’il s’agit d’un Singleton.

Un autre motif de conception peu connu mais néanmoins utile : le Multiton. Ce dernier est une sorte de singleton mais associé à une clé passée en paramètre de la méthode getInstance().

Un exemple concret de multiton est le ModelLocator implémenté dans la librairie Pyxoo. Un ModelLocator est associé à un Plugin passé en paramètre.

Voici un autre exemple d’implémentation du design pattern Multiton :

class MaClasse:
    __instances = dict()
    class __PRIVATE:pass

    @classmethod
    def getInstance(cls, unObjet):
        if unObject not in cls.__instances:
            cls.__instances[unObjet] = MaClasse(cls.__PRIVATE)
        return cls.__instances[unObjet]

    def __init__(self, privateAccess):
        if privateAccess is not self.__PRIVATE:
            raise Exception("Contructeur privé")

#Pour recuperer une instance de la classe

o1 = MaClasse.getInstance( "A1" )
o2 = MaClasse.getInstance( "A1" )
o3 = MaClasse.getInstance( "A2" )

id(o1) == id(o2) #retourne vrai
id(o1) == id(o3) #retourne faux

Une méthode statique release() peut souvent être utile dans les deux cas présentés ci-dessus. En effet, il peut être nécessaire de réinitialiser l’instance.

class MaClasse:
    __instance = None
    class __PRIVATE:pass

    @classmethod
    def getInstance(cls):
        if cls.__instance is None:cls.__instance = MaClasse(cls.__PRIVATE)
        return cls.__instance

    def __init__(self, privateAccess):
        if privateAccess is not self.__PRIVATE:
            raise Exception( "Constructeur privé")

    @classmethod
    def release(cls):
        cls.__instance = None

Comme vous pouvez le constater cette méthode réinitialise l’instance de la classe.

Voilà, c’est fini pour ce petit tutoriel, en espérant vous avoir été utile dans la compréhension de ces deux Design Pattern.

Aujourd’hui je vais tenter de vous expliquer comment fonctionne l’un des Design Patterns les plus utilisé qui fut initialement proposé par le GOF (Gang Of Four) : le Design Pattern Stratégie.

Pour commencer, il peut être intéressant de rappeler ce que sont les Design Pattern ou “Motifs de conception” en français. Les Design Patterns sont un ensemble de solutions standards permettant de répondre à des problèmes de conception rencontrés lors du développement de projets orientés objet. Les Design Patterns se regroupent dans trois grands groupes : Créationnel, Structurel et Comportemental. Le motif de conception que l’on va voir aujourd’hui fait partie du dernier groupe : les comportementaux.

Le Design Pattern Stratégie

Description :

L’intérêt principal de ce motif de conception est de permettre l’encapsulation d’algorithmes et de les rendre permutables. En effet, imaginons que l’on souhaite changer dynamiquement le comportement d’un objet et cela sans modifier la classe de ce dernier. A première vue, celà semble plutôt compliqué… mais il n’en est rien
Prenons un exemple simple : Une classe Personne qui a le dont de se déplacer. On peut imaginer plusieurs types de déplacements : marcher, courir !
De manière générale on aurait tendance à créer une méthode par déplacement :

Exemple en Python:

class Personne:
def marcher(self):
print "je marche"

def courir(self):
print "je cours"

Exemple en PHP 5 :

class Personne
{
public function marcher()
{
print "je marche";
}

public function courir()
{
print "je cours";
}
}

C’est pas mal, mais rien de très dynamique ! En effet, imaginons que l’on souhaite ajouter un nouveau comportement de déplacement (par exemple : nager) il faudra ajouter une nouvelle méthode.
Stratégie va permettre à notre classe Personne de posséder un comportement de déplacement dynamiquement interchangeable. Pour cela nous devons externaliser les comportements de la classe en utilisant un système bien connu en POO : la composition.
Regardons le diagramme de classe suivant :

Le diagramme UML :

Ce schéma mérite une petite explication. Comme on peut le voir, la classe Personne ne possède plus les trois méthodes “marcher“, “courir” mais elles ont été remplacées par deux autres : “setMouvement” et “déplacer“. La première va nous permettre d’attribuer aux instances de la classe Personne un objet Mouvement. La seconde quant à elle va exécuter le mouvement précédemment attribué à l’objet Personne. Les comportements sont désormais des classes à part entière qui implémente l’interface Mouvement.

Exemple en python :

class Personne:
def __init__(self):
self.__mouvement = None

def setMouvement(self, mouvement):
self.__mouvement = mouvement

def deplacer(self):
if self.__mouvement:
self.__mouvement.execute()

class Mouvement:
def execute(self):
raise "Doit être implementé"

class Marcher(Mouvement):
def execute(self):
print "je marche"

class Courir(Mouvement):
def execute(self):
print "je cours"

pers = Personne()

unMouvement = Marcher()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je marche"

unMouvement = Courir()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je cours"

En Python la notion d’interface comme en Java ou PHP 5 n’existe pas. J’ai donc fait en sorte, dans mon exemple, que la méthode execute de la classe Mouvement soit obligatoirement redéfinie dans les classes qui étendent de celle-ci.

Exemple en PHP 5 :

interface Mouvement
{
public function execute();
}

class Marcher implements Mouvement
{
public function execute()
{
print "je marche";
}
}

class Courir implements Mouvement
{
public function execute()
{
print "je cours";
}
}

class Personne
{
private $mouvement;

public function setMouvement( Mouvement $mouvement )
{
$this->mouvement = $mouvement;
}

public function deplacer()
{
if( !is_null($this->mouvement) )
{
$this->mouvement->execute();
}
}
}

$pers = new Personne();

$unMouvement = new Marcher();
$pers->setMouvement( $unMouvement );
$pers->deplacer();// affiche "je marche"

$unMouvement = new Courir();
$pers->setMouvement( $unMouvement );
$pers->deplacer();// affiche "je cours"

La méthode deplacer appelle la méthode execute du mouvement passé en paramètre. On s’aperçoit dans cet exemple que comportement de la méthode deplacer est modifiable dynamiquement. Lors de son premier appel elle affiche “je marche” puis “je cours” lors du second appel. Ceci est du au fait que le mouvement passé en paramètre n’est plus le même. Imaginons désormais que l’on doivent ajouter un nouveau comportement de déplacement (par exemple : “nager”), il suffira tout simplement de créer une nouvelle classe nommée Nager qui implémente la classe Mouvement.

class Nager(Mouvement):
def execute(self):
print "je nage"

pers = Personne()

unMouvement = Nager()
pers.setMouvement( unMouvement )
pers.deplacer() #affiche "je nage"

Très pratique si votre boss ne vous à fourni que la version compilée de la classe Personne On peut modifier son comportement sans toucher une seule ligne de celle-ci.

Et voilà que ce premier tutoriel sur les Design Patterns touche à sa fin. En espérant que ça vous a plu…