Przeciążanie konstruktorów - Revision history

Krashan: Link switched to Polish version.

2011-01-26T07:49:37Z

Link switched to Polish version.

Krashan: Switched one of links to Polish version.

2011-01-26T06:49:59Z

Switched one of links to Polish version.

Krashan at 07:56, 25 January 2011

2011-01-25T07:56:56Z

Krashan: Translated comments in code snippets.

2011-01-24T21:23:05Z

Translated comments in code snippets.

Krashan: Translation finished (except of diagram).

2011-01-24T21:21:47Z

Translation finished (except of diagram).

Krashan: Translation in progress.

2011-01-24T21:04:43Z

Translation in progress.

Krashan: Translation in progress.

2011-01-24T20:54:32Z

Translation in progress.

Krashan: Translation in progress.

2011-01-24T20:44:45Z

Translation in progress.

Krashan: Translation in progress.

2011-01-24T19:50:18Z

Translation in progress.

Krashan: Translation in progress.

2011-01-24T19:09:06Z

Translation in progress.

@@ Line 6: / Line 6: @@
 ==Obiekty bez obiektów potomnych==
-Konstruktor obiektu (metoda ''OM_NEW()'') ma tę samą strukturę parametrów ''opSet'' co metoda ''[[Overriding OM_SET()|OM_SET()]]''. Struktura ta zawiera pole ''ops_AttrList'' będące wskaźnikiem na [[Taglists|taglistę]] zawierającą początkowe wartości atrybutów obiektu. Implementacja konstruktora dla obiektu nie zawierającego obiektów potomnych jest raczej prosta. Na początku wywołuje się konstruktor klasy nadrzęnej. Jeżeli zwróci on wskaźnik na obiekt, konstruktor inicjalizuje dane obieku, alokuje potrzebne zasoby (np. bufory w pamięci) i ustawia początkowe wartości atrybutów zgodnie z tagami przekazanymi w ''ops_AttrList''.
+Konstruktor obiektu (metoda ''OM_NEW()'') ma tę samą strukturę parametrów ''opSet'' co metoda ''[[Przeciążanie metody OM_SET()|OM_SET()]]''. Struktura ta zawiera pole ''ops_AttrList'' będące wskaźnikiem na [[Taglists|taglistę]] zawierającą początkowe wartości atrybutów obiektu. Implementacja konstruktora dla obiektu nie zawierającego obiektów potomnych jest raczej prosta. Na początku wywołuje się konstruktor klasy nadrzęnej. Jeżeli zwróci on wskaźnik na obiekt, konstruktor inicjalizuje dane obieku, alokuje potrzebne zasoby (np. bufory w pamięci) i ustawia początkowe wartości atrybutów zgodnie z tagami przekazanymi w ''ops_AttrList''.
 Najważniejszą zasadą przy przeciążaniu konstruktorów jest '''nie zostawianie nigdy częściowo skonstruowanego obiektu'''. Konstruktor powinien zwrócić albo kompletny i całkowicie zaincjalizowany obiekt, albo zakończyć się niepowodzeniem, ale przedtem zwrócić wszystkie te zasoby, które udało się mu zarezerwować. Jest to szczególnie istotne, jeżeli obiekt uzyskuje przydział więcej niż jednego zasobu i którykolwiek z przydziałów zakończy się niepowodzeniem (przykładowo alokacja dużego obszaru pamięci albo otwarcie pliku). W przykładzie poniżej obiekt usiłuje zarezerwować trzy zasoby nazwane umownie ''A'', ''B'' i ''C''.

@@ Line 27: / Line 27: @@
+  }
-Jeżeli destruktor obiektu zwalnia zasoby ''A'', ''B'' i ''C'' (co byłoby logiczne, skoro są rezerwowane w konstruktorze), oczyszczanie po nieudanej konstrukcji można wykonać przy jego użyciu. Taki destruktor musi być jednak przygotowany na fakt, że może mieć do czynienia z częściowo skonstruowanym obiektem.  Nie może zakładać, że wszystkie zasoby do zwolnienia na pewno zostały przydzielone. Najcześciej oznacza to sprawdzenie każdego wskaźnika do zasobu na okoliczność wartości zerowej (lub innej, jeżeli zero jest prawidłowym identyfikatorem zasobu). Destruktor wywołuje następnie destruktor klasy nadrzędnej. Przykłady destruktorów z objaśnieniami znajdują się w rozdziale "[[Overriding Destructors]]".
+Jeżeli destruktor obiektu zwalnia zasoby ''A'', ''B'' i ''C'' (co byłoby logiczne, skoro są rezerwowane w konstruktorze), oczyszczanie po nieudanej konstrukcji można wykonać przy jego użyciu. Taki destruktor musi być jednak przygotowany na fakt, że może mieć do czynienia z częściowo skonstruowanym obiektem.  Nie może zakładać, że wszystkie zasoby do zwolnienia na pewno zostały przydzielone. Najcześciej oznacza to sprawdzenie każdego wskaźnika do zasobu na okoliczność wartości zerowej (lub innej, jeżeli zero jest prawidłowym identyfikatorem zasobu). Destruktor wywołuje następnie destruktor klasy nadrzędnej. Przykłady destruktorów z objaśnieniami znajdują się w rozdziale "[[Przeciążanie destruktorów]]".
 Pozostaje jeszcze otwarta kwestia funkcji ''CoerceMethod()''. Jakie jest jej działanie i dlaczego została tu użyta zamiast zwykłego ''DoMethod()''? Funkcja ta wykonuje metodę na obiekcie, tak samo jak ''DoMethod()'', ale wykonuje tzw. "wymuszenie" (ang. ''coercion'') wykonania metody ściśle określonej klasy, poprzez bezpośredni skok do jej dispatchera, zamiast do rzeczywistej klasy obiektu. Jeżeli obiekt jest klasy pochodnej względem tej, której konstruktor przeciążamy, to będą to oczywiście dwie różne klasy. Diagram poniżej ilustruje problem:

← Older revision		Revision as of 07:56, 25 January 2011
Line 32:		Line 32:


−	[[File:~~Coercemethod~~.png\|center]]	+	[[File:Coercemethod_pl.png\|center]]

@@ Line 46: / Line 46: @@
     if (obj = DoSuperNew(cl, obj,
       MUIA_Group_Child, MUI_NewObject(MUIC_Text,
-        /* attributes for the first subobject */
+        /* atrybuty dla pierwszego podobiektu */
       TAG_END),
       MUIA_Group_Child, MUI_NewObject(MUIC_Text,
-        /* attributes for the second subobject */
+        /* atrybuty dla drugiego podobiektu */
       TAG_END),
     TAG_MORE, msg->ops_AttrList))
@@ Line 59: / Line 59: @@
        && (d->ResourceC = ObtainResourceC())
+      {
-        return (IPTR)obj;    /* success */
+        return (IPTR)obj;    /* sukces */
+      }
       else CoerceMethod(cl, obj, OM_DISPOSE);

@@ Line 68: / Line 68: @@
 Warto zauważyć, że funkcja ''DoSuperNew()'' '''łączy''' taglistę przekazaną konstruktorowi w polu ''ops_AttrList'' struktury parametrów metody z taglistą zbudowaną ze swoich argumentów. Robi się to za pomoca specjalnego taga ''TAG_MORE'', który przekierowuje iterator [[Taglists|taglisty]] (taki jak na przykład funkcja ''NextTagItem()'') do następnej części znajdującej się pod adresem określonym przez wartość tego taga. Łączenie taglist pozwala na modyfikowanie obiektu tagami podanymi w wywołaniu konstruktora, na przykład dodanie ramki lub tła do grupy z powyższego przykładu.
+Automatyczna obsługa błędów przy tworzeniu obiektów potomnych działa następująco: jeżeli konstruktor któregokolwiek z podobiektów zwróci ''NULL'', wskaźnik ten umieszczany jest w budowanej na stosie tagliście jako wartość taga (np. ''MUIA_Group_Child''). Wszystkie standardowe klasy MUI, które mogą posiadać obiekty potomne zaprojektowane są w sposób taki, że:
-The automatic handling of failed child objects works in the following way: when a subobject fails, its constructor returns ''NULL''. This ''NULL'' value is then inserted as the value of a "child" tag (''MUIA_Group_Child'') in the example. All MUI classes able to have child objects are designed in a way that:
+* Konstruktor zwraca ''NULL'', jeżeli wskaźnik na którykolwiek z przekazanych obiektów potomnych jest równy ''NULL''.
-* the constructor fails if any "child" tag has a ''NULL'' value,
+* Konstruktor usuwa wszystkie pomyślnie stworzone obiekty potomne przed wyjściem.
-* the constructor disposes any successfully constructed child objects before exiting.
+Ponieważ wynik funkcji ''DoSuperNew()'' jest wynikiem działania konstruktora klasy nadrzędnej, funkcja ta również zwróci zerowy wskaźnik. W ten sposób w przypadku jakiegokolwiek błędu przy budowaniu drzewa obiektów aplikacji wszystkie stworzone obiekty zostaną prawidłowo zniszczone, bez pozostawiania obiektów "osieroconych".

@@ Line 40: / Line 40: @@
 ==Obiekty z obiektami potomnymi==
-Konstruktor klasy, która dodaje obiektowi obiekty potomne, jest napisany zgodnie z podstawowymi zasadami omówionymi powyżej, ale pewne szczegóły są inne. Z klas standardowych MUI mogących posiadać obiekty potomne najcześciej klasy pochodne tworzy się od klasy ''Group'' i ''Application'' (obiektami potomnymi aplikacji są okna). Bardzo często używa się również klas pochodnych od ''Window'', z tym, że obiekt tej klasy posiada tylko jeden obiekt potomny, klasy ''Group'', specyfikowany atrybutem ''MUIA_Window_RootObject''. Oczywiście ten obiekt posiada z reguły liczne podobiekty, mianowicie całą zawartość okna.
+Konstruktor klasy, która dodaje obiektowi obiekty potomne, jest napisany zgodnie z podstawowymi zasadami omówionymi powyżej, ale pewne szczegóły są inne. Z klas standardowych MUI mogących posiadać obiekty potomne najcześciej klasy pochodne tworzy się od klasy ''Group'' i ''Application'' (obiektami potomnymi aplikacji są okna). Bardzo często używa się również klas pochodnych od ''Window'', z tym, że obiekt tej klasy posiada tylko jeden obiekt potomny, klasy ''Group'', specyfikowany atrybutem ''MUIA_Window_RootObject''. Oczywiście ten obiekt posiada z reguły liczne podobiekty, mianowicie całą zawartość okna. Konstruktor powinien najpierw przystąpić do tworzenia obiektów potomnych a dopiero potem wywołać konstruktor klasy nadrzędnej. Jeżeli jego wywołanie zakończy się sukcesem, konstruktor wykonuje inicjalizację danych i stanu obiektu oraz rezerwuje potrzebne zasoby. Ponieważ każda z faz konstruktora może zakończyć się niepowodzeniem, prawidłowa obsługa błędów staje się dość skomplikowana. Dodatkowo wstawianie wskaźników stworzonych podobiektów do taglisty (jako wartości atrybutów takich jak ''MUIA_Group_Child'') jest niezbyt wygodne. Na szczęście zadania te upraszcza funkcja ''DoSuperNew()'', która łączy tworzenie obiektów potomnych i wywołanie konstruktora klasy nadrzędnej w jedną operację. Zapewnia również automatyczną obsługę błędów przy konstrukcji obiektów potomnych. Poniższy przykład demonstruje konstruktor klasy pochodnej od ''Group'' tworzącej dwa obiekty tekstowe (klasa ''Text''):
   IPTR MyClassNew(Class *cl, Object *obj, struct opSet *msg)

← Older revision		Revision as of 20:44, 24 January 2011
Line 39:		Line 39:

	==Obiekty z obiektami potomnymi==		==Obiekty z obiektami potomnymi==
		+
		+	Konstruktor klasy, która dodaje obiektowi obiekty potomne, jest napisany zgodnie z podstawowymi zasadami omówionymi powyżej, ale pewne szczegóły są inne. Z klas standardowych MUI mogących posiadać obiekty potomne najcześciej klasy pochodne tworzy się od klasy ''Group'' i ''Application'' (obiektami potomnymi aplikacji są okna). Bardzo często używa się również klas pochodnych od ''Window'', z tym, że obiekt tej klasy posiada tylko jeden obiekt potomny, klasy ''Group'', specyfikowany atrybutem ''MUIA_Window_RootObject''. Oczywiście ten obiekt posiada z reguły liczne podobiekty, mianowicie całą zawartość okna.

	While retaining the same principles, the constructor of an object with subobjects is designed a bit differently. The most commonly subclassed classes able to have child objects are ''Application'', and ''Group''. The ''Window'' class is also often subclassed in a similar way. While a ''Window'' object can have only one child, specified by ''MUIA_Window_RootObject'', this child often has multiple subobjects. The constructor should create its child objects first, then insert them into the ''ops_AttrList'' [[Taglists\|taglist]] and call the superclass constructor. If it succeeds, then resources may be allocated if needed. As any of the three constructor stages may fail, proper handling of errors becomes complicated. Also inserting objects created into the taglist as values of child tags (like ''MUIA_Group_Child'') is cumbersome. Fortunately one can use the ''DoSuperNew()'' function, which merges the creation of subobjects and the calling of the superclass into one operation. It also provides automatic handling of failed child object construction. An example below is a constructor for a ''Group'' subclass putting two ''Text'' objects in the group.		While retaining the same principles, the constructor of an object with subobjects is designed a bit differently. The most commonly subclassed classes able to have child objects are ''Application'', and ''Group''. The ''Window'' class is also often subclassed in a similar way. While a ''Window'' object can have only one child, specified by ''MUIA_Window_RootObject'', this child often has multiple subobjects. The constructor should create its child objects first, then insert them into the ''ops_AttrList'' [[Taglists\|taglist]] and call the superclass constructor. If it succeeds, then resources may be allocated if needed. As any of the three constructor stages may fail, proper handling of errors becomes complicated. Also inserting objects created into the taglist as values of child tags (like ''MUIA_Group_Child'') is cumbersome. Fortunately one can use the ''DoSuperNew()'' function, which merges the creation of subobjects and the calling of the superclass into one operation. It also provides automatic handling of failed child object construction. An example below is a constructor for a ''Group'' subclass putting two ''Text'' objects in the group.

← Older revision		Revision as of 19:50, 24 January 2011
Line 35:		Line 35:


−	~~The class~~ ''B'' ~~on the diagram is a subclass of the class~~ ''A'' ~~and similarly~~, ~~the class~~ ''C'' ~~is a subclass of~~ ''B''. ~~Let's assume an object of the class~~ ''C'' ~~is being constructed~~. ~~As every constructor calls the superclass first~~, ~~the call goes up to~~ ''rootclass'' (~~the root of all~~ BOOPSI ~~classes~~) ~~first~~. ~~Then going down the class tree~~, ~~every class constructor allocates its resources~~. ~~Unfortunately the constructor of class~~ ''A'' ~~has been unable to allocate one of its resources and decided to fail~~. ~~If it had just called~~ ''DoMethod(obj, OM_DISPOSE)'' ~~it will unnecessarily execute destructors in classes~~ ''B'' ~~and~~ ''C'', ~~while constructors in these classes have been not yet fully executed~~. ~~Even if these destructors can cope with this~~, ~~calling them is superfluous~~. ~~With the~~ ''CoerceMethod()'' ~~the destructor in the class~~ ''A'' ~~is called directly~~. ~~Then class~~ ''A'' ~~constructor returns~~ NULL, ~~which causes constructors in classes~~ ''B'' ~~and~~ ''C'' ~~to fail immediately without resource allocation attempts~~.	+	Klasa ''B'' na rysunku jest klasą pochodną klasy ''A'', klasa ''C'' jest klasą pochodną ''B''. Załóżmy, że konstruujemy obiekt klasy ''C''. Ponieważ każdy konstruktor zaczyna pracę od wywołania konstruktora klasy nadrzędnej, łańcuch wywołań dociera do klasy ''rootclass'' (klasy głównej wszystkich klas BOOPSI). Następnie wywołania schodzą w dół drzewa klas, konstruktory tych klas inicjalizują swoje części obiektu i rezerwują zasoby. Niestety okazało się, że konstruktor klasy ''A'' nie dostał wszystkich oczekiwanych zasobów i zakończył się niepowodzeniem. Gdyby w tym wypadku po prostu wywołał destruktor przez ''DoMethod(obj, OM_DISPOSE)'', niepotrzebnie wywołałby destruktory klas ''B'' i ''C'', mimo tego, że ich konstruktory nie zostały jeszcze wykonane. Nawet jeżeli konstruktory te potrafią sobie poradzić z taką sytuacją, wywoływanie ich jest całkowicie zbędne. Uruchomienie destruktora funkcją ''CoerceMethod()'' powoduje, że od razu wywoływany jest destruktor w klasie ''A''. Po zwolnieniu tych zasobów, do których dało się uzyskać dostęp, konstruktor klasy ''A'' zwraca ''NULL'', co z kolei powoduje natychmiastowe zakończenie wykonywania się konstruktorów klas ''B'' i ''C'', również z wynikiem zerowym, bez próby inicjalizacji obiektu i alokacji zasobów.