cherche exemple pratique de taille relativement réduite de programme ou modèle conçu en orienté objet. merci

Question

Quiconque ne discute plus la pertinence de la programmation orienté objet. Avant de programmer objet, il faut avant tout concevoir en objet, ce qui n'est pas aussi évident. pour se familiariser avec la conception OO, je cherche un exemple pratique de périmètre réduit démontrant l'adéquation de sa conception en objet plutôt que sa réalisation avec la programmation classique (procédurale ou fonctionnelle)

Merci d'apporter aide

Answer 1

L'orienté Objet est très pratique dans le sens ou tu peux créer un objet qui correspond exactement à ce que tu recherche et l'instantier plusieurs fois de suite :
Par exemple tu veux avoir une bibliothèque :
Tu créés un objet livre avec des attributs comme titre, auteur, description, nombre de pages
Le grand avantage c'est que pour ton auteur tu créés un autre objet auteur qui contient en attribut : nom, prénom, date de naissance
En java ça donne à peu près celà :
public class bibliotheque {
private String titre;
private Auteur auteur;
private String description;
private Date date;
}
Pour la classe (objet) bibliotheque et pour la classe Auteur :
public class Auteur {
private String nom;
private String prenom;
private Date dateDeNaissance;
}

Voilà j'espère que tu vois l'avantage, néanmoins mon exemple est incomplet car il faut créer des constructeurs pour créer les différents objets et faire des méthodes pour l'accès aux attributs et pour "faire vivre" l'objet.

Answer 2

Ramis V : mieux vaut lire ton message plutôt que d'être aveugle.

Dire que la programmation objet c'est la même chose que le procédurale "C like" est absurde : tu penses comme une machine, si tu vas par là à un moment donnée tout est transformé en assembleur. A ce moment là autant laisser tomber le C qui est beaucoup plus lent que l'assembleur. Pour l'anecdote Word 3 était réalisé en C et à l'époque tout le monde c'était plaint de la lenteur par rapport au version précédente codée directement en assembleur.

Ce n'est pas une mode, c'est une façon naturelle de programmer avec un niveau d'abstraction *beaucoup* plus haut que le procédurale. Tout l'intêret de la théorie objet provient des concepts qu'elle autorise. L'évolutivité des programmes objets (bien conçus) est à des années lumières des programmes procéduraux.

Pour répondre à la question : le meilleur entraînement est la découverte des design pattern. Etudie tous les motifs du GoF (création, structure, comportement) un par un et tu auras un aperçu du monde objet. Etudie aussi UML au passage car les design pattern sont expliqués à l'aide d'UML.

Généralités :
http://fr.wikipedia.org/wiki/Design_pattern

Python :
http://www.python.org/workshops/1997-10/proceedings/savikko.html

.net :
http://patternshare.org/default.aspx/Home.AllPatterns
Exemple pour le Singleton :
http://patternshare.org/search.aspx?search=singleton&namespace=Home.GOF

Answer 3

la pertinence n'est pas si évidente que ça.

à mon avis, c'est juste une question de mode et de convention d'écriture.

on pourrait même associer ça à une précompilation.

comme les #define du langage C, on peut imaginer que le compilateur commence par transformer les variables objets en structures (records) où les méthodes sont remplacées par des pointeurs de fonctions. les méthodes redéfinies ou surchargées d'une sous-classe pointeront simplement vers la fonction/méthode alternative.

pour l'instant, je ne vois pas d'apport réel. en tout cas, ça ne diminue pas le nombre de lignes ni le temps d'éxécution...

à suivre.