La pratica del passaggio dell'oggetto padre come riferimento per l'interazione oggetto padre Evil?

Question

In alcune revisioni del codice di eredità codice C# che ho fatto di recente ho visto un certo numero di esempi come questo:

class ManagerParentClass 
{ 
    public string CustomProperty{get;set;} 
    public void Log(string message); 

    void DoABunchOfTasks() 
    { 
     new SomethingService().DoSomething(this); 
    } 
} 

con il seguente:

public class SomethingService 
{ 
    ManagerParentClass _manager; 

    void DoSomething(ManagerParentClass manager) 
    { 
     _manager = manager; 

     // do something 
     _manager.CustomProperty = "hello world"; 
     _manager.Log("said hello world"); 
    } 
} 

Anche se questo funziona bene su In superficie, sono preoccupato che questo sia un po 'un anti-pattern che potrebbe causare cose malvagie con la garbage collection.

Questo interromperà il garbage collector generazionale nella capacità di .Net di pulire correttamente gli oggetti padre e figlio o qualsiasi altra cosa negativa?

Answer 1

Oh sì, questo è un terribile anti-pattern in generale. Lavoro con una base di codice che usa molto questo ed è pura follia.

Il più grande reato? Violazione dell'incapsulamento e stretto accoppiamento tra le classi che ne derivano: SomethingService sa troppo su ManagerParentClass e ManagerParentClass rinuncia al controllo di se stesso su SomethingService.

Due alternative migliori:

1. guadagna DoSomething() un metodo di ManagerParentClass esempio, ciò è in stretta sintonia con un punto essenziale di indirizzo dell'oggetto: strutture dati portano loro operatori
2. Fai SomethingService un puro metodo che esegue alcuni calcoli e restituisce un valore, il chiamante può quindi eseguire l'assegnazione allo ManagerParentClass

Ovviamente, entrambi questi refactoring implicano una mutazione di fine partita di ManagerParentClass e, provenendo da un angolo di programmazione funzionale, proverei a evitarlo del tutto. Ma senza ulteriori informazioni, non posso raccomandare un corso per questo.

Answer 2

Questo è in realtà un modo decente di disaccoppiare classi l'uno dall'altro: ciò che hai scritto assomiglia molto al modello di visitatore.

L'esempio come scritto non ha gran parte dell'impatto della memoria, perché SomethingService non è presente su ManagerParentClass tranne la lunghezza di tale metodo. Se dovessimo assumere che SomethingService salverebbe una tale istanza durante la costruzione o metodi regolari, allora sarebbe leggermente più complicato.

Avere SomethingService contiene un riferimento a ManagerParentClass significa che ManagerParentClass si terrà nel riferimento 1) finché SomethingService viene tenuto in memoria attraverso una catena di riferimenti che riconducono a una radice GC e 2) purché SomethingService mantiene il suo riferimento a MPC.

Se SS doveva rilasciare il suo riferimento (annullarlo), il problema è risolto. Se SS non fosse più a sua volta referenziato da nulla, allora il GC saprà che SS può essere GCd, e se MPC è quindi detenuto solo da SS, allora MPC può essere a sua volta GCd.