je suis avec le cours de Mateo21 sur le C (au TP de Sokoban) et j'ai eu un peu de curiosité de voir c que c'est que le C++ , du coup j'ai vu que c'est un langage orienté objet.. ça veu dire quoi la programmation orientée objet?
j'ai lu ça: http://fr.wikipedia.org/wiki/Programma [...] %C3%A9e_objet ... vraiment inconprensible
de cet extrait: La modélisation objet consiste à créer un modèle informatique du système de l’utilisateur (un système informatique). Ce modèle peut rassembler aussi bien des éléments du monde réel que des concepts ou des idées propres au métier ou au domaine duquel fera partie le système. La modélisation Objet consiste à définir, à qualifier dans un premier temps ces éléments sous forme de types, donc indépendamment de la mise en œuvre. C’est ce que l’on appelle l'analyse orientée objet ou OOA (Object-Oriented Analysis). j'ai compris que la programamtion orientée objet fera des logiciels, alors que la programmation non orientée objet ne ferai que des fonctions toute seules... c ça?
j'ai compris que la programamtion orientée objet fera des logiciels, alors que la programmation non orientée objet ne ferai que des fonctions toute seules... c ça?
Cette phrase là est fausse : on peut créer un logiciel aussi bien avec programmation orientée objet que sans.
La POO (abréviation) est simplement une manière d'organiser et de concevoir son programme différemment.
En gros, jusqu'ici tu as vu la programmation impérative structurée. Le nom est barbare, mais cela signifie simplement une chose : ton programme est censé résoudre un problème en le découpant en pleins de sous-problèmes, chacun étant résolu par une suite d'instructions de base(affectation, addition, ...), regroupées dans des blocs de code (boucles, tests, fonctions...).
Pour avoir une bonne explication de ce qu'est la POO, regarde sur wikipédia ou sur internet (si ce n'est déjà fait). Difficile de résumer cela de façon compréhensible en quelques mots, mais je vais tenter.
En gros, plutôt que de regarder le programme du point de vue des manipulations qu'il va faire sur ses données, on va mettre les "données" au premier plan.
En POO, on se préoccupe moins de la découpe du programme en étapes (même si ça se fait encore, mais c'est pas le point principale de la POO), mais on regarde les données, les machins qui interviennent dans le problème, qu'on appelle les objets et quelles sont les actions que peuvent faire ces objets ou qu'on peut leur faire subir. C'est assez contre-intuitif pour certains, et il faut comprendre quelques notions avant.
La notion d'objet entoure notre vie quotidienne en vérité. C'est juste que la "POO" a tranduit cette notion en quelque chose d'utilisable en prog.
Qu'est-ce qu'un objet, qu'est-ce qu'une classe ? Tout ça on le cotoit tous les jours. Par exemple, ma calculatrice est un objet de classe TI-84+, qui est une class fille de la classe TICalculatrices, elle-même fille de la classe Calculatrice, ... et on pourrait aller loin comme ça.
L'intérêt de former des objets c'est aussi qu'il représentent quelque chose de concret, un objet a des attributs qui lui sont propres, d'autres qui sont liés à sa classe. Et de même pour les méthodes ou actions qu'il peut faire.
Pour bien faire de la POO, la question à toujours se poser est donc "est-ce logique et cohérent que tel objet ou telle classe possède tel attribut, puisse faire telle méthode, ou hérite de telle classe ?" N'oublie pas qu'une classe héritant d'une autre, ça veut dire que la petite classe est une sous-classe de la grande. Tout comme un objet de la classe TI-84+ est "une" calculatrice TI, et à ce titre est "une" calculatrice.
La chose à ne pas faire par exemple, c'est de placer un objet de connexion SQL dans les attributs d'un objet de classe Personnage, et lui donner des méthodes de communication avec la base de données. Tu vois $sangoku s'ouvrir le bide pour en sortir un ordi portable qui lui dira s'il existe ? Pour moi c'est pas possible.
Merci de tous vos messages. J'ai bien copris ce qu'est la programmation impérative structurée grâce a newtow... mais le concept de POO me dépasse.
J'ai compris le truc des objets->classes (c'est un pei comme homo sapiens sapiens etc...) mais je ne vois aps trop comment mettre ça en informatique... et la question de Darth Killer est-ce logique et cohérent que tel objet ou telle classe possède tel attribut, puisse faire telle méthode, ou hérite de telle classe ? .. oulà!
J'ai compris le truc des objets->classes (c'est un pei comme homo sapiens sapiens etc...) mais je ne vois aps trop comment mettre ça en informatique...
En gros, chaque objet est un objet "physique", un truc plus ou moins réel. Comme un objet réel, il a des propriétés, des trucs mesurables. Par exemple, si tu prends un objet homme, suivant ce que tu voudra faire (on va prendre une application médicale), tu aura besoin de sa taille, son poids, les maladies qu'il a, ou autre chose encore. Chacune de ces particularités peut être codées dans ordinateur : un entier, un flottant, une chaine de caractère.
Le tout, c'est qu'on peut regrouper plusieurs de ces données, chacune codées dans un entier, une chaine de caractère, ou autres machins fournis de base dans ton langages favori, dans un truc qu'on appelle un structure de donnée qu'on peut manipuler. Une classe, c'est une structure de donnée comme une autre, avec des fonctions qui peuvent la modifier pour représenter ce qui va lui arriver. Tu peux voir une classe comme une grosse structure de donnée auquel on greffe des fonctions spécialisées.
ça donne en informatique le même raisonnement qu'on aurait en vie quotidienne, ni plus ni moins.
Par exemple, On peut imaginer une classe Vehicule, une classe Bateau, une classe Voiture, une classe Peugeot205 et un objet $mavoiture, on peut même le rédiger en PHP
<?php
class Vehicule {
protected $couleur;
public function switch($on = true) {
// Mise en marche ou à l'arrêt
}
public function __construct($couleur) {
// constructeur général
$this->couleur = $couleur;
}
}
class Bateau extends Vehicule {
// Classe fille de Vehicule
protected $vit_noeuds_max;
public function naviguer() {
}
public function __construct($couleur, $vit_noeuds_max) {
// constructeur général
$this->vit_noeuds_max = $vit_noeuds_max;
parent::__construct($couleur); // On appelle le constructeur de la maman
}
}
class Voiture extends Vehicule {
protected $nb_portes;
protected $nb_chevaux;
public function rouler() {
}
public function freiner() {
}
public function __construct($couleur, $nb_portes) {
// constructeur général
$this->nb_portes = $nb_portes;
parent::__construct($couleur); // On appelle le constructeur de la maman
}
}
class Peugeot205 extends Voiture {
$nb_chevaux = 12;
// Je ne connais pas le nombre de chevaux dans le moteur d'une 205
}
$ma_voiture = new Peugeot205('noire', 5);
$ma_voiture instanceof Peugeot205; // true : c'est bien une 205
$ma_voiture instanceof Voiture; // true : c'est bien une voiture
$ma_voiture instanceof Bateau; // false
$ma_voiture instanceof Vehicule; // true
$ma_voiture->switch(true); // Mise en marche. Cohérent pour tout véhicule
$ma_voiture->naviguer(); // Plante. Cohérent que pour un bateau, pas une voiture
$ma_voiture->rouler(); // cohérent pour toute voiture
$ma_voiture->freiner(); // idem
$ma_voiture->switch(false); // Arrêt
// De même une voiture ne peut pas avoir une vitesse max en noeuds, c'est pour les bateaux.
// Mais elle peut avoir un nombre de chevaux
// et le nombre est imposé selon la classe fille de Voiture.
// Tout véhicule a une couleur cependant.
?>
Je ne suis pas d'accord avec l'idée selon laquelle les objets de la POO seraient exactement les "objets du monde réel" ou qu'il permettraient de "raisonner comme dans la vie quotidienne".
L'héritage d'interface n'est pas spécifique à l'orienté objet. L'héritage d'implémentation n'a pas d'interprétation naturelle dans "le monde réel" (sinon décrire précisément le comportement des appels de méthode). L'appel de méthode n'a pas non plus d'analogue "du monde réel" terriblement convaincant (à part le passage de messages).
Il n'y a pas de consensus sur la définition de ce qu'est la programmation orientée objet. Il y a un relatif consensus sur le fait que l'appel de méthodes (ou envoi de messages) gérées par chaque objet individuellement de façon opaque (encapsulation et late binding) est nécessaire pour la POO. Il n'y a pas vraiment de consensus sur la notion d'héritage d'implémentation (est-elle nécessaire à la POO ou non ?), qui est pourtant présente dans la plupart des mises en œuvres dans des langages de programmation.
excalibur1491 > c'est une question un peu abstraite sur laquelle on trouve malheureusement beaucoup de charlatanisme. Le mieux pour toi c'est d'apprendre par la pratique : si tu apprends un langage dit "objet" un jour, tu auras l'occasion d'expérimenter avec ces méthodes de conception¹, et tu pourras donc mieux comprendre les discours abstraits qui s'y réfèrent.
¹: attention, apprendre une fonctionnalité d'un langage et apprendre à l'utiliser correctement pour écrire de meilleurs programmes, ce n'est pas la même chose. En particulier pour l'objet (l'héritage d'implémentation) il y a un très gros effort de conception à faire pour ne pas rendre le code difficile à maintenir, et c'est quelque chose qui doit s'apprendre *en plus* du langage de programmation.
Les langages Smalltalk (par exemple Pharo) et surtout Eiffel sont sans doute de bon choix (très différents, et parmi d'autres) pour apprendre la programmation orientée objet.
Le tout, c'est qu'on peut regrouper plusieurs de ces données, chacune codées dans un entier, une chaine de caractère, ou autres machins fournis de base dans ton langages favori, dans un truc qu'on appelle un structure de donnée qu'on peut manipuler. Une classe, c'est une structure de donnée comme une autre, avec des fonctions qui peuvent la modifier pour représenter ce qui va lui arriver. Tu peux voir une classe comme une grosse structure de donnée auquel on greffe des fonctions spécialisées.
um.... disons donc qu'en C (c'est le seul langage que je connais) on ferait:
struct classe{
int un_Attribut;
long autre_Attirbut;
....
int uneFonction (variables_de_cette_classe);
}
quelque part on creerai des objets auxquels on dirai: toi structure Homme, t'as les attributs (variables) bras, jambes et tête. T'as les fonctions courir, marcher et nager.
Si là je fais une classe de cet Homme je dirai: la classe "videur" ( ) a toutes les choses que Homme (c'est une classe de cet objet), mais t'as en plus la fonction "vigilance"... c'est ça?
=========
Citation : Darth Killer
ça donne en informatique le même raisonnement qu'on aurait en vie quotidienne, ni plus ni moins.
Par exemple, On peut imaginer une classe Vehicule, une classe Bateau, une classe Voiture, une classe Peugeot205 et un objet $mavoiture, on peut même le rédiger en PHP
Je ne connais pas le PHP, mais j'ai un lu le code, et quelque part j'ai compris ce que je viens d'écrire au dessus en reponse à newtow.
Par contre.. je trouve pas ça trop intuitif, "comme dans la vie quotidienne".... tu vas dans le sens ou "un four ça chauffe -> un four microondes ça doit chauffer lui aussi"... ou "ma tv est une SONY -> cette telecomande est une Siemes ->ça appartient pas a la même classe " c'est ça?
========
Citation : bluestorm
excalibur1491 > c'est une question un peu abstraite sur laquelle on trouve malheureusement beaucoup de charlatanisme. Le mieux pour toi c'est d'apprendre par la pratique : si tu apprends un langage dit "objet" un jour, tu auras l'occasion d'expérimenter avec ces méthodes de conception¹, et tu pourras donc mieux comprendre les discours abstraits qui s'y réfèrent.
¹: attention, apprendre une fonctionnalité d'un langage et apprendre à l'utiliser correctement pour écrire de meilleurs programmes, ce n'est pas la même chose. En particulier pour l'objet (l'héritage d'implémentation) il y a un très gros effort de conception à faire pour ne pas rendre le code difficile à maintenir, et c'est quelque chose qui doit s'apprendre *en plus* du langage de programmation.
Pour le moment je continue avec le C, puis je ferai du C++... c'est un bon choix ou le Java est plus "objet" encore?
c'est quoi exactement l'heritage?? le fait de passer le code a d'autres programmeurs??
Bluestorm : j'en étais qu'à l'approche du concept objet. Le reste des nuances ne peut venir qu'une fois qu'on a mis les 2 pieds dedans, excalibur n'en est pas encore là.
je suis avec le cours de Mateo21 sur le C (au TP de Sokoban) et j'ai eu un peu de curiosité de voir c que c'est que le C++ , du coup j'ai vu que c'est un langage orienté objet.. ça veu dire quoi la programmation orientée objet?
Tiens, je pense justement à écrire un tuto sur l'orienté objet, en prenant le TP Sokoban du tuto de Mateo comme point de départ et en l'adaptant petit à petit vers de l'OO
Pour réagir à ce qui a été dit ici, je dirais que si effectivement les classes peuvent aider à modéliser des objets de la vie quotidienne, ce sont les exemples les moins intéressants. Ces objets ne devraient servir qu'à représenter des données et ne devraient avoir qu'un minimum de comportement (méthodes), sous peine de passer rapidement à la trappe toute réusabilité.
Les objets les plus intéressants ne sont pas nécessairement ceux qui sautent aux yeux en premier. La difficulté est qu'il n'y a pas de solution miracle pour identifier les "bons" objets. Par exemple, dans le cas du Sokoban on serait tenté de faire une classe Sprite, dont hériterait une classe Box, une classe Wall etc. On pourrait leur donner une méthode Display(), dont le code serait différent afin d'afficher la bonne image correspondant à chaque classe... mais on n'irait pas beaucoup plus loin. Et si par malheur l'affichage des objets du plateau est différent selon qu'on soit en train d'éditer une map ou d'y jouer, on est bien embêté. Faudrait-il prévoir une méthode DisplayGame() et une autre méthode DisplayEditor() pour gérer les différents cas de figure ? Ou bien un simple paramètre booléen, qu'on utiliserait dans un if pour savoir quoi faire ? C'est certainement faisable, mais ça semble bancal. De plus, ces objets sont des objets "métier" et ne devraient pas être aussi intimement liés à l'interface.
Il existe bien des patterns pour aider à résoudre ce problème plus ou moins élégamment (par exemple ici les patterns State ou Décorateur), mais la mise en place de tels patterns a un coût non négligeable. Mieux vaut d'abord réfléchir à une meilleure découpe du problème.
En particulier dans le jeu de Sokoban, il y a 3 objets "non matériels" (quoique?) mais bien plus intéressants à identifier : l'objet Menu, l'objet Game et l'objet Editor, avec chacun leurs méthodes Load(), Update() et Display(). Ces 3 classes pourraient hériter d'une même classe (ou idéalement d'une interface) GameMode; il y aurait une instance de GameMode "active" à tout moment selon que l'on soit en train de jouer, de créer une map ou de voir le menu principal, et c'est cette instance qui serait directement responsable de présenter l'interface perçue par le joueur.
En gros, on reste sur le principe de l'OO: on sépare les cas (Menu/Edition/Jeu) et on regroupe les opérations pour chaque cas (Load/Update/Display). Le problème est de trouver quels cas séparer, et c'est loin d'être si intuitif qu'on le prétend car la séparation est rarement nette. En effet, si je sépare le jeu et l'éditeur et que les éléments du plateau sont finalement affichés de la même façon, je risque de devoir dupliquer du code pour écrire leur méthode Display() respective - une solution (discutable) serait alors de factoriser le code commun dans la classe abstraite GameMode, ou (mieux) d'utiliser des templates visuels partagés.
Notez qu'en disant ça, je m'écarte de la présentation traditionnelle de l'OO (celle évoquée par mewtow) qui encourage la mise en avant des données au détriment des procédures, et qui voudrait que le jeu de Sokoban soit finalement construit comme un ensemble d'interactions entre des caisses, des murs et un personnage - et rien d'autre. Cette approche est aujourd'hui largement critiquée et, si l'architecture OO a bien toujours un sens, il est à chercher ailleurs : s'il y a bien des objets qui intéragissent, ce ne sont certainement pas les données.
Les langages Smalltalk (par exemple Pharo) et surtout Eiffel sont sans doute de bon choix (très différents, et parmi d'autres) pour apprendre la programmation orientée objet.
J'avais toujour envie de me mettre a Smalltalk mais je n'aime pas le modele d'execution utilise, c'est ... bizzare. L'Objective-C est un bon langage tres inspire de Smalltalk, qui reprend la notion d'objet, les messages, etc. mais compatible avec le C (et le C++ avec Objective-C++), je le recommande a tous. (Et bien sur c'est le langage utilise pour la programmation sur iOS )
Sinon il y a Io qui a une notion d'objet un peut bizarre (tout herite d'Object, pas de classes, on peut definir un nouveau membre a l'execution,...) mais tres sympathique
Orwell : jolie présentation de la POO
Je suis d'accord avec toi que les exemples issus de la vie quotidienne sont les moins intéressants. Mais ils représentent une excellente approche pédagogique pour quiconque n'est pas familier avec l'OO, ce pourquoi j'utilise ces exemples.
Facile à comprendre oui, pédagogique non : cette façon de voir les choses pousse les gens à faire n'importe quoi (en particulier utiliser l'héritage à outrance: "bah oui les humains sont des mammifères").
Oui les humains sont des mammifère, mais donc il faut réfléchir à ce qu'il y a de commun à tous les mammifères et ce qui est spécifique aux humains. Si cette réflexion est fait, il n'y a pas d'erreur possible sur ce plan là.
Au moins vous avez essayé de m'expliquer .
Moi, jusqu'ici j'ai comrpis qu'on cree des "structures" qu'on appele objets ou classe (j'ai pas compris la difference entre objet et classe....). Ces structures ont des carcateristiques qui leurs sont propres (dissons des variables, non?) et des fonctionalites propres aussi (des fonctions?).
Si jusque là j'ai bien compris, c'es déjà ça.
Si ce que j'ai dit est vrai, maintent j'ai un souci: ces structures que je viens de définir.... elles servent à quoi? elles interagisent comment? parce que pour moi c'est facile de me dire: j'ai une focntion, je lui envoi telle ou telle variable, elle me donne ça. mais là j'ai des objet? je les balance où?
@excalibur1491 apprend la POO , tu comprendras mieux par la pratique , ça ne sert à rien de t'expliquer des notions POO.
Puis bon ici comme certain le fond , à part pour eux-mêmes un débutant ,ne comprendrait rien.
La POO est géniale mais si tu arrives à comprendre correctement sinon c'est la porte à n'importe quoi , il est pas évident d'expliquer une notion comme la POO par des mots , phrases.
J'ai pas dit que le fonctionnel, ou même le procédural, c'était mal. Juste que quand dans un même langage on se converti à la POO, on en vient à se demander comment on faisait avant sans les objets.
J'ai pas dit que le fonctionnel, ou même le procédural, c'était mal. Juste que quand dans un même langage on se converti à la POO, on en vient à se demander comment on faisait avant sans les objets.
J'ai pas dit que le fonctionnel, ou même le procédural, c'était mal. Juste que quand dans un même langage on se converti à la POO, on en vient à se demander comment on faisait avant sans les objets.
Ca dépend ce que tu veux faire, la POO n'est pas une solution miracle à tout. Pour un programme orienté calcul pur par exemple, tu n'as pas forcément beaucoup de gains à faire de la POO, alors qu'un langage fonctionnel (qu'il ait des apsects POO ou pas) sera souvent beaucoup plus adapté.
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?
{LVM}Plan de "partitions" pour machines virtuelles ? Carte de capture sous linux ? Erreur ACPI au boot ?