Wie benenne ich fabrikähnliche Methoden?


145

Ich denke, dass die meisten fabrikähnlichen Methoden damit beginnen create. Aber warum heißen sie " schaffen "? Warum nicht " machen ", " produzieren ", " bauen ", " generieren " oder etwas anderes? Ist es nur Geschmackssache? Eine Konvention? Oder hat "erstellen" eine besondere Bedeutung?

createURI(...) 
makeURI(...)
produceURI(...)
buildURI(...)
generateURI(...)

Welches würdest du generell wählen und warum?


4
Ich habe einmal an einem Projekt gearbeitet, das die Factory-Methoden "get ()" nennt. Anfangs sehr verwirrend.
Muxecoid

4
Und die letzte Option, wie wäre es ohne Präfix? Sollte es nicht klar sein, da wir fast immer Fabriken aus einem statischen Kontext verwenden? Ich bitte nur darum, eine Diskussion anzuregen - meine persönliche Präferenz ist createXyz().
Wikingersteve

@vikingsteve In einem von mir erstellten System habe ich das createPräfix aus Gründen der API- Konsistenz als Konvention verwendet und auch, weil nur das Eingeben des Buchstabens cdazu führen würde, dass alle in der automatischen Vervollständigung der IDE angezeigt werden, was es einfacher machen würde für jemanden, der versucht zu erfahren, was verfügbar ist. Ich hätte hatte Matrix4f.identity(), Matrix4f.transpose()etc. , aber sie würde schneller sein als zu finden Matrix4f.createIdentity()und Matrix4f.createTranspose(...)etc.
code_dredd

Antworten:


117

Einige zufällige Gedanken:

  • 'Erstellen' passt besser zu der Funktion als die meisten anderen Wörter. Das nächstbeste Wort, das mir auf den ersten Blick einfällt, ist "Konstruieren". In der Vergangenheit wurde 'Alloc' (Allocate) möglicherweise in ähnlichen Situationen verwendet, was die stärkere Betonung von Datenblöcken als von Objekten in Sprachen wie C widerspiegelt.

  • 'Erstellen' ist ein kurzes, einfaches Wort, das eine klare intuitive Bedeutung hat. In den meisten Fällen wählen die Leute es wahrscheinlich nur als das erste, offensichtlichste Wort, das ihnen einfällt, wenn sie etwas erschaffen möchten. Es ist eine übliche Namenskonvention, und "Objekterstellung" ist eine übliche Art, den Prozess des ... Erstellens von Objekten zu beschreiben.

  • 'Konstruieren' ist nah, wird aber normalerweise verwendet, um eine bestimmte Phase beim Erstellen eines Objekts zu beschreiben (Zuweisen / Neu, Konstruieren, Initialisieren ...).

  • 'Build' und 'Make' sind gebräuchliche Begriffe für Prozesse, die sich auf das Kompilieren von Code beziehen. Daher haben Programmierer unterschiedliche Konnotationen, was einen Prozess impliziert, der viele Schritte und möglicherweise viel Festplattenaktivität umfasst. Die Idee, dass eine Fabrik etwas "baut", ist jedoch eine vernünftige Idee - insbesondere in Fällen, in denen eine komplexe Datenstruktur aufgebaut wird oder viele separate Informationen auf irgendeine Weise kombiniert werden.

  • 'Generieren' impliziert für mich eine Berechnung, die verwendet wird, um einen Wert aus einer Eingabe zu erzeugen, z. B. das Generieren eines Hash-Codes oder einer Zufallszahl.

  • 'Produzieren', 'Generieren', 'Konstruieren' sind länger zu tippen / zu lesen als 'Erstellen'. In der Vergangenheit haben Programmierer Kurznamen bevorzugt, um das Tippen / Lesen zu reduzieren.


5
Daumen hoch für "Create"
Pimbrouwers

103

Joshua Bloch schlägt in "Effective Java" die folgenden Namenskonventionen vor

valueOf - Gibt eine Instanz zurück, die im Großen und Ganzen denselben Wert wie ihre Parameter hat. Solche statischen Fabriken sind effektiv Typkonvertierungsmethoden.

of - Eine prägnante Alternative zu valueOf, populär gemacht durch EnumSet(Punkt 32).

getInstance - Gibt eine Instanz zurück, die durch die Parameter beschrieben wird, von der jedoch nicht gesagt werden kann, dass sie denselben Wert hat. Im Fall eines Singletons werden getInstancekeine Parameter verwendet und die einzige Instanz zurückgegeben.

newInstance - Like getInstance, mit der Ausnahme, dass newInstancegarantiert wird, dass sich jede zurückgegebene Instanz von allen anderen unterscheidet.

get Type - Like getInstance, wird jedoch verwendet, wenn sich die Factory-Methode in einer anderen Klasse befindet. Typ gibt den Objekttyp an, der von der Factory-Methode zurückgegeben wird.

new Type - Like newInstance, wird jedoch verwendet, wenn sich die Factory-Methode in einer anderen Klasse befindet. Typ gibt den Objekttyp an, der von der Factory-Methode zurückgegeben wird.


Wie würden Sie bewerten from? ZB eine hypothetische Id.of("abc")vs nehmen Id.from("xyz")... oder würde frommehr Logik vorschlagen (dh Parsen der Eingabe, Nachschlagen / Korrelieren von / mit anderen Daten, ...)? Es ist wirklich schwierig, nach "of vs from" zu suchen: D
knittl

22

Wollte ein paar Punkte hinzufügen, die ich in anderen Antworten nicht sehe.

  1. Obwohl "Fabrik" traditionell "Objekte erstellen" bedeutet, stelle ich es mir gerne allgemeiner vor als "gibt mir ein Objekt zurück, das sich so verhält, wie ich es erwartet habe". Ich sollte nicht immer wissen müssen, ob es sich um ein brandneues Objekt handelt , eigentlich ist es mir vielleicht egal. In geeigneten Fällen können Sie den Namen "Erstellen ..." vermeiden, auch wenn Sie ihn gerade so implementieren.

  2. Guave ist eine gute Sammlung von Ideen für Fabriknamen. Es macht einen schönen DSL-Stil populär. Beispiele:

    Lists.newArrayListWithCapacity(100);
    ImmutableList.of("Hello", "World");
    

1
Sie haben Recht, Guava ist eine großartige Bibliothek mit sehr lesbarem Code.
Deamon

11

"Create" und "make" sind kurz, einigermaßen anregend und nicht an andere Muster bei der Benennung gebunden, die mir einfallen. Ich habe beide auch ziemlich häufig gesehen und vermute, dass sie "De-facto-Standards" sind. Ich würde eine auswählen und sie zumindest innerhalb eines Projekts konsequent verwenden. (Wenn ich mir mein aktuelles Projekt anschaue, scheine ich "make" zu verwenden. Ich hoffe, ich bin konsequent ...)

Vermeiden Sie "Build", da es besser zum Builder-Muster passt, und vermeiden Sie "Produce", da es Producer / Consumer hervorruft.

Um die Metapher des Namens "Factory" für das Muster wirklich fortzusetzen, würde mich "Manufacturing" in Versuchung führen, aber das ist ein zu langes Wort.


3

Ich denke, es ergibt sich aus " ein Objekt erstellen ". Im Englischen wird das Wort „erschaffen“ jedoch mit dem Begriff „entstehen lassen, als etwas Einzigartiges, das sich nicht auf natürliche Weise entwickeln würde oder das nicht durch gewöhnliche Prozesse hergestellt wird“ und „sich aus dem eigenen Gedanken oder dem eigenen Gedanken entwickeln“ Phantasie als Kunstwerk oder Erfindung. “ Es scheint also, dass „erstellen“ nicht das richtige Wort ist. "Machen" bedeutet andererseits "durch Formen oder Ändern von Material, Kombinieren von Teilen usw." entstehen. Zum Beispiel müssen Sie nicht erstellen Sie ein Kleid, Sie machen ein Kleid (Objekt). Also, meiner Meinung nach, "machen" mit der Bedeutung "produzieren"; Ursache zu existieren oder zu geschehen; herbeiführen “ist ein weitaus besseres Wort für Fabrikmethoden.


3

Ich mag neu. Mir

var foo = newFoo();

liest sich besser als

var foo = createFoo();

Übersetzt ins Englische haben wir foo ist ein neues foo oder foo ist foo erstellen. Obwohl ich kein Grammer-Experte bin, bin ich mir ziemlich sicher, dass Letzteres grammatikalisch falsch ist.


Sie arbeiten beide. createFooist eine Funktion. fooist nicht createFoo, wie du sagst. fooist ein Ergebnis von createFoo().
Krzysztof Czelusniak

2

Teilweise Konvention, teils Semantik.

Factory-Methoden (vom Traditionellen signalisiert create) sollten geeignete Konstruktoren aufrufen. Wenn ich das sehen würde buildURI, würde ich davon ausgehen, dass es sich um eine Berechnung oder Montage aus Teilen handelt (und ich würde nicht glauben, dass es sich um eine Fabrik handelt). Das erste, was ich dachte, als ich es sah, war generateURI, etwas Zufälliges zu machen, wie einen neuen personalisierten Download-Link. Sie sind nicht alle gleich, verschiedene Wörter rufen unterschiedliche Bedeutungen hervor; aber die meisten von ihnen sind nicht konventionell.


1

Ich würde es nennen UriFactory.Create()

Wo,

UriFactoryist der Name des Klassentyps, der Methode (n) zum Erstellen von UriInstanzen bereitstellt .

und die Create()Methode ist für so viele Variationen überladen, wie Sie in Ihren Spezifikationen haben.

public static class UriFactory
{
    //Default Creator
    public static UriType Create() 
    {
    }

    //An overload for Create()
    public static UriType Create(someArgs) 
    {
    }
}

1
Obwohl ich Ihrer Benennung zustimme, stimme ich Ihrer Konvention zur Verwendung von Methodennamen mit Pascal-Gehäuse nicht zu.
Chatatata

2
@Leviathlon es kommt immer auf die Programmiersprache und interne Konventionen an. Pascal Case ist völlig in Ordnung für Sprachen wie C #.
Momo

@momo Genau, ich glaube, ich hatte die Annahme, dass die Sprache, über die gesprochen wird, Java ist.
Chatatata

0

Ich möchte darauf hinweisen, dass ich alle Verben gesehen habe, aber in der einen oder anderen Bibliothek verwendet habe, also würde ich create nicht als universelle Konvention bezeichnen.

Jetzt klingt create für mich besser und ruft die genaue Bedeutung der Aktion hervor.

Also ja, es ist eine Frage des (literarischen) Geschmacks.


0

Persönlich mag ich instantiateund instantiateWith, aber das liegt nur an meinen Erfahrungen mit Unity und Objective C. Namenskonventionen innerhalb der Unity-Engine scheinen sich um das Wort zu drehen instantiate, um eine Instanz über eine Factory-Methode zu erstellen, und Objective C scheint dies zu mögenwith anzugeben, was die Parameter sind. Dies funktioniert nur dann wirklich gut, wenn sich die Methode in der Klasse befindet, die instanziiert werden soll (und in Sprachen, die das Überladen von Konstruktoren ermöglichen, ist dies nicht so sehr eine 'Sache').

Nur alte Objective C's initWithsind auch eine gute Sache!


-3

Die Factory-Methode bestimmt nicht den Methodennamen. Sie können so viele Methoden in Ihrer Fabrik haben, wie Sie möchten, vorausgesetzt, alle geben das Objekt aus derselben Familie zurück.

Weitere Informationen finden Sie unter der URL http://xeon2k.wordpress.com


4
Link macht keinen Sinn, sollte genauer sein.
Brunsgaard
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.