Jak zostało wspomniane w poprzednim poście, istnieje schemat, by nie mówić 'szablon' klas.
Do jego obsługi potrzebna jest specjalizowana klasa, cos w rodzaju rozdzielnika. Ale przyglądając sie wprawce - generowaniu mudowego miasta, zauważyłem potrzebę jeszcze kilku zaprzyjaźnionych funkcji.
Są to funkcje: 'dołączania argumentu', wywoływania, korekty i naprawy.
Tak. Argumenty Obiektów sa Obiektami przekazywanymi w inny sposob. Daje się je na listę, a następnie 'wywołuje' Obiekt. Kiedy dany Obiekt zna i akceptuje argument, wywoływana jest 'standardowa', napisana funkcjonalnie (jak ktoś chce, to nawet obiektowo) funkcja.
Każda operacja na Obiekcie może go modyfikować. Może zmieniać stan tego Obiektu, może wskazać, że jest niepotrzebny. Może wyzwolić kaskadę kolejnych zmian na Obiektach. Dlatego wartością funkcji powinien być integer, wartość boolowska ma za malo możliwości.
Wartością wyjścia jest liczba ujemna w przypadku krytycznego błędu. Błąd dotyczy jednak tylko danego Obiektu! Po jego naprawie można działać dalej.
Wartość 0 oznacza pomyślne zakończenie, wartości dodatnie oznaczają informacje o stanie Obiektu do systemu. Po przechwyceniu wartości, z Obiektem mozna zrobić to, co zaproponował swoją wartością, skasować, odłożyć do kolejki do ponownego wywołania.
W projektowaniu walczą ze sobą: kolejka na void* oraz klasa abstrakcyjna, będaca korzeniem wszystkich Obiektów. A na razie powinienem pamiętać o sprawdzaniu zwracanej wartości!
