casting pour une classe abstraite...comment est-ce possible?

je suis en train de lire un livre sur les design patterns en java et je suis un newbie 🙂

http://www.amazon.com/Design-Patterns-Java-TM-Software/dp/0321333020/ sur le chapitre composite modèle, je suis tombé sur un code qui me énigmes, d'un plâtre pour une classe abstraite, j'ai pas bien compris ce qui se passe quand la sous-classe appelle le constructeur de la superclasse abstraite, pouvez-vous m'aider s'il vous plaît !!

le casting que je suis en train de parler dans le isTree( Set visité)

        MachineComponent c = (MachineComponent) i.next();
        if (visited.contains(c) || !c.isTree(visited))

Comment peut-on appeler le isTree méthode de la sous-classe après un casting pour sa super-classe abstraite
alors que le isTree méthode de superclasse abstraite?

Voici des extraits de deux classes:

package com.oozinoz.machine;
/*
 * Copyright (c) 2001, 2005. Steven J. Metsker.
 */

import java.util.*;
import com.oozinoz.iterator.ComponentIterator;

/**
 * Objects of this class represent either individual machines or composites of
 * machines.
 */

public abstract class MachineComponent {

    /*
     * Subclasses implement this to support the isTree() algorithm.
     */

    protected abstract boolean isTree(Set s);

    //rest of class omitted
}

package com.oozinoz.machine;    
/*
 * Copyright (c) 2001, 2005. Steven J. Metsker.
 */

import java.util.*;
import com.oozinoz.iterator.ComponentIterator;
import com.oozinoz.iterator.CompositeIterator;

 /**
 * Represent a collection of machines: a manufacturing line, a bay, or a
 * factory.
 */

public class MachineComposite extends MachineComponent {
    protected List components = new ArrayList();

    /**
     * @param visited a set of visited nodes
     * @return true if this composite is a tree
     * @see MachineComponent#isTree()
     */

    protected boolean isTree(Set visited) {
        visited.add(this);
        Iterator i = components.iterator();
        while (i.hasNext()) {
            MachineComponent c = (MachineComponent) i.next();
            if (visited.contains(c) || !c.isTree(visited)) 
                return false;
        }
        return true;
    }

    //rest of class omitted
}

Veuillez formater votre code correctement, si vous allez juste dump ensemble de fichiers.

OriginalL'auteur user1125516 | 2012-01-02

9

C'est la distinction entre l'exécution type (type réel) et le type de compilation.

Le transtypage d'une classe abstraite MachineComponent est bien, parce que l'objet réel de l'instance sera effectivement certains non-abstraite sous-classe de MachineComponent qui implémente toutes les méthodes abstraites.

L'abstrait MachineComponent classe est le moment de la compilation du type de la variable. Mais aucune instance est (ou peut être) créé à cette classe abstraite.

Tout à fait exact. Et en fait c'est la DÉFINITION d'une classe abstraite - c'est une classe pour laquelle vous ne pouvez pas créer des instances pour lesquels vous DEVEZ sous-classe AFIN de créer un exemple concret. Franchement, "interfaces" ont tendance à être beaucoup, beaucoup plus utile en Java. Mais les classes abstraites dans de nombreux cas, y compris l'OP de l'exemple.

OriginalL'auteur wrschneider
4

La isTree n'est abstrait pour la classe abstraite. Une fois que la classe a été initialisé en tant que non-abstraite, un moulage d'un résumé ne changera pas sa mémoire. Par conséquent, l'appel de la méthode sur une classe abstraite efficacement les appels sur la mise en œuvre concrète.

La raison pour laquelle il est utile pour le passage de la sous-classes autour de la via de la mise en œuvre abstraite.

Disons, d'une Chaîne de classe a "longueur" de la méthode. Il n'y a pas besoin d'avoir une fonction pour chaque type Chaîne de sous-classe. Au lieu de cela, vous lancez à la base (résumé) Chaîne qui a la "longueur" de la mise en œuvre, et le passer autour de.

OriginalL'auteur David

OK - essayez encore une fois:

Q: Pouvez-vous en fonte pour une classe abstraite?

A: Assurez-vous - bien sûr, vous pouvez

Par exemple:

public class UseAbstract
{
  public static void main (String[] args)
  {
    //Instantiate an abstract class
    AbstractPet myDog = new Dog ();
    myDog.sound ();

    //Instantiate a concrete class
    Cat myCat = new Cat ();
    myCat.sound ();

    //Cast a concrete class to an abstract class
    AbstractPet somePet = (AbstractPet)myCat;
    somePet.sound ();
  }
}

abstract class AbstractPet
{
  void sound ()
  {
    System.out.println ("eek");
  }
}

class Dog extends AbstractPet
{
  void sound ()
  {
    System.out.println ("Woof");
  }
}

class Cat extends AbstractPet
{
  void sound ()
  {
    System.out.println ("meow");
  }
}

OriginalL'auteur paulsm4

2

Eh bien, nous allons prendre Cat qui est une sous-classe de la classe abstraite Animal.

Vous pouvez lancer Cat à Animal parce que un chat est un animal. Il fait tout ce qu'un animal normal, car il a les fonctions d'un animal.

Sous-classement d'une classe abstraite est la même. Vous pouvez simplement utiliser "est un" parce que c'est une sous-classe.

Vous pouvez définir une liste d'animaux de zoo, mais il peut y avoir des chiens et des chats - après tout, ils sont les deux animaux.

En jetant un Cat à un Animal n'est pas effectivement moins d'un Cat qu'il ne l'était - il vous suffit de dire votre code pour le traiter comme il le traiter de tout autre animal.

Modifier

Dans le cas où vous n'aimez pas les chats (je n'ai pas non plus), permettez-moi de vous rediriger vers le Article de wikipédia à propos de l'héritage. Les classes abstraites serait inutile si vous ne pouvez pas les jeter.

OriginalL'auteur Tom van der Woerdt
1

Q: Pouvez-vous en fonte pour une classe abstraite?

A: Assurez-vous - bien sûr, vous pouvez.

Ce que vous ne peut pas faire est d'appeler une méthode abstraite d'une classe abstraite. (insertion de l'article commentaire -Andrew Barber - dessous) - vous Vous sont effectivement à l'appel de la mise en œuvre concrète dans la sous-classe.

Ouais...pas du tout vrai.
ce n'est pas vrai? Une méthode abstraite n'a pas de code de sorte que feriez-vous appel?
C'est vrai, bien que je puisse voir comment certains pourraient le penser si ils sont tatillonne les termes différemment que le répondeur. Si vous pensez que vous êtes à l'appel de la fonction abstraite, vous êtes en fait en appelant la mise en œuvre concrète dans la sous-classe.
Pour moi, cette réponse semblait dire qu'il était impossible d'invoquer une méthode abstraite d'une classe abstraite, qui n'est pas vrai du tout.

OriginalL'auteur paulsm4

Vous devez vous connecter pour publier un commentaire.