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).

Spring parallel processing. Exécution parallèle avec Spring

Ce billet tente de démystifier l'utilisation en java5+ des exécutions en parallèle des tâches (parallel processing) en s'appuyant sur les classes de Spring qui masquent les difficultés du parallélisme en java.

Les machines de nos jours viennent avec plusieurs processeurs: des multi-core (quatre, huit ou plusieurs centaines cœurs).

Or la puissance de ces ressources n'est pas constamment utilisée.

L'exécution parallèle autorise des calculs parallèles qui consomment ces ressources pour améliorer les performances.

Mais c’est comme tout, le parallélisme ça se mérite. Même si c'est un petit chouia difficile!

En réalité, la difficulté n'est pas dans la mise en place technique mais réside dans la gestion de la cohésion des données.

Techniquement, c'est le développeur qui doit réaliser les calculs parallèles.

C'est sûr, demain apparaîtront côté JVM les méthodes de traitement du parallélisme comme c'était le cas de la gestion mémoire avec le garbage collector ou récemment la gestion des descripteurs de fichier avec try/catch en java7.

Java 8+ nous proposera (peut-être) de faire le calcul paralléle à notre place (nous développeurs).

Ce qui reste au développeur c'est de décrire les traitements atomiques (comme l'atomicité dans les transactions), et à partir de là c'est la JVM qui mène le traitement global parallélisé efficacement en fonction des ressources disponibles.

Bel enjeu de demain.

Signalons que nous n'utilisons pas directement la classe Executors de java qui offre des méthodes statiques pour instancier un Executor ou un ExecutorService.

A la place nous utiliserons les classes de Spring.

La démo ci-après est faite en java7 et spring 3.

Passons à la mise en pratique.

Tests JUnit4 combiné avec Spring et Spring MVC en mode transactionnel

Le titre de ce billet montre bien l'étendue des thèmes variés qui seront traités. Il a pour objectif d'illustrer, à l'aide d'un exemple assez complet et proche des cas réels, la mise en place des tests, en mode transactionnel, pour les différentes couches applicatives. Ainsi les vraies difficultés rencontrées par les développeurs seront évoquées.

Le billet traite JUnit4 enrichi avec les annotations de Spring 2.5+ et ses lanceurs pour exécuter facilement les tests.
Des illustrations en mode transactionnel vous sont proposées à la fin de ce billet.
Le framework JUnit est l'oeuvre conjointe de Kent Beck (créateur de XP) et Erich Gamma (auteur des Design Patterns).
Avec la version 4, JUnit tente de rattraper son retard sur Testng tout en gardant la compatibilité avec JUnit3x ainsi qu'une parfaite intégration aux éditeurs Eclipse, Netbeans, ...

Avec les lanceurs de spring, les tests deviennent plus attrayants. Spring encourage ainsi à adopter l'approche TDD "Test Driven Design" ou "Test-First Developpment".
Notez que le jdk5+ est nécessaire pour certaines parties de code Java. Les commentaires dans le code java le mentionnent au bon endroit.