Si tratta di un esempio di 'over engineered' o una buona pratica?

6

Il codice che ho ereditato ha un design che non conosco (sono ancora nuovo nel mondo della programmazione).

È un progetto .net e ci sono 3 classi in questione qui.

public Class1
{
    public void DoSomething()
    {
        Class2 class2 = new Class2();
        string myValue = class2.GetSomeValuePlease();

       //why would I not do class2.MyClass3.GetActualValue();
    }
}

public Class2
{
    public Class3 MyClass3 = new Class3();
    public string GetSomeValuePlease()
    {
        return this.MyClass3.TheActualValue();
    }
}

public Class3
{
    public string TheActualValue()
    {
        return "This is the value";
    }
}

Come puoi vedere, tutte e 3 le classi sono pubbliche. Non capisco perché, usando l'esempio sopra, vorrei usare Class2? Potrei capire se all'interno del metodo GetSomeValuePlease() ci fosse qualche logica che ha influenzato Class2, ma non c'è.

Normalmente, andrei avanti e rimuovere il metodo Class2 (GetSomeValuePlease) e chiamare il metodo Class3 (GetActualValue) direttamente da Class1, ma lo sviluppatore che ho assunto (che non è contattabile) è più saggio e più esperto di me Ho un sentimento questo è solo un po 'di ingegneria e questo è solo un codice extra / manutenzione extra.

Qualcuno ha esperienza nel progettare in questo modo che potrebbe spiegare il processo di pensiero o le implicazioni di avere questa "classe media" o andare diretta?

    
posta Dave 14.11.2013 - 10:38
fonte

3 risposte

19

Sembra che lo scopo di Class2 sia di sottrarre l'implementazione di Class3 .

Ciò consente a Class3 di essere modificato in futuro. Forse il valore verrà prelevato da un database, forse verrà letto da un file locale, forse verrà letto dal web. Forse non verrà nemmeno letto da Class3 , forse verrà letto da Class4 .

L'astrazione consente di modificare l'implementazione di ottenere un valore corretto senza che Class1 debba modificare alcun codice.

Questo è un modello di progettazione valido (vedi Pattern di facciata Pattern Bridge ). Per dire se è necessario o meno, è necessario fornire le classi effettive.

    
risposta data 14.11.2013 - 10:47
fonte
2

Dipende. La buona notizia è che se capisci il refactoring, puoi invertire la tua decisione più tardi.

Il vantaggio del codice scritto è che hai più flessibilità nel modificare la struttura interna di Class2 o cambiare Class3 senza influenzare Class1 .

Lo svantaggio è che ogni volta che desideri aggiungere una funzione a Class3 utilizzata da Class1 , devi aggiungere un metodo delegato a Class2 .

Ti suggerisco di fidarti del tuo istinto. Puoi utilizzare Rimuovere il Middle Man per avere la Class1 chiamata Class3 direttamente.

Se in seguito decidi di tornare al design originale, puoi utilizzare Nascondi delegato .

Raccomando il libro Refactoring: migliorare il design del codice esistente di Martin Fowler.

    
risposta data 14.11.2013 - 22:07
fonte
2

Questa è l'applicazione della "Legge di Demeter" (che non è tanto una legge, ma una buona guida)

link

L'idea di base non è quella di raggiungere attraverso gli oggetti per ottenere l'accesso ad altri oggetti in quanto ciò accresce l'accoppiamento con un sistema di oggetti eco, il che significa che i cambiamenti probabilmente si propagheranno su interi sistemi.

Tuttavia, ho visto persone andare troppo oltre e finire con la costruzione di facciate ad altri oggetti in oggetti che hanno la loro responsabilità.

Molto spesso, se trovi che vuoi applicare "LoD" e scopri che stai facendo questo tipo di delega / facciata / tipo di bridge, inizia a pensare se il tuo progetto è giusto, perché molto spesso un leggero aggiustamento per la progettazione / le responsabilità districherà la necessità di raggiungere attraverso un oggetto per raggiungere altri oggetti.

    
risposta data 14.11.2013 - 22:40
fonte

Leggi altre domande sui tag