DoSomethingToThing (Thing n) vs Thing.DoSomething ()

Question

Welche Faktoren bestimmen, welcher Ansatz besser geeignet ist?

Answer 1

Ich denke, beide haben ihre Plätze.

Sie sollten nicht einfach DoSomethingToThing(Thing n) verwenden, nur weil Sie denken, „Funktionale Programmierung ist gut“. Ebenso sollte man einfach nicht Thing.DoSomething() verwenden, da „Objektorientierte Programmierung ist gut“.

Ich denke, es kommt darauf an, was Sie versuchen zu vermitteln. Hören Sie auf Ihren Code als eine Reihe von Anweisungen zu denken und anfangen, über sie wie ein Absatz oder Satz einer Geschichte zu denken. Denken Sie darüber nach, welche Teile sind das wichtigste aus der Sicht der Aufgabe.

Zum Beispiel, wenn der Teil des ‚Satzes‘ Sie das Objekt betonen möchten ist, sollten Sie den OO-Stil verwenden.

Beispiel:

fileHandle.close();

Die meiste Zeit, wenn Sie um Datei-Handles vorbei sind, die Hauptsache, Sie denken, ist die Verfolgung der Datei es darstellt.

Gegenbeispiel:

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

In diesem Fall wird die HTTP-Antrag ist viel wichtiger als die Zeichenfolge, die der Körper ist, so submitHttpRequst(x) vorzuziehen x.submitViaHttp()

Unnötig zu sagen, ist diese nicht gegenseitig aus. Sie werden wahrscheinlich tatsächlich haben

networkConnection.submitHttpRequest(x)

, in dem Sie sie beide mischen. Das Wichtigste ist, dass Sie darüber nachdenken, welche Teile hervorgehoben werden, und was Sie in der Zukunft Leser des Codes werden zu befördern.

Answer 2

Um objektorientiert, sagen, fragen Sie nicht: http: // www.pragmaticprogrammer.com/articles/tell-dont-ask .

Also, Thing.DoSomething () statt DoSomethingToThing (Thing n).

Answer 3

Wenn Sie sich mit internem Zustand einer Sache zu tun, Thing.DoSomething () macht mehr Sinn, denn selbst wenn Sie die interne Darstellung der Sache ändern, oder, wie es funktioniert, wird der Code, um es sprechen muss nicht Veränderung. Wenn Sie mit einer Sammlung von Dingen zu tun haben, oder einige Utility-Methoden schreiben, verfahrens Stil DoSomethingToThing () könnte mehr Sinn machen oder mehr geradlinig; aber immer noch, kann in der Regel als Methode für das Objekt dargestellt werden repräsentiert dass die Sammlung: zum Beispiel

GetTotalPriceofThings();

vs

Cart.getTotal();

Es hängt wirklich davon ab, wie objektorientierten Code ist.

Answer 4

1. Thing.DoSomething ist angebracht, wenn Ding das Thema Ihres Satzes ist.
   • DoSomethingToThing (Thing n) ist geeignet, wenn Ding das Objekt Ihres Satzes ist.
   • ThingA.DoSomethingToThingB (ThingB m) ist eine unvermeidliche Kombination, da in allen Sprachen, die ich denken kann, Funktionen zu einer Klasse gehören und nicht für beide Seiten gehört. Aber das macht Sinn, weil Sie ein Thema und ein Objekt haben können.

Aktive Stimme ist einfacher als passive Stimme, so stellen Sie sicher, dass Ihr Satz hat ein Thema, das nicht nur „der Computer“ ist. Das bedeutet, die Verwendung Form 1 und Form 3 häufig und 2 Anwendungsform selten.

Aus Gründen der Klarheit:

// 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

Ich bin mit Orion, aber ich werde den Entscheidungsprozess neu zu formulieren.

Sie haben ein Substantiv und ein Verb / ein Objekt und eine Aktion aus.

• Wenn viele Objekte dieser Art wird diese Aktion verwenden, versuchen Sie die Aktion Teil des Objekts zu machen.
• Ansonsten versucht die Aktion separat Gruppe, aber mit ähnlichen Aktionen.

Ich mag die Datei / string Beispiele. Es gibt viele String-Operationen, wie zum Beispiel „SendAsHTTPReply“, die für Ihre durchschnittliche Saite wird nicht passieren, aber in einer bestimmten Einstellung oft passieren. Aber im Grunde haben Sie immer eine Datei (hoffentlich) schließen, so macht es durchaus Sinn, die Close-Aktion in der Klasse Schnittstelle zu setzen.

Eine andere Möglichkeit, dies zu denken ist als Teil eines Entertainment-System zu kaufen. Es macht Sinn, eine TV-Fernbedienung mit einem Fernseher zu bündeln, weil man sie immer zusammen verwenden. Aber es wäre seltsam, ein Stromkabel für einen bestimmten Video-Recorder mit TV zu bündeln, da viele Kunden werden nie verwenden. Die Schlüsselidee ist Wie oft wird diese Aktion für dieses Objekt verwendet wird

Answer 6

Nicht annähernd genug Informationen hier. Es hängt davon ab, ob Ihre Sprache auch das Konstrukt „Thing.something“ oder gleichwertig unterstützt (dh. Es ist eine OO-Sprache). Wenn ja, es ist viel besser geeignet, weil das das OO-Paradigma ist (Mitglieder sollen mit dem Ziel, sie wirken auf in Verbindung gebracht werden). In einem prozeduralen Stil, natürlich, DoSomethingtoThing () ist die einzige Wahl ... oder ThingDoSomething ()

Answer 7

DoSomethingToThing (Ding n) würde eher einen funktionalen Ansatz sein, während Thing.DoSomething () würde mehr einen objektorientierten Ansatz wird.

Answer 8

Das ist die objektorientierte gegen prozeduralen Programmierung Wahl:)

Ich denke, die gut dokumentiert OO Vorteile für den Thing.DoSomething apply ()

Answer 9

Dies ist gebeten worden, Design Frage: ist das Telefon das Phone wählen, oder sich die Phone selbst auf dem Telefon wählen

Answer 10

Hier sind ein paar Faktoren zu berücksichtigen:

• Können Sie die Thing Klasse ändern oder erweitern. Wenn nicht, verwenden Sie die ehemalige
• Kann Thing instanziiert werden. Wenn nicht, verwendet die später als statische Methode
• Wenn Thing tatsächlich geändert erhalten (das heißt hat Eigenschaften, die aus), bevorzugen die letztere. Wenn Thing letzteres nicht geändert wird, ist ebenso akzeptabel.
• Andernfalls als Objekte sollen auf reales Objekt abzubilden auf, wählen Sie die Methode, die mehr in der Realität geerdet zu sein scheint.

Answer 11

Auch wenn Sie arbeiten nicht in einer OO-Sprache, wo man würde Thing.DoSomething (), für die allgemeine Lesbarkeit des Codes, mit einer Reihe von Funktionen wie:

ThingDoSomething () ThingDoAnotherTask () ThingWeDoSomethingElse ()

dann

AnotherThingDoSomething ()

und so weiter ist viel besser.

Sie den Code Alles, was auf „Dinge“ ist auf dem einem Standort arbeitet. Natürlich sollte die „DoSomething“ und andere Aufgaben konsequent benannt werden - so haben Sie eine ThingOneRead (), eine ThingTwoRead () ... jetzt sollten Sie Punkt. Wenn Sie gehen zurück in zwölf Monaten auf dem Code zu arbeiten, schätzen Sie die Zeit nehmen, um die Dinge logisch zu machen.

Answer 12

In der Regel, wenn „etwas“ ist eine Aktion, die „Sache“ natürlich weiß, wie zu tun, dann sollten Sie thing.doSomething (verwenden). Das ist gut OO Verkapselung, weil sonst DoSomethingToThing (Ding) würde potenzielle interne Informationen von „Ding“ zugreifen müssen.

Zum Beispiel invoice.getTotal ()

Wenn „etwas“ ist natürlich nicht Teil von „Dinge“ Domain-Modell, dann einer Option ist eine Hilfsmethode zu verwenden.

Zum Beispiel: Logger.log (Rechnung)

Answer 13

Wenn auf ein Objekt DoingSomething ist wahrscheinlich ein anderes Ergebnis in einem anderen Szenario zu erzeugen, dann würde ich Ihnen vorschlagen oneThing.DoSomethingToThing (anotherThing).

Zum Beispiel können Sie zwei retten, was waren in Sie programmieren, so könnten Sie ein DatabaseObject.Save (Ding) annehmen SessionObject.Save (Ding) vorteilhafter wäre als thing.Save () oder thing.SaveToDatabase oder Sache. SaveToSession ().

Ich gehe selten keine Parameter zu einer Klasse, es sei denn, ich bin öffentliche Eigenschaften abgerufen werden.

Answer 14

zu Aeon Antwort hinzuzufügen, hängt es von der der Sache und was Sie wollen, es zu tun. Wenn Sie also Sache schreiben, und DoSomething ändert den internen Zustand der Sache, dann ist der beste Ansatz ist Thing.DoSomething. Wenn jedoch die Aktion mehr tut, als den internen Zustand zu ändern, dann DoSomething (Ding) macht mehr Sinn. Zum Beispiel:

Collection.Add(Thing)

ist besser als

Thing.AddSelfToCollection(Collection)

Und wenn du hast Sache nicht schreiben, und kann eine abgeleitete Klasse nicht schaffen, dann haben Sie keine chocie aber DoSomething (Ding)

zu tun

Answer 15

Auch in der objektorientierten Programmierung kann es sinnvoll sein, anstelle ein Verfahren einen Funktionsaufruf zu verwenden (oder was das betrifft ein Verfahren zur Herstellung eines Objektes andere als der Aufruf nennen wir es auf). Stellen Sie sich einen einfachen Datenbank-Persistenz-Framework, wo Sie gerade mögen rufen speichern () auf einem Objekt. Statt mit einer SQL-Anweisung in jeder Klasse würden Sie gespeichert haben möchten, also Code zu verkomplizieren, SQL ganzen Spreizcode und machen die Speicher-Engine ein PITA zu ändern, können Sie eine Schnittstelle definiert, save (Class1) erstellen, speichern (Class2 ) usw. und deren Umsetzung. Dann würden Sie tatsächlich databaseSaver.save (class1) und haben alles an einem Ort anrufen.

Answer 16

Ich habe vereinbaren mit Kevin Conner

Beachten Sie auch, den Anrufer von einem der zwei Formen. Der Anrufer ist wahrscheinlich eine Methode eines anderen Objekts, das auf jeden Fall etwas zu Ihrer Sache tut:)