Le classi di denominazione diventano debilitanti [chiuso]


9

Non sono sicuro che si tratti di un carattere OCD o meno, ma trovo che a volte mi blocco completamente incapace di continuare quello che sto facendo quando nomina un codice (o funzione, spazio dei nomi, ecc.) Che ritengo debba essere usato all'esterno di un determinato progetto. Un'API per esempio. O una libreria di classi di utilità.

Se la denominazione non è esattamente corretta (nella mia mente) non riesco proprio a continuare ... Sono bloccato nel tentativo di trovare il nome giusto. Ho provato a scrivere piccole app che la userebbero per vedere che aspetto avevano i nomi ma che non sembra aiutare ...

So che non dovrebbe importare, ed è contro ogni mentalità di programmazione supporre che lo faresti perfetto per primo ... Mi sento impotente ...

Eventuali suggerimenti / idee sarebbero molto apprezzati ...


3
Dalla mia esperienza, una volta finalizzato il corpo della classe, ricodificato, ecc., Il nome della classe e i metodi iniziano a ricadere al loro posto.
Giobbe

11
Citazione obbligatoria: "Ci sono solo due problemi gravi in ​​Informatica: invalidazione della cache e denominazione delle cose". - Phil Karlton
Macke,

Sensazione familiare. Basta non mollare, non iniziare a nominare le cose "Common", "Utilities", "Managers" e "Helpers". :)
Arnis Lapsa,

Risposte:


10

A mio avviso, il problema che hai non è solo quello di trovare un modo migliore per trovare buoni nomi, ma anche di occuparmi della coazione a farlo. Se sono onesto, riconosco un tratto simile in me stesso. I nomi sono importanti, dopo tutto, e mi piace un buon nome per i concetti a cui sto lavorando. Tuttavia, non sono sempre la cosa più importante.

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

  1. Riconosci che non esiste una soluzione perfetta, solo soluzioni migliori di altre.
  2. Metti le prime cose al primo posto. È più importante completare un compito di programmazione che farlo perfettamente.
  3. Chiedi ad altre persone. Abbiamo tutti le nostre aree in cui impantanarsi, ma fortunatamente persone diverse impantanano in luoghi diversi. Forse qualcun altro troverà un buon nome o ti dirà che davvero non importa.
  4. Imposta un limite di tempo. Concediti x minuti per fare la cosa a cui sei stato bloccato, quindi vai avanti.
  5. Promettiti che tornerai più tardi. Tieni un registro delle cose a cui vuoi tornare. Molti di questi tipi di problemi diventano più chiari quando li lasci in pace per un po '. O ti verrà in mente un nome migliore in seguito, o riconoscerai che davvero non importa.
  6. Riconosci che tra 100 anni nessuno si preoccuperà comunque.
  7. Fare il contrario. Dai a una classe un nome davvero brutto e guarda cosa succede. Ciò confermerà la necessità di dedicare tempo a nomi migliori o mostrerà quanto poco importa davvero. Inoltre, questo ti aiuterà a uscire dalla mentalità ossessiva.
  8. Pregare. Questo spesso funziona per me.
  9. Valorizza te stesso a parte quello che fai. Allontanati dall'idea che il tuo valore deriva dalla fornitura della perfezione. Quando riconosciamo che abbiamo un valore intrinseco, indipendentemente dal nostro lavoro, ci sentiamo meno vergognosi quando non rispettiamo i nostri standard.
  10. Crea nuove parole e usale per dare un nome alle tue lezioni, 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 avere 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. Pranzare. Il pranzo è sempre buono.

4
+1 a pranzo. Molte persone non danno abbastanza valore a pensare a qualcos'altro per risolvere un problema.
unholysampler

Alcuni punti fantastici e ben ponderati ...
davidsleeps,

5

in primo luogo

Ponetevi la domanda "Qual è il solo scopo di questa classe?". Senza aderire al principio di responsabilità singola, la denominazione di classi e metodi diventa molto difficile. Se non riesci a rispondere a questa domanda, potresti dover ripensare a ciò che vuoi che faccia la classe e considerare di separare le preoccupazioni. Ciò renderà più facile nominare

in secondo luogo

Hai un modello per come dai un nome alle tue classi? Forse prova ad esaminare alcuni modelli di denominazione comuni, ad esempio il modello, che diventa molto più facile da seguire dopo aver 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 pubblica un messaggio di successo su Twitter? Prova il refactoring.

In terzo luogo

Capisco da dove vieni e mi sono già trovato in una situazione simile. Forse prova a completare la tua classe con alcune funzionalità, con un nome temporaneo per cominciare. Con qualsiasi IDE valido o assistente di refactoring, rinominare la classe dovrebbe essere un'azione con un clic, quindi ciò che inizialmente nominerai la tua classe non deve essere permanente! Ciò ti aiuterà a superare il blocco OCD e a concedere al tuo subconscio il tempo di elaborarlo un po 'più avanti.


Finalmente e leggermente fuori tema

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


Sì, ho avuto anche questo tipo di momento ... il problema è che sei bravissimo e non puoi mai scrivere il codice desiderato, tre sono sempre un altro schema di astrazione ...
Robin Vessey,

1

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

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

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


spaventosamente, conosco il software spedito che è stato chiamato in quel modo ... immagina di provare a spiegarlo uno dopo 5 anni quando sei l'unico in azienda che sa ancora chi è "Tim".
Yaur,

0

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


Questo è un semplice esercizio di tipo CS101 per insegnare OOAD . Tuttavia, non è all'altezza di qualsiasi sistema reale che non sia ideato da un professore o da un autore di libri di testo.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.