Recentemente mi sono accorto di implementare pattern simili a quello descritto di seguito. A partire dall'interfaccia:
public interface IUserProvider
{
User GetUser(UserData data);
}
Il puro lavoro del metodo% p_de% è in qualche modo il ritorno dell'utente (che sarebbe un'operazione che parla in termini compositi). Potrebbero esserci molte implementazioni di GetUser , che fanno tutte la stessa cosa: restituire l'utente basandosi sui dati di input. Non ha molta importanza, poiché sono solo lascia in termini compositi ed è abbastanza semplice.
Ora, le mie foglie sono utilizzate da una classe composita proprietaria di tutti loro , che al momento segue questa implementazione:
public interface IUserProviderComposite : IUserProvider
{
void RegisterProvider(Predicate<UserData> predicate, IUserProvider provider);
}
public class UserProviderComposite : IUserProviderComposite
{
public User GetUser(SomeUserData data) ...
public void RegisterProvider(Predicate<UserData> predicate, IUserProvider provider) ...
}
L'idea alla base di IUserProvider è semplice. Si registrano i provider e questa classe agisce come un punto di ingresso riutilizzabile. Quando si chiama UserProviderComposite , userà qualunque fornitore registrato corrisponde predicato per i dati utente richiesti (se questo aiuta, memorizza il valore-chiave della mappa di predicati e fornitori internamente).
Ora, ciò che mi confonde è se il metodo GetUser (che richiama l'operazione add del composito) dovrebbe essere una parte di quella classe. Aumenta le sue responsabilità dal fornire all'utente anche alla gestione della raccolta dei fornitori. Per quanto riguarda la mia comprensione, questo viola il Principio di Responsabilità Unica ... o ho sbagliato qui?
Ho pensato di estrarre la parte del registro in un'entità separata e di iniettarla nel composito. Finché sembra decente sulla carta (in termini di SRP), si sente un po 'imbarazzante perché:
- Sarei essenzialmente inietto Dizionario (o altra mappa valore-chiave)
- ... o un involucro stupido attorno ad esso, facendo nient'altro che aggiungere elementi
- Questo non seguirà più il composito (dato che add non farà parte del composito)
Che cos'è esattamente il modello presentato? Il composito sembrava naturale confrontarlo, ma mi rendo conto che non è esattamente quello, ma nient'altro suona le campane. Quale approccio prenderesti: attenersi a SRP o attenersi a "composite" / pattern? O il design qui è difettoso e considerato il problema, questo può essere fatto in un modo migliore?