Pratiquons le Design Pattern Delegate (ou Façade) : Démos avancées

 

Le design pattern delegate ( ou façade ) est un pattern très utilisé et facile à expliquer.

Deux démos, une simple et une seconde très avancée, vous permettent de pratiquer sereinement ce design sans difficulté.

Ainsi, les ingrédients de ce blog sont divisés en deux parties:

  • La première partie, contenant une démo simple, n'exige aucun prérequis (mis à part un peu de java 8).
  • La seconde partie, contenant une démo très avancée, nécessite de connaître un peu spring-batch et en particulier son FlatFileItemReader (retrouvez un article sur le sujet ici).

Design pattern Command illustré en java 8 et en Javascript & PhantomJS!

COMMAND_designPattern

Rien que le titre est tout un programme!

Ce billet présente des exemples pratiques, en Java8 et en JS, du design pattern (motif de conception) de comportement nommé Command. L'objectif principal de ce design est de découpler le sender (producer) du receiver (consumer). Nous détaillons cela un peu plus loin. A la fin de la première démo, on peut surtout constater que cet objectif est atteint.

Architecture DDDD N-Layered (Distributed Domain Driven Design) et .NET

Régulièrement, l'équipe des architectes Microsoft met à jour un excellent document d'architecture pour les très gros projets. Cet article a pour but de présenter en synthèse cette architecture, particulièrement bien découpée.

Besoins en architecture

Il existe une grosse demande pour faire correspondre les patterns d’architectures avec les toutes dernières technologies Microsoft.
Il est nécessaire de bénéficier d’architectures d’entreprise préétablies pour avoir une démarche unifiée de construction des applications.

Les frameworks techniques

Les briques technologiques offertes par Microsoft (ou le monde du .NET) sont extrêmement nombreuses: Framework .NET, Silverlight, WPF, WCF, WF, ASP.NET MVC, Windows Identity Foundation, Entity Framework, Azure, SQL Server, Unity, …
Comment distribuer tous ces frameworks sur une architecture d’entreprise ?

Pratiquer le design-pattern Strategy en 15 min

Dans ce billet, nous poursuivons les notions de design-pattern (motifs de conception).
Après le design-pattern Observer, étudions un autre motif de conception Strategy qui appartient aussi au groupe de comportement.
Ce motif de conception permet de définir plusieurs algorithmes interchangeables dynamiquement.

Encore un motif de conception qui répond à la question : Comment faire simple quand on peut faire compliqué ?

En fait, cela reste simple si on n'oublie pas de le pratiquer tôt. Sinon, ce sont les développements, les tests et les évolutions qui deviennent compliqués.
Mais, la revue de code permet aussi d'éviter de rendre les développements plus compliqués et de tirer profit de la mise en place de ces design.

D'un point de vue théorique, il est facile de l'appréhender. Néanmoins, la mise en pratique (avec le langage Java) de ce design reste un peu moins évidente.

Beaucoup d'entre nous l'ont déjà pratiqué sans, forcément, le savoir.
Un exemple de l'API Java est la méthode Collections.sort ayant deux arguments dont le second est l'algorithme de comparaison pour effectuer le tri.
Ainsi, cette méthode est fournie avec une implémentation par défaut qui convient à bon nombre de types de données avec la possibilité de redéfinir dynamiquement de nouveaux algorithmes de tri.

Notons enfin que dans l'exemple d'illustration ci-après, nous allons comparer deux entreprises déclarées dans des répertoires différents
Et par conséquent, les codes de référence et libellés sont variés et distincts d'un répertoire à un autre.
La comparaison est basée sur un score de pertinence qui est une moyenne de(s) différente(s) note(s) calculée(s).

Un seul pré-requis pour ce billet : connaître la notion de composition en programmation objet.