In generale è opportuno evitare parole come "handle" o "process" come parte dei nomi di routine e di classe, a meno che non si abbia a che fare con (ad esempio) handle di file o (ad esempio) processi unix. Tuttavia, le classi astratte spesso non sanno veramente cosa faranno con qualcosa oltre a, ad esempio, elaborarlo. Nella mia situazione attuale ho un "EmailProcessor" che accede alla casella di posta in arrivo di un utente ed elabora i messaggi da esso. Non mi è chiaro come dare un nome più preciso, anche se ho notato che la seguente questione di stile si pone:
- meglio trattare le classi derivate come client e denominate la classe base per la parte della funzionalità che implementa? Dà più significato, ma violerà is-a. Per esempio. EmailAcquirer sarebbe un nome ragionevole poiché sta acquisendo per la classe derivata, ma la classe derivata non acquisterà per nessuno.
- O solo un nome davvero vago poiché chissà cosa faranno le classi derivate. Tuttavia "Processore" è ancora troppo generico dal momento che sta eseguendo molte operazioni rilevanti, come l'accesso e l'utilizzo di IMAP.
Qualche via d'uscita da questo dilemma?
Il problema è più evidente per i metodi astratti, in cui non si può realmente rispondere alla domanda "che cosa fa?" perché la risposta è semplicemente "qualunque cosa il cliente desideri".