Alors, comme beaucoup je suppose qu'arrivés à cette partie vous vous demandez pourquoi vous changeriez de méthode de programmation.
C'est vrai après tout, celle que nous utilisions fonctionnait très bien jusqu'à maintenant et pourquoi ne pas continuer ?
Eh bien d'un point de vue, la méthodologie de programmation que nous avons vus à présent est très bonne, nous avons même vus quels genre de programmes nous étions capables de réaliser en suivant ce concept.
Mais d'un autre côté ... Il y a plein de choses qui sont impossible ou très difficilement réalisables en programmant de cette façon.
Vous imaginez créer un jeu comme ça ?
Même le plus basique des jeux de rôles vous prenait des heures de travail pour un résultat que la POO vous apporterait sur un plateau.
Bref, je m'égare, je vais essayer de vous expliquer plus en détail ce qu'est le fabuleux monde de l'Orienté Objet.
Mesdames, Messieurs, Sa Majesté POO.
Je rappelle pour ceux qui ont tendance à sauter des chapitres entiers : POO = Programmation Orientée Objet.
Jusqu'à maintenant nous avons fait de la programmation
Procédurale, pour faire simple, ce principe se base sur les procédures et fonctions, vous avez remarqués que pendant tous nos TPs, chaque "action" à effectuer était souvent décomposée en un sous-ensemble de fonctions et procédures (sub). C'est donc cela la programmation procédurale.
Comme vous le voyez sur le schéma, ces fonction s'imbriquent les unes aux autres. Pour le moment, aucun problème. Lorsque nous attaquerons de gros projet, cette structure va devenir un véritable pêle-mêle.
C'est pourquoi
dieu Alan Kay se décida à révolutionner la façon de programmer en élaborant la Programmation Orientée Objet.
Comme son nom l'indique, nous allons créer des objets. Mais tout d'abord qu'est-ce qu'un objet programmatiquement parlant ?
Nous nouveaux amis : les objets
Dans la vie de tous les jours, vous voyez ce qu'est qu'un objet ? Eh bien en programmation le concept reste le même.
Je m'explique :
Nous allons créer des objets qui vont nous permettre de rassembler des groupes de procédures ou fonctions appartenant à la même famille. En gros, si nous voulons contrôler une voiture, nous pouvons, avec nos connaissances actuelles, créer des dizaines de fonctions pour faire avancer, reculer, tourner, freiner notre voiture. Mais si nous en voulons une seconde nous allons être obligés de recommencer.
Avec le concept d'objet, nous programmions des fonctions qui seront liées à l'objet "Voiture" et après peu importe que l'on décide d'en faire 1 ou 100, il n'y aura pas à recommencer.
Ici, sur le principe d'un gâteau. Nous allons coder le "moule" du gâteau, une fois ce moule bien bâtit, il sera capable de nous créer des dizaines de gâteaux.
Vous avez utilisés pas mal d'objet jusqu'à maintenant, exemple : la class File.
Le moule de "File" nous a permis de créer des dizaines de "File" et de les manipuler séparément.
Retournons à notre voiture.
Notre moule, en Visual Basic se nomme la Classe. La classe contient un Contructeur (ce qui se produit lorsque l'on crée notre objet, en l'occurence notre voiture) et possibilité de mettre un destructeur (je pense que vous avez compris son utilité).
Ces méthodes seront présentes dans le fichier de la Class. On peut également ajouter beaucoup d'autres fonctions ou sub à notre classe. Une fonction pour faire avancer notre voiture, une autre pour la faire reculer, nous pouvons également déclarer des variables qui seront utilisables seulement par cette classe.