Frage Naming Classes - Wie vermeidet man, alles als " Manager" zu bezeichnen? [geschlossen]


Vor langer Zeit habe ich einen Artikel gelesen (ich glaube einen Blog-Eintrag), der mich auf die "richtige" Spur bei der Benennung von Objekten gebracht hat: Seien Sie sehr gewissenhaft bei der Namensgebung in Ihrem Programm.

Zum Beispiel, wenn meine Anwendung (als eine typische Business-App) mit Benutzern, Firmen und Adressen umgehen würde, hätte ich eine User, ein Company und ein Address Domain-Klasse - und wahrscheinlich irgendwo a UserManager, ein CompanyManager und ein AddressManager würde auftauchen, die diese Dinge behandelt.

Also kannst du was sagen UserManager, CompanyManager und AddressManager machen? Nein, denn Manager ist ein sehr allgemeiner Begriff, der zu allem passt, was Sie mit Ihren Domänenobjekten tun können.

Der Artikel, den ich gelesen habe, wurde mit sehr spezifischen Namen empfohlen. Wenn es eine C ++ - Anwendung war und die UserManagerDer Job war das Zuweisen und Freigeben von Benutzern von dem Heap, der die Benutzer nicht verwalten würde, aber ihre Geburt und ihren Tod bewachen würde. Hmm, vielleicht könnten wir das a nennen UserShepherd.

Oder vielleicht die UserManagerAufgabe ist es, die Daten jedes Benutzerobjekts zu untersuchen und die Daten kryptografisch zu signieren. Dann hätten wir eine UserRecordsClerk.

Jetzt, wo diese Idee bei mir bleibt, versuche ich sie anzuwenden. Und finde diese einfache Idee erstaunlich schwer.

Ich kann beschreiben, was die Klassen tun und (solange ich nicht in die schnelle & schmutzige Codierung eindringe), die Klassen, die ich schreibe, tun genau ein Ding. Was ich vermisse, von dieser Beschreibung zu den Namen zu gelangen, ist eine Art Katalog von Namen, ein Vokabular, das die Begriffe Namen zuordnet.

Letztendlich möchte ich etwas wie einen Musterkatalog in meinem Kopf haben (häufig stellen Entwurfsmuster leicht die Objektnamen bereit, z Fabrik)

  • Factory - Erzeugt andere Objekte (Benennung aus dem Designmuster)
  • Hirte - Ein Hirte kümmert sich um die Lebensdauer von Objekten, ihre Erstellung und Stilllegung
  • Synchronizer - Kopiert Daten zwischen zwei oder mehr Objekten (oder Objekthierarchien)
  • Nanny - Hilft Objekten, nach der Erstellung einen "nutzbaren" Zustand zu erreichen - zum Beispiel durch Verkabeln mit anderen Objekten

  • usw. usw.

Also, wie gehst du mit diesem Problem um? Hast du ein festes Vokabular, erfindest du neue Namen im laufenden Betrieb oder erwägst du, Dinge nicht so wichtig oder falsch zu benennen?

PS .: Ich bin auch an Links zu Artikeln und Blogs interessiert, die das Thema diskutieren. Als erstes hier ist der Originalartikel, der mich darüber nachdenken ließ: Java-Klassen ohne 'Manager' benennen


Update: Zusammenfassung der Antworten

Hier ist eine kleine Zusammenfassung dessen, was ich in der Zwischenzeit von dieser Frage gelernt habe.

  • Versuche, keine neuen Metaphern zu kreieren (Nanny)
  • Sehen Sie sich an, was andere Frameworks tun

Weitere Artikel / Bücher zu diesem Thema:

Und eine aktuelle Liste von Namenspräfixen / Suffixen, die ich (subjektiv!) Aus den Antworten gesammelt habe:

  • Koordinator
  • Erbauer
  • Schriftsteller
  • Leser
  • Handler
  • Container
  • Protokoll
  • Ziel
  • Konverter
  • Regler
  • Aussicht
  • Fabrik
  • Entität
  • Eimer

Und ein guter Tipp für die Straße:

Benenne nicht Lähmung. Ja, Namen sind sehr wichtig, aber sie sind nicht wichtig genug, um viel Zeit zu verschwenden. Wenn Sie in 10 Minuten keinen guten Namen finden, machen Sie weiter.


934
2017-12-08 13:26


Ursprung


Antworten:


Ich fragte ein ähnliche Frage, aber wo es möglich ist, versuche ich, die Namen bereits im .NET Framework zu kopieren, und suche nach Ideen in den Java und Android Frameworks.

Es scheint Helper, Manager, und Util sind die unvermeidlichen Substantive, die Sie für die Koordination von Klassen verwenden, die keinen Status enthalten und in der Regel prozedural und statisch sind. Eine Alternative ist Coordinator.

Sie könnten besonders lila Prosa mit den Namen und für Dinge wie gehen Minder, Overseer, Supervisor, Administrator, und Master, aber wie gesagt, ich ziehe es vor, es wie die Framework-Namen zu behalten, die Sie verwenden.

Einige andere gebräuchliche Suffixe (wenn das der richtige Begriff ist) finden Sie auch im .NET Framework:

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

153
2017-12-08 12:59



Sie können einen Blick darauf werfen source-code-wordle.deIch habe dort die am häufigsten verwendeten Suffixe von Klassennamen des .NET Framework und einiger anderer Bibliotheken analysiert.

Die Top 20 sind:

  • Attribut
  • Art
  • Helfer
  • Sammlung
  • Konverter
  • Handler
  • Info
  • Anbieter
  • Ausnahme
  • Bedienung
  • Element
  • Manager
  • Knoten
  • Möglichkeit
  • Fabrik
  • Kontext
  • Artikel
  • Designer
  • Base
  • Editor

88
2017-12-08 13:13



Ich bin alles für gute Namen, und ich schreibe oft darüber, wie wichtig es ist, bei der Auswahl von Namen für Dinge große Sorgfalt walten zu lassen. Aus genau diesem Grund bin ich vorsichtig bei Metaphern, wenn ich Dinge nenne. In der ursprünglichen Frage sehen "Fabrik" und "Synchronizer" wie gute Namen für das aus, was sie zu bedeuten scheinen. "Hirte" und "Kindermädchen" sind jedoch nicht, weil sie darauf basieren Metaphern. Eine Klasse in Ihrem Code kann nicht sein buchstäblich ein Kindermädchen; Du nennst es ein Kindermädchen, weil es sich um ein paar andere Dinge kümmert, so wie eine echte Kinderfrau sich um Babys oder Kinder kümmert. Das ist OK in der informellen Rede, aber nicht OK (für meine Meinung) für das Benennen von Klassen im Code, der von wem weiß wer weiß wer wann gehalten werden muss.

Warum? Weil Metaphern kulturabhängig und oft auch individuell abhängig sind. Für Sie kann die Benennung einer Klasse "Kindermädchen" sehr klar sein, aber vielleicht ist es für jemand anderen nicht so klar. Wir sollten uns nicht darauf verlassen, es sei denn, Sie schreiben Code, der nur für den persönlichen Gebrauch bestimmt ist.

In jedem Fall kann Konvention eine Metapher machen oder brechen. Die Verwendung von "Factory" selbst basiert auf einer Metapher, die aber schon eine ganze Weile existiert und derzeit in der Programmierwelt ziemlich gut bekannt ist, also würde ich sagen, dass es sicher ist. "Kindermädchen" und "Hirte" sind jedoch nicht akzeptabel.


50
2017-12-08 13:18



Wir könnten auf nichts verzichten xxxFactory, xxxManager oder xxxRepository Klassen, wenn wir die reale Welt korrekt modelliert haben:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)


39
2017-12-08 13:02



Es klingt wie ein rutschiger Abhang zu etwas, das auf thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", usw. veröffentlicht werden würde.

Ich nehme an, es ist richtig, dass eine monolithische Manager-Klasse kein gutes Design ist, aber die Verwendung von "Manager" ist nicht schlecht. Anstelle von UserManager können wir sie in UserAccountManager, UserProfileManager, UserSecurityManager usw. zerlegen.

"Manager" ist ein gutes Wort, weil es deutlich zeigt, dass eine Klasse kein wirkliches "Ding" darstellt. 'AccountsClerk' - wie soll ich sagen, ob das eine Klasse ist, die Benutzerdaten verwaltet, oder eine Person repräsentiert, die für ihren Job ein Account-Clerk ist?


31
2017-12-08 13:12



Da Sie sich für Artikel in diesem Bereich interessieren, interessiert Sie vielleicht Steve Yegges Meinungsartikel "Hinrichtung im Königreich der Substantive":

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


19



Wenn ich über den Gebrauch nachdenke Manager oder Helper In einem Klassennamen halte ich es für einen Code - Geruch, was bedeutet, dass ich noch nicht die richtige Abstraktion gefunden habe und / oder ich die Grundsatz der einheitlichen VerantwortungRefactoring und mehr Designaufwand machen die Benennung oft einfacher.

Aber selbst gut gestaltete Klassen benennen sich (immer) nicht selbst, und Ihre Auswahl hängt teilweise davon ab, ob Sie Geschäftsmodellklassen oder technische Infrastrukturklassen erstellen.

Business Model-Klassen können schwierig sein, da sie für jede Domain unterschiedlich sind. Es gibt einige Begriffe, die ich oft benutze, wie Policy für Strategieklassen innerhalb einer Domäne (z.B. LateRentalPolicy), aber diese fließen normalerweise vom Versuch, ein "ubiquitäre Sprache"Sie können sie mit Geschäftsanwendern teilen, Klassen entwerfen und benennen, sodass sie reale Ideen, Objekte, Aktionen und Ereignisse modellieren.

Technische Infrastrukturklassen sind etwas einfacher, weil sie Domänen beschreiben, die wir wirklich gut kennen. Ich bevorzuge es, Musternamen in die Klassennamen einzubauen, wie InsertUserCommand,  CustomerRepository, oder SapAdapter. Ich verstehe die Sorge um die Kommunikation von Implementierung anstelle von Absicht, aber Design-Patterns vereinen diese beiden Aspekte des Klassen-Designs - zumindest wenn es um Infrastruktur geht, wo Sie die Implementierung wünschen Design transparent sein, auch wenn Sie die Details verstecken.


16