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

Posiadając zdefiniowaną klasę, programista może stworzyć nieograniczoną ilość obiektów (zwanych też czasami instancjami klasy). Każdy obiekt posiada własny obszar danych, alokowany i zwalniany automatycznie przez BOOPSI. Oczywiście wyłącznie dane obiektu są przydzielane dla każdej instancji. Kod metod nie jest powielany, więc musi być napisany w sposób pozwalający na jednoczesne wykonywanie go przez wiele procesów (ang. reentrant), oznacza to m. in. nieużywanie zmiennych statycznych i samomodyfikującego się kodu.

Obiekty są tworzone i niszczone za pomocą dwóch specjalnych metod, odpowiednio konstruktora (OM_NEW()) i destruktora (OM_DISPOSE()).

Konstruktor nie może być, rzecz jasna, wywołany na obiekcie, ponieważ dopiero stworzy ten obiekt. Potrzebuje więc wskaźnika na klasę obiektu do stworzenia. Z tego wynika, że nie można wywołać konstruktora poprzez DoMethod(). Do tego celu biblioteka intuition.library ma w swoim obfitym API funkcje NewObjectA() i NewObject(). Różnica między nimi to sposób podania konstruktorowi początkowych wartości atrybutów. NewObjectA() przyjmuje wskaźnik na taglistę zawierającą wartości początkowe. NewObject() pozwala na zbudowanie tej listy tagów na stosie z kolejnych agrumentów.

Funkcja NewObject[A]() posiada dwa alternatywne argumenty podające klasę obiektu do stworzenia. Klasę prywatną podaje się poprzez wskaźnik na strukturę Class. Klasę publiczną podaje się poprzez wskaźnik nazwę, która jest łańcuchem tekstowym (zakończonym, jak to zwykle bywa, bajtem 0). Jeżeli podajemy wskaźnik na klasę prywatną, wskaźnik na nazwę powinien mieć wartość NULL i odwrotnie, jeżeli używamy nazwy, wskaźnik na klasę powinien być NULL-em. Poniższe cztery przykłady demonstrują tworzenie obiektów klasy publicznej i prywatnej z użyciem bądź to NewObjectA(), bądź to NewObject():

Object *obj;
Class *private;

struct TagItem initial = {        /* wartości początkowe atrybutów */
  { MUIA_Attribute1, 4 },
  { MUIA_Attribute2, 46 },
  { TAG_END, 0 }
};

Klasa prywatna, NewObjectA():

obj = NewObjectA(private, NULL, initial);

Klasa prywatna, NewObject():

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

Klasa publiczna, NewObjectA():

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

Klasa publiczna, NewObject():

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

Funkcja NewObject[A]() zwraca wskaźnik zerowy w przypadku nieudanej konstrukcji obiektu. Typowe przyczyny to: nieprawidłowy wskaźnik na klasę lub nazwę klasy, brak wolnej pamięci, błędne lub brakujące wartości początkowe atrybutów. Wartość zwracana przez konstruktor powinna być zawsze sprawdzana w kodzie.

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

Magic User Interface nie tylko bazuje na BOOPSI, ale także go rozszerza. Oprócz postawienia do dyspozycji programisty szerokiej palety klas standardowych, MUI modyfikuje także co nieco sposób działania BOOPSI. W tym rozdziale omówione są dwie modyfikacje: rozszerzenie struktury Class oraz własne funkcje do konstrukcji i destrukcji obiektów.

MUI używa struktury MUI_CustomClass do reprezentowania swoich klas. Struktura ta zawiera w sobie standardową strukturę Class. W czasie tworzenia obiektów klas prywatnych MUI za pomocą NewObject(), należy "wydobyć" strukturę Class z MUI_CustomClass:

struct MUI_CustomClass *priv_class;
Object *obj;

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

Druga różnica między BOOPSI a MUI to funkcje używane do wywoływania konstruktora i destruktora. Używając MUI należy używać funkcji MUI_NewObject[A]() i MUI_DisposeObject(), ale tylko do klas publicznych. Obiekty klas prywatnych są po staremu tworzone przez NewObject(), jak w przykładzie powyżej. Główną zaletą MUI_NewObject() jest automatyczne otwieranie i zamykanie klas publicznych. Oto przykład:

Object *text;

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

'MUIC_Text jest makrem zdefiniowanym w pliku nagłówkowym <libraries/mui.h> i jest rozwijane do łańcucha tekstowego "Text.mui". Do nazw publicznych klas MUI powinno się odwoływać poprzez makra MUIC_, bezpośrednie używanie nazw nie jest zalecane. Makra pozwalają uniknąć błędów w nazwach klas, takie błędy dzięki użyciu makr zostaną wychwycone na etapie kompilacji. Na początek MUI sprawdza, czy klasa Text.mui nie znajduje się czasem na systemowej liście klas publicznych. Jeżeli nie, klasa jest ładowana z dysku i otwierana. Następnie tworzony jest obiekt. Zamykanie klasy jest również wykonane automatycznie. Wszystkie obiekty MUI powinny być usuwane funkcją MUI_DisposeObject(), której jedynym argumentem jest wskaźnik na obiekt do usunięcia, podobnie jak w przypadku DisposeObject().

MUI_DisposeObject(text);