>> cela ne veut pas dire qu'il faut considérer les classes et l'héritage comme étant une construction à éviter.
Tout à fait d'accord, il faut juste se garder des classes en poupées russes. Chaque héritage doit se justifier et sa raison rester évidente six mois après. La possibilité de "rouvrir" les classes (qui n'est pas sans danger si on n'y prend pas garde), supprime un raison majeure d'hériter, l'enrichissement de la classes de base. Reste le STI dont le danger est qu'il est difficile de se représenter ce qui se passe dans les corner-cases et donc on prie pour pas avoir d'ennuis. Bref pour revenir à la question de départ, ma "rule of thumb" : Quand je me pose des questions pointues sur private et protected je prend systématiquement un moment de recul pour savoir si je ne suis pas en train de compliquer pour rien... My 2 Francs (pour ce que ça vaut aujourd'hui ;-) 2014-09-19 15:34 GMT+02:00 Jean-Hadrien Chabran <j...@chabran.fr>: > Juste pour réagir vis à vis de l'héritage, > > Je serais pas aussi radical personnellement. Si on voulait raisonner façon > FP dans 80% des cas, autant aller faire du Clojure. On est en Ruby, le > principe de classes/instances/mixins est omniprésent. On retrouve très > clairement des composantes ou inspirations fonctionnelles un peu partout > (coucou Enumerable), mais cela ne veut pas dire qu'il faut considérer les > classes et l'héritage comme étant une construction à éviter. Au contraire, > on a nos objets absolument partout et on vient tirer parti du fort > dynamisme de Ruby pour y inclure des constructions habituelles dans les > langages fonctionnels, justement grâce à ce dynamisme. > > Pour ma part, je le résume ainsi le choix entre l'héritage et les mixins: > > - Si le concept que j'implémente est concret et autonome. Il s'agit d'une > contrainte forte que l'on met en place, il ne peut être conjugué qu'au > travers une composition et sera hérité pour être étendu. > - Si le concept que j'implémente n'existe pas tout seul et doit forcément > être conjugué à un autre alors il s'agit d'un mixin (module). > > Tu vas me répondre, oui mais AR et DataMapper, les deux implémentent la > même chose. Sauf que ce n'est pas exactement le même cas : AR implémente un > "Record", un enregistrement db donc qui sera étendu pour devenir un objet > métier là où DataMapper vient apporter la "persistance" en db à un objet > métier. > > C'est donc l'approche qui change, avec AR on a très clairement la notion > qu'il s'agit d'une ligne dans la db a qui je fais faire des trucs business, > d'ailleurs sa structure est définie dans la db, c'est donc la DB qui > détermine quels attributs sont persistés, soulignant ainsi sa nature. > D'ailleurs rien n'est fait pour le masquer. Bref, c'est moins souple, mais > c'est plus facile à utiliser (j'ai choisi "facile" ici, pas "simple", la > différence est subtile mais importante). > > A côté, tu as DataMapper, où je viens indiquer dans mon objet métier > quelles sont les propriétés persistées directement dans le corps de la > classe et les différents comportements sont splittés au sein de différentes > gems, que j'inclus selon ce dont j'ai besoin. C'est clairement moins facile > à utiliser, le comportement ne m'est pas imposé mais c'est beaucoup plus > souple. > > Bref, clairement on peut implémenter n'importe quel problème avec une > approche ou l'autre, il s'agit simplement de savoir quel focus on veut > donner, c'est lui qui conditionnera l'usage qui en est fait, genre est-ce > que ça va me paraitre logique/évident/sensé ou pas. C'est toute la beauté > de Ruby je trouve. > > Enfin pour le STI, je comprends tout à fait ce que tu veux dire, mais > serait plus judicieux à mon goût de le formuler autrement : on sort le STI > uniquement quand le problème à modéliser s'y prête parfaitement, ce qui est > tout de même pas si courant que ça, d'où la méfiance envers son usage. Si > j'implémente la notion d'être humain, je vais avoir des trucs genre > House.has_many(:humans) et je trouverais donc Man et Woman qui sous > classent Human. Les deux sont très très similaires, sauf qu'à l'heure > actuelle l'homme n'est pas encore capable d'être "enceint", donc j'ai un > attribut supplémentaire sur la classe Woman. Maintenant, si je viens > implémenter un truc genre Workshop.has_many: tools, Tool comporte une > tétrachiée de différentes subtilitées et potentiellement de concepts > différents (outil qui a besoin du courant, outil à la con genre marteau) > là, je me tire une balle dans le pied en sortant le STI. > > My 2 euros (oui car quand même j'ai beaucoup écris là ^^), > > > 2014-09-19 14:39 GMT+02:00 Tim <itsumo.sibyl...@gmail.com>: > >> >> Merci beaucoup pour la justification, >> en effet je pensais que private avait le meme comportement dans tous les >> langages et j'ai commencé avec le JAVA... >> > Comme beaucoup d'entre nous (ou le C++), c'est parfaitement normal de > raisonner ainsi quand tu n'as été exposé qu'à ceux-ci. > >> >> Bon ben je m'écrase, merci pour vos liens/explications. >> > >> >> Le vendredi 19 septembre 2014 14:13:18 UTC+2, Tim a écrit : >>> >>> Salut à tous >>> >>> >>> Je viens de tomber sur quelque chose qui perturbe totalement mon >>> intuition de dev : >>> >>> apparemment une méthode déclarée comme privée est accessible par son >>> enfant dans le controller : voici mon code réel : >>> >>> Rails 4.1.5 (fonctionne aussi sur 3.2.19), Ruby 2.1.2 >>> >>> class ApplicationController < ActionController::Base >>> protect_from_forgery with: :exception >>> >>> private >>> >>> def method_privee >>> p "method_privee accessible" >>> end >>> end >>> >>> >>> class PhrasesController < ApplicationController >>> def index >>> method_privee # affiche "method prive accessible" >>> end >>> end >>> >>> Ce code (je viens de le lancer plusieurs fois) fonctionne lorsque l'on >>> va sur /phrases/index et ne fais pas "raise error, NoMethodError" mais >>> affiche bien "method_privee accessible" >>> >>> Quelqu'un peut m'expliquer ? merci >>> >>> Ciao. >>> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> railsfrance@googlegroups.com >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance-unsubscr...@googlegroups.com >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse >> railsfrance+unsubscr...@googlegroups.com. >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > > > > -- > Jean-Hadrien Chabran > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > railsfrance@googlegroups.com > Pour résilier votre abonnement envoyez un e-mail à l'adresse > railsfrance-unsubscr...@googlegroups.com > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes > "Railsfrance". > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le > concernant, envoyez un e-mail à l'adresse > railsfrance+unsubscr...@googlegroups.com. > Pour obtenir davantage d'options, consultez la page > https://groups.google.com/d/optout. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
