La firma del metodo non è solo il suo nome, ma anche il tipo di ritorno, gli argomenti, i parametri generici, ecc. Nel tuo caso, sembra che i nomi, per la maggior parte, ripetano ciò che è già specificato dal argomenti.
Se il tuo linguaggio di programmazione supporta l'overloading, puoi finire con qualcosa di simile:
-
DealRepository.GetAll(DateRange range, int userLimit, int quota)
-
DealRepository.GetAll(Category category, DateRange range, User user, int quota)
-
DealRepository.GetAll(SubCategory sub, DateRange range, User user, int quota)
-
DealRepository.GetSubCategories(DateRange range, User user, int quota)
Forzando il chiamante a specificare l'intervallo, si mostra che i valori restituiti rientrano nell'intervallo (altrimenti, il metodo non avrebbe alcun senso). Lo stesso vale per il limite utente e la quota.
Se la tua lingua ha anche parametri opzionali, puoi ridurre ancora di più il numero di metodi:
-
DealRepository.GetAll(DateRange range, int userLimit, int quota, Category category: null)
-
DealRepository.GetAll(SubCategory sub, DateRange range, int userLimit, int quota)
-
DealRepository.GetSubCategories(DateRange range, int userLimit, int quota)
e quindi, rendendo Category
e SubCategory
ereditati dalla stessa abstract classe Grouping
, puoi refactoring su:
-
DealRepository.GetAll(DateRange range, int userLimit, int quota, Grouping grouping: null)
-
DealRepository.GetSubCategories(DateRange range, int userLimit, int quota)
Che cosa è successo con Unique
?
Usando il principio del minimo stupore, puoi davvero, come nel mio esempio qui sotto, omettere Unique
dal nome. In altre parole:
-
Se l'utente si aspetta, chiamando GetSubCategories
, per ricevere solo valori distinti, non aggiungere Unique
al nome del metodo.
-
Se l'utente presuppone che il metodo possa produrre valori duplicati, allora è preferibile GetUniqueSubCategories
per mostrare che i valori sono necessariamente univoci. Oppure puoi cambiare la firma del metodo per restituire un tipo che corrisponde a una sequenza contenente solo valori distinti.
GetSubCategories
appartiene davvero qui?
Se GetAll
restituisce una sequenza digitata (come DealsCollection
), puoi spostare GetSubCategories
in questa classe. Invece di fare:
new DealRepository().GetSubCategories(...)
il chiamante preferisce fare:
new DealRepository().GetAll(...).GetSubCategories()
Alcune note ...
A parte il fatto che WithinValidRangeStartDateEndDateUserLimitAndQuota
non ha posto nel nome del metodo, ci sono anche alcuni problemi:
-
WithinValidRange
: perché non semplicemente WithinRange
? Avrebbe senso che un chiamante interroghi le offerte in un intervallo non valido ?
-
StartDateEndDate
: non dovresti farlo neanche a livello di oggetto. Non è Date start, Date end
. È un intervallo di date. Quindi crea una classe DateRange
.
-
All
sembra sbagliato. Attualmente, il chiamante non recupera tutte le offerte , ma solo le offerte che corrispondono ai filtri specificati.
-
A seconda della comunità che usa la lingua, può essere accettabile rimuovere il prefisso Get
, che porta a DealRepository.All(...)
e DealsCollection.SubCategories()
.
-
Se sei in grado di utilizzare il pattern iteratore, il metodo diventa:
DealRepository.GetAll()
senza argomenti. È usato in questo modo:
DealRepository
.GetAll()
.Where(d => range.Contains(d.date) && d.user == user)
.Take(quota)