Wysyłanie referencji obiektu przed jego budową

Jeśli napotkasz ten wzór, możesz sprawdzić, czy można go przekształcić w ten:

public class First()
{
      private Second _second;

      public First()
      {
          _second = new Second(this);
          // Doing some other initialization stuff,
      }

      private class Second
      {
          public Second(First f)
          {
          }
      }
}

Przekazanie zależności do konstruktora implikuje pewien rodzaj ścisłego sprzężenia między dwiema klasami, ponieważ pierwsza musi zaufać drugiej, która wie, co robi i nie będzie próbowała polegać na niezainicjalizowanym stanie First. Ten rodzaj silnego sprzężenia jest bardziej odpowiedni, gdy Second jest prywatną zagnieżdżoną podklasą (a tym samym wyraźnym szczegółem implementacji) lub ewentualnie, gdy jest Klasa wewnętrzna.

Odpowiedź brzmi: to zależy. Ogólnie rzecz biorąc, byłoby to uważane za zły pomysł ze względu na potencjalne konsekwencje.

Mówiąc dokładniej, dopóki Second nie używa niczego z First przed jego zbudowaniem, powinieneś być w porządku. Jeśli jednak nie możesz tego jakoś zagwarantować, zdecydowanie możesz napotkać problemy.

Tak, jest trochę źle. Możliwe jest robienie rzeczy z polami First, zanim zostaną w pełni zainicjalizowane, co spowodowałoby niepożądane lub nieokreślone zachowanie.

To samo dzieje się, gdy wywołujesz metodę wirtualną z konstruktora.

W przeciwieństwie do np. C++, CLR nie ma pojęcia w pełni skonstruowanych lub niekompletnie skonstruowanych obiektów. Gdy tylko alokator pamięci zwróci zerowany obiekt i zanim konstruktor uruchomi się, jest on gotowy do użycia (z punktu widzenia CLR). Ma swój ostateczny Typ, wywołania wirtualnych metod wywołują najbardziej pochodne nadpisanie itd. Możesz użyć this w ciele konstruktora, wywołać metody wirtualne itp. Może to rzeczywiście powodować problemy z kolejnością inicjalizacji, ale nie ma nic w CLR do zapobiegaj im.

To prawda, że może to prowadzić do problemów, jak to opisałeś. Dlatego generalnie zaleca się uruchamianie poleceń takich jak _second = new Second(this); tylko po innych rzeczach inicjalizacyjnych sugerowanych przez twój komentarz.

Dość często ten wzorzec jest jedynym rozwiązaniem do przechowywania wzajemnych odniesień między dwoma obiektami. W wielu przypadkach dzieje się to jednak w taki sposób, że Klasa otrzymująca potencjalnie-Nie-w pełni zainicjalizowaną instancję jest ściśle powiązana z klasą, do której się odwołuje (np. ten sam autor; część tej samej aplikacji; lub klasa zagnieżdżona, ewentualnie prywatna). W takich przypadkach można uniknąć negatywnych skutków, ponieważ autor Second zna (lub może nawet napisał) wewnętrzne strony First.

To zależy od scenariusza, ale może prowadzić do trudnych do przewidzenia zachowań. Jeśli Second zrobi cokolwiek z First w konstruktorze, to zachowanie może stać się źle zdefiniowane po zmianie konstruktora First. Dodatkowe wskazówki konstruktora sugerują również, że nie należy wywoływać wirtualnych lub abstrakcyjnych metod (na konstruowanej klasie) w konstruktorze, ponieważ może to prowadzić do podobnych konsekwencji, w których zachowanie może być trudne do rozumowania.

Odpowiedź na to pytanie zależy od charakteru relacji pomiędzy First i Second.

Zastanów się, jakiego rodzaju obiekt może się składać z innego obiektu, który sam się składa (lub wymaga do jego inicjalizacji) obiektu typu First. W takich sytuacjach należy uważać na tworzenie wykresów obiektowych z cyklami.

Niemniej jednak istnieje wiele uzasadnionych sytuacji, w których cykl powinien wystąpić w grafie obiektowym. Jeśli First opiera się na stanie Second, aby wykonać jego inicjalizację, powinieneś zachować metodę taką, jaka jest i to jest ogólnie w porządku. Jeśli Second opiera się na stanie First, Aby wykonać własną inicjalizację, powinieneś prawdopodobnie zmienić konstruktor w taki sposób:

  public First()
  {

      // Doing some other initialization stuff,
      _second = new Second(this);
  }

Jeśli oba poprzednie stwierdzenia są prawdziwe (Second zależy od stanu First, A First zależy od stanu Second), to prawie na pewno powinieneś wrócić do swojego projektu i dowiedzieć się dokładniej charakter relacji pomiędzy First i Second. (Może powinien istnieć jakiś obiekt Third, który zawiera odniesienie do First i Second, a związek między tymi dwoma ostatnimi powinien być rozstrzygany przez Third.)