Modèles
L'une des exigences les plus courantes pour les postes vacants est la « connaissance des modèles ». Tout d’abord, il convient de répondre à une question simple : « Qu’est-ce qu’un modèle de conception ? » Pattern est traduit de l’anglais par « modèle ». C'est-à-dire qu'il s'agit d'un certain modèle selon lequel nous faisons quelque chose. La même chose est vraie en programmation. Il existe certaines bonnes pratiques et approches établies pour résoudre les problèmes courants. Chaque programmeur est un architecte. Même lorsque vous créez seulement quelques classes, voire une, cela dépend de vous, de la durée pendant laquelle le code peut survivre à des exigences changeantes et de la commodité avec laquelle il peut être utilisé par d'autres. Et c'est là que la connaissance des modèles sera utile, car... Cela vous permettra de comprendre rapidement la meilleure façon d’écrire du code sans le réécrire. Comme vous le savez, les programmeurs sont des gens paresseux et il est plus facile de bien écrire quelque chose tout de suite que de le refaire plusieurs fois.) Les modèles peuvent aussi ressembler à des algorithmes. Mais ils ont une différence. L'algorithme se compose d'étapes spécifiques qui décrivent les actions nécessaires. Les modèles décrivent uniquement l'approche, mais ne décrivent pas les étapes de mise en œuvre. Les modèles sont différents, parce que... résoudre différents problèmes. On distingue généralement les catégories suivantes :-
Génératif
Ces modèles résolvent le problème de la flexibilité de la création d'objets
-
De construction
Ces modèles résolvent le problème de la création efficace de connexions entre les objets
-
Comportemental
Ces modèles résolvent le problème de l'interaction efficace entre les objets
Modèles de création
Commençons par le début du cycle de vie des objets – avec la création des objets. Les modèles génératifs aident à créer des objets plus facilement et offrent de la flexibilité dans ce processus. L'un des plus connus est « Builder ». Ce modèle vous permet de créer des objets complexes étape par étape. En Java, l'exemple le plus connu estStringBuilder:
class Main {
public static void main(String[] args) {
StringBuilder builder = new StringBuilder();
builder.append("Hello");
builder.append(',');
builder.append("World!");
System.out.println(builder.toString());
}
}java.util.Calendar. La classe elle-même Calendarest abstraite, et pour la créer la méthode est utilisée getInstance:
import java.util.*;
class Main {
public static void main(String[] args) {
Calendar calendar = Calendar.getInstance();
System.out.println(calendar.getTime());
System.out.println(calendar.getClass().getCanonicalName());
}
}Calendaret une classe est créée GregorianCalendar. Si nous regardons le constructeur, nous pouvons voir que différentes implémentations sont créées en fonction des conditions Calendar. Mais parfois, une seule méthode d’usine ne suffit pas. Parfois, vous devez créer différents objets pour qu’ils s’emboîtent. Un autre modèle nous y aidera - « Usine abstraite ». Et puis nous devons créer différentes usines en un seul endroit. En même temps, l'avantage est que les détails de mise en œuvre ne sont pas importants pour nous, c'est-à-dire peu importe l'usine spécifique que nous obtenons. L'essentiel est qu'il crée les bonnes implémentations. Super exemple :
java.lang.Cloneable:
class Main {
public static void main(String[] args) {
class CloneObject implements Cloneable {
@Override
protected Object clone() throws CloneNotSupportedException {
return new CloneObject();
}
}
CloneObject obj = new CloneObject();
try {
CloneObject pattern = (CloneObject) obj.clone();
} catch (CloneNotSupportedException e) {
//Do something
}
}
}clone. Autrement dit, la création d’un objet basé sur un prototype relève de la responsabilité de l’objet lui-même. Ceci est utile car cela ne lie pas l'utilisateur à l'implémentation de l'objet modèle. Eh bien, le tout dernier de cette liste est le modèle « Singleton ». Son objectif est simple : fournir une seule instance de l'objet pour l'ensemble de l'application. Ce modèle est intéressant car il montre souvent des problèmes de multithreading. Pour un examen plus approfondi, consultez ces articles :
Modèles structurels
Avec la création d’objets, c’est devenu plus clair. Il est désormais temps d’examiner les modèles structurels. Leur objectif est de construire des hiérarchies de classes et leurs relations faciles à prendre en charge. L'un des premiers modèles les plus connus est le « adjoint » (proxy). Le proxy a la même interface que l'objet réel, cela ne fait donc aucune différence pour le client de travailler via le proxy ou directement. L'exemple le plus simple est java.lang.reflect.Proxy :import java.util.*;
import java.lang.reflect.*;
class Main {
public static void main(String[] arguments) {
final Map<String, String> original = new HashMap<>();
InvocationHandler proxy = (obj, method, args) -> {
System.out.println("Invoked: " + method.getName());
return method.invoke(original, args);
};
Map<String, String> proxyInstance = (Map) Proxy.newProxyInstance(
original.getClass().getClassLoader(),
original.getClass().getInterfaces(),
proxy);
proxyInstance.put("key", "value");
System.out.println(proxyInstance.get("key"));
}
}HashMapqui implémente l'interface Map. Nous créons ensuite un proxy qui remplace celui d'origine HashMappour la partie client, qui appelle les méthodes putet get, en ajoutant notre propre logique lors de l'appel. Comme nous pouvons le voir, l’interaction dans le modèle se produit via les interfaces. Mais parfois, un substitut ne suffit pas. Et puis le motif " Décorateur " peut être utilisé. Un décorateur est également appelé emballage ou emballage. Proxy et décorateur sont très similaires, mais si vous regardez l'exemple, vous verrez la différence :
import java.util.*;
class Main {
public static void main(String[] arguments) {
List<String> list = new ArrayList<>();
List<String> decorated = Collections.checkedList(list, String.class);
decorated.add("2");
list.add("3");
System.out.println(decorated);
}
}import java.util.*;
class Main {
public static void main(String[] arguments) {
String[] array = {"One", "Two", "Three"};
List<String> strings = Arrays.asList(array);
strings.set(0, "1");
System.out.println(Arrays.toString(array));
}
}List. Lorsque nous travaillons avec, nous travaillons en fait avec un tableau. Par conséquent, ajouter des éléments ne fonctionnera pas, car... Le tableau d'origine ne peut pas être modifié. Et dans ce cas, nous obtiendrons UnsupportedOperationException. La prochaine approche intéressante pour développer une structure de classe est le modèle composite . Il est intéressant dans la mesure où un certain ensemble d'éléments utilisant une interface sont disposés dans une certaine hiérarchie arborescente. En appelant une méthode sur un élément parent, nous obtenons un appel à cette méthode sur tous les éléments enfants nécessaires. Un excellent exemple de ce modèle est l'interface utilisateur (que ce soit java.awt ou JSF) :
import java.awt.*;
class Main {
public static void main(String[] arguments) {
Container container = new Container();
Component component = new java.awt.Component(){};
System.out.println(component.getComponentOrientation().isLeftToRight());
container.add(component);
container.applyComponentOrientation(ComponentOrientation.RIGHT_TO_LEFT);
System.out.println(component.getComponentOrientation().isLeftToRight());
}
}java.awt :
Modèles comportementaux
Nous avons donc compris comment créer des objets et comment organiser les connexions entre les classes. La chose la plus intéressante qui reste est d'offrir une flexibilité dans la modification du comportement des objets. Et les modèles de comportement nous y aideront. L'un des modèles les plus fréquemment mentionnés est le modèle « Stratégie ». C'est ici que commence l'étude des modèles dans le livre « Head First. Design Patterns ». En utilisant le modèle « Stratégie », nous pouvons stocker à l'intérieur d'un objet comment nous allons effectuer l'action, c'est-à-dire l'objet à l'intérieur stocke une stratégie qui peut être modifiée pendant l'exécution du code. Il s'agit d'un modèle que nous utilisons souvent lorsque nous utilisons un comparateur :import java.util.*;
class Main {
public static void main(String[] args) {
List<String> data = Arrays.asList("Moscow", "Paris", "NYC");
Comparator<String> comparator = Comparator.comparingInt(String::length);
Set dataSet = new TreeSet(comparator);
dataSet.addAll(data);
System.out.println("Dataset : " + dataSet);
}
}TreeSet. Il a le comportement de TreeSetmaintenir l'ordre des éléments, c'est-à-dire les trie (puisqu'il s'agit d'un SortedSet). Ce comportement a une stratégie par défaut, que l'on voit dans le JavaDoc : le tri en "ordre naturel" (pour les chaînes, il s'agit d'un ordre lexicographique). Cela se produit si vous utilisez un constructeur sans paramètre. Mais si on veut changer de stratégie, on peut passer Comparator. Dans cet exemple, nous pouvons créer notre ensemble en tant que new TreeSet(comparator), puis l'ordre de stockage des éléments (stratégie de stockage) passera à celui spécifié dans le comparateur. Fait intéressant, il existe presque le même modèle appelé « État ». Le modèle « État » dit que si nous avons un comportement dans l'objet principal qui dépend de l'état de cet objet, alors nous pouvons décrire l'état lui-même comme un objet et modifier l'objet d'état. Et déléguez les appels de l'objet principal à l'état. Un autre modèle que nous connaissons grâce à l'étude des bases mêmes du langage Java est le modèle « Command ». Ce modèle de conception suggère que différentes commandes peuvent être représentées comme différentes classes. Ce modèle est très similaire au modèle Stratégie. Mais dans le modèle Stratégie, nous redéfinissons la manière dont une action spécifique serait effectuée (par exemple, trier dans TreeSet). Dans le modèle « Commande », nous redéfinissons quelle action sera effectuée. La commande pattern nous accompagne tous les jours lorsque nous utilisons des threads :
import java.util.*;
class Main {
public static void main(String[] args) {
Runnable command = () -> {
System.out.println("Command action");
};
Thread th = new Thread(command);
th.start();
}
}java.util.logging:
import java.util.logging.*;
class Main {
public static void main(String[] args) {
Logger logger = Logger.getLogger(Main.class.getName());
ConsoleHandler consoleHandler = new ConsoleHandler(){
@Override
public void publish(LogRecord record) {
System.out.println("LogRecord обработан");
}
};
logger.addHandler(consoleHandler);
logger.info("test");
}
}logger.getHandlers) pour cet enregistreur. Un autre modèle que nous voyons quotidiennement est “ Itérateur ”. Son essence est de séparer une collection d'objets (c'est-à-dire une classe représentant une structure de données. Par exemple List) et de parcourir cette collection.
import java.util.*;
class Main {
public static void main(String[] args) {
List<String> data = Arrays.asList("Moscow", "Paris", "NYC");
Iterator<String> iterator = data.iterator();
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
}
}java.nio.file.FileVisitor :
import java.nio.file.*;
import java.nio.file.attribute.*;
import java.io.*;
class Main {
public static void main(String[] args) {
SimpleFileVisitor visitor = new SimpleFileVisitor() {
@Override
public FileVisitResult visitFile(Object file, BasicFileAttributes attrs) throws IOException {
System.out.println("File:" + file.toString());
return FileVisitResult.CONTINUE;
}
};
Path pathSource = Paths.get(System.getProperty("java.io.tmpdir"));
try {
Files.walkFileTree(pathSource, visitor);
} catch (AccessDeniedException e) {
// skip
} catch (IOException e) {
// Do something
}
}
}import java.util.*;
class Main {
public static void main(String[] args) {
Observer observer = (obj, arg) -> {
System.out.println("Arg: " + arg);
};
Observable target = new Observable(){
@Override
public void notifyObservers(Object arg) {
setChanged();
super.notifyObservers(arg);
}
};
target.addObserver(observer);
target.notifyObservers("Hello, World!");
}
}java.util.Timer :
import java.util.*;
class Main {
public static void main(String[] args) {
Timer mediator = new Timer("Mediator");
TimerTask command = new TimerTask() {
@Override
public void run() {
System.out.println("Command pattern");
mediator.cancel();
}
};
mediator.schedule(command, 1000);
}
}Timer'a. À l'intérieur du minuteur, il y a une file d'attente des tâches TaskQueue, il y a un fil de discussion TimerThread. Nous, en tant que clients de cette classe, n'interagissons pas avec eux, mais interagissons avec Timerl'objet qui, en réponse à notre appel à ses méthodes, accède aux méthodes des autres objets dont il est l'intermédiaire. Extérieurement, cela peut ressembler beaucoup à "Façade". Mais la différence est que lorsqu'une façade est utilisée, les composants ne savent pas que la façade existe et se parlent. Et lorsque "Mediator" est utilisé, les composants connaissent et utilisent l'intermédiaire, mais ne se contactent pas directement. Il vaut la peine de considérer le modèle « Template Method », qui ressort clairement de son nom. L'essentiel est que le code est écrit de telle manière que les utilisateurs du code (développeurs) disposent d'un modèle d'algorithme dont les étapes peuvent être redéfinies. Cela permet aux utilisateurs de code de ne pas écrire l'intégralité de l'algorithme, mais de réfléchir uniquement à la manière d'effectuer correctement l'une ou l'autre étape de cet algorithme. Par exemple, Java possède une classe abstraite AbstractListqui définit le comportement d'un itérateur par List. Cependant, l'itérateur lui-même utilise des méthodes feuilles telles que : get, set, remove. Le comportement de ces méthodes est déterminé par le développeur des descendants AbstractList. Ainsi, l'itérateur dans AbstractList- est un modèle pour l'algorithme d'itération sur une feuille. Et les développeurs d'implémentations spécifiques AbstractListmodifient le comportement de cette itération en définissant le comportement d'étapes spécifiques. Le dernier des modèles que nous analysons est le modèle « Snapshot » (Momento). Son essence est de préserver un certain état d'un objet avec la capacité de restaurer cet état. L'exemple le plus reconnaissable du JDK est la sérialisation d'objets, c'est-à-dire java.io.Serializable. Regardons un exemple :
import java.io.*;
import java.util.*;
class Main {
public static void main(String[] args) throws IOException {
ArrayList<String> list = new ArrayList<>();
list.add("test");
// Save State
ByteArrayOutputStream stream = new ByteArrayOutputStream();
try (ObjectOutputStream out = new ObjectOutputStream(stream)) {
out.writeObject(list);
}
// Load state
byte[] bytes = stream.toByteArray();
InputStream inputStream = new ByteArrayInputStream(bytes);
try (ObjectInputStream in = new ObjectInputStream(inputStream)) {
List<String> listNew = (List<String>) in.readObject();
System.out.println(listNew.get(0));
} catch (ClassNotFoundException e) {
// Do something. Can't find class fpr saved state
}
}
}
Conclusion
Comme nous l’avons vu lors de l’examen, il existe une grande variété de modèles. Chacun d'eux résout son propre problème. Et la connaissance de ces modèles peut vous aider à comprendre à temps comment écrire votre système pour qu'il soit flexible, maintenable et résistant au changement. Et enfin, quelques liens pour approfondir :- La ressource la plus étonnante pour les modèles : refactoring.guru
- Playlist vidéo « Modèles de conception dans la programmation orientée objet »
- Exercices sur les modèles de conception
- Test de modèle
- Cours modèles sur Udemy
- Cours de patrons sur Coursera
GO TO FULL VERSION