La legge di Demetra contro il concatenamento del metodo: quando usare quale?

3

Dato questo codice dal framework Symfony :

use Symfony\Component\HttpFoundation\Request;

public function indexAction(Request $request)
{
    $request->isXmlHttpRequest(); // is it an Ajax request?

    $request->getPreferredLanguage(array('en', 'fr'));

    // retrieve GET and POST variables respectively
    $request->query->get('page');
    $request->request->get('page');

    // retrieve SERVER variables
    $request->server->get('HTTP_HOST');

    // retrieves an instance of UploadedFile identified by foo
    $request->files->get('foo');

    // retrieve a COOKIE value
    $request->cookies->get('PHPSESSID');

    // retrieve an HTTP request header, with normalized, lowercase keys
    $request->headers->get('host');
    $request->headers->get('content_type');
}

Penso che questo modo di accedere per esempio alle variabili GET e POST sia bello. Si chiama il metodo get () sull'oggetto query che fa parte dell'oggetto richiesta. Penso che il concetto di concatenamento dei metodi sia breve e piacevole. Tuttavia, conosco gli svantaggi di questo accoppiamento stretto. Qui, il mio controller rivendica molta conoscenza sul metodo dell'oggetto query. Cioè, quando l'oggetto query cambia il suo metodo, avrei bisogno di cambiare tutti questi script. Questi inconvenienti si manifestano nella legge di Demetra.

Quindi qual è la domanda? La mia domanda è, quando c'è così tanto descrizione delle "buone pratiche" come mai decidono tali framework popolari come Symfony contro alcune di queste regole. O interpreto male la legge di Demetra? Ho l'impressione che a volte le considerazioni sulla buona pratica di un grado dipendano dalle preferenze personali. Mi sbaglio?

    
posta agoldev 08.01.2018 - 11:47
fonte

2 risposte

5

Innanzitutto, la legge di Demeter non deve essere percepita come regola set-in-stone . La struttura della tua richiesta è soggetta a cambiamenti? Esiste un comportamento aggiuntivo che può essere invocato quando ottenere le proprietà di $request ? Se ottieni "no" a entrambe le risposte, non penso che violare questa "legge" sia una cosa così brutta.

Or do I misinterpret the law of Demeter?

Probabilmente. Per capirlo meglio, penso che non potresti guardare oltre questo .

    
risposta data 08.01.2018 - 13:42
fonte
-1

Non stai interpretando male la Legge di Demetra, il tuo esempio è un buon esempio di ciò che la Legge è contraria.

Non credo che tutto sia una questione di preferenze personali. Credo che architetture / design possano essere confrontati in un determinato contesto. Purtroppo questa è solo la mia opinione a questo punto:)

Alla tua domanda concreta sul perché i framework non prestano molta attenzione al LoD, e questo dalla mia prospettiva Java Enterprise:

  1. Cultura. La nostra cultura di sviluppatori è appena dominata da altri paradigmi al momento. Tutto proveniva dal paradigma "Procedural" ("C", "Pascal", "Basic" e simili). Quindi le persone hanno provato Object-Orientation per un po '(le persone "Smalltalk"), e la sua sintassi è stata aggiunta alle lingue ("Java", "C ++"). Tuttavia non lo facciamo OO. Facciamo ancora progetti basati su componenti, disegni a strati, progettazione strutturata o persino programmazione procedurale. Pertanto, il LoD, che è una legge dell'orientamento agli oggetti, spesso non si applica.

  2. Non vedendo alternative. Ci sono pochissimi progetti che fanno realmente Object-Orientation / Tell non chiedere / LoD. Ci sono solo pochi esempi da cui le persone possono imparare.

Ecco il mio articolo su Law of Demeter . Sono sostanzialmente d'accordo con l'articolo di Yegor, può essere riassunto come: non scrivere getter.

Ps .: Giusto per commentare il tweet "occasionalmente utile suggerimento di Demetra" di Martin Fowler. Di tanto in tanto è utile se fai occasionalmente un orientamento all'oggetto. Se si utilizza Orientamento oggetto, è necessario seguire LoD.

    
risposta data 08.01.2018 - 15:08
fonte

Leggi altre domande sui tag