modèle de conception pour la mise en œuvre par défaut avec des méthodes vides
https://stackoverflow.com/questions/1259495
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Y at-il un design pattern qui décrit le scénario dans lequel une implémentation par défaut non abrégé est fourni qui met en œuvre tout ou partie des méthodes de l'interface avec vide, les implémentations NO-OP. Cela se fait dans le but d'alléger les sous-classes à la charge de mettre en œuvre des méthodes qu'ils peuvent eux-mêmes ne pas avoir besoin / utilisation:
public interface MyInterface {
public void doThis();
public void doThat();
public void done();
}
public class MyClass implements MyInterface {
public void doThis() {
// NO-OP
}
public void doThat() {
// NO-OP
}
public void done() {
// Some standard implementation
}
}
public class MuSubClass extends MyClass {
public void doThat() {
// Subclass only cares about doThat()
}
}
Je l'ai vu ce modèle a utilisé un certain nombre de fois, y compris DefaultHandler de Java dans le cadre de SAX et MouseAdapter . Dans les cas somes ces classes sont nommées comme adaptateurs, mais j'avais l'impression que le modèle d'adaptateur se traduit entre deux interfaces différentes.
Étant donné que dans ces cas il n'y a qu'une seule interface déclarée qui est en cours de traduction à un sous-ensemble non défini de cette interface - Je ne sais pas exactement comment cela est dans l'esprit du modèle d'adaptateur
.En outre, je ne vois pas tout à fait comment cela adhère au modèle NullObject soit, étant donné que certaines méthodes pourraient avoir une mise en œuvre et le NullObject est traditionnellement un singleton.
La solution
Il n'y a pas de modèles de conception pour la mise en œuvre par défaut.
Je joins habituellement préfixe DoNothing au nom de la classe. Selon son intention je aussi utiliser Base ou Default (celui-ci est largement utilisé). Probablement MouseAdapter devrait être appelé DefaultMouseListener.
Dans le cas où vous tenez, vous pouvez stub systématiquement une interface avec un simple DynamicProxy , vous devez retourner uniquement une valeur par défaut "agréable" (null pour objet, 0 pour numérique, etc.).
BTW ceci est une très bonne question.
EDIT
De plus, ce n'est ni un Stub ou Mock :. peut-être il peut être confondu avec un Stub, mais l'intention est différente
Autres conseils
Je l'ai vu cette conception utilisée au printemps où ils ont une classe nommée FlowExecutionListenerAdapter qui vous évite la mise en œuvre de toutes les opérations FlowExecutionListener.
Cependant, il ne sonne comme le modèle d'objet nul aussi. Cependant, je pense qu'il se trouve mieux dans le monde de l'adaptateur uniquement parce qu'il changeant la behavour de l'interface en vous permettant de mettre en œuvre que le bit que vous voulez ... mais est un difficile.
Je suis sûr que cette question a été posée?
Cela semble similaire non? pourrait être intéressant à lire.
Il est également utilisé dans Swing (WindowAdapter, qui met en œuvre WindowListener). Il est seulement un adaptateur pratique, il suffit de définir 1-2 méthodes de cette façon d'avoir un WindowListener utile. Ceci est en effet une instance du modèle d'adaptateur, montre aussi la puissance des classes abstraites. Il est même un exemple pour illustrer pourquoi l'héritage multiple de mise en œuvre est parfois utile.
En ce qui concerne les modèles de conception réguliers, dans la méthode Temlate vous pouvez définir des opérations de crochet, qui peut être outrepassée (contrairement aux méthodes abstraites, qui doivent être), mais le comportement par défaut (généralement le NO-OP) est significatif aussi.
Vous devez suivre un principe différent de la conception: principe ségrégation d'interface
Le principe Ségrégation Interface déclare que les clients ne devraient pas être contraints de mettre en œuvre des interfaces qu'ils n'utilisent pas. Au lieu d'une interface de graisse de nombreuses petites interfaces sont préférés en fonction des groupes de méthodes, chacun servant un sous-module.
Vous ne devriez pas mettre en œuvre PLUS Et vous ne devriez pas mettre en œuvre MOINS
Jetez un oeil à des questions connexes SE pour plus de détails.
Grande question.
J'ai commencé à utiliser NoOp comme préfixe de nom de classe pour ce modèle. Il est court, clair, et non surchargé (comme Empty [contient rien?], Null [Null modèle d'objet, qui est différent?], Abstract [Prévoit-il une mise en œuvre?], Ou Base [Prévoit-il une mise en œuvre?]) .
Je peux écrire ce style de classe quand j'ai une API tiers qui fournit des « crochets » pour isntrumentation lors d'une opération complexe. Considérons les deux classes suivantes fournies par une bibliothèque:
public class LongRunningActionRunner {
public void runSomethingLong(DecisionListener cdh) {
// ...
}
}
public interface DecisionListener {
public void beforeFooHook();
public void afterFooHook();
public void beforeBarHook();
public void afterBarHook();
public void beforeBazHook();
public void afterBazHook();
}
Dans ce cas, vous pourriez droit une classe en utilisant ce modèle comme celui-ci:
public class NoOpDecisionListener implements DecisionListener {
@Override public Something beforeFooHook() {}
@Override public Something afterFooHook() {}
@Override public Something beforeBarHook() {}
@Override public Something afterBarHook() {}
@Override public Something beforeBazHook() {}
@Override public Something afterBazHook() {}
}
Ce modèle était très répandu dans les anciennes versions de Java. Il est l'alternative Java 7 du .
Josh Bloch appelle un mise en œuvre du squelette . Même si une mise en œuvre du squelette est généralement abstraite, vous devez pas forcer les clients à créer une sous-classe si le squelette lui-même est suffisante.
Je suis d'accord avec la réponse précédente pointant vers le Interface Principe Ségrégation . La nécessité d'une mise en œuvre du squelette peut être une odeur de code indiquant une interface est trop « gras » et peut essayer de faire plus d'un emploi. Fractionnement l'interface est préférable dans ce scénario à la création d'une mise en œuvre du squelette avec une logique factice ou noop.
Pour moi, cela semble plus proche de la Cas particulier ou modèle Null objet .
Vos mises à jour suggèrent quelque chose de similaire à Méthode modèle attendre à ce que vous ne disposez pas d'un seul méthode qui appelle chaque méthode modèle, par exemple
public void doEverything()
{
doThis();
doThat();
done();
}
Demandez-vous sur le Null Objet Motif ?
Suite à votre édition, l'objet MyClass est rien de plus qu'un implemenation par défaut. Je ne pense pas qu'il y ait une quelconque modèle de conception particulière qui le décrit.
Je crois que Martin Fowler appellerait ce un modèle d'objet nul. Dans son livre Refactoring [1], Martin présente les objets nuls en tant que tel:
L'essence du polymorphisme est qu'au lieu de demander un objet que tapez-est et invoquait un comportement en fonction de la réponse, vous invoquer simplement le comportement. L'objet, en fonction de son type, fait la bonne chose. L'un des endroits moins intuitifs pour le faire est où vous avoir une valeur nulle dans un champ.
Il ajoute plus tard, « Vous bénéficiez alors que de nombreux clients veulent faire la même chose, ils peuvent simplement compter sur le comportement nul par défaut. » Il introduit également une méthode isNull () pour les clients nécessitant des comportements variant.
Je suis d'accord que je vois parfois une mise en œuvre (souvent abstraite) a appelé un adaptateur. Par exemple, dans le cadre Android, AnimatorListenerAdapter (code source ici ) est décrit comme suit:
Cette classe d'adaptateur fournit des implémentations vides des méthodes de Animator.AnimatorListener. Tout auditeur personnalisé qui ne se soucie que d'un sous-ensemble des méthodes de cet auditeur peut simplement sous-classe de cette classe d'adaptateur au lieu d'implémenter l'interface directement.
[1] "Refonte: Améliorer la conception du code existant". Le chapitre 9, "Simplifying Expressions conditionnelles", "Introduire l'objet Null"
