Nous voilà avec plusieurs Design patterns déjà présentés, et pourtant nous n’avons pas réellement parlé de comment découpler la création de l’utilisation d’une classe.Après le Design Pattern Composite, continuons notre aventure avec le Factory, ou Fabrique (en français). Pour suivre le projet : le github. Problématique Plusieurs armes sont utilisées par les Wookies, par les
Après la présentation du design pattern Bridge (le pont), nous passons à un patron de conception un peu plus simple, et pourtant bien pratique pour encapsuler des éléments d’un même type : le design pattern Composite. Souvent utilisé avec le patron Decorator ou bien Iterator, il est très souvent utilisé. Pour suivre le projet : le github.
Construisons un pont entre certaines modifications qui ne seront pas implémentées pareilles et leur utilisation dans le code. C’est ici, qu’intervient le pattern : Bridge.Il est par exemple très utile pour l’utilisation de différentes versions d’une dll, d’api. Pour suivre le projet : le github. Pour découvrir d’autres patterns : Le Proxy Le Decorator Problématique
Continuons notre aventure des Design Patterns, avec le Proxy. La dernière fois, nous avions un Design Pattern qui lui ressemblait quand même un peu : le Decorator. Patron très pratique pour encapsuler, protéger du code d’appel par exemple à un système d’authentification, il va permettre de proposer une interface commune (le Proxy) pour effectuer le
Nous commençons notre série des design patterns (patrons de conception) avec le Décorateur. Pour suivre tous les projets, nous vous avons proposé un github dédié : Découverte des design patterns Problématique ? Comment réussir à ajouter des fonctionnalités à un Wookie, sans modifier la classe Wookie ? Ici, nous souhaitons garder plusieurs grands principes en