Je crois que je vais faire un arrêt cardiaque si je continu de voir ces abérations sur le forum. Étant donné que le Ruby est un langage orienté objet, voyons voir les bases de ce type de langage.

Nous prendrons comme exemple mon dernier script en date de ce jour: Le générateur aléatoire.

Cet atelier est sous forme de dialogue entre un maître et son disciple.

Premièrement, quels sont les avantages de l'orienté objet?
L'orienté objet permet de séparer des bout de code de façon à pouvoir les réutiliser.

Oui, mais pas totalement. Il faut aussi savoir que l'orienté objet sert à créer des "objets", d'où son nom. Ce qu'on entend par objet en informatique n'a rien à voir avec un ordinateur, un téléphone ou une pomme. Un objet est und entité typée ayant un certain nombre de paramètre et une certaine comportement. Dans notre exemple, on crée un livre qui a un auteur, des pages, une couverture et tout le tralala. Regarder le nombre de classe que ce module possède. Le nom de l'auteur, le sujet du livre, les matériaux pour le livre et le livre lui-même sont tous dans des classes distinctes. Pourquoi? Simplement parce qu'on pourait décider de généré un nom sans pour autant vouloir un livre. L'auteur peut exister sans son livre. On pourait donc, à partir du générateur de livre généré uniquement l'auteur sans tout le reste du livre, et ainsi avoir simplement un générateur de nom.
:chaud2: Fiou, mais pourquoi ne pas avoir simplement séparer la classes en différentes méthodes?
C'est aussi une possibilité, mais dans ce cas, imaginons qu'on veuillent réutiliser le générateur de nom... Il faut recopier la bonne méthode ainsi que les bonne variables dans une nouvelle classe et on va se faire chier à essayer de ne rien oublier, ou sinon, on va généré un livre au complet juste pour avoir l'auteur... Une perte considérable en temps de calcul et d'espace mémoire. En classes distincte, tu veux seulement le nom, tu obtiens seulement un nom.

Ah! Là j'ai compris! On mets ce truc en pièce pour réutiliser ses morceaux!
Non!! C'est pas ça que je dis. Il faut mettre ensemble ce qui est difficilement dissociable et séparer ce qui est ségrégable. En ce sens, mon code n'est pas parfait car mettre les feuilles et la couverture ensemble.... j'aurais dû faire des séparations de plus... mais bon. Dans ma façon de voir le problème sur le coup, j'avais les matériaux qui formait le livre, le contenu du livre, l'auteur et j'avais le livre lui-même. Je l'avoue, j'aurais du faire mes classes différemment.
QUOI!! Ce code n'est pas bon...

Ce n'est pas exactement ce que j'ai dit... Il faut savoir cibler... En fait, ce que j'aurais pu faire, c'est de définir une classe matériaux avec tous les matériaux possible et imaginable sous classé par catégorie et appeler la classe matériaux en déclarant de quel type j'avais besoin. Dans ce cas, je trouvais cette pratique un peu redondante, mais ça aurait été la bonne façon de faire.
Ok... Bon maintenant qu'on a une idée de l'orienté objet, quels sont les grande division... Tu parlais de définitions et de comportement et d'objets.

Oui disciple, tu comences à comprendre. La classe est une définition d'objet. Elle regroupe tout ce qu'on a besoin pour concevoir l'objet. Si on compare le code à une maison, la classe est un peu comme le plan de la maison. On a des constantes, des variables, des méthodes, des accessors, bref tout ce qu'il nous faut pour construire un objet, mais ce n'est rien en lui-même sinon une définition. Si nous n'avons pas d'objet de cette classe, rien qui est écrit dans cette classe ne sera exécuter... C'est une maison sur papier, personne ne peut y habiter.
Ok, c'est bien beau tout ça, mais c'est quoi un objet dans ce cas?

Un objet c'est une instance de la classe, ou dit plus simplement, une réalisation de la classe. Lorsqu'on dit «Ok, construisons une nouvelle maison.» ( .new ), bien on prends le plan et on construit un nouvel objet selon ce plan. Là notre code va servir car l'objet est réel et a ses attributs et comportements.
Les comportement sont les méthode, c'est ça?

Tout à fait. La définition des méthodes est ce qui définit le comportement. Dans l'exemple, du générateur de livre, ont dit au générateur comment concevoir un livre de manière aléatoire. Dans une classe qui définirait une porte de notre maison, on lui dirait qu'elle peut s'ouvrir, se fermer, se verrouiller et se déverrouiller et comment elle fait pour passer de l'un à l'autre.
Donc on peut avoir plusieurs comportement pour un même objet et plusieurs objets généré depuis la même classe. Mais si ce sont tous des objets venant de la même classes, mes variables sont-elles communes à chacune.
Pitié, venez-moi en aide... NON!!! Rappelez-vous du cours des variables. Les variables locales sont détruite à la fin de leur contexte, donc vous perdrez leur valeur en sortant du contexte qui l'a créer. Un contexte est un bout de code isolé. En Ruby, c'est un code qui commence par un mot clé et qui termine par end. En Java, c'est ce q'il y a entre { et }.

Les constantes sont permanentes et partagées, mais qui voudrait modifier une constante...??? En Ruby, rien ne permet de protéger une constante sinon le bon sens du programmeur, mais certain langage permettent de définir ces constante de manière statique..., mais laissons faire ce détail, ce qui vous intéresse, c'est le Ruby / RGSS2.

Les variables globales, pour leur part, sont également permanante, mais surtout rémanente. Elle ne sont pas habituellement défini dans une classe puisque ce n'est pas sa place. C'est variables sont d'usage publique et sont partagées par tout le système.

Finalement, il nous reste les variables d'instances, celles qui commence par un @ et qui peuvent être lu manuellement par une méthode ou automatiquement grâce aux accessors.
Instance.?! Il me semble que ce mot me dit quelque chose...
:depression: Au secours... «Les objets sont des instances d'une classe». C'est ce que j'ai dit quelques lignes plus haut..!!! Instance, ça veut dire réalisation, le fait qu'un objet soit RÉEL. Donc ce sont des variables qui sont défini pour CHACUNE des instances (création) d'objet de cette classe. Elle ne sont détruite que si l'objet est détruit. Si on fait bruler notre livre, il n'y aura vraisemblablement plus de page du livre... Je vous entends me demander, encore, «Quand un objet est-il détruit dans le code?». Par pitié, ne la poser pas, je vais vous répondre tout de suite... Un objet est détruit si on lui dit clairement (plusieurs classe possède une méthode delete) ou sinon, le garbage collector (le rammasse ordure) le détruira lorsque l'objet sera hors de portée.
Hors de portée??
Veux-tu bien me dire comment tu crées tes objets!!! Ton objet sera une variable dans ton code. Donc si tu fait un objet en variable locale ou en variable d'instance ou globale, bien tu connais la porté de ton objet... S'il est en variable locale, il sera détruit en sortant de son contexte, en variable d'instance lorsque l'objet de la classe qui a créer cet objet comme variable d'instance sera détruit et finalement s'il est en variable globale, bien il sera détruit avec l'application qui soutient les variables globales...
:pleaaase: Ohhhhhhhhh!!! D'accord...
Tu as tout compris disciple?
:YES: Oui... La classe définit des objets qui sont des instances de la classes qui ont des comportement défini par les méthodes et des attributs qui sont gérés par les variables d'instances redéfini de façon unique pour chaque existance d'objet de cette classe. On peut lire et écrire ces valeurs à partir des méthode d'accession (définie manuellement ou avec des accessors). La mémoire est libérée lorsqu'un objet est détruit suivant la même règle que les variables qui retiennent les informations de ces objets, soit hors contexte, hors instance ou hors application pour les variables locale, d'instance ou globale respectivement. La programation orienté objet permet donc de définir un objet typé qui aura ses comportements et attributs qui est réutilisable dans un contexte différent.
En effet. C'est pour ça qu'il faut bien définir sa classe, sinon, on fait de la programation procédural, donc non réutilisable. L'orienté objet est peut-être plus long sur le coup, mais quand c'est bien fait, ça permet de sauver beaucoup de temps par la suite.
Mais c'est quoi la surcharge à la fin du code du générateur?
C'est pour ajouter une fonctionnalité à une classe existante sans avoir à la réécrire entièrement. L'alias me permet de garder l'ancienne fonctionnalité en rappelant l'alias et le code qui suit est le nouveau comportement qu'on veut avoir. La surcharge permet que si un autre code ajoute une fonctionnalité, bien on ne pert pas cette fonctionnalité, on ne fait que l'ajouter à côté.
Ça fait beaucoup d'information, mais je vais réétudier le tout, je devrais tout comprendre...
Je l'espère bien, sinon tout est à recommencer...