Remplacement d'une méthode avec différents types de retour en java?

J'ai lu un livre et il dit que je peux remplacer une méthode si elle a la même signature. selon le livre de la signature d'une méthode est Method_Name + Paramètres passés.

que par le livre, je peux remplacer une méthode qui a différents types de retour. Est-il réellement possible de surcharger une méthode avec différents type de retour en Java? parce que j'ai fait quelque recherche sur le net, j'ai trouvé des gens en disant que de remplacer une méthode du type de retour doit être la même que bien.

selon le livre il dit aussi que le java lèvera une erreur de compilation lorsque nous essayons de surcharge d'une méthode du même nom de la méthode et des paramètres mais différents types de retour depuis la signature signifie seulement le nom de la méthode et des paramètres. Si cela est vrai, nous devrions être en mesure de remplacer une méthode avec différents type de retour.

Merci de m'aider à comprendre cela. Merci à l'avance.

  • Convariant types de retour ont été ajoutés dans Java 5.0 je ne voudrais pas vous soucier de rien avant de Java 6 trop. Il y avait un bug dans la version 6 de Java qui a permis de surcharger le type de retour, mais cela a été corrigé dans Java 7 😉
  • double possible de Peut substituée méthodes diffèrent dans le type de retour?
InformationsquelleAutor nzhmz | 2013-01-25
  1. 25

    Vous pouvez retourner un type différent, aussi longue que il est compatible avec le type de retour de la méthode redéfinie. Compatible signifie: c'est une sous-classe, sous-interface, ou la mise en œuvre de la classe ou de l'interface retourné par la méthode de remplacement.

    Et c'est logique. Si une méthode retourne un Animal, et votre classe dérivée renvoie une Vache, vous n'êtes pas de rompre le contrat de la super-classe de la méthode, car une Vache est un Animal. Si la classe dérivée renvoie une Banane, ce n'est pas correct de plus, depuis une Banane n'est pas un Animal.

    • Pour rendre la réponse parfaite, la légende avec Principe de Substitution de Liskov.
    • La banane sont très savoureux si!
    • donc, est la vache.
    • La bonne réponse. Je suis en colère quand j'ai lu "tant que c'est compatible" et s'est immédiatement rendu "qu'est-compatibles veux dire!?" mais vous l'avez expliqué dans la prochaine ligne =)
    InformationsquelleAutor JB Nizet
  2. 11

    Votre classe parent a fait une promesse à l'extérieur. Par exemple, la méthode:

    public Price calculatePrice(Items[] items).

    Il raconte le monde de s'attendre à un Prix.

    Si vous améliorez les fonctionnalités de votre sous-classe, vous devez toujours garder votre parent des classes d'origine des promesses pour elle.

    Vous pouvez ajouter de la surcharge des moyens de calcul:

    public Price calculatePrice(Items[] items, Integer minimumCharge).

    Vous pouvez même améliorer votre parent des promesses d'aide de façon PLUS spécifique le type de retour:

    public AccuratePrice calculatePrice(Items[] items, Integer minimumCharge).

    Mais vous devez retourner au moins le type que votre parent a promis.
    Il en va de même pour les Exceptions dans la déclaration de méthode trop.

    InformationsquelleAutor David Lavender
  3. 3

    Oui, il est possible depuis Java 5, il est appelé covariante type de retour. Le type de retour doit être un subcass de super méthode de classe de type de retour (types primitifs ne sont pas autorisés). Exemple 

    class X implements Cloneable {

    @Override
    protected X clone() {
        try {
            return (X) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new Error(e); //can never happen
        }
    }
}
    InformationsquelleAutor Evgeniy Dorofeev
  4. 1

    Voici un exemple:

    class Base {
    public Number test() {
        return 0;
    }
}

class A extends Base {
    public Long test() {
        return 1L;
    }
}
    InformationsquelleAutor jdb
  5. 1

    Votre surchargée de la méthode peut avoir le même type ou sous-type de la
    d'origine type de retour qui est appelé comme covariants de retour.

    Si vous modifiez le type de retour de la méthode surchargée quelque chose d'autre qui n'est pas un sous-type du type d'original, alors vous obtiendrez une erreur de compilation.

    • pouvez-vous expliquer pourquoi nous sommes d'erreur? ou quelle est la raison derrière?
    InformationsquelleAutor PermGenError
  6. 0
    Yes we can override different return types but they should be subclass.

public class Shape {
    public Shape area(Integer i) {
        System.out.println("Sape Area");
        System.out.println("Integer");
        return null;
    }
}


package com.oops;

public class Circle extends Shape {
    public Circle area(Integer i) {
        System.out.println("Circle Area");
        System.out.println("int");
        return null;
    }
}
    • Peut-être ajouter quelques explications.
    • Bienvenue DONC. Une réponse devrait fournir des renseignements supplémentaires. Votre réponse cependant lieux des restrictions artificielles sur les règles, a déclaré complet par JB Nizet déjà.
    InformationsquelleAutor shwetank
  7. 0
    //Covariant Overriding 
public class Parent {

  public Parent(){}
  String parentName;
  public Parent(String parentName){
    this.parentName=parentName;
    System.out.println(this.parentName);
 }

public  Parent show(){
    return new Parent("Parent");
}
}




public class Child extends Parent{

  public Child(){}
  String name;
  public Child(String name){
    this.name=name;
    System.out.println(this.name);
  }
  public Child show(){
    return new Child("Child");
}
}



public class Main {

public static void main(String[] args) {
    Parent parent=new Child();
    parent.show();

    Parent parent1=new Parent();
    parent1.show();
}
}
    InformationsquelleAutor Deepak