DoSomethingToThing (Thing n) vs Thing.DoSomething ()

Question

Quels facteurs déterminent quelle approche est la plus appropriée?

Answer 1

Je pense que les deux ont leur place.

Vous ne devriez pas simplement utiliser DoSomethingToThing (Thing n) simplement parce que vous pensez que "la programmation fonctionnelle est bonne". De même, vous ne devez pas simplement utiliser Thing.DoSomething () car "la programmation orientée objet est bonne".

Je pense que cela dépend de ce que vous essayez de transmettre. Arrêtez de considérer votre code comme une série d'instructions, et commencez à le penser comme un paragraphe ou une phrase d'un récit. Pensez aux parties les plus importantes du point de vue de la tâche à accomplir.

Par exemple, si la partie de la "phrase" que vous souhaitez souligner est l'objet, vous devez utiliser le style OO.

Exemple:

fileHandle.close();

La plupart du temps, lorsque vous transmettez des descripteurs de fichiers, la principale chose à laquelle vous songez est de garder une trace du fichier qu'il représente.

CounterExample:

string x = "Hello World";
submitHttpRequest( x );

Dans ce cas, l'envoi de la requête HTTP est beaucoup plus important que la chaîne qui constitue le corps. submitHttpRequst (x) est préférable à x.submitViaHttp ()

Il va sans dire que ces activités ne s’excluent pas mutuellement. Vous aurez probablement réellement

networkConnection.submitHttpRequest(x)

dans lequel vous mélangez les deux. L'important est que vous réfléchissiez aux parties sur lesquelles l'accent est mis et à ce que vous allez transmettre au futur lecteur du code.

Answer 2

Pour être orienté objet, ne demandez pas à http: // www.pragmaticprogrammer.com/articles/tell-dont-ask .

Alors, Chose. Quelque chose () plutôt que Do Quelque ChoseToThing (Chose n).

Answer 3

Si vous traitez avec l'état interne d'une chose, Thing.DoSomething () a plus de sens, car même si vous modifiez la représentation interne de Thing, ou son fonctionnement, le code qui en parle ne doit pas nécessairement changement. Si vous avez affaire à une collection d'objets ou si vous écrivez des méthodes utilitaires, DoSomethingToThing () de style procédural pourrait être plus logique ou plus simple; mais néanmoins, peut généralement être représenté comme une méthode sur l'objet représentant cette collection: par exemple

GetTotalPriceofThings();

vs

Cart.getTotal();

Cela dépend vraiment de la manière dont votre code est orienté objet.

Answer 4

1. Thing.DoSomething est approprié si Thing est le sujet de votre phrase.
   • Faire quelque chose de bon (Thing n) est approprié si Thing est l’objet de votre phrase.
   • ThingA.DoSomethingToThingB (ThingB m) est une combinaison incontournable, car dans toutes les langues auxquelles je peux penser, les fonctions appartiennent à une classe et ne sont pas mutuellement propriétaires. Mais cela a du sens car vous pouvez avoir un sujet et un objet.

La voix active est plus directe que la voix passive, assurez-vous donc que votre phrase a un sujet qui n'est pas seulement "l'ordinateur". Cela signifie que vous utilisez fréquemment les formulaires 1 et 3 et que vous utilisez rarement le formulaire 2.

Pour plus de clarté:

// Form 1:  "File handle, close."
fileHandle.close(); 

// Form 2:  "(Computer,) close the file handle."
close(fileHandle);

// Form 3:  "File handle, write the contents of another file handle."
fileHandle.writeContentsOf(anotherFileHandle);

Answer 5

Je suis d'accord avec Orion, mais je vais reformuler le processus de décision.

Vous avez un nom et un verbe / un objet et une action.

• Si de nombreux objets de ce type utilisent cette action, essayez de faire de l'action une partie de l'objet.
• Sinon, essayez de regrouper l'action séparément, mais avec les actions associées.

J'aime les exemples File / string. Il existe de nombreuses opérations sur les chaînes, telles que "SendAsHTTPReply", qui ne se produiront pas pour votre chaîne moyenne, mais qui se produisent souvent dans certains paramètres. Cependant, fondamentalement, vous fermerez toujours un fichier (espérons-le), il est donc parfaitement logique de placer l'action Close dans l'interface de classe.

Une autre façon de voir les choses est d’acheter une partie d’un système de divertissement. Il est judicieux d’associer une télécommande à un téléviseur, car vous les utilisez toujours ensemble. Mais il serait étrange d’assembler un câble d’alimentation pour un magnétoscope spécifique avec un téléviseur, car de nombreux clients ne l’utiliseront jamais. L'idée clé est à quelle fréquence cette action sera-t-elle utilisée sur cet objet ?

Answer 6

Pas assez d’informations ici. Cela dépend si votre langue prend même en charge la construction "Thing.something". ou équivalent (c'est-à-dire que c'est un langage OO). Si c'est le cas, c'est beaucoup plus approprié car c'est le paradigme OO (les membres doivent être associés à l'objet sur lequel ils agissent). Dans un style procédural, bien sûr, DoSomethingtoThing () est votre seul choix ... ou ThingDoSomething ()

Answer 7

DoSomethingToThing (Thing n) serait davantage une approche fonctionnelle que Thing.DoSomething () serait davantage une approche orientée objet.

Answer 8

C’est le choix entre programmation orientée objet et procédure:)

Je pense que les avantages OO bien documentés s’appliquent à la Thing.DoSomething ()

Answer 9

Cette question a été posée Question de conception: le téléphone compose-t-il le numéro de téléphone ou est-il composé lui-même sur le téléphone?

Answer 10

Voici quelques facteurs à prendre en compte:

• Pouvez-vous modifier ou étendre la classe Thing . Sinon, utilisez l'ancien
• Est-ce que Thing peut être instancié. Sinon, utilisez cette dernière comme méthode statique
• Si Thing est réellement modifié (c'est-à-dire que ses propriétés changent), préférez cette dernière. Si Thing n'est pas modifié, cette dernière est tout aussi acceptable.
• Autrement, comme les objets sont censés correspondre à un objet du monde réel, choisissez la méthode qui semble plus ancrée dans la réalité.

Answer 11

Même si vous ne travaillez pas dans un langage OO, où vous auriez Thing.DoSomething (), pour la lisibilité globale de votre code, ayant un ensemble de fonctions telles que:

ChoseDoQuelque Chose () ThingDoAnotherTask () ThingWeDoSomethingElse ()

puis

AnotherThingDoSomething ()

et ainsi de suite est beaucoup mieux.

Tout le code qui fonctionne avec "Thing". est sur le même emplacement. Bien sûr, le " DoSomething " et les autres tâches doivent être nommées de manière cohérente - vous avez donc un ThingOneRead (), un ThingTwoRead () ... vous devriez maintenant avoir un point. Lorsque vous retournerez travailler sur le code dans 12 mois, vous apprécierez de prendre le temps de rendre les choses logiques.

Answer 12

En général, si "quelque chose" est une action qui " chose " Naturellement, vous devez utiliser thing.doSomething (). C'est une bonne encapsulation OO, car sinon DoSomethingToThing (chose) devrait accéder à des informations internes potentielles de la "chose".

Par exemple invoice.getTotal ()

Si "quelque chose" ne fait pas naturellement partie de " chose de " modèle de domaine, une option consiste à utiliser une méthode d'assistance.

Par exemple: Logger.log (facture)

Answer 13

Si Faire quelque chose avec un objet est susceptible de produire un résultat différent dans un autre scénario, je vous suggère alors oneThing.DoSomethingToThing (anotherThing).

Par exemple, vous pouvez enregistrer deux éléments dans votre programme, vous pouvez donc adopter un objet DatabaseObject.Save (chose) SessionObject.Save (chose) serait plus avantageux que chose.Save () ou chose.SaveToDatabase. SaveToSession ().

Je ne passe rarement aucun paramètre à une classe, sauf si je récupère des propriétés publiques.

Answer 14

Pour ajouter à la réponse d’Aeon, cela dépend de la chose et de ce que vous voulez y faire. Donc, si vous écrivez Thing et que DoSomething modifie l'état interne de Thing, la meilleure approche est alors Thing.DoSomething. Toutefois, si l'action ne se limite pas à modifier l'état interne, DoSomething (Thing) a alors plus de sens. Par exemple:

Collection.Add(Thing)

est meilleur que

Thing.AddSelfToCollection(Collection)

Et si vous n'avez pas écrit Chose et que vous ne pouvez pas créer de classe dérivée, vous n'avez pas d'autre choix que de faire DoSomething (Thing)

Answer 15

Même en programmation orientée objet, il peut être utile d’utiliser un appel de fonction au lieu d’une méthode (ou d’appeler une méthode d’un objet autre que celui sur lequel on l’appelle). Imaginez un cadre de persistance de base de données simple dans lequel vous voudriez simplement appeler save () sur un objet. Au lieu d'inclure une instruction SQL dans chaque classe que vous souhaitez enregistrer, ce qui compliquerait le code, répartirait tout le code SQL et transformerait le moteur de stockage en PITA, vous pourriez créer une interface définissant save (Class1), save (Class2). ) etc. et sa mise en œuvre. Ensuite, vous appelez en fait databaseSaver.save (class1) et tout est réuni au même endroit.

Answer 16

Je suis d'accord avec Kevin Conner

N'oubliez pas non plus l'appelant de l'un ou l'autre des 2 formulaires. L'appelant est probablement une méthode d'un autre objet qui fait certainement quelque chose à votre chose:)