Discussion :

[BakaOnigiri]

Bonjour,

j'ai 2 classes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public class IFrameCommun extends JTrafficInternalFrame
{
    ...bla bla plein de méthodes bla bla...
 
    public void closeDialog()
    {
        .... du code
    }
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public class DialogBoxConfiguration extends IFrameCommun
{
    ...bla bla plein de méthodes bla bla...
 
    @Override
    public void closeDialog()
    {
        .... du code .....
 
        super.closeDialog();
    }
}

Je cherche un moyen pour qu'il soit obligatoire pour que la deuxième classe surcharge la méthode closeDialog() de IFrameCommun


En fait des classes comme la deuxième dans mon projet j'en ai plein, mais je voudrais pas oublier de surcharger la méthode qqpart, donc je voudrais que le projet ne compile pas si j'oublie la surchage, un peut comme une classe qui implémenterais pas toutes les méthodes d'une interface.

J'espère ne pas me mélanger

Merci d'avance.

[dinobogan]

Définie la en "abstract".

[BakaOnigiri]

cela semble être ce que je veux faire, mais dans la FAQ java, la méthode abstraite de la classe abstraite, est déclarée comme pour une interface : sans code, or moi je veux laisser le code qui est dedans

[dinobogan]

cela semble être ce que je veux faire, mais dans la FAQ java, la méthode abstraite de la classe abstraite, est déclarée comme pour une interface : sans code, or moi je veux laisser le code qui est dedans

Je m'en doutais ;-)
J'imagine que tu vas toujours appeler la méthode de la classe mère ?
Alors je ne vois pas de solution directe, à part faire une classe abstraite commune AbstractIFrameCommun :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public abstract class AbstractIFrameCommun extends JTrafficInternalFrame
{
  ...bla bla plein de méthodes bla bla...
 
  public void closeDialog()
  {
    internalCloseDialog();
    .... du code
  }
 
  protected abstract internalCloseDialog()
  {
    ...
  }
}

Toutes les autres classes, y compris "IFrameCommun", vont dérivées de cette classe abstraite. Elles seront obligées de déclarer "internalCloseDialog".

[BakaOnigiri]

bon çà me fait changer trop de chose, donc le corp de ma méthode closeDialog dans IFrameCommun, passe dans une méthode plop(), j'ai mis comme expliqué closeDialog en abstract, et il faudra que je me force d'appeler plop() dans les classe qui dérivent de IFrameCommun, c'est pas génial, mais c'est le plus simple à mettre en place.


Merci dinobogan

[dinobogan]

Et du coup, tu n'as pas résolu ton problème de départ

[djo.mos]

Bonjour,
Juste pour info, on parle ici de redéfinition et pas de surcharge.

[herve91]

Ou alors peut-être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class IFrameCommun extends JTrafficInternalFrame
{
    ...bla bla plein de méthodes bla bla...
 
    public abstract void closeDialog();
 
    protected void closeDialogImpl()
    {
        .... du code
    }
}
 
public class DialogBoxConfiguration extends IFrameCommun
{
    ...bla bla plein de méthodes bla bla...
 
    @Override
    public void closeDialog()
    {
        .... du code .....
 
        super.closeDialogImpl();
    }
}

[BakaOnigiri]

djo.mos merci pour l'info, je vais essayer de retenir le terme.

herve91 oui au final c'est ce que je fais, çà fait ce que je veux grace à dinobogan j'ai opté pour ce code, bien sûr çà m'oblige à appeler à chaque fois une méthode super. et il faut pas que j'oublie de l'appeler, mais çà reste le plus simple pour moi

[djo.mos]

Bonne idée Hervé
Mais ce serait mieux d'inverser la donne, comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
abstract class Base {
	protected abstract void toBeOverridden();
	public void aMethod() {
		toBeOverridden();
		System.out.println("Base.defaultImpl()");
	}
}
 
class Actual extends Base {
	@Override
	protected void toBeOverridden() {
		System.out.println("Actual.toBeOverridden()");
	}
}
 
public class Test {
	public static void main(String[] args) {
		Actual a = new Actual();
		a.aMethod();
	}
}

Pour eviter le cas ou la classe fille n'appèle pas le code du parent

[BakaOnigiri]

en fait dans mon cas c'est la classe Actual qui doit appeler le code, çà fonctionne aussi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
abstract class Base {
	protected abstract void toBeOverridden();
	public void aMethod() {
		toBeOverridden();
		System.out.println("Base.defaultImpl()");
	}
}
 
class Actual extends Base {
	@Override
	protected void toBeOverridden() {
		System.out.println("Actual.toBeOverridden()");
	}
 
	private void plop(){
		aMethod();
	}
}

[dinobogan]

Bonne idée Hervé
Mais ce serait mieux d'inverser la donne, comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
abstract class Base {
	protected abstract void toBeOverridden();
	public void aMethod() {
		toBeOverridden();
		System.out.println("Base.defaultImpl()");
	}
}
 
class Actual extends Base {
	@Override
	protected void toBeOverridden() {
		System.out.println("Actual.toBeOverridden()");
	}
}
 
public class Test {
	public static void main(String[] args) {
		Actual a = new Actual();
		a.aMethod();
	}
}

Pour eviter le cas ou la classe fille n'appèle pas le code du parent

Oui, c'est ce que j'ai posté ci-dessus mais l'idée ne lui plait pas trop

[BakaOnigiri]

bon ba au final c'est niquel, mais j'avais pas bien saisis le code de dinobogan, donc ba merci à tous, maintenant tout fonctionne comme il faut