Java implémente le partage d'exemples de code en utilisant la réflexion en mode visiteur

Le type de collection est en Orienté vers les Objetsprogrammation est très couramment utilisée, ce qui amène également quelques questions liées au code, telles que : « Comment faire fonctionner différents types d'objets dans la collection ? ”

Une approche consiste à parcourir chaque élément de la collection, puis à effectuer des opérations spécifiques en fonction de son type. Cela sera très compliqué, surtout lorsque vous ne connaissez pas le type des éléments de la collection. Si vous souhaitez imprimer les éléments de la collection, vous pouvez écrire une méthode comme celle-ci :

public void messyPrintCollection(Collection collection) {
    Iterator iterator = collection.iterator()
    while (iterator.hasNext())
        System.out.println(iterator.next().toString())
}

Cela semble simple d'appeler simplement la méthode Object.toString() et d'imprimer l'objet, n'est-ce pas ? et si votre collection ? Qu'en est-il d'un vecteur contenant une table de hachage ? Cela devient plus compliqué. Vous devez vérifier le type de l'objet retourné par la collection :

public void messyPrintCollection(Collection collection) {
    Iterator iterator = collection.iterator()
    while (iterator.hasNext()) {
        Object o = iterator.next();
        if (o instanceof Collection)
            messyPrintCollection((Collection)o);
        else
            System.out.println(o.toString());
        }
}

D'accord, vous pouvez maintenant gérer les objets de collection imbriqués, mais d'autres objets

String n'est pas ce que vous voulez ? Si vous souhaitez ajouter des guillemets à l'objet chaîne et ajouter un f après l'objet Float, que devez-vous faire ? 🎜>

Le code devient très vite compliqué. Vous ne voulez pas avoir un tas d'instructions if-else dans votre code ! Comment le

public void messyPrintCollection(Collection collection) {
    Iterator iterator = collection.iterator()
    while (iterator.hasNext()) {
        Object o = iterator.next();
        if (o instanceof Collection)
            messyPrintCollection((Collection)o);
        else if (o instanceof String)
            System.out.println("'"+o.toString()+"'");
        else if (o instanceof Float)
            System.out.println(o.toString()+"f");
        else
            System.out.println(o.toString());
    }
}

modèle de visiteur

peut-il vous aider ? 🎜>Pour implémenter le modèle de visiteur, vous devez créer une interface Visiteur et créer une interface Visitable pour l'objet de collection visité. Ensuite, vous devez créer des classes spécifiques pour implémenter Visiteur et Visitable. Les interfaces sont à peu près les suivantes :

Pour une classe String spécifique, elle peut être implémentée comme suit :

public interface Visitor
{
    public void visitCollection(Collection collection);
    public void visitString(String string);
    public void visitFloat(Float float);
}
public interface Visitable
{
    public void accept(Visitor visitor);
}

Dans la méthode accept, appeler le visiteur selon différents types. méthode correspondante dans :

public class VisitableString implements Visitable
{
    private String value;
    public VisitableString(String string) {
        value = string;
    }
    public void accept(Visitor visitor) {
        visitor.visitString(this);
    }
}

L'implémentation spécifique de Visitor est la suivante :

visitor.visitString(this)

À ce moment-là, tant que la classe VisitableFloat et la classe VisitableCollection sont implémentés et les appels appropriés sont effectués par la méthode visiteur, vous pouvez supprimer la méthode messyPrintCollection qui contient un tas de structures if-else et implémenter la même fonction d'une manière très rafraîchissante. La méthode visitCollection() appelle Visitable.accept(this) , et la méthode accept(). À son tour, la méthode correcte dans le visiteur est appelée. Il s'agit d'une double répartition : le visiteur appelle une méthode dans la classe Visitable, qui à son tour appelle une méthode dans la classe Visiteur. L'instruction if-else a disparu, mais elle introduit toujours beaucoup de code supplémentaire. Vous devez envelopper les objets d'origine, String et Float, dans une classe qui implémente l'interface Visitable. Ce n'est généralement pas un problème. peut restreindre la collection visitée pour qu'elle contienne uniquement des objets visitables. Cependant, cela représente beaucoup de travail supplémentaire. Pire encore, que faites-vous lorsque vous souhaitez ajouter un nouveau type Visitable, tel que VisitableInteger ? Il s’agit là d’un inconvénient majeur du modèle de visiteur. Si vous souhaitez ajouter un nouveau type Visitable, vous devez modifier l'interface Visiteur et chaque classe qui implémente les méthodes de l'interface Visiteur. Vous ne pouvez pas concevoir Visitor comme une interface. Au lieu de cela, vous pouvez concevoir Visitor comme une classe de base abstraite avec

Aucune opération

. Ceci est très similaire à la classe Adapter dans l’interface graphique Java. Le problème avec cela est que vous épuiserez le seul

public class PrintVisitor implements Visitor
{
    public void visitCollection(Collection collection) {
        Iterator iterator = collection.iterator();
        while (iterator.hasNext()) {
            Object o = iterator.next();
            if (o instanceof Visitable)
                ((Visitable)o).accept(this);
    }
    public void visitString(String string) {
        System.out.println("'"+string+"'");
    }
    public void visitFloat(Float float) {
        System.out.println(float.toString()+"f");
    }
}

héritage

, et une situation courante est que vous souhaitez également utiliser l'héritage pour implémenter d'autres fonctions, telles que l'héritage de la classe StringWriter. Encore une fois, cela ne peut accéder avec succès qu'aux objets qui implémentent l'interface Visitable.

Heureusement, Java peut rendre votre modèle de visiteur plus flexible, vous pouvez ajouter des objets visitables à votre guise. Comment y parvenir ? La réponse est d’utiliser la réflexion. L'interface réfléchissanteVisitor utilisant la réflexion ne nécessite qu'une seule méthode :

D'accord, ce qui précède est très simple. L'interface Visitable ne sera pas utilisée pour l'instant, j'en reparlerai plus tard. Maintenant, j'implémente la classe PrintVisitor en utilisant la réflexion. Vous n'avez plus besoin d'utiliser la classe wrapper Visitable (qui enveloppe les types primitifs String et Float). Vous pouvez accéder directement à visit() et il appellera la bonne méthode. L’un des avantages de visit() est qu’il distribue la méthode qu’il juge appropriée. Cela n’utilise pas nécessairement la réflexion, cela pourrait utiliser un mécanisme complètement différent.

Dans la nouvelle classe PrintVisitor, il existe des méthodes d'opération correspondant à Collections, String et Float ; pour les types qui ne peuvent pas être traités, elles peuvent être capturées via des instructions catch. Pour les types qui ne peuvent pas être gérés, vous pouvez essayer de gérer toutes leurs superclasses en étendant la méthode visit(). Tout d'abord, ajoutez une nouvelle méthode getMethod(Class c), et la valeur de retour est une méthode qui peut être déclenchée. Il

recherchera toutes les classes parentes et interfaces de la

public interface ReflectiveVisitor {
    public void visit(Object o);
}

Classe c pour trouver une méthode correspondante.

protected Method getMethod(Class c) {
    Class newc = c;
    Method m = null;
    // Try the superclasses
    while (m == null && newc != Object.class) {
        String method = newc.getName();
        method = "visit" + method.substring(method.lastIndexOf('.') + 1);
        try {
            m = getClass().getMethod(method, new Class[] {newc});
        } catch (NoSuchMethodException e) {
            newc = newc.getSuperclass();
        }
    }
    // Try the interfaces.  If necessary, you
    // can sort them first to define 'visitable' interface wins
    // in case an object implements more than one.
    if (newc == Object.class) {
        Class[] interfaces = c.getInterfaces();
        for (int i = 0; i < interfaces.length; i++) {
            String method = interfaces[i].getName();
            method = "visit" + method.substring(method.lastIndexOf(&#39;.&#39;) + 1);
            try {
                m = getClass().getMethod(method, new Class[] {interfaces[i]});
            } catch (NoSuchMethodException e) {}
        }
    }
    if (m == null) {
        try {
            m = thisclass.getMethod("visitObject", new Class[] {Object.class});
        } catch (Exception e) {
            // Can&#39;t happen
        }
    }
    return m;
}

这看上去很复杂，实际上并不。大致来说，首先根据传入的class名称搜索可用方法；如果没找到，就尝试从父类搜索；如果还没找到，就从接口中尝试。最后，（仍没找到）可以使用visitObject()作为默认方法。

由于大家对传统的访问者模式比较熟悉，这里沿用了之前方法命名的惯例。但是，有些人可能注意到，把所有的方法都命名为“visit”并通过参数类型不同来区分，这样更高效。然而，如果你这么做，你必须把visit(Object o)方法的名称改为其他，比如dispatch(Object o)。否则，（当没有对应处理方法时），你无法退回到默认的处理方法，并且当你调用visit(Object o)方法时，为了确保正确的方法调用，你必须将参数强制转化为Object。

为了利用getMethod()方法，现在需要修改一下visit()方法。

public void visit(Object object) {
    try {
        Method method = getMethod(getClass(), object.getClass());
        method.invoke(this, new Object[] {object});
    } catch (Exception e) { }
}

现在，visitor类更加强大了——可以传入任意的对象并且有对应的处理方法。另外，有一个默认处理方法，visitObject(Object o)，的好处就是就可以捕捉到任何没有明确说明的类型。再稍微修改下，你甚至可以添加一个visitNull()方法。

我仍保留Visitable接口是有原因的。传统访问者模式的另一个好处是它可以通过Visitable对象控制对象结构的遍历顺序。举例来说，假如有一个实现了Visitable接口的类TreeNode，它在accept()方法中遍历自己的左右节点。

public void accept(Visitor visitor) {
    visitor.visitTreeNode(this);
    visitor.visitTreeNode(leftsubtree);
    visitor.visitTreeNode(rightsubtree);
}

这样，只要修改下Visitor类，就可以通过Visitable类控制遍历：

public void visit(Object object) throws Exception
{
    Method method = getMethod(getClass(), object.getClass());
    method.invoke(this, new Object[] {object});
    if (object instanceof Visitable)
    {
        callAccept((Visitable) object);
    }
}
public void callAccept(Visitable visitable) {
    visitable.accept(this);
}

如果你实现了Visitable对象的结构，你可以保持callAccept()不变，就可以使用Visitable控制的对象遍历。如果你想在visitor中遍历对象结构，你只需重写allAccept()方法，让它什么都不做。

当使用几个不同的visitor去操作同一个对象集合时，访问者模式的力量就会展现出来。比如，当前有一个解释器、中序遍历器、后续遍历器、XML编写器以及SQL编写器，它们可以处理同一个对象集合。我可以轻松地为这个集合再写一个先序遍历器或者一个SOAP编写器。另外，它们可以很好地兼容它们不识别的类型，或者我愿意的话可以让它们抛出异常。

总结

使用Java反射，可以使访问者模式提供一种更加强大的方式操作对象结构，可以按照需求灵活地增加新的Visitable类型。我希望在你的编程之旅中可以使用访问者模式。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!