abstract et methode non redéfini

Version imprimable

Bonjour
Est ce une "bonne pratique", de ne pas redéfinir tout les méthodes abstraite dans une classe dérivée ?

mon cas :

Code:

1
2
3
4
5
6
7
 
 abstract class  Champ
...
      public abstract void setDefaultValue(int value);
 
      public abstract void setDefaultValue(String value);
...

______________________________________________________

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class  ChampInt extends Champ
...
    private int selectedIndex;  
 
 
    public  void setDefaultValue(int value){
      this.selectedIndex = value;             
    }
 
    public  void setDefaultValue(String value) {
//        //non applicable
    }

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class  ChampStr  extends Champ
...
    private String stringValue;  
 
 
    public  void setDefaultValue(int value){
       //non applicable         
    }
 
    public  void setDefaultValue(String value) {
   this.stringValue = value;
    }

Code:

1
2
3
4
5
6
7
 
Champ c = new ChampInt();
c.setDefaultValue(3)
Champ d = new ChampStr();
d.setDefaultValue("Toto");
 
...

Merci de vos suggestions

23/06/2010, 18h34
tchize_
non, si une partie des méthodes n'ont pas de sens pour les classes implémentant ou héritant, alors il n'y a pas de sens à les faire implémenter / hériter de cette classe, il y a un problème de design. Pour ton cas, par exemple, le design correct serait
Code:

1 2 3 4 abstract class Champ<T> ... public abstract void setDefaultValue(T value);
Code:

1 2 3 4 5 6 7 8 9 class ChampStr extends Champ<String> ... private String stringValue; public void setDefaultValue(String value) { this.stringValue = value; }
Code:

1 2 3 4 5 6 7 8 class ChampInt extends Champ<Integer> ... private Integer selectedIndex; public void setDefaultValue(Integer value){ this.selectedIndex = value; }
Ceci dit, il arrive, dans d'autre cas, qu'une interface ou une méthode abstraite définisse certaines opérations comme optionnelles, ou refusent certaines opération. Dans ce cas, la bonne pratique, en général, est, dans la méthode, de lancer une exception UnsupportedOperationException, plutôt que de ne rien faire. C'est utilisé, par exemple, sur les api collections de java, les collection readonly lancent des exceptions sur les méthodes de modification (add, remove, etc).
23/06/2010, 21h09
totoche

Merci tchize_

Avec un Typage java 1.4, :oops:
comment dois-je convertir Champ<T> ?

ps :
dans "mon cas" Netbeans, en l'absence de definission d'une méthode abstraite dans une classe dérivée

Citation:

propose de lancer une exception UnsupportedOperationException, plutôt que de ne rien faire
23/06/2010, 22h35
tchize_

dans le cas 1.4 faut faire le travail à la main: accepter un Object en paramètre, faire du typecasting.