Se tiendra ce week-end, le 2 et 3 juin, à la Cité des Sciences à Paris la première journée python francophone organisée par l’afpy. On y retrouvera entre autres une présentation sur le framework Django réalisée par David Larlet.
De nombreux autres sujets seront proposés : Zope, Twisted, Python et la 3D, etc…
Le programme complet du week-end.
Un petit billet pour signaler l’ouverture de Prizee Labs. Un blog principalement orienté sur la technologie Flash et de tout ce qui l’entoure. On retrouve notamment des interventions de Francis Bourre le créateur de Pixlib une librairie bien connue dans le milieu Flash tout comme Kairos une extension de Pixlib développée par Cédric Nehemie.
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.
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:
def courir(self):
print “je cours”
Exemple en PHP 5 :
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 :
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.
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.
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.
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…
Depuis peu je suis passé sous la dernière version de Kubuntu : la Festy Fawn. Mais un petit bug semble être apparu. En effet, lors de l’ouverture d’une seconde console dans Konsole ou Yakuake, celle-ci n’est pas transparente malgré la configuration qui normalement le permet.
Après quelques recherches, il semblerait que celà soit un soft nommé ‘Scim’ qui poserait problème. Donc pour rétablir cette fameuse transparence, il suffit tout simplement de désinstaller tous les packages scim (pour ma part : libscim8c2a, libskim0, skim, et scim-qtimm)
Relancer Konsole et/ou Yakuake et le tour est joué!
Pour ceux que ça intéresse voici un petit lien qui explique à quoi sert SCIM