Rzut oka na BOOPSI

Grzegorz Kraszewski

---

Ten artykuł w innych językach: angielski

Programowanie zorientowane obiektowo

Programowanie zorientowane obiektowo jest sposobem tworzenia programów, jaki powstał w odpowiedzi na dwie tendencje na rozwijającym się rynku oprogramowania. Po pierwsze zarządzanie tradycyjnie napisanym kodem staje się coraz trudniejsze w miarę zwiększania się jego rozmiarów. Po drugie, w latach osiemdziesiątych ubiegłego wieku nastąpił lawinowy rozwój graficznych interfejsów użytkownika, co oznaczało koniec programów wykonujących się w z góry zdefiniowanej sekwencji. Nowoczesne programy są sterowane zdarzeniami. Oznacza to, że tok wykonywania programu jest określony przez zdarzenia zewnętrzne (najczęściej wywoływane przez użytkownika) i nie jest znany w czasie pisania programu. Programowanie obiektowe dzieli program na zbiór obiektów oddziałujących na siebie poprzez dokładnie zdefiniowane zestawy metod i atrybutów. Wprowadzona w ten sposób modułowość ułatwia zapanowanie nad projektem i w naturalny sposób pasuje do koncepcji nowoczesnego interfejsu użytkownika. Elementy GUI (zwane w MUI "gadżetami") są po prostu obiektami wymieniającymi informacje z innymi obiektami reprezentującymi dane użytkownika.

To krótkie wprowadzenie nie jest oczywiście kompletnym wykładem z programowania obiektowego. Z drugiej strony do zaznajomienia się z BOOPSI nie jest wymagana znajomość jakiegokolwiek obiektowo zorientowanego języka programowania. Zazwyczaj to język programowania daje programiście do ręki podstawowe konstrukcje obiektowe. Taki język jest albo obiektowy od podstaw (np. C++, C#, Java) albo ma obiektowość doklejoną w mniej lub bardziej logiczny sposób (Objective C, PHP). Inaczej jest w przypadku BOOPSI i MUI. Tutaj konstrukcje wspierające obiektowość dostajemy od systemu operacyjnego. Dzięki temu możemy używać MUI w dowolnym języku programowania, również tradycyjnym, jak np. stare dobre C, a nawet asembler.

Moduł BOOPSI znajduje się w bibliotece intuition.library, niektóre ważne funkcje znajdziemy w statycznej bibliotece libabox. Pierwotnym zadaniem BOOPSI było "zapakowanie w obiekty" elementów GUI tworzonych przez Intuition. Takie podejście okazało się jednak za mało elastyczne, dlatego MUI używa BOOPSI wyłącznie jako podstawę programowania obiektowego, tworząc własne elementy GUI i wykorzystując Intuition jedynie do podstawowych rzeczy (np. tworzenie okien). BOOPSI tworzy cztery podstawowe pojęcia programowania obiektowego: klasy, obiekty, metody i atrybuty. Obsługuje również dziedziczenie klas. Dzięki swojej prostocie BOOPSI jest łatwe w użyciu, szczególnie w porównaniu do bardziej zaawansowanych platform obiektówych, takich jak np. język C++.

Klasy

Klasa jest podstawowym pojęciem programowania obiektowego. Jest ona kompletnym opisem swoich obiektów, definiuje ich metody i atrybuty. W BOOPSI klasa składa się z:

• Struktury IClass. Do klasy odwołujemy się zawsze poprzez wskaźnik na tę strukturę. Struktura IClass jest zdefiniowana w systemowym pliku nagłówkowym <intuition/classes.h>. Znajduje się tam również definicja typu Class, który jest tożsamy z struct IClass.
• Funkcji, tzw. dispatchera. Gdy program wykonuje metodę na obiekcie, wywoływany jest dispatcher klasy obiektu. Na podstawie identyfikatora metody dispatcher wykonuje skok do metody. Jest on zwykle implementowany w postaci dużego bloku switch. W przypadku małych klas zawierających jedynie kilka krótkich metod, kod metod jest często umieszczany bezpośrednio w poszczególnych wyrażeniach case. Większe klasy mają metody w oddzielnych funkcjach umieszczonych poza dispatcherem. Ponieważ każda metoda przechodzi przez dispatcher, wszystkie metody BOOPSI są wirtualne w sensie C++. Z tego powodu wywołanie metody w BOOPSI jest zwykle wolniejsze niż w C++.

Zestaw metod klasy (metod, jakie można wykonywać na jej obiektach) jest określony przez zestaw wyrażeń case dispatchera. Atrybuty obiektu są ustawiane przy użyciu metody OM_SET(), a odczytywane metodą OM_GET(). Atrybuty mogą być również przekazane bezpośrednio do konstruktora obiektu. Zestaw atrybutów klasy, oraz możliwość ich odczytu, zapisu i użycia przy inicjacji obiektu są zatem zdefiniowane przez kod metody OM_GET() (odczyt), OM_SET() (zapis) i OM_NEW() (konstruktor, a więc inicjacja). W BOOPSI nie występuje formalna deklaracja klasy, nie ma też podziału między metody i atrybuty publiczne i prywatne. Pewną imitację deklaracji i poziomy dostępu można wprowadzić umieszczając każdą klasę w odrębnym pliku źródłowym. Towarzyszący mu plik nagłówkowy zawiera wtedy definicje identyfikatorów metod i atrybutów i struktur parametrów metod, ale tylko te uważane za "publiczne". Identyfikatory metod prywatnych umieszcza się wewnątrz pliku z kodem klasy, nie są więc formalnie dostępne na zewnątrz.

Klasa BOOPSI może być współdzielona między programami. Wszystkie klasy wbudowane w MUI są klasami współdzielonymi. BOOPSI tworzy systemową listę klas publicznych (listę tę można przeglądać np. za pomocą monitora systemu Scout). Klasy publiczne są identyfikowane przez nazwę. Część klas standardowych MUI znajduje się w jego głównej bibliotece – muimaster.library. Biblioteka dodaje te klasy do listy klas publicznych, kiedy zostaje załadowana do pamięci przy pierwszym otwarciu. Pozostałe standardowe klasy MUI są umieszczone na partycji systemowej dysku w katalogu MOSSYS:Classes/MUI/. Dodatkowe klasy, pisane przez niezależnych programistów, powinny być instalowane w katalogu SYS:Classes/MUI/.

Klasy publiczne są zaimplementowane jako biblioteki współdzielone MorphOS-a. Taka biblioteka zawiera kod klasy i dodaje klasę do listy systemowej podczas pierwszego otwarcia i załadowania z dysku. Ponieważ klasy publiczne są bibliotekami, powinny być przed użyciem otwarte funkcją OpenLibrary() (więcej na temat), tym bardziej, że klasy BOOPSI zazwyczaj nie znajdują się na liście bibliotek otwieranych automatycznie. Inaczej jest w przypadku klas MUI, które mogą być używane, bez ich jawnego otwierania w programie. Zostało to wyjaśnione w rozdziale "Jak MUI rozszerza BOOPSI" poniżej.

Metody i atrybuty

Metody

Metody to akcje, jakie możemy wykonać na obiekcie danej klasy. Zestaw dostępnych metod jest definiowany przez klasę. Bardziej technicznie, metoda jest funkcją, wywoływaną z wskaźnikiem na obiekt jako parametr, w celu zmany stanu obiektu. W BOOPSI metody są wywoływane przy użyciu funkcji DoMethod() z biblioteki statycznej libabox:

wynik = DoMethod(obiekt, id_metody, ... /* parametry metody */);
wynik = DoMethodA(obiekt, struktura_metody);

Pierwsza, bardziej popularna forma wywołania tworzy strukturę metody "w locie" na stosie procesora z podanych argumentów. Każda struktura metody (zwana często "wiadomością", ang. message) zawiera identyfikator metody jako pierwsze pole. Forma DoMethodA() otrzymuje gotową strukturę metody poprzez wskaźnik, struktura musi być stworzona przez program. Ta druga forma jest raczej rzadko używana. Ilość i znaczenie parametrów oraz znaczenie wyniku są zmienne i zależą od konkretnej metody. Poniższy kod ilustruje różnice w obu formach wywołania metody:

struct MUIP_JakasMetoda
{
  ULONG MethodID;
  LONG ParametrA;
  LONG ParametrB;
};

DoMethod(obiekt, MUIM_JakasMetoda, 3, 7);

struct MUIP_JakasMetoda mparams = { MUIM_JakasMetoda, 3, 7 };
DoMethodA(obiekt, &mparams);

Oczywiście forma DoMethod() jest znacznie wygodniejsza i dlatego jest w powszechnym użyciu. MUI używa ustalonych przedrostków w nazwach swoich struktur i stałych:

• MUIM_ dla identyfikatorów metod.
• MUIP_ dla struktur (wiadomości) metod.
• MUIA_ dla identyfikatorów atrybutów.
• MUIV_ dla specjalnych, predefiniowanych wartości atrybutów.

Typy języka C użyte w powyższej strukturze metody wymagają wyjaśnienia. LONG to 32-bitowa liczba całkowita ze znakiem, ULONG to taka sama liczba bez znaku. Ponieważ struktura metody jest zwykle budowana na stosie procesora, wszystkie parametry muszą mieć rozmiar i początek wyrównany do 32 bitów. Dlatego każdy parametr musi być zdefiniowany albo jako liczba 32-bitowa, albo jako wskaźnik. Każdy parametr większy niż 32 bity musi być przekazany poprzez wskaźnik (na przykład liczby zmiennoprzecinkowe podwójnej precyzji albo łańcuchy tekstowe).

Ustawianie wartości atrybutu

Atrybuty obiektu reprezentują jego właściwości. Atrybuty zapisuje się i odczytuje używając dwóch specjalnych metod: OM_SET() i OM_GET(). To dość nietypowy sposób w porównaniu z większością obiektowo zorientowanych języków programowania, gdzie atrybuty (implementowane jako pola obiektu) są odczytywane i zapisywane bezpośrednio. Manipulowanie atrybutami w BOOPSI jest więc nieco wolniejsze, bo wymaga wykonania metody.

Metoda OM_SET() jest w stanie ustawić wiele atrybutów jednocześnie, bowiem jej argumentami nie są atrybut i jego nowa wartość, ale tablica identyfikatorów atrybutów i ich wartości, zwana potocznie taglistą. Poniższy przykład pokazuje ustawienie dwóch atrybutów:

struct TagItem atrybuty[] = {
  { MUIA_JakisAtr1, 756 },
  { MUIA_JakisAtr2, 926 },
  { TAG_END, 0 }
};

DoMethod(obiekt, OM_SET, (ULONG)atrybuty);

Nie jest to zbyt wygodne, a i czytelność kodu pozostawia nieco do życzenia. Życie ułatwia nam intuition.library za pomocą funkcji SetAttrsA(), która jest swego rodzaju nakładką na metodę OM_SET(). Używając tej funkcji i tablicy zdefiniowanej powyżej, możemy napisać:

SetAttrsA(obiekt, atrybuty);

Mimo wszystko wciąż trzeba zdefiniować tymczasową taglistę, ale funkcja ma na szczęście formę ze zmienną liczbą argumentów, pozwalającą na zbudowanie taglisty "w locie" na stosie, forma ta nazywa się SetAttrs().

SetAttrs(obiekt,
  MUIA_JakisAtr1, 756,
  MUIA_JakisAtr2, 926,
TAG_END);

To jednak nie wszystko. Programiści są leniwi, więc doszli do wniosku, że w często spotykanym przypadku ustawiania pojedynczego atrybutu, SetAttrs() to wciąż za dużo pisania. Powszechną praktyką w programach używających MUI było definiowanie makr nazywanych xset() lub set(), obecnie makro set() jest zdefiniowane w systemowym pliku nagłówkowym <libraries/mui.h>.

#define set(object, attribute, value) SetAttrs(object, attribute, value, TAG_END)

Używając tego makra pojedynczy atrybut ustawia się następująco:

set(object, MUIA_JakisAtr1, 756);

Metoda OM_SET() zwraca jako wynik ilość ustawionych w obiekcie atrybutów. Jeżeli jakieś atrybuty nie są znane w klasie obiektu (i klasach nadrzędnych), nie są zliczane. Wynik tej metody jest zwykle ignorowany, może być użyty do testowania czy dany atrybut jest obsługiwany i czy można go ustawiać.

W MUI znajdziemy kilka dodatkowych metod ustawiających atrybuty, są to MUIM_Set(), MUIM_NoNotifySet() i MUIM_MultiSet(). Są używane przede wszystkim w notyfikacjach.

Odczytywanie wartości atrybutu

Metoda OM_GET() odczytuje wartość pojedynczego atrybutu z obiektu. Nie ma metody do odczytania wielu atrybutów jednocześnie. Pierwszym, oczywistym parametrem OM_GET() jest identyfikator atrybutu. Jego wartość nie jest jednak zwracana jako wynik metody. Drugi argument metody jest wskaźnikiem na miejsce w pamięci, gdzie ma być zapisana wartość atrybutu. Pozwala to na przekazywanie wartości nie mieszczących się w 32 bitach, są one po prostu kopiowane do wskazanego miejsca w pamięci. Oczywiście sposób ten sprawdza się wyłącznie dla wartości o stałych rozmiarach. Łańcuchy tekstowe nie mogą być przekazane w ten sposób, są więc przekazywane poprzez wskaźnik (adres łańcucha tekstowego jest zapisywany pod adresem przekazanym jako drugi parametr OM_GET()). Poniższe przykłady demonstrują te trzy przypadki:

LONG wartosc1;
QUAD wartosc2;     /* liczba całkowita 64-bitowa ze znakiem */
char **wartosc3;  

DoMethod(obiekt, OM_GET, MUIA_Atrybut1, (ULONG)&wartosc1);  /* atrybut całkowity */
DoMethod(obiekt, OM_GET, MUIA_Atrybut2, (ULONG)&wartosc2);  /* duży atrybut o stałym rozmiarze */
DoMethod(obiekt, OM_GET, MUIA_Atrybut3, (ULONG)&wartosc3);  /* łańcuch tekstowy */

W przypadku, gdy wartość atrybutu jest przekazywana przez wskaźnik, wskazywane dane powinny być traktowane jako tylko do odczytu, o ile dokumentacja wyraźnie nie stwierdza inaczej.

Podobnie jak dla metody OM_SET(), istnieje w intuition.library nakładka na metodę OM_GET() nazwana GetAttr(). Nieoczekiwanie dla programisty, funkcja ta zmienia kolejność argumentów: identyfikator atrybutu jest pierwszym argumentem, potem następuje wskaźnik na obiekt, a na końcu wskaźnik na miejsce w pamięci do zapisania wartości atrybutu. Korzystając z GetAttrs() powyższe trzy przykłady można zapisać w następujący sposób:

GetAttr(MUIA_Atrybut1, obiekt, &wartosc1);
GetAttr(MUIA_Atrybut2, obiekt, (ULONG*)&wartosc2);
GetAttr(MUIA_Atrybut3, obiekt, (ULONG*)&wartosc3);

Trzeci parametr funkcji (wskaźnik na miejsce zapisu wartości) jest zdefiniowany jako wskaźnik na ULONG, więc w pierwszym przykładzie rzutowanie typu nie jest potrzebne.

W pliku nagłówkowym <libraries/mui.h> jest zdefiniowane makro get(), które odwraca porządek argumentów na taki jak w OM_GET() oraz dodaje wyżej wspomniane rzutowanie typu na (ULONG*). Kolejność argumentów get() jest taka sama jak w set(), co pozwala uniknąć pomyłek. Trzeci przykład z użyciem get() przyjmuje następującą formę:

get(obiekt, MUIA_Atrybut3, &wartosc3);

Najczęściej używane typy atrybutów to liczby całkowite (32-bitowe lub krótsze) i łańcuchy tekstowe. Oba mieszczą się w zmiennej 32-bitowej, jako że teksty są przekazywane poprzez wskaźnik. Biorąc to pod uwagę, programiści używający MUI zaczęli używać makra (czasami definiowanego jako funkcja), które zwraca wartość atrybutu jako wynik, zamiast zapisywać ją w przygotowanym miejscu w pamięci. Funkcja nazywa się xget(), oto przykłady jej użycia:

wartosc1 = xget(obiekt, MUIA_Atrybut1);
/* MUIA_Atrybut2 nie może być odczytany przez xget() */
wartosc3 = (char*)xget(obiekt, MUIA_Atrybut3);

Funkcję xget() można zdefiniować następująco:

inline ULONG xget(Object *obiekt, ULONG atrybut)
{
  ULONG wartosc;

  GetAttr(atrybut, obiekt, &wartosc);
  return wartosc;
}

Funkcja jest bardzo prosta i kompiluje się do kilku rozkazów procesora. Dlatego jest zadeklarowana jako inline, co powoduje wstawianie jej kodu w każdym miejscu wywołania, zamiast skoku do niej. Czyni to program nieco szybszym za cenę niewielkiego zwiększenia jego rozmiarów. Wadą xget(), oprócz działania wyłącznie z atrybutami o wartościach miesczczących się w 32 bitach, jest ignorowanie wyniku metody OM_GET(). Wynik ten jest wartością logiczną i jest równy TRUE, jeżeli klasa obiektu (albo któraś z jej klas nadrzędnych) rozpozna atrybut, w przeciwnym wypadku ma wartość FALSE. Wynik OM_GET() jest zwykle ignorowany, ale może się przydać do sprawdzania atrybutów obsługiwanych przez klasę.

Funkcja xget() nie jest zdefiniowana w systemowych plikach nagłówkowych. Została tu opisana dlatego, że jest powszechnie używana w programach korzystających z MUI. Można również, w razie potrzeby, zdefiniować jej odpowiedniki dla wartości typów nie mieszczących się w 32 bitach.

Konstrukcja obiektu

Having a class, the programmer can create an unlimited number of objects (instances) of this class. Every object has its own instance data area, which is allocated and cleared automatically by the BOOPSI. Of course only object data are allocated for each instance. The code is not duplicated, so it must be reentrant (static variables and code self-modification must not be used).

Objects are created and disposed with two special methods: the constructor, OM_NEW() and the destructor, OM_DISPOSE(). Of course the constructor method cannot be called on an object, because it creates a new one. It needs a pointer to the object's class instead, so it cannot be invoked with DoMethod(). The intuition.library provides NewObjectA() and NewObject() functions for calling the constructor. The difference between them is that NewObjectA() takes a pointer to a taglist specifying initial values for objects. NewObject() allows the programmer to build this taglist from a variable number of function arguments.

NewObject[A]() has two alternative ways of specifying the created object's class. Private classes are specified by pointers of Class type. Shared classes are specified by name, which is a null-terminated string. If the pointer is used for class specification, the name should be NULL, if a name is used, the pointer should be NULL. Four examples below show creating instances of private and public class with both NewObjectA() and NewObject():

Object *obj;
Class *private;

struct TagItem initial = {
  { MUIA_Attribute1, 4 },
  { MUIA_Attribute2, 46 },
  { TAG_END, 0 }
};

A private class, NewObjectA():

obj = NewObjectA(private, NULL, initial);

A private class, NewObject():

obj = NewObject(private, NULL,
  MUIA_Attribute1, 4,
  MUIA_Attribute2, 46,
TAG_END);

A public class, NewObjectA():

obj = NewObjectA(NULL, "some.class", initial);

A public class, NewObject():

obj = NewObject(NULL, "some.class",
  MUIA_Attribute1, 4,
  MUIA_Attribute2, 46,
TAG_END);

NewObject[A]() returns NULL in case of an object creation failure. Usual reasons are: wrong class pointer/name, lack of free memory, wrong/missing initial values of attributes. The return value of NewObject[A]() should always be checked in the code.

Destrukcja obiektu

Do zniszczenia obiektu służy metoda OM_DISPOSE(). W przeciwieństwie do konstruktora, destruktor może być wywołany poprzez DoMethod():

DoMethod(obiekt, OM_DISPOSE);

W bibliotece intuition.library znajdziemy nakładkę na tę metodę, nazwaną DisposeObject():

DisposeObject(obiekt);

Jak MUI rozszerza BOOPSI

The Magic User Interface not only builds on BOOPSI but also extends it. Other than providing a broad set of classes, MUI also modifies the BOOPSI mode of operation a bit. Two modifications are discussed in this chapter: extension of the IClass structure and MUI's own functions for object construction and destruction.

MUI uses the MUI_CustomClass structure for its internal class representation. This structure contains the standard Class structure inside. It is important when creating objects from MUI private classes with NewObject(), that the Class structure must be extracted from the MUI_CustomClass structure:

struct MUI_CustomClass *priv_class;
Object *obj;

obj = NewObject(priv_class->mcc_Class, NULL, /* ... */ TAG_END);

MUI's second modification of BOOPSI is using its own functions for object construction and destruction, MUI_NewObject[A]() and MUI_DisposeObject() respectively. These two functions are used only for objects of MUI shared (public) classes. Objects of private classes are created with NewObject() as shown above. The main advantage of MUI_NewObject() is automatic opening and closing of disk based shared classes. Here is an example:

Object *text;

text = MUI_NewObject(MUIC_Text, MUIA_Text_Contents, "foobar", TAG_END);

'MUIC_Text is a macro defined in <libraries/mui.h> and it expands to "Text.mui" string. All MUI public classes should be referenced by their MUIC_ macros rather than by direct string literals. It helps to detect mistyped class names, as a typo in a macro will be detected during compilation. The MUI checks if a class named Text.mui has been added to the public list of classes. If not, the class is found on disk, opened and used for creating the requested object. Closing the class when no longer in use is handled automatically too. All MUI objects should be disposed using MUI_DisposeObject(), which takes the object to be disposed as its only argument, the same as DisposeObject().

MUI_DisposeObject(text);