Ce support de cours est une introduction aux services Web de type REST. Il présente les grands concepts de l'architecture REST à savoir les ressources, les verbes et les représentations. Un exemple au travers du service Google URL Shortener est présenté. Finalement une comparaison entre les services Web étendus et services Web REST est présentée.

Ce support de cours présente JAX-WS (JSR-224), une API pour développer des Web Services étendus (WSDL + SOAP) via la plateforme de développement Java.

Dans mon article précédent sur fr les principes SOLID, j'ai mentionné, brièvement, les outils disponibles pour faire de l'injection de dépendances.
Comme ces outils, ainsi que les patterns et principes qui s'y rattachent, semblent relativement peu connus (et encore moins utilisés) dans la communauté .NET francophone, cet article va s'attarder plus longuement sur les avantages de l'injection de dépendances, ainsi que sur les moyens de la mettre en oeuvre.

Ce document représente une compilation du savoir-faire et de l'expertise de Valtech dans le domaine de l'urbanisation et de l'intégration de systèmes. Il s'intéresse aussi bien aux nouvelles perspectives offertes par la vision SOA qu'aux retours d'expériences de Valtech dans ce domaine et plus généralement dans l'urbanisation et l'intégration de systèmes.

Les ESB (Enterprise Service Bus) visent, d'une part à assurer l'interconnexion et d'autre part à gérer la médiation des communications et des interactions entre services et applications d'un SI. Quoique non indispensables, ils n'en demeurent pas moins une brique à forte valeur ajoutée dans le cadre d'une mise en place d'une architecture orientée service (SOA) mature.
Néanmoins les ESB sont aujourd'hui victimes de leur succès et il est souvent difficile de décrypter leur rôle exact.
L'objectif de ce livre blanc est de présenter les fonctionnalités que l'on peut attendre d'un ESB et comment il peut répondre aux besoins d'adaptation inter-applications d'une SOA.

Cette article présente les bases du développement d'une application modulaire. Il présente également un exemple complet d'implémentation en Java.

Présentation du motif de conception Fabrique, exemple en Java.

Cet article a pour objectif de présenter les Design Patterns du "Gang of Four" avec des exemples concis appliqués à Java.
Chaque Design Pattern est présenté avec son diagramme de classes, ses objectifs, les motivations pour l'utiliser, les responsabilités des classes le constituant, puis une implémentation simple.

De tous les motifs de conception (Design patterns), le motif MVC est sans doute celui sur lequel il y a le plus à dire.
Je vais cependant rester simple, le but de cet article est de comprendre MVC, et pourquoi MVC ? Exemples en PHP.

Présentation du pattern architectural MVC (Modèle Vue Contrôleur)qui permet de bien structurer de grosses applications graphiques.
Exemple en Java (Swing).

Cet article a pour but de vous présenter la majorité des design patterns via un exemple de besoin qui sera complété par une mise en pratique en C++.

Le pattern Registry est un pattern méconnu mais largement utilisé dans de nombreux cas. Il est utilisé pour gérer les paramètres d'un programme - exemple typique, la base de registres de Windows est un registre particulier -, les tests unitaires sont enregistrés dans un registre dans certaines implémentation - comme celles de JUnit -, ou plus simplement des menus.

Le pattern Object Pool sert à gérer une quantité finie d'objets de même type utilisés couramment, sans qu'on veuille permettre de construction ou de destruction lors de l'utilisation d'une instance de ces objets. On peut aussi empêcher de cette manière la création de "trop" d'instances.
Exemple en C++.

Cet article montre comment il est possible de créer des programmes souples et puissants au moyen de modules (des éléments interchangeables, réutilisables et combinables entre eux). On y présente de nombreux patterns importants ainsi que la manière de les utiliser et de les combiner entre eux.

Vous souhaitez introduire de la "qualité logicielle" au sein de vos applications ? Sans augmenter les coûts ? En facilitant la maintenance ? En rendant votre programme évolutif ? Vous faites de la Programmation Orientée Objets ? Alors cet article devrait vous intéresser...

Je vous présente ici un pattern essentiel pour développer une application robuste, durable et maintenable : Inversion du contrôle (ou Inversion of Control soit encore IOC).

Permet de modifier le comportement d'un objet lorsque son état est modifié. Tout est mis en place pour donner l'impression que l'objet lui-même a été modifié.
Exemple en Java.

Que sont les GRASP (General Responsability Assignement Software Patterns), ou patterns généraux d'affectation des responsabilités ? Il s'agit de patterns fondamentaux qu'il est nécessaire d'appliquer pour une bonne conception. Ces patterns sont, pour la plupart, directement issus du bon sens du concepteur, et leur représentation est tout aussi intuitive.

Modèle de structure arborescente d'un ensemble de composants cohérents. Permet à la classe cliente de composer, et utiliser d'une manière cohérente (unique) une hiérarchie complexe d'objets.
Exemple en Java.

Unifie et simplie l'interface d'un sous-système cohérent et éventuellement autonome. Forme donc un point d'entrée simplifié dans une API. La façade permet en effet de limiter les points d'entrée d'une API, ce qui a comme effet bénéfique pour votre ensemble de classes, s'il est complexe, d'avoir une chance d'être utilisé.

Ajout dynamique de responsabilités à un objet. L'ajout de responsabilités à un objet sonne évidemment comme un héritage. C'est en effet, le moyen le plus évident de lui fournir des responsabilités supplémentaires. Le manque de souplesse de cette méthode (l'héritage) est bien entendu, son inconvénient majeur. Premièrement, l'héritage n'est pas toujours possible. Deuxièmement, l'héritage peut donner lieu à la prolifération de classes. Enfin, les responsabilités supplémentaires ne sont pas dynamiques.
Exemple en Java.

Construire son application, construire l'architecture de base applicative est l'un des premiers rôles de votre programme : un point d'entrée (fonction mail en C, méthode static main en C++ et en java, etc.) qui va construire l'application, pourtant l'architecture peut être différente d'un appel à l'autre.
Exemple en Java.

Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, pour permettre l'évolutivité de votre projet, il arrive que vous ayez besoin de vous reposer sur une interface ou une API qui n'est pas précisement celle qui vous est fournie. Ce design pattern vous propose de pallier cette problématique.
Exemple en Java.

Classe dont on veut s'assurer qu'il n'existera qu'une et une seule instance dans l'espace et dans le temps d'un bout à l'autre du cycle de vie de l'application.
Exemple en Java.

Recueil de design patterns basés sur ceux du GOF.

Dissocie le processus de construction d'un objet complexe de la structure de représentation de cet objet.

Utiliser un système de stockage de données, tel qu'une base de données, avec Java (ou tout autre langage orienté objet) peut s'avérer plus compliqué qu'il n'y parait... Ceci parce qu'on se retrouve vite avec des objets encombrés de requêtes SQL (ou autres instructions) qui rendent leur utilisation assez lourde, leur modification problématique et leur maintenabilité dans le temps quasiment impossible ! Ce tutoriel vous présente un modèle de conception (design pattern) permettant d'éviter ou d'atténuer ce genre de contraintes afin de rendre votre programme plus souple.

Comprendre les différents design patterns de construction fait partie d'une suite d'articles que j'ai écrits pour expliquer comment implémenter les 23 modèles de conception les plus connus. Dans cet article, nous allons nous concentrer sur le fonctionnement des design patterns liés à la construction d'objets, les deux autres familles feront le sujet d'un autre article.

Dans le cadre du développement d'interfaces graphiques, le terme MVC est sans doute le plus couramment employé quand il s'agit de définir l'architecture utilisée. Pourtant, peu d'architectures utilisent encore aujourd'hui le design pattern MVC tel qu'il a été originellement décrit. Dans cet article, nous allons tenter de faire un tour des différents modèles qu'on appelle communément MVC, et voir en quoi l'utilisation du terme contrôleur est incorrecte et apporte une confusion dans la compréhension de ces modèles.

Le pattern state, ou patron état, est l'un des patterns les plus utilisés. Dans sa définition initiale, il est très simple, mais comme beaucoup de design pattern, son implémentation concrète peut varier beaucoup selon le contexte. Je vous propose ici d'analyser plusieurs implémentations possibles.

Traduction d'un article de Pádraic Brady auteur du site web "patterns for Php". L'article original n'est plus accessible dans la mesure où le site n'est plus en ligne.
Il s'agit de la présentation d'un cas d'utilisation du design pattern strategy en PHP en prenant l'exemple d'un logger.

Présentation du motif de conception Fabrique, exemple en Java.

Cet article a pour objectif de présenter les Design Patterns du "Gang of Four" avec des exemples concis appliqués à Java.
Chaque Design Pattern est présenté avec son diagramme de classes, ses objectifs, les motivations pour l'utiliser, les responsabilités des classes le constituant, puis une implémentation simple.

L'agrégation est une association UML qui lie deux classes. Alors que l'association indique qu'un objet utilise d'autres objets pour son fonctionnement, l'agrégation indique l'utilisation et le pilotage d'un ou plusieurs objets d'un même type.
La composition, elle, est une agrégation particulière dans laquelle un objet agrégé ne peut exister sans son objet conteneur. La relation d'agrégation permet de répondre efficacement à l'étude des variations et des communalités d'une classe, en cherchant à déléguer des responsabilités à certains objets, agrégés dans d'autres (en général tout ce qui est susceptible de varier).
Dans cet article, nous allons voir comment créer une classe mère qui permettra l'agrégation de ses filles, selon certaines règles.

Cet article explore en profondeur les itérateurs apparus avec C# 2.0, ainsi que l'utilisation du mot clé yield.

Le modèle KVO forme avec KVC l'un des principaux socle de l'environnement de développement Cocoa.
Si KVC se rapproche très largement des règles de codage définies en Java pour les Java Beans, on peut considérer que le modèle KVO est le pendant du modèle d'événements en Java.
La similitude s'arrête là car le modèle KVO est bien plus simple.

L'aspect fortement dynamique des types dans Cocoa est enrichi par un modèle de conception très simple pour permettre un accès générique aux propriétés des objets que l'on manipule.
Ce modèle définie une propriété comme un couple formé d'une clef, le nom de la propriété, et de sa valeur.

Cocoa s'appuie sur le langage Objective-C qui, contrairement au C++, ne propose pas un modèle de classe avec héritage multiple. L'héritage simple est la règle, comme dans le monde Java.
Si le langage propose des solutions techniques pour contourner les limites de l'héritage en introduisant l'idée de protocoles (interfaces en Java), le socle Cocoa s'appuie sur une solution conceptuelle : la délégation.
Ainsi, au lieu de dériver une classe NSApplication ou NSWindow pour l'enrichir de comportement spécifiques à votre application, Cocoa vous propose d'implémenter les comportements spécifiques dans un objet délégué.

Présentation de 5 motifs de conception (Design Pattern) implémentés en PHP : Adapter, Iterateur, Decorateur, Delegation, Etat.
Cet article est une traduction d'un article publié en anglais sur IBM developerWorks par Nathan A. Good.

Présentation de 5 motifs de conception (Design Pattern) implémentés en PHP : Fabrique, Singleton, Observer, Chain-of-command, Stratégie, Strategie.
Cet article est une traduction d'un article publié en anglais sur IBM developerWorks par Jack D. Herrington.

Par l'utilisation du pattern MVP vous allez découvrir comment créer une application pouvant utiliser différents interfaces graphiques (Windows, Console, Web, ...) en minimisant au maximum la redondance de code.

Au travers de cet article nous irons à la découverte du design pattern Adaptateur. Nous verrons la problématique qu'il permet de résoudre ainsi que son implémentation en C#.

Mise en oeuvre d'une Façade avec le Zend Framework.

De tous les motifs de conception (Design patterns), le motif MVC est sans doute celui sur lequel il y a le plus à dire.
Je vais cependant rester simple, le but de cet article est de comprendre MVC, et pourquoi MVC ? Exemples en PHP.

Présentation du front contrôleur (modèle MVC) du Zend Framework.

Les design patterns sont nombreux et plus ou moins connus, au cours de cet article je vais vous présenter le plus connu et populaire, il s'agît du Singleton. Ce pattern à pour but de contrôler et de limiter à une ou quelques unes le nombre d'instances existantes pour une classe donnée. Voyons sans plus tarder comment implémenter ce pattern en .Net (Visual Basic 2005 et C# 2.0).

Suite de la série consacrée à l'utilisation des design patterns sous VEGAS.
Au programme: les designs patterns MVC et Observateur.

1er tutoriel d'une série destinée à montrer comment utiliser différents motifs de conception à partir du framework Vegas.
Nous commençons cette série par le Design Pattern Visiteur.

Présentation du pattern architectural MVC (Modèle Vue Contrôleur)qui permet de bien structurer de grosses applications graphiques.
Exemple en Java (Swing).

Cet article a pour but de vous présenter la majorité des design patterns via un exemple de besoin qui sera complété par une mise en pratique en C++.

Le pattern Registry est un pattern méconnu mais largement utilisé dans de nombreux cas. Il est utilisé pour gérer les paramètres d'un programme - exemple typique, la base de registres de Windows est un registre particulier -, les tests unitaires sont enregistrés dans un registre dans certaines implémentation - comme celles de JUnit -, ou plus simplement des menus.

Le pattern Object Pool sert à gérer une quantité finie d'objets de même type utilisés couramment, sans qu'on veuille permettre de construction ou de destruction lors de l'utilisation d'une instance de ces objets. On peut aussi empêcher de cette manière la création de "trop" d'instances.
Exemple en C++.

Cet article explique les avantages de la composition par rapport à un usage souvent trop systématique de l'héritage dans la conception d'API.
Exemple en Java.

Mise en oeuvre de Design Patterns avec Delphi et C#.

Ce document montre les possibilités de configuration des architectures web à trois couches, apportées par le framework Spring (Java) et sa notion d'IoC (Inversion of Control), également appelée injection de dépendance (Dependency Injection).

Dans ce document, je présente certains patterns, indispensables au développeur J2EE. Pour nous aider dans cette tâche, supposons que nous essayions de construire un forum, comme celui de www.developpez.com.
Ce document repose sur les concepts relatifs à la norme J2EE 1.4 et aux EJB 2.1.

Dans cet article, je vais aborder le problème du Singleton en environnement multithread. Cette discussion nous amènera à parler du Java Memory Model et du double-check Locking qui, bien qu'encore recommandé dans de nombreux endroits, ne marche pas.

Présentation des principaux Design Patterns appliqués à Java.

Permet de modifier le comportement d'un objet lorsque son état est modifié. Tout est mis en place pour donner l'impression que l'objet lui-même a été modifié.
Exemple en Java.

Modèle de structure arborescente d'un ensemble de composants cohérents. Permet à la classe cliente de composer, et utiliser d'une manière cohérente (unique) une hiérarchie complexe d'objets.
Exemple en Java.

Ajout dynamique de responsabilités à un objet. L'ajout de responsabilités à un objet sonne évidemment comme un héritage. C'est en effet, le moyen le plus évident de lui fournir des responsabilités supplémentaires. Le manque de souplesse de cette méthode (l'héritage) est bien entendu, son inconvénient majeur. Premièrement, l'héritage n'est pas toujours possible. Deuxièmement, l'héritage peut donner lieu à la prolifération de classes. Enfin, les responsabilités supplémentaires ne sont pas dynamiques.
Exemple en Java.

Construire son application, construire l'architecture de base applicative est l'un des premiers rôles de votre programme : un point d'entrée (fonction mail en C, méthode static main en C++ et en java, etc.) qui va construire l'application, pourtant l'architecture peut être différente d'un appel à l'autre.
Exemple en Java.

Pour des raisons de conformité à une norme, pour ne pas dépendre d'une implémentation, pour permettre l'évolutivité de votre projet, il arrive que vous ayez besoin de vous reposer sur une interface ou une API qui n'est pas précisement celle qui vous est fournie. Ce design pattern vous propose de pallier cette problématique.
Exemple en Java.

Classe dont on veut s'assurer qu'il n'existera qu'une et une seule instance dans l'espace et dans le temps d'un bout à l'autre du cycle de vie de l'application.
Exemple en Java.

Dans cet article nous allons passer en revue les principaux patterns livrés avec ModelMaker de Delphi 7 : Mediator, Wrapper, Visitor, Decorator, Observer, Autres patterns.

Ce tutoriel a pour but de présenter une adaptation possible du design pattern MVC pour une application développée en JAVA Micro-édition

Cet article traite du développement de winforms .NET en mode MVC.

Dans l'API java, on trouve une classe au comportement tout a fait particulier, ThreadLocal. Son principe: stocker des données dans le Thread courant afin de les récupérer plus tard, dans une autre méthode par exemple, sans avoir à les passer en argument à toute la chaine d'appel. Cette classe peut vous être d'un grand secours, mais elle doit être utilisée judicieusement et surtout en extrêmement précautionneusement!

Cet article a pour objectif d'étudier les différents types d'héritage multiple que l'on trouve généralement dans les langages de programmation orientés objet à base de classes. Plus précisément, il va comparer l'héritage multiple à une version bridée, nommée héritage multiple d'interfaces, que l'on trouve dans certains langages ; ceci afin de montrer en quoi les limitations introduites par cette dernière me semblent problématiques pour mettre en place une bonne architecture de code.
Cet article n'est pas une introduction à l'héritage (qu'il soit simple ou multiple). Il n'entrera pas non plus dans les détails et les difficultés d'implémentation de l'héritage multiple mais se concentrera sur le point de vue de l'utilisateur du langage.