Le classi di denominazione diventano debilitanti [chiuso]

A mio parere, il problema che hai non è solo trovare un modo migliore per trovare un buon nome, ma affrontare la compulsione a farlo. Se sono onesto, riconosco un tratto simile in me stesso. I nomi sono importanti, dopotutto, e mi piace un buon nome per i concetti su cui sto lavorando. Tuttavia, non sono sempre la cosa più importante.

Ecco alcuni dei metodi che uso per superare questo tipo di cose:

1. Riconosci che non esiste una soluzione perfetta, solo soluzioni migliori di altre.
2. Metti le cose per prime. È più importante completare un compito di programmazione piuttosto che farlo perfettamente.
3. Chiedi ad altre persone. Tutti noi abbiamo le nostre aree in cui ci impantaniamo, ma fortunatamente persone diverse imperversano in posti diversi. Forse qualcun altro avrà un buon nome, o ti dirà che non importa davvero.
4. Imposta un limite di tempo. Datti x minuti per fare ciò che ti viene appeso, quindi vai avanti.
5. Promettiti che tornerai più tardi. Tieni un registro delle cose a cui vuoi tornare. Un sacco di questi tipi di problemi diventano più chiari quando li lasci da soli per un po '. O otterrai un nome migliore più tardi, o riconoscerai che non ha importanza.
6. Riconoscere che tra 100 anni, a nessuno interesserà comunque
7. Fai il contrario. Dai un nome davvero brutto a una classe e guarda cosa succede. Ciò confermerà la necessità di dedicare tempo a nomi migliori o mostrerà quanto poco importi davvero. Inoltre, questo ti aiuterà a uscire dalla mentalità ossessiva.
8. Pray. Questo spesso funziona per me.
9. Valorizza te stesso a prescindere da ciò che fai. Allontanati dall'idea che il tuo valore derivi dalla perfezione. Quando riconosciamo di avere un valore intrinseco, al di là del nostro lavoro, ci sentiamo meno vergognosi quando non siamo all'altezza dei nostri standard.
10. Crea nuove parole e usale per nominare le tue classi o semplicemente riutilizzare quelle vecchie. La programmazione è un processo creativo e talvolta le idee che catturiamo sono nuove idee. Le nuove idee hanno bisogno di nuovi nomi. "EmployeeTransmogrifier" è un nome perfettamente valido per una classe.
11. Considera che stai cercando di risolvere il problema sbagliato. Ad esempio, non è una buona idea scrivere un'API senza un'idea molto chiara di quali siano le esigenze del chiamante. Se risolvi questo problema, il tuo problema di denominazione potrebbe essere molto più semplice.
12. Pranzate. Il pranzo è sempre buono.

In primo luogo

Porsi la domanda "qual è lo scopo unico di questa classe?". Senza aderire al principio di responsabilità unica, le classi e i metodi di denominazione diventano molto difficili. Se non è possibile rispondere a questa domanda, potrebbe essere necessario ripensare a ciò che si desidera fare alla classe e considerare la possibilità di separare le preoccupazioni. Questo renderà più facile nominare

In secondo luogo

Hai uno schema per il modo in cui dai il nome alle tue classi? Forse prova a guardare alcuni schemi di denominazione comuni, ad esempio il modello, che diventa molto più facile da seguire una volta che hai affrontato SRP sopra. La tua classe analizza XML? Prova XMLParser. Analizza XML, crea modelli di dominio per rappresentare l'input, li mantiene nel DB e quindi invia un messaggio di successo a Twitter? Prova a refactoring.

In terzo luogo

Capisco da dove vieni, e mi sono già trovato in una situazione simile prima. Forse prova ad arricchire la tua classe con alcune funzionalità, con un nome temporaneo per cominciare. Con qualsiasi buon IDE o refactoring assitant, la rinomina della classe dovrebbe essere un'azione con un clic, quindi inizialmente non è necessario che il nome della classe sia permanente! Ciò ti aiuterà sia a superare il tuo blocco OCD, sia a dare al tuo subconscio il tempo di elaborarlo un po 'oltre.

Finalmente e leggermente fuori tema

Ho avuto un momento lightbulb in un lavoro che stavo facendo l'altro giorno, implementando un sistema non critico, e stavo spendendo un bel po 'di tempo giocando con diversi nomi di classi ecc ... Nome delle tue interfacce in base alla funzionalità , dai un nome alle tue classi in base alla loro specifica implementazione ... Ad esempio, potresti essere tentato di avere IXMLParser e XMLParser, ma cosa succede quando l'input cambia in JSON? Prova invece IInputParser, in questo modo puoi creare classi concrete XMLParser e JSONParser che implementano entrambi IInputParser in modi diversi.

Per me di solito è un segno che il design non è chiaro nella mia mente, quindi ho inventato un nome e mi concedo un tempo (diciamo 2 minuti) per trovare uno migliore, alla fine di quel periodo, Devo usare quello che ho inventato per primo. Barney, Wilma e Fred sono i preferiti per cominciare. Faccio cose come "BarniesInputParser" I nomi sono così cattivi che devo inventarne uno migliore o cambiarli in seguito. Sono anche così cattivi che sono unici, rendendo il refactoring banale e sicuro, e chiunque guardi il codice incompleto può vedere istantaneamente che è incompleto.

L'importante è che mentre non stai aggiungendo funzionalità, non stai dando al tuo cervello alcuna nuova informazione da usare per definire il nome (e chiarire il design). Tutto quello che stai facendo è rigurgitare lo stesso input in modi diversi.

O vai a fare un caffè. Prima di arrivare alla macchina lo avrai ...

L'ho preso da un amico qualche tempo fa. Scrivi cosa dovrebbe fare il tuo processo. Solo una breve narrazione. Quindi prendi i nomi e trasformali in classi, i verbi in metodi e gli avverbi in proprietà.