Sunteți pe pagina 1din 13

Initiattion

à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

La programmation orientée objet est l'un des outils les plus importants dans le
développement logiciel. C'est une façon de programmer qui permet une meilleure
organisation de son code.

Le code développé à l'aide de la programmation orientée objet est bien


plus flexible et donc facilement exportable. C'est ce qui a permis, en grande partie, à
autant de librairies et frameworks de voir le jour en Java.

Ainsi, la programmation orientée objet a de nombreux avantages qui expliquent


que cette méthode est une des plus utilisées de nos jours :

• facilité d'organisation grâce aux objets


• méthode plus intuitive car plus proche de la réalité, principe d'héritage
• gestion de projet plus efficace : la sécurisation via encapsulation permet
d'avoir plusieurs développeurs travaillant sur un même projet, chacun ne
travaille que sur les implémentations le concernant.
• le code est "factorisé" : il est plus facilement lisible et donc corrigible, et est
moins lourd

1 - Les fondamentaux de la programmation orientée objet


Dans le cours sur les bases de Java, j'ai fait le choix dès le début de vous expliquer
les bases de l'objet. Vous avez eu l'occasion de voir qu'une variable pouvait être de
type simple ou objet. Vous avez pu voir également que, pour créer un nouveau type
objet, il faut créer un fichier contenant une classe. Enfin, vous avez vu qu'un objet
possédait des attributs et des méthodes.

Dans ce cours, nous allons revoir tous ces principes en les approfondissant. De
cette façon, vous comprendrez complètement la programmation orientée objet et ses
concepts.

La programmation orientée objet permet de représenter toutes les problématiques


imaginables. Vous pouvez représenter, par exemple :

• une voiture avec ses roues, son moteur et ses sièges ;


• un cinéma avec ses films et ses clients ;
Nous l'avons déjà vu, Java est composé de nombreux objets et classes :

• String ;
• Scanner ;
• System ;
• Iterator<String>.
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

2 - La démarche
En programmation orientée objet, il y a toujours une phase d'analyse avant de
coder. Il est important de réfléchir à : quels sont les besoins de mon application et
comment y répondre ?

Cette analyse se fait généralement au travers de différents outils de représentation


graphique.

Notamment le diagramme de classes UML .

La schématisation est importante en programmation orientée objet. Dans ce cours,


je vais vous fournir un schéma que vous implémenterez au fur et à mesure.
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

Dans le cours sur les bases de Java, vous avez eu l'occasion de découvrir
différentes notions liées aux variables de type objet :

• les classes ;
• les méthodes ;
• les attributs.
Volontairement, j'ai laissé quelques imprécisions autour de ces concepts. Dans ce
cours, nous allons revoir ces notions en profondeur.

3 – L’objet
Quand on parle d'objet, il faut le voir comme un objet du quotidien. Chaque objet qui
nous entoure a des fonctionnalités et des caractéristiques.

Si vous prenez un four, par exemple, il possède avant tout


une fonctionnalité : faire cuire des aliments.

Pour mener à bien cette fonctionnalité, il possède des caractéristiques :

• Puissance : quantité en watts,


• Capacité : quantité en litres.
Avec une représentation UML, on peut représenter ce four de cette manière :

UML d'un Four


On a, dans l'ordre :

• Four : le nom du type de l'objet → la classe ;


• puissance et capacite : les caractéristiques de l'objet → les attributs ;
• cuire : les fonctionnalités de l'objet → les méthodes.
Dans le code, vous le savez maintenant, cela correspondrait à un fichier
nommé Four contenant une classe nommée elle aussi Four :

package com.cursan.miam;

public class Four {


Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

int puissance;

int capacite;

public void cuire() {

System.out.println("Je cuis un aliment");

System.out.println("avec ma capacité de " + capacite + " litres");

System.out.println("et ma puissance de " + puissance + " degrés.");

}
Cette classe n'est pas un four, mais la description d'un four. C'est lorsque l'on va
créer une variable de type Four que l'on va réellement créer un four.

package com.cursan.miam;

public class Main {

public static void main(String[] args) {

Four petitFour = new Four();

petitFour.capacite = 30;

petitFour.puissance = 180;

Four grandFour = new Four();

grandFour.capacite = 55;

grandFour.puissance = 260;
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

petitFour.cuire();

System.out.println("");

grandFour.cuire();

}
Dans ce code, j'ai créé 2 fours, un petit et un grand. Si je lance mon programme, le
résultat suivant s'affiche :
Je cuis un aliment
avec ma capacité de 30 litres
et ma puissance de 180 degrés.

Je cuis un aliment
avec ma capacité de 55 litres
et ma puissance de 260 degrés.

Process finished with exit code 0


Il ne faut surtout pas confondre classe et objet :

• La classe est la description d'un type : de quels éléments ce type est


composé.
• Un objet est une variable du type d'une classe. On dit aussi : une instance de
classe.
Pour décrire un concept, il y a une seule et unique classe, mais il peut y avoir une
infinité d'instances de cette classe.
Notre four sert à faire cuire quoi ? Des aliments bien sûr ! Nous allons procéder de la
même façon que pour notre Four .

Quelles sont les fonctionnalités d'un Aliment ? On peut le manger !

De quelles caractéristiques a besoin un aliment pour qu'on puisse le manger ? Pour


faire simple, nous allons dire : son nom et s'il est cuit ou cru.

Voici son UML :

UML d'un Aliment


Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

Et voici son code :

package com.cursan.miam;

public class Aliment {

String nom;

boolean estCuit;

public void manger() {

if (estCuit) {

System.out.println("Miam miam cet aliment : " + nom + " est bien


cuit");

} else {

System.out.println("Beeerk cet aliment : " + nom + " est cru !");

}
On va modifier Four.cuire pour faire interagir nos 2
classes Four et Aliment entre elles :

public void cuire(Aliment aliment) {

System.out.println("Je cuis un aliment : " + aliment.nom);

System.out.println("avec ma capacité de " + capacite + " litres");

System.out.println("et ma puissance de " + puissance + " degrés.");

aliment.estCuit = true;

}
Logique, non ? On prend simplement l'aliment en paramètre, on affiche qu'on est en
train de le cuire et on le met à l'état cuit !
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

Amusons-nous avec cela dans le main :

public static void main(String[] args) {

Four grandFour = new Four();

grandFour.capacite = 55;

grandFour.puissance = 260;

Aliment cake = new Aliment();

cake.nom = "cake aux fruits";

cake.estCuit = false;

cake.manger();

System.out.println("");

grandFour.cuire(cake);

System.out.println("");

cake.manger();

}
À votre avis, quel va être le résultat ?
Beeerk cet aliment : cake aux fruits est cru !

Je cuis un aliment : cake aux fruits


avec ma capacité de 55 litres
et ma puissance de 260 degrés.

Miam miam cet aliment : cake aux fruits est bien cuit

Process finished with exit code 0


Surpris ? J'espère que non ! Le processus que l'on vient de voir ici est celui qu'il
faut toujours utiliser dans la programmation orientée objet.

Il faut toujours réfléchir à :

• Quel objet je souhaite représenter ?


• Quelles fonctionnalités possède cet objet ?
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

• De quelles caractéristiques a besoin cet objet pour assurer ses


fonctionnalités ?
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

4 - Utilisez un UML complet


Le but de ce cours n'est pas de vous donner la démarche pour concevoir de A à Z un
diagramme de classe UML. Le but est que vous compreniez cette façon
de schématiser. Avec l'experience, vous serez capable un jour d'élaborer des
diagrammes très complexes.

Nous allons ici élaborer une première version de notre schéma UML et celui-ci
va évoluer au fur et à mesure des chapitres.

Notre projet est une application de gestion de facture dans un magasin en ligne.

La base de notre projet, c'est la facture. De quoi est composée une facture ?

de produits ;

• d'un client.
Commençons par représenter ces 2 concepts :

Le produit


UML d'un produit
Pour pouvoir regarder ou acheter un produit, nous avons besoin de son nom, de
sa description et de son prix.

Le Client


Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

UML d'un client


En nous limitant au strict minimum, pour pouvoir vendre à un client en ligne, il nous
faut son nom complet et son adresse.

La facture


UML d'une facture
products est de type Map<Product, Integer> . Cela sert à représenter un ensemble de
produits et une quantité achetée pour chaque produit. Dans un prochain chapitre, je vous
explique exactement ce qu'est une Map .
Vous comprenez facilement à quoi servent les flèches →, non ? Une facture est
composée de produits et d'un client. On représente cela avec deux flèches.
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

5 - La visibilité
Quand on développe du code, il faut toujours penser : "Peut-être qu'un jour, un
autre développeur utilisera mon code." C'est pour cette raison que l'on :

• nomme correctement nos classes, attributs, méthodes et variables ;


• rédige de la javadoc ;
• écrit des tests.
Dans cette même logique, la visibilité est une des notions les plus importantes.

Prenons un exemple de la vie réelle :

Quand vous utilisez un four, vous pouvez le démarrer à 180 degrés pendant 10
minutes. Quand vous faites cela, de nombreux mécanismes internes vont être
activés (les résistances vont chauffer, la soufflerie va s'activer, etc.).

Vous, en tant qu'utilisateur de ce four, n'avez pas accès à tous ces composants :
ils sont cachés par la carcasse du four.

Pour coder un four, nous pourrions faire :

public class Four {

Resistance resistance;

Soufflerie soufflerie;

public void cuire(int temperature, int duree) {

...

}
Si nous codons Four de cette façon, un développeur qui l'utilise pourrait avoir accès
à Resistance et Soufflerie .

Il pourrait, par exemple, faire :

Four four = new Four();

four.resistance = null;

four.cuire(180, 10);
En supprimant la valeur de resistance , il risque de casser la logique
interne de Four .
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

En tant que développeur, vous devez protéger Resistance et Soufflerie pour


que vous puissiez y avoir accès dans Four , mais pas à l'extérieur.

Pour cela, il existe un mot clé : private .

public class Four {

private Resistance resistance;

private Soufflerie soufflerie;

public void cuire(int temperature, int duree) {}

}
En faisant cela, il est impossible de faire fonctionner la ligne four.resistance =
null;. Le compilateur indiquera une erreur. De cette façon, seul le développeur
de Four a un contrôle sur ses composants internes.

Il existe 4 types de visibilités :

• private : uniquement accessible dans la classe ;


• public : accessible partout ;
• "" (rien) : accessible dans le package ;
• protected : nous verrons ce type plus tard.
Ce concept est aussi applicable aux méthodes. Continuons avec notre exemple
du four. Sur certains fours professionnels, il peut y avoir des fonctions de
maintenance accessibles au technicien, mais pas à l'utilisateur final du four. Cela se
symboliserait par une méthode accessible uniquement à l'intérieur d'une classe.

public class Four {

...

private void maintenir() {

...

}
Les méthodes servent principalement à structurer son code à l'intérieur d'une classe.
Initiattion à la POO / Source : OpenClassRooms / Edité par : Brunell Josny

6 - Getter et Setter
Par défaut, il faut toujours mettre tous les attributs à private , afin de bien maîtriser
ce que l'on peut faire ou non avec notre classe depuis l'extérieur.

Il faut ensuite se poser la question : est-ce que l'on a besoin de lire cette
information depuis l'extérieur ?

Si oui, il faut créer un Getter. C'est une méthode très simple qui ressemble à :

public Resistance getResistance() {

return resistance;

}
Cette fonction retourne une copie de la valeur de resistance . Les autres
développeurs peuvent donc accéder à sa valeur, mais ne peuvent pas la modifier.

La deuxième question à se poser est : est-ce que l'on a besoin de modifier cette
information depuis l'extérieur ?

Si oui, il faut créer un Setter. De nouveau le code est très simple :

public void setSoufflerie(Soufflerie soufflerie) {

this.soufflerie = soufflerie;

}
Mais du coup, cela revient au même ? Pas du tout ! Un développeur
qui utilise votre classe va voir les méthodes Getter et Setter que vous
avez créées. Il sait ce que vous l'autorisez à faire. Un Setter veut clairement dire
: "J'ai prévu dans mon code que tu puisses modifier cette valeur."
IntelliJ propose de facilement générer vos Getter et Setter via le menu Code > Generate...

S-ar putea să vă placă și