Question de paradigme orientée objet

Pensez comme si vous parlez anglais. La règle générale est, les verbes (et les méthodes) devraient avoir une "voix active" autant que possible - c'est-à-dire qu'un objet devrait faire quelque chose, plutôt que de faire quelque chose à cela.

Si c'est un événement, la voix passive a un peu plus de sens - le laboratoire devrait savoir quelles sont les personnes qui y sont, mais une personne aléatoire (même une personne travaillant dans le même laboratoire) devrait probablement pas, donc une notification que le Lab Slew Up serait mieux venant du laboratoire lui-même. Mais vraiment, il s'agit d'une préférence personnelle (ou d'équipe) dans ce cas.

Je pense que cela est lié au monde réel et à votre convention de codage plutôt que de bonnes pratiques générales. Pour votre anglais, je préfère toujours appeler les gens.Notifier (laboratoire). Toutefois, si vous voulez que votre laboratoire ait des données sur qui l'appelez, quelle personne, vous pouvez faire lab.isnotifiedby (personnes).

La bonne pratique ici est que cela a du sens pour vous et votre collègue lors de la recherche du code, ils comprennent ce qu'il fait, s'ils veulent trouver une méthode, ils savent où ils devraient commencer plutôt que de continuer à rechercher ou à demander vous

J'aime concevoir des choses comme ceci: xxx

Vous voudrez peut-être lire un peu sur l'observateur et publier / souscrire des modèles. Ce que vous décrivez, c'est à peu près l'application classique pour le modèle d'observateur. Le pub / sous-modèle est fondamentalement la même idée qui a été un peu plus attrayant pour aider à l'échelle.

Dans tous les cas, étant donné à quel point ce modèle est déjà connu, vous pourriez aussi bien suivre sa convention, sauf si vous rencontrez une situation où vous êtes vraiment sûr de faire autrement.

Dans ce cas, j'aimerais introduire un nouvel objet - Labexplosion

// To find out if Gordon Freeman ever blew up Black Mesa
explosions.find("Gordon Freeman", "Black Mesa").length > 0;
// returns T/F

Je ne suis pas tout à fait sûr de votre exemple, mais un

Un excellent livre qui a ce que vous voulez, c'est Appliquer UML et motifs par Craig Larman.

Le livre parle de manière approfondie de l'attribution de responsabilités. Par exemple, vous pouvez utiliser le modèle d'expert de l'information, auquel cas l'objet qui a le plus de connaissances des variables impliquées sera celui qui compte la responsabilité d'avoir la méthode.

Tu as raison. Je pense que c'est l'un des principaux problèmes de la plupart des systèmes axés sur les objets d'aujourd'hui: des méthodes semblent naturellement "appartenir à" un objet, mais elles ne le font pas.

systèmes avec Dispatch multiple Évitez bien ce problème. Par exemple, en Dylan, vous pourriez dire quelque chose comme: xxx

(i lié à la page multimethods C2.com parce que je pense que cela fait le moins mauvais travail de décrire cette . Wikipedia a une page pour plusieurs_dispatch, mais son exemple est assez terrible.)

quelle est la meilleure pratique ici ... em> p>

Cela dépend de votre UTILISATION , comment l'utilisateur va-t-il utiliser le système? . Serait-ce un laboratoire «soufflé» par une personne code>? Ou le cas d'utilisation du système consiste à avoir une personne code> exploser labons code>? P>

ou peut-être que cela n'a même pas d'importance: s em> p> BlockQuote>

À la fin du résultat est le même, mais la chose importante ici est la sémantique du code. Si cela sonne bien pour que les laboratoires soient gonflés par des gens, alors ne le faites pas. P>

La règle d'or, alors que Bobturbo mentionne, est de découvrir "l'expert de l'information" (voir: saisir ) dans le système et donnez le contrôle à cet objet. p>

Vous définissez généralement un historique de l'utilisateur ou une narration sur la manière dont le système serait utilisé, si, par exemple, le récit est: P>

quand une personne fait quelque chose que tout le monde dans le laboratoire doit être notifié. em> p> blockQuote>

puis, cela signifie que cela signifie qu'un personne code> fonctionne dans un laboratoire code>, lors de sa création, cette personne peut recevoir le laboratoire qu'il travaille, et s'inscrire à être informé de ce qui se passe dans ce laboratoire de Perticula. p>

Puisque le laboratoire a la liste des personnes à notifier, il est logique d'être le laboratoire qui effectue la notification (la personne donne le contrôle au laboratoire dans ce cas) p>

alors probablement le personne code> pourrait être défini comme suit: P>

 labs.MainApp {
     _ main() {
          blackMesaLab = Lab("BlackMesa")
          gordon = Person( withLab: blackMesaLab, andName: "Gordon Freeman")
          scott  = Person( withLab: blackMesaLab, andName: "Scott Tiger")
          james  = Person( withLab: Lab("SO Labs"), andName:" James Hetfield");

          persons = Array( gordon, scott, james )

          .... 

         while( true ) {
              // every now and then, have someone blowing up it's lab 
              if ( randomNumber() .== 42 ) {
                  person.at( randomPosition ).blowUpLab()
             } 
         }
       }
   } 

OO vous donne une perspective différente de ce sujet: En réalité, vous n'êtes pas intéressé par des personnes ou des laboratoires, mais dans une relation entre eux. Si vous le regardez à partir d'une perspective UML- ou de bases de données, vous verriez que cette relation est très un nouveau concept de votre modèle (mental). Voir @dacris Commentaire ci-dessus également, où il introduit une nouvelle classe.

Si vous utilisez Orm (cartographie relative à un objet), comme lorsque vous feriez lorsque vous le feriez lors de l'ingénierie avec des modèles UML, ces deux méthodes BloWowup () et Blownupby () serait automatiquement généré par code, avec leurs contrôles d'exécution respectifs pour assurer leur cohérence.

Le livre de Larman devrait en effet contenir quelque chose à propos de ce sujet pour vous.