Classi di denominazione - Come evitare di chiamare tutto un "<WhatEver> Manager"? [chiuso]

Molto tempo fa ho letto un articolo (credo un post di blog) che mi ha messo sulla strada "giusta" per la denominazione degli oggetti: sii molto scrupoloso nel nominare le cose nel tuo programma.

Ad esempio, se la mia applicazione (come una tipica app aziendale) gestisse utenti, aziende e indirizzi, avrei una classe a User, a Companye una di Addressdominio - e probabilmente da qualche parte comparirebbero a UserManager, a CompanyManagere AddressManagera che gestiscono tali cose.

Così si può dire ciò che coloro UserManager, CompanyManagere AddressManagerfare? No, perché Manager è un termine molto generico che si adatta a qualsiasi cosa tu possa fare con i tuoi oggetti di dominio.

L'articolo che ho letto mi ha raccomandato di usare nomi molto specifici. Se si trattasse di un'applicazione C ++ e il UserManagerlavoro fosse quello di allocare e liberare gli utenti dall'heap, non li avrebbe gestiti ma salvaguardati la loro nascita e morte. Hmm, forse potremmo chiamarlo a UserShepherd.

O forse il UserManagercompito è quello di esaminare i dati di ciascun oggetto Utente e firmarli crittograficamente. Quindi avremmo un UserRecordsClerk.

Ora che questa idea mi è rimasta, provo ad applicarla. E trova questa idea semplice incredibilmente difficile.

Posso descrivere cosa fanno le classi e (purché non scivoli nella codifica veloce e sporca) le classi che scrivo fanno esattamente una cosa. Quello che mi manca per passare da quella descrizione ai nomi è una specie di catalogo di nomi, un vocabolario che associa i concetti ai nomi.

Alla fine mi piacerebbe avere qualcosa come un catalogo di modelli nella mia mente (spesso i modelli di progettazione forniscono facilmente i nomi degli oggetti, ad esempio una fabbrica )

• Factory: crea altri oggetti (denominazione presa dal modello di progettazione)
• Pastore - Un pastore gestisce la vita degli oggetti, la loro creazione e spegnimento
• Sincronizzatore: copia i dati tra due o più oggetti (o gerarchie di oggetti)

• Tata: aiuta gli oggetti a raggiungere lo stato "utilizzabile" dopo la creazione, ad esempio collegando altri oggetti

• ecc ecc.

Quindi, come gestite questo problema? Hai un vocabolario fisso, inventi al volo nuovi nomi o pensi di nominare cose non così importanti o sbagliate?

PS: Sono anche interessato a link ad articoli e blog che trattano il problema. Come inizio, ecco l'articolo originale che mi ha fatto riflettere: nominare le classi Java senza un "Manager"

Aggiornamento: riepilogo delle risposte

Ecco un breve riassunto di ciò che ho imparato da questa domanda nel frattempo.

• Cerca di non creare nuove metafore (Tata)
• Dai un'occhiata a cosa fanno gli altri framework

Ulteriori articoli / libri su questo argomento:

• Quali nomi ti trovi ad anteporre / aggiungere regolarmente alle lezioni?
• Qual è l'approccio migliore alle classi di denominazione?
• Libro: Modelli di progettazione: elementi di software riutilizzabile orientato agli oggetti (copertina rigida)
• Libro: Patterns of Enterprise Application Architecture (Hardcover)
• Libro: Implementation Patterns (Paperback)

E un elenco attuale di prefissi / suffissi di nome che ho raccolto (soggettivamente!) Dalle risposte:

• Coordinatore
• Costruttore
• scrittore
• Lettore
• handler
• Contenitore
• Protocollo
• Bersaglio
• Converter
• controllore
• Visualizza
• Fabbrica
• Entità
• Secchio

E un buon consiglio per la strada:

Non ottenere la paralisi dei nomi. Sì, i nomi sono molto importanti ma non sono abbastanza importanti da perdere enormi quantità di tempo. Se non riesci a trovare un buon nome in 10 minuti, vai avanti.

Ho fatto una domanda simile , ma dove possibile provo a copiare i nomi già nel framework .NET e cerco idee nei framework Java e Android .

Sembra Helper, Managere Utilsono i nomi inevitabili che attribuisci per coordinare le classi che non contengono stato e sono generalmente procedurali e statici. Un'alternativa è Coordinator.

Si potrebbe ottenere prosey particolarmente viola con i nomi e andare per le cose come Minder, Overseer, Supervisor, Administrator, e Master, ma come ho detto preferisco tenerlo come i nomi quadro a cui siete abituati.

Alcuni altri suffissi comuni (se questo è il termine corretto) che trovi anche nel framework .NET sono:

• Builder
• Writer
• Reader
• Handler
• Container

Puoi dare un'occhiata a source-code-wordle.de , ho analizzato lì i suffissi più usati dei nomi delle classi del framework .NET e alcune altre librerie.

I primi 20 sono:

• attributo
• genere
• aiutante
• collezione
• convertitore
• gestore
• Informazioni
• fornitore
• eccezione
• servizio
• elemento
• manager
• nodo
• opzione
• fabbrica
• contesto
• articolo
• progettista
• base
• editore

Sono tutto per buoni nomi e scrivo spesso sull'importanza di prestare molta attenzione nella scelta dei nomi per le cose. Per questa stessa ragione, sono diffidente nei confronti delle metafore quando nominerò le cose. Nella domanda originale, "fabbrica" ​​e "sincronizzatore" sembrano buoni nomi per ciò che sembrano significare. Tuttavia, "pastore" e "tata" non lo sono, perché si basano su metafore . Una classe nel tuo codice non può essere letteralmente una tata; la chiami una tata perché si prende cura di altre cose proprio come una tata nella vita reale si prende cura di neonati o bambini. Va bene nel discorso informale, ma non va bene (secondo me) per nominare le classi nel codice che dovranno essere mantenute da chi sa chi sa quando.

Perché? Perché le metafore dipendono dalla cultura e spesso anche dall'individuo. Per te, nominare una "tata" di classe può essere molto chiaro, ma forse non è così chiaro per qualcun altro. Non dovremmo fare affidamento su questo, a meno che tu non stia scrivendo codice che è solo per uso personale.

In ogni caso, la convenzione può creare o distruggere una metafora. L'uso della stessa "fabbrica" ​​si basa su una metafora, ma che esiste da un po 'di tempo ed è attualmente abbastanza conosciuta nel mondo della programmazione, quindi direi che è sicuro da usare. Tuttavia, "tata" e "pastore" sono inaccettabili.

Potremmo fare senza xxxFactory, xxxManagero xxxRepositoryclassi se abbiamo modellato correttamente il mondo reale:

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

;-)

Sembra una pendenza scivolosa verso qualcosa che sarebbe stato pubblicato su thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", ecc.

Suppongo sia giusto che una classe Manager monolitica non sia una buona progettazione, ma l'uso di "Manager" non è male. Invece di UserManager potremmo suddividerlo in UserAccountManager, UserProfileManager, UserSecurityManager, ecc.

'Manager' è una buona parola perché mostra chiaramente che una classe non rappresenta una 'cosa' del mondo reale. "AccountsClerk" - come posso dire se si tratta di una classe che gestisce i dati degli utenti o che rappresenta qualcuno che è un impiegato degli account per il loro lavoro?

Dato che sei interessato ad articoli in quest'area, potresti essere interessato all'articolo d'opinione di Steve Yegge "Esecuzione nel regno dei nomi":

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

Quando mi trovo a pensare di usare Managero Helperin un nome di classe, lo considero un odore di codice che significa che non ho ancora trovato la giusta astrazione e / o sto violando il principio della singola responsabilità , quindi rifattorando e mettendo più impegno nella progettazione spesso rende la denominazione molto più semplice.

Ma anche le classi ben progettate non si nominano (sempre) da sole e le tue scelte dipendono in parte dal fatto che tu stia creando classi di modelli di business o classi di infrastrutture tecniche.

Le classi del modello di business possono essere difficili, perché sono diverse per ogni dominio. Ci sono alcuni termini che uso molto, come Policyper le classi di strategia all'interno di un dominio (ad esempio LateRentalPolicy), ma di solito derivano dal tentativo di creare un " linguaggio onnipresente " che puoi condividere con gli utenti aziendali, progettando e denominando le classi in modo che modellino - idee, oggetti, azioni ed eventi del mondo.

Le classi di infrastruttura tecnica sono un po 'più semplici, perché descrivono domini che conosciamo molto bene. Preferisco incorporare i nomi dei modelli di progettazione nei nomi delle classi, come InsertUserCommand, CustomerRepository,o SapAdapter.capisco la preoccupazione di comunicare l'implementazione anziché l'intento, ma i modelli di progettazione sposano questi due aspetti del design della classe - almeno quando si ha a che fare con l'infrastruttura, dove si desidera il il design dell'implementazione è trasparente anche mentre nascondi i dettagli.

Essere al passo con i motivi definiti dal (diciamo) il libro GOF e nominare gli oggetti dopo questi mi porta molto a nominare i corsi, organizzarli e comunicare l'intento. Molte persone capiranno questa nomenclatura (o almeno una parte importante di essa).

Se non riesco a trovare un nome più concreto per la mia classe rispetto a XyzManager, questo sarebbe un punto per me da riconsiderare se questa è davvero funzionalità che appartiene insieme in una classe, cioè un "odore di codice" architettonico.

Penso che la cosa più importante da tenere a mente sia: il nome è abbastanza descrittivo? Puoi dire guardando il nome che cosa dovrebbe fare la Classe? L'uso di parole come "Manager", "Service" o "Handler" nei nomi delle classi può essere considerato troppo generico, ma poiché molti programmatori le usano, aiuta anche a capire a cosa serve la classe.

Io stesso ho usato molto il modello di facciata (almeno, penso che sia così che si chiama). Potrei avere una Userclasse che descrive un solo utente e una Usersclasse che tiene traccia della mia "raccolta di utenti". Non chiamo la classe a UserManagerperché non mi piacciono i manager nella vita reale e non voglio ricordarmeli :) L'uso del modulo plurale mi aiuta a capire cosa fa la classe.

Specifico per C #, ho trovato "Linee guida per la progettazione di framework: convenzioni, modi di dire e schemi per librerie .NET riutilizzabili" per avere molte buone informazioni sulla logica della denominazione.

Per quanto riguarda la ricerca di quelle parole più specifiche, però, spesso uso un dizionario dei sinonimi e salto tra le parole correlate per cercare di trovarne una buona. Cerco di non spendere troppo tempo con esso, mentre progredisco attraverso lo sviluppo mi vengono in mente nomi migliori, o talvolta mi rendo conto che SuchAndSuchManagerdovrebbero davvero essere suddivisi in più classi, e quindi il nome di quella classe deprecata diventa un problema .

Credo che la cosa fondamentale qui sia di essere coerenti nell'ambito della visibilità del tuo codice, vale a dire fino a quando tutti coloro che hanno bisogno di guardare / lavorare sul tuo codice capiscono la tua convenzione di denominazione, allora dovrebbe andare bene, anche se decidi di chiamarli "CompanyThingamabob" e "UserDoohickey". La prima tappa, se lavori per un'azienda, è vedere se esiste una convenzione aziendale per la denominazione. Se non c'è o non lavori per un'azienda, crea i tuoi termini personali che hanno senso per te, passali in giro con alcuni colleghi / amici fidati che almeno codificano casualmente e incorpora qualsiasi feedback che abbia senso.

Applicare la convenzione di qualcun altro, anche quando è ampiamente accettato, se non ti sfugge di dosso, è un errore nel mio libro. Innanzitutto devo capire il mio codice senza fare riferimento ad altra documentazione ma allo stesso tempo deve essere abbastanza generico da non essere incomprensibile per qualcun altro nello stesso campo dello stesso settore.

Considererei i modelli che stai usando per il tuo sistema, le convenzioni di denominazione / catalogazione / raggruppamento di classi di tende da definire in base al modello usato. Personalmente, mi attengo a queste convenzioni di denominazione in quanto sono il modo più probabile per un'altra persona di essere in grado di raccogliere il mio codice ed eseguirlo.

Ad esempio UserRecordsClerk potrebbe essere meglio spiegato estendendo un'interfaccia RecordsClerk generica che sia UserRecordsClerk che CompanyRecordsClerk implementano e poi si specializzano, il che significa che si possono esaminare i metodi nell'interfaccia per vedere a cosa servono / sono generalmente le sue sottoclassi.

Vedi un libro come Design Patterns per informazioni, è un libro eccellente e potrebbe aiutarti a chiarire dove stai mirando a stare con il tuo codice - se non lo stai già usando! ; o)

Immagino che fino a quando il tuo modello sia ben scelto e usato per quanto è appropriato, allora i nomi delle classi abbastanza semplici e poco inventivi dovrebbero essere sufficienti!