COURS JAVA
REDEFINITION vs
POO Java | ENSAM SURCHARGE
GITD3 2025-2026
Tous les cas possibles et toutes les regles
# Chapitre
1 Difference fondamentale — Surcharge vs Redefinition
2 SURCHARGE — Regles et tous les cas
3 REDEFINITION — Regles et tous les cas
4 Cas speciaux — static, final, private, abstract
5 Visibilite — regles strictes
6 Type de retour — regles
7 @Override — pourquoi et quand
8 Cas pieges — questions difficiles
9 Resume final — tableau comparatif complet
1. DIFFERENCE FONDAMENTALE
SURCHARGE = meme nom + parametres DIFFERENTS + meme classe
REDEFINITION = meme nom + meme signature + SOUS-CLASSE
Critere SURCHARGE (Overload) REDEFINITION (Override)
Ou ? MEME classe SOUS-CLASSE uniquement
Nom Identique Identique
Parametres DIFFERENTS obligatoire IDENTIQUES obligatoire
Type retour Peut changer Doit etre compatible
Visibilite Libre Ne peut pas REDUIRE
@Override Non (erreur si mis) Recommande
static Possible Masquage (pas poly.)
But Plusieurs versions methode Specialiser comportement
// SURCHARGE — meme classe, parametres differents
class Calculateur {
public int add(int a, int b) { return a+b; } // original
public double add(double a, double b) { return a+b; } // surcharge 1
public int add(int a, int b, int c) { return a+b+c;} // surcharge 2
public String add(String a, String b) { return a+b; } // surcharge 3
}
// REDEFINITION — sous-classe, meme signature
class Animal {
public void parler() { [Link]("..."); }
}
class Chien extends Animal {
@Override
public void parler() { [Link]("Waf !"); } // redefinition
}
2. SURCHARGE — REGLES ET TOUS LES CAS
Regle 1 — Ce qui DOIT changer
Les parametres DOIVENT etre differents. C'est la SEULE obligation !
Les parametres sont differents si : le nombre change OU les types changent OU l'ordre des types change.
class Test {
// Methode originale
public void methode(int a, String b) { }
// SURCHARGES VALIDES
public void methode(int a) { } // nombre different
public void methode(String b, int a) { } // ordre different
public void methode(int a, String b, int c){ } // nombre different
public void methode(double a, String b) { } // type different
public void methode(int a, int b) { } // type different
// PAS DES SURCHARGES — ERREURS !
public void methode(int x, String y) { } // meme signature !
public int methode(int a, String b) { } // juste type retour change
}
PIEGE : Changer SEULEMENT le type de retour ne suffit PAS pour surcharger !
Regle 2 — Ce qui PEUT changer
Element Peut changer ? Exemple
Parametres OUI — obligatoire methode(int) -> methode(double)
Type de retour OUI — mais pas suffisant seulvoid -> int
Visibilite OUI — libre private -> public
Nom variables params OUI — sans effet methode(int a) -> methode(int x)
Classe NON — meme classe uniquement
N/A
Regle 3 — Surcharge des constructeurs
REGLE : Les constructeurs PEUVENT etre surcharges — meme nom, parametres differents !
class Etudiant {
private String nom;
private int age;
public Etudiant(String nom) { [Link] = nom; } // constructeur 1
public Etudiant(String nom, int age) { [Link]=nom; [Link]=age; } // constructeur 2
public Etudiant(Etudiant e) { [Link]=[Link]; } // constructeur 3 (copie)
}
Regle 4 — Surcharge et static
REGLE : Les methodes static PEUVENT etre surchargees — meme regles !
class Utils {
public static int max(int a, int b) { return a>b?a:b; }
public static double max(double a, double b) { return a>b?a:b; } // surcharge OK !
}
Regle 5 — Comment Java choisit la bonne surcharge
Java choisit la methode en fonction du TYPE des arguments passes.
class Test {
public void methode(int a) { [Link]("int"); }
public void methode(double a) { [Link]("double"); }
public void methode(String a) { [Link]("String"); }
}
Test t = new Test();
[Link](5); // int -> "int"
[Link](5.0); // double -> "double"
[Link]("Ali"); // String -> "String"
[Link]('A'); // char -> promu en int -> "int" !
3. REDEFINITION — REGLES ET TOUS LES CAS
Regle 1 — Conditions obligatoires
Meme nom + Memes parametres + Sous-classe = REDEFINITION
class Animal {
public void parler(String message) {
[Link]("Animal: " + message);
}
}
class Chien extends Animal {
// REDEFINITION CORRECTE — meme signature exacte
@Override
public void parler(String message) {
[Link]("Chien: " + message);
}
}
Regle 2 — Meme signature = meme nom + memes params + meme type retour
class Animal {
public void parler() { } // void, sans params
public int calculer() { return 0; }
}
class Chien extends Animal {
// REDEFINITION correcte
@Override
public void parler() { } // void, sans params = OK
// REDEFINITION correcte
@Override
public int calculer() { return 5; } // int = compatible
// PAS UNE REDEFINITION — c'est une surcharge !
public void parler(String msg) { } // param different -> surcharge
// ERREUR — type retour incompatible
// public String calculer() { } // String != int -> ERREUR
}
Regle 3 — [Link]() dans la redefinition
On peut appeler la version parente avec [Link]() — optionnel !
class Animal {
public void afficher() {
[Link]("Animal");
}
}
class Chien extends Animal {
// Cas 1 — Redefinition complete (remplace totalement)
@Override
public void afficher() {
[Link]("Chien"); // Animal non appele
}
// Cas 2 — Redefinition avec appel parent (etend le comportement)
@Override
public void afficher() {
[Link](); // appelle [Link]()
[Link]("Chien"); // puis ajoute
}
}
4. CAS SPECIAUX — static, final, private, abstract
Cas 1 — Methode static : masquage, pas redefinition !
PIEGE : Une methode static ne peut PAS etre redefinie — c'est du MASQUAGE !
class Animal {
public static void type() { [Link]("Animal"); }
public void parler() { [Link]("..."); }
}
class Chien extends Animal {
// MASQUAGE — pas redefinition !
public static void type() { [Link]("Chien"); }
// REDEFINITION — polymorphisme OK
@Override
public void parler() { [Link]("Waf"); }
}
Animal a = new Chien();
[Link](); // "Animal" — masquage : regarde le TYPE REFERENCE
[Link](); // "Waf" — redefinition : regarde le TYPE REEL
Cas 2 — Methode final : non redefinis sable !
PIEGE : Une methode final ne peut PAS etre redefinie — erreur de compilation !
class Animal {
public final void respirer() { [Link]("Respire"); }
public void parler() { [Link]("..."); }
}
class Chien extends Animal {
// ERREUR — respirer() est final !
// public void respirer() { } // erreur de compilation
// OK — parler() n'est pas final
@Override
public void parler() { [Link]("Waf"); }
}
Cas 3 — Methode private : non heritee, non redefinis sable !
PIEGE : Une methode private ne s'herite PAS — on ne peut pas la redeffinir !
class Animal {
private void secret() { [Link]("Animal secret"); }
public void parler() { [Link]("..."); }
}
class Chien extends Animal {
// CE N'EST PAS UNE REDEFINITION — c'est une nouvelle methode !
public void secret() { [Link]("Chien secret"); }
// @Override ici provoquerait une ERREUR car secret() n'est pas herite
}
Cas 4 — Methode abstract : DOIT etre redefinie !
REGLE : Une methode abstract DOIT etre redefinie dans la sous-classe — obligatoire !
abstract class Forme {
public abstract double surface(); // pas de corps !
public void afficher() { // methode concrete
[Link]("Surface: " + surface());
}
}
class Cercle extends Forme {
private double rayon;
public Cercle(double rayon) { [Link] = rayon; }
// OBLIGATOIRE — doit redefenir surface()
@Override
public double surface() {
return [Link] * rayon * rayon;
}
}
Type methode Surchargeable ? Redefinis sable ? Remarque
normale OUI OUI Cas standard
static OUI NON (masquage) Pas de polymorphisme
final OUI NON Erreur compilation
private OUI NON Non heritee
abstract OUI OBLIGATOIRE Doit etre redefinie
protected OUI OUI Accessible sous-classe
5. VISIBILITE — REGLES STRICTES
Lors d'une REDEFINITION : on peut ELARGIR la visibilite mais JAMAIS la REDUIRE !
Visibilite dans mere Dans fils : AUTORISE Dans fils : INTERDIT
private N/A (non heritee) N/A (non heritee)
(rien) protected, public private
protected protected, public private, (rien)
public public seulement private, (rien), protected
class Animal {
public void methode1() { }
protected void methode2() { }
}
class Chien extends Animal {
// CORRECT — meme visibilite
@Override public void methode1() { }
@Override protected void methode2() { }
// CORRECT — elargissement
@Override public void methode2() { } // protected -> public OK
// ERREUR — reduction
// @Override private void methode1() { } // public -> private ERREUR !
// @Override void methode1() { } // public -> (rien) ERREUR !
}
PIEGE : public -> private = ERREUR. public -> protected = ERREUR. protected -> private = ERREUR !
6. TYPE DE RETOUR — REGLES
Pour la SURCHARGE — type retour libre
REGLE : En surcharge, le type de retour peut changer LIBREMENT — mais ce n'est pas suffisant seul !
class Test {
public int calculer(int a) { return a; } // int
public double calculer(double a) { return a; } // surcharge OK — params differents
// ERREUR — meme params, juste type retour change
// public double calculer(int a) { return a; } // ERREUR !
}
Pour la REDEFINITION — type retour compatible
Le type de retour doit etre IDENTIQUE ou un SOUS-TYPE (covariant)
class Animal {
public Animal creer() { return new Animal(); }
public int calculer() { return 0; }
}
class Chien extends Animal {
// CORRECT — meme type
@Override
public Animal creer() { return new Chien(); }
// CORRECT — sous-type (Chien EST un Animal)
@Override
public Chien creer() { return new Chien(); } // covariant OK !
// ERREUR — type incompatible
// public String calculer() { return ""; } // String != int ERREUR !
}
7. @Override — POURQUOI ET QUAND
@Override est une annotation qui demande au compilateur de verifier qu'on redeffinit bien une methode existante.
class Animal {
public void parler() { }
}
class Chien extends Animal {
// SANS @Override — risque de bug silencieux
public void parleer() { } // faute de frappe — Java cree une NOUVELLE methode !
// AVEC @Override — erreur detectee a la compilation
@Override
public void parleer() { } // ERREUR immediate — parleer() n'existe pas dans Animal
}
Situation @Override present @Override absent
Signature correcte Compilation OK Compilation OK
Faute de frappe ERREUR detectee Bug silencieux !
Surcharge ERREUR (pas une redef.) Pas d'erreur
Methode private ERREUR (non heritee) Nouvelle methode
REGLE : Toujours utiliser @Override lors d'une redefinition — detecte les erreurs !
8. CAS PIEGES — QUESTIONS DIFFICILES
Piege 1 — Surcharge ou Redefinition ?
class Animal {
public void parler() { }
public void parler(String msg) { }
}
class Chien extends Animal {
public void parler() { } // REDEFINITION (meme classe, meme signature)
public void parler(String msg) { } // REDEFINITION (meme classe, meme signature)
public void parler(int fois) { } // SURCHARGE (nouveau parametre)
}
Piege 2 — Changer seulement les noms de parametres
class Animal {
public void parler(String message) { }
}
class Chien extends Animal {
@Override
public void parler(String msg) { } // REDEFINITION !
// msg != message mais le TYPE est String -> meme signature !
}
PIEGE : Changer le NOM du parametre ne change PAS la signature — c'est toujours une redefinition !
Piege 3 — static et polymorphisme
class A {
public static void test() { [Link]("A"); }
public void afficher() { [Link]("A"); }
}
class B extends A {
public static void test() { [Link]("B"); } // masquage
@Override
public void afficher() { [Link]("B"); } // redefinition
}
A obj = new B();
[Link](); // "A" — masquage : type REFERENCE
[Link](); // "B" — redefinition : type REEL
PIEGE : Methode static = PAS de polymorphisme ! Java regarde le type de REFERENCE !
Piege 4 — Constructeur ressemblant a une methode
class Animal {
public Animal() { } // CONSTRUCTEUR — pas de type retour
public void Animal() { } // METHODE — a un type retour (void)
}
// Ces deux sont DIFFERENTS !
// Animal() sans void = constructeur
// void Animal() avec void = methode ordinaire (mauvaise pratique !)
PIEGE : public void NomClasse() est une METHODE, pas un constructeur ! Le constructeur n'a JAMAIS de type retour.
Piege 5 — Surcharge avec promotion de type
class Test {
public void methode(int a) { [Link]("int"); }
public void methode(long a) { [Link]("long"); }
public void methode(double a) { [Link]("double"); }
}
Test t = new Test();
[Link](5); // int -> "int"
[Link](5L); // long -> "long"
[Link](5.0); // double -> "double"
[Link]('A'); // char -> promu en int -> "int" !
[Link](5.0f); // float -> promu en double -> "double" !
9. RESUME FINAL — TABLEAU COMPARATIF COMPLET
Tableau complet Surcharge vs Redefinition
Critere SURCHARGE REDEFINITION
Ou ? Meme classe Sous-classe uniquement
Nom methode Identique Identique
Parametres DOIVENT etre differents DOIVENT etre identiques
Type de retour Libre Identique ou sous-type
Visibilite Libre Ne peut pas REDUIRE
@Override Non (erreur si present) Recommande fortement
static Possible Masquage (pas polymorphisme)
final Possible IMPOSSIBLE — erreur
private Possible IMPOSSIBLE — non heritee
abstract Possible OBLIGATOIRE
Polymorphisme Non OUI — liaison dynamique
[Link]() Non applicable Possible et optionnel
But Plusieurs versions Specialiser comportement
Tous les pieges QCM
PIEGE : Changer SEULEMENT le type de retour ne suffit pas pour surcharger
PIEGE : Changer le NOM des parametres ne change pas la signature
PIEGE : Methode static = masquage, pas redefinition — pas de polymorphisme
PIEGE : Methode final = non redefinis sable — erreur de compilation
PIEGE : Methode private = non heritee — ne peut pas etre redefinie
PIEGE : On ne peut pas REDUIRE la visibilite en redefinissant
PIEGE : public -> private = ERREUR. public -> protected = ERREUR
PIEGE : @Override sur une surcharge = ERREUR
PIEGE : @Override detecte les fautes de frappe — toujours l'utiliser
PIEGE : Animal a = new Chien() -> [Link]() appelle version Animal !
PIEGE : Animal a = new Chien() -> [Link]() appelle version Chien !
PIEGE : void NomClasse() est une METHODE, pas un constructeur !
Regles a retenir
REGLE : Surcharge = meme nom + parametres DIFFERENTS + meme classe
REGLE : Redefinition = meme nom + meme signature + SOUS-CLASSE
REGLE : Seule facon de surcharger : changer les parametres !
REGLE : Redefinition = toujours avec @Override pour securite
REGLE : Visibilite en redefinition : peut elargir, jamais reduire
REGLE : static : surchargeable mais pas redefinis sable (masquage)
REGLE : final : surchargeable mais pas redefinis sable (erreur)
REGLE : abstract : DOIT etre redefinie dans la sous-classe
REGLE : private : ni heritee, ni redefinis sable
Ce cours couvre tous les cas possibles de surcharge et redefinition. Consulte-le avant chaque quiz ! Bonne chance pour
le QCM !