Architecture Best Practice (MVC): Repository Restituisce oggetto e oggetto Membro accesso diretto o deposito Restituisce oggetto Membro

Question

Architecture Best Practice (MVC): Repository Restituisce oggetto e oggetto Membro accesso diretto o deposito Restituisce oggetto Membro

#1 da (2 voti)
#2 da (1 voti)

2

Architettonicamente parlando, qual è l'approccio preferibile (e perché)?

$validation_date = $users_repository->getUser($user_id)->validation_date;

Sembra violare Law of Demeter accedendo al membro dell'oggetto restituito dalla chiamata al metodo
Sembra violare l'incapsulamento accedendo direttamente al membro dell'oggetto

$validation_date = $users_repository->getUserValidationDate($user_id);

Sembra violare il Principio di Responsabilità Unica in quanto $ users_repository non restituisce più oggetti utente

encapsulation coupling php object-oriented-design single-responsibility

posta coderabbi 12.12.2012 - 06:38

fonte

2 risposte

Leggi altre domande sui tag encapsulation coupling php object-oriented-design single-responsibility

Devo gestire l'autenticazione da solo se l'alternativa è molto bassa nell'usabilità e sto già gestendo i ruoli? Consegna continua TFS

score 2 · Answer 1

Il modo tecnicamente "corretto" per affrontare questo problema è passare l'oggetto User corretto nel metodo (o classe) che richiederà "validation_date". Ove possibile, la dipendenza dall'iniettare l'oggetto esatto richiesto dovrebbe essere sempre favorita per l'iniezione di Repository, ServiceLocators e fabbriche. Il componente richiesto più piccolo deve essere passato al metodo che lo richiede. Il codice nella domanda non ha realmente una dipendenza dal repository ma dall'utente.

Non è una violazione di Law of Demeter perché, come suggerisce la domanda, il codice deve accedere alla data di convalida. È una violazione di Law of Demeter perché il repository viene utilizzato solo come gateway per altri oggetti.

Vedi link per una spiegazione dettagliata del problema e il migliore modo per risolverlo.

score 1 · Answer 2

A volte, scegliere la cosa più intuitiva è la migliore regola empirica.

Molte persone in realtà non sono nemmeno d'accordo con le leggi / regole / principi che hai affermato. Cioè la programmazione funzionale sta chiaramente andando via da OO e cerca di separare i dati dall'elaborazione, penso che nessuno si preoccupi di LoD per cose così banali, e la roba di singola responsabilità, anche se carina, a volte è difficile da ottenere nel mondo reale.

Detto questo, IMHO e questo particolare esempio, trovo la prima alternativa la più diretta e intuitiva.