Poznaj kluczowe idee Alana Kaya stojące za Smalltalk i wczesnymi GUI — oraz jak ukształtowały współczesne postrzeganie oprogramowania jako systemów współdziałających obiektów.
Alan Kay to nie tylko nazwisko z historii programowania. Wiele powszechnych założeń o komputerach — czym jest „okno”, dlaczego oprogramowanie powinno być interaktywne, jak programy mogą powstawać z współpracujących części — ukształtowały idee, które on promował (często razem z zespołami w Xerox PARC).
Ten tekst dotyczy koncepcji, nie ciekawostek. Nie musisz umieć programować, żeby go zrozumieć, i nie znajdziesz tu przeglądu drobiazgowych technicznych szczegółów. Skupimy się raczej na kilku modelach myślowych, które wciąż pojawiają się w narzędziach i produktach, z których korzystamy: jak oprogramowanie można rozumieć, zmieniać i uczyć się z niego.
Po pierwsze, Smalltalk: nie tylko język programowania, ale całe środowisko pracy, które zachęcało do eksploracji i uczenia się.
Po drugie, GUI (graficzne interfejsy użytkownika): okna, ikony, menu — interaktywne oprogramowanie jako coś, czym można bezpośrednio manipulować, a nie tylko wydawać polecenia.
Po trzecie, myślenie systemowe: traktowanie oprogramowania jako zestawu współdziałających części z pętlami sprzężenia zwrotnego, a nie jako sterty plików z kodem.
Nie przedstawi Kaya jako samotnego geniusza i nie będzie twierdził, że jeden „właściwy” paradygmat rozwiązuje wszystko. Niektóre pomysły zadziałały świetnie, inne były źle rozumiane, a część nie rozprzestrzeniła się tak szeroko, jak mogła.
Cel jest praktyczny: na końcu powinieneś patrzeć na współczesne aplikacje i kod z jaśniejszym zrozumieniem dlaczego czują się tak, jak się czują — i co możesz zapożyczyć do swojego następnego projektu.
Alan Kay trafił do kultury komputerowej potężnej, kosztownej i w dużej mierze nieprzystępnej dla zwykłych ludzi. Komputery traktowano jak współdzieloną infrastrukturę: rezerwowałeś czas, wysyłałeś zadanie i czekałeś na wynik. Ten model kształtował wszystko — jak wyglądały programy, kto z nich korzystał i co uważano za „sukces”.
Dla wielu użytkowników korzystanie z komputera oznaczało przekazanie zadania maszynie (często przez karty lub terminale w kolejce) i otrzymanie wyników później. Jeśli coś poszło nie tak, nie „grzebałeś” i nie uczyłeś się — wysyłałeś zadanie ponownie i czekałeś. Eksploracja była powolna, a komputer bardziej przypominał zdalną usługę niż narzędzie, z którym można myśleć.
Celem Kaya nie były jedynie „mniejsze komputery”. Chodziło o inną relację: komputer jako osobiste medium do nauki, pisania, symulacji, rysowania i budowania pomysłów — szczególnie dla dzieci i osób niebędących specjalistami. To wymagało natychmiastowości. Trzeba było widzieć, co robią twoje działania, szybko poprawiać i utrzymywać twórczy flow.
Aby dążyć do takiej zmiany, potrzebne było miejsce na eksperymenty z sprzętem, oprogramowaniem i projektowaniem interakcji jednocześnie. Laboratoria badawcze, takie jak Xerox PARC, finansowały długoterminowe ryzyka: nowe wyświetlacze, nowe urządzenia wejściowe, nowe modele programowania i sposoby łączenia tego w spójne doświadczenie. Celem nie było wdrożenie funkcji — celem było wynalezienie nowego sposobu korzystania z komputera.
Jeśli komputer ma być maszyną do nauki i tworzenia, użyteczność nie może być dodatkiem. Interfejs musiał wspierać odkrywanie, informację zwrotną i zrozumiałe działania. Ten nacisk skierował Kaya ku systemom, w których „odczucie” interakcji — co się dzieje, gdy klikniesz, edytujesz lub eksplorujesz — było ściśle powiązane ze strukturą samego oprogramowania.
Alan Kay nie zaczynał od pytania „Jak przyspieszyć pracę biurową?”. Zaczął od innego pytania: co gdyby dziecko mogło nosić ze sobą osobisty komputer jak książkę i używać go do eksplorowania pomysłów, tworzenia rzeczy i uczenia się przez działanie? Ta myśl stała się Dynabookiem — mniej specyfikacją produktu, a bardziej gwiazdą polarną dla komputerów osobistych.
Dynabook wyobrażano sobie jako lekki, zasilany bateryjnie i zawsze dostępny. Jednak najważniejsze nie było „przenośny”, lecz „osobisty”. Ten komputer miał należeć do użytkownika tak jak notatnik lub instrument — coś, co kształtujesz z czasem, a nie tylko obsługujesz.
Równie ważne: musiał być przystępny. Cel Kaya nie polegał na ukrywaniu informatyki za ścianą menu; chodziło o to, by ludzie stopniowo stawali się autorami, a nie tylko konsumentami.
„Killer appsy” Dynabooka to czytanie, pisanie, rysowanie, komponowanie muzyki, symulowanie doświadczeń naukowych i budowanie interaktywnych opowieści. Traktował programowanie jako umiejętność czytania i pisania — inny sposób wyrażania pomysłów — a nie specjalistyczny zawód zarezerwowany dla profesjonalistów.
To przesunięcie zmienia definicję „dobrego oprogramowania”. Narzędzie do nauki musi zapraszać do majsterkowania, dawać szybką informację zwrotną i sprawiać, że warto próbować ponownie.
Tu wchodzą Smalltalk i wczesne GUI. Jeśli chcesz, by ludzie tworzyli, potrzebujesz bezpośredniej manipulacji, natychmiastowych rezultatów i środowiska, w którym eksperymentowanie jest naturalne. Żywy, interaktywny system Smalltalka i wizualne metafory GUI wspierały ten sam cel: skracały dystans między pomysłem a działającym artefaktem.
Dynabook nie „przewidywał tabletu”. Proponował nową relację z komputerem: medium do myślenia i tworzenia. Wiele urządzeń może to przybliżyć, ale wizja dotyczy upodmiotowienia użytkownika — szczególnie uczących się — a nie konkretnego rozmiaru ekranu czy projektu sprzętu.
Gdy ludzie słyszą „Smalltalk”, często wyobrażają sobie język programowania. Zespół Kaya traktował go jednak jako coś większego: kompletne środowisko pracy, w którym język, narzędzia i doświadczenie użytkownika zostały zaprojektowane razem.
W prostych słowach: w Smalltalku wszystko jest obiektem. Okna na ekranie, tekst, który wpisujesz, przyciski, które klikasz, liczby, które obliczasz — każdy to obiekt, któremu możesz zlecić wykonanie czegoś.
Smalltalk powstał z myślą o nauce przez działanie. Zamiast pisać kod, kompilować i mieć nadzieję, że działa, możesz inspekcjonować obiekty podczas działania systemu, zobaczyć ich aktualny stan, zmienić je i natychmiast wypróbować nowy pomysł.
Ta żywotność miała znaczenie, bo zmieniała programowanie w eksplorację. Nie tworzyłeś tylko plików — kształtowałeś działający świat. Zachęcało to do ciekawości: „Czym jest ten obiekt?”, „Co zawiera?”, „Co się stanie, jeśli to zmienię?”.
Narzędzia deweloperskie Smalltalka nie były osobnymi dodatkami. Przeglądarki klas, inspektory, debugery i edytory były częścią tej samej obiektowej rzeczywistości. Narzędzia rozumiały system od środka, bo same były zbudowane w tym samym medium.
To ścisłe powiązanie zmieniło odczucie pracy nad oprogramowaniem: mniej zarządzania odległym kodem źródłowym, bardziej bezpośrednia interakcja z systemem, który budujesz.
Pomyśl o edytowaniu dokumentu, który jest otwarty i responsywny — zmiany formatowania pojawiają się natychmiast, możesz szukać, przestawiać i cofać bez „przebudowy” dokumentu. Smalltalk dążył do takiej natychmiastowości, ale dla programów: edytujesz działającą rzecz, widzisz rezultaty od razu i kontynuujesz pracę.
Najbardziej użyteczny model myślowy Kaya to nie „klasy i dziedziczenie”, lecz pomysł, że obiekt to mały, samodzielny komputer: przechowuje swój stan (to, co wie teraz) i sam decyduje, jak zareagować, gdy poprosisz go o coś.
Pomyśl o każdym obiekcie jako o mającym:
To ramowanie jest praktyczne, bo przesuwa uwagę z „gdzie przechowywane są dane?” na „kto jest odpowiedzialny za obsługę tego?”.
Częstym nieporozumieniem jest traktowanie obiektów jako wypasionych rekordów danych: pakiet pól z kilkoma pomocniczymi funkcjami. W takim podejściu inne części programu swobodnie zaglądają do środka i manipulują wnętrzem.
Pogląd Kaya jest bliższy aktorom w systemie. Nie zaglądasz do obiektu i nie przestawiasz jego szuflad. Wysyłasz żądanie i pozwalasz mu zarządzać swoim stanem. Ta separacja jest sednem sprawy.
Przekazywanie komunikatów to po prostu żądanie/odpowiedź.
Wyobraź sobie kawiarnię: nie wchodzisz do kuchni i nie gotujesz sobie sam. Składasz zamówienie („proszę kanapkę”), i otrzymujesz wynik („oto twoja kanapka” lub „nie mamy chleba”). Kawiarnia decyduje, jak zrealizować zamówienie.
Obiekty w oprogramowaniu działają podobnie: wysyłasz komunikat („oblicz sumę”, „zapisz”, „wyrenderuj się”), a obiekt odpowiada.
Gdy inne części systemu zależą tylko od wiadomości, możesz zmieniać wewnętrzne działanie obiektu — zamieniać algorytmy, zmieniać sposób przechowywania, dodać cache — bez konieczności przepisywania reszty systemu.
W ten sposób systemy rosną bez łamania wszystkiego: stabilne umowy na granicach, a wewnątrz komponentów dowolność.
Ludzie często utożsamiają „programowanie obiektowe” z używaniem klas. To zrozumiałe — większość języków uczy OOP przez diagramy klas i drzewa dziedziczenia. Jednak pierwotny nacisk Kaya był inny: myśl w kategoriach komunikujących się części.
Klasa to plan: opisuje, co coś wie i co potrafi robić.
Instancja (obiekt) to konkretna rzecz wykonana według tego planu — twoja „konkretna sztuka”.
Metoda to operacja, którą obiekt wykonuje, gdy ją mu zlecisz.
Stan to aktualne dane obiektu: to, co zapamiętuje teraz i co może się zmieniać.
Smalltalk popularyzował jednolity model obiektowy: wszystko jest obiektem i wchodzi się w interakcję z obiektami w spójny sposób. Kładł też duży nacisk na przekazywanie komunikatów — nie zaglądasz do wnętrza innego obiektu; wysyłasz mu wiadomość i pozwalasz zdecydować, co zrobić.
To podejście współgra z wiązaniem późnym (dynamicznym wyborem metody w czasie wykonania): program może zdecydować, która metoda obsłuży komunikat, w oparciu o obiekt odbierający. Praktyczną korzyścią jest elastyczność: możesz podmieniać zachowania bez przepisywania wywołującego.
Przydatna reguła: projektuj wokół interakcji. Pytaj „jakie wiadomości powinny istnieć?” i „kto powinien być właścicielem tego stanu?”. Jeśli obiekty ładnie współpracują, struktura klas zwykle sama staje się prostsza i bardziej odporna na zmiany.
Graficzny interfejs użytkownika zmienił odczucie korzystania z oprogramowania. Zamiast zapamiętywać polecenia, możesz wskazywać rzeczy, przesuwać je, otwierać i widzieć efekty natychmiast. Okna, menu, ikony i przyciski sprawiają, że obsługa komputera przypomina obchodzenie się z przedmiotami — bezpośrednia manipulacja zamiast abstrakcyjnych instrukcji.
Ta „rzeczowość” naturalnie mapuje się na model obiektowy. W dobrze zaprojektowanym GUI niemal wszystko, co widzisz i z czym możesz wejść w interakcję, można potraktować jako obiekt:
To nie tylko wygoda programistyczna — to most pojęciowy. Użytkownik myśli w kategoriach obiektów („przenieś to okno”, „kliknij ten przycisk”), a oprogramowanie buduje te działania jako obiekty, które rzeczywiście potrafią je wykonać.
Gdy klikniesz, wpiszesz tekst lub przeciągniesz, system generuje zdarzenie. Z perspektywy obiektowej zdarzenie to w zasadzie wiadomość wysłana do obiektu:
Obiekty mogą następnie przekazywać wiadomości dalej („powiedz dokumentowi, żeby zapisał się”, „powiedz oknu, żeby się odrysowało”), tworząc łańcuch zrozumiałych interakcji.
Ponieważ UI składa się z trwałych obiektów o widocznym stanie, przypomina wejście do przestrzeni roboczej, a nie uruchomienie jednorazowego polecenia. Możesz zostawić okna otwarte, ustawić narzędzia, wrócić do dokumentu i kontynuować. GUI staje się spójnym środowiskiem — miejscem, w którym działania są rozmowami między widocznymi obiektami.
Jednym z najbardziej charakterystycznych pomysłów Smalltalka nie była cecha składniowa — był to image. Zamiast myśleć o programie jako o „kodzie źródłowym, który się kompiluje do aplikacji”, Smalltalk traktował system jako działający świat obiektów. Gdy zapisywałeś, mógłbyś zachować całe żywe środowisko: obiekty w pamięci, otwarte narzędzia, stan UI i bieżącą pracę.
System oparty na image to jak zatrzymanie filmu i zapisanie nie tylko scenariusza, lecz dokładnej klatki, scenografii i pozycji aktorów. Po wznowieniu wracasz tam, gdzie przerwałeś — z narzędziami otwartymi, obiektami nadal obecnymi i zmianami już w ruchu.
To wspiera ciasne pętle informacji zwrotnej. Możesz zmienić zachowanie, natychmiast to wypróbować, zaobserwować i poprawić — bez mentalnego resetu „przebuduj, uruchom, załaduj dane, wróć do ekranu”.
Ta sama zasada pojawia się we współczesnych przepływach „vibe-coding”: gdy możesz opisać zmianę prostym językiem, zobaczyć ją od razu i iterować, uczysz się systemu szybciej i zachowujesz impet. Platformy takie jak Koder.ai wykorzystują to, zamieniając budowanie aplikacji na konwersacyjną pętlę — planuj, poprawiaj, podglądaj — przy jednoczesnej możliwości eksportu i utrzymania kodu.
Echa idei image widać we funkcjach, które cenimy dzisiaj:
To nie są identyczne mechanizmy jak Smalltalk image, ale mają ten sam cel: skrócić dystans między pomysłem a rezultatem.
Zapisanie całego działającego świata stawia trudne pytania. Powtarzalność może ucierpieć, jeśli „prawda” żyje w mutowalnym stanie zamiast w czystym procesie budowania. Wdrażanie bywa trudniejsze: wysyłanie image może zacierać granicę między aplikacją, danymi i środowiskiem. Debugowanie też może być bardziej skomplikowane, gdy błędy zależą od konkretnej sekwencji interakcji i nagromadzonego stanu.
Zakład Kaya polegało na tym, że szybsze uczenie się i iteracja są warte tych komplikacji — i to założenie wciąż wpływa na to, jak wiele zespołów myśli o doświadczeniu dewelopera.
Gdy Alan Kay mówił o oprogramowaniu, często traktował je mniej jak stos kodu, a bardziej jak system: wiele części współdziałających w czasie, aby wytworzyć zachowanie, na którym nam zależy.
System nie jest definiowany przez pojedynczy komponent. Jest definiowany przez relacje — kto z kim rozmawia, o co można prosić i co się dzieje, gdy te rozmowy się powtarzają.
Kilka prostych komponentów może wygenerować złożone zachowanie, gdy dodasz powtarzalność i sprzężenie zwrotne. Zegarek odliczający, model aktualizujący stan i UI rysujący ekran mogą być z pozoru proste. Po złączeniu dają animacje, cofanie/ponawianie, autosave, alerty i momenty „dlaczego to się zmieniło?”.
Dlatego myślenie systemowe jest praktyczne: skłania do szukania pętli („gdy A się zmienia, B reaguje, co wywołuje C…”) i uwzględnienia czasu („co się stanie po 10 minutach używania?”), a nie tylko pojedynczych wywołań funkcji.
W systemie interfejsy mają większe znaczenie niż implementacja. Jeśli jedna część może komunikować się z inną tylko przez jasne wiadomości („zwiększ licznik”, „wyrenderuj”, „zarejestruj zdarzenie”), możesz wymieniać wnętrza bez przepisywania wszystkiego.
To bliskie naciskowi Kaya na przekazywanie komunikatów: nie kontrolujesz innych części bezpośrednio; prosisz, one odpowiadają.
Wyobraź sobie trzy obiekty:
Przepływ w czasie:
clicked.increment do CounterModel.changed(newValue).changed i przerysowuje się.record("increment", newValue).Żaden komponent nie musi zaglądać do wnętrza innego. Zachowanie wyłania się z rozmowy.
Alan Kay promował prostą, nadal odczuwalną ideę: oprogramowanie powinno być łatwe do nauczenia, a nie tylko potężne. „Sprytne” rozwiązania często optymalizują satysfakcję twórcy — skróty, ukryte triki, gęste abstrakcje — i zostawiają zwykłych użytkowników z koniecznością zapamiętywania rytuałów.
Kay zależało na prostocie, bo ona się skaluje: pojęcie, które początkujący może szybko pojąć, łatwiej przekazać, udostępnić i rozwinąć.
Wiele oprogramowania traktuje użytkowników jak operatorów: naciśnij odpowiednie przyciski, a otrzymasz wynik. Cel Kaya był bliższy narzędziu do myślenia — coś, co zachęca do eksploracji, wspiera próby i błędy i pozwala budować modele myślowe.
Dlatego cenił interaktywne systemy, w których widzisz, co się dzieje, i możesz od razu dostosować. Gdy system reaguje natychmiast i sensownie, uczenie się staje się częścią używania.
Kay często wykorzystywał naukę — wyobrażając sobie czasem dzieci jako użytkowników — jako wymuszacz jasności. Jeśli koncepcję można bezpośrednio manipulować, inspekcjonować i wyjaśnić bez uciekania się do gestów „bo tak działa”, jest większa szansa, że zadziała dla wszystkich.
To nie znaczy „projektuj tylko dla dzieci”. To znaczy używać przyswajalności jako testu jakości: czy system potrafi ujawnić swoją logikę?
Przyswajalność to cecha produktu. Możesz ją projektować, robiąc:
Zysk to nie tylko szczęśliwsi początkujący. To szybsze wdrożenie, mniej zgłoszeń do pomocy i produkt, który ludzie czują, że mogą rozszerzać — dokładnie ten rodzaj „agencji użytkownika”, który Kay chciał wzmacniać.
Praca Kaya nie „wynalazła wszystkiego, czego dziś używamy”, ale mocno wpłynęła na sposób myślenia o tworzeniu oprogramowania — zwłaszcza tego skierowanego do ludzi, a nie tylko maszyn.
Wiele współczesnych praktyk odbija idee, które Smalltalk i kultura Xerox PARC uczyniły realnymi i popularnymi:
Niektóre elementy pierwotnej wizji nie przeszły bez zmian:
Jeśli się przyjrzeć, wiele aktualnych wzorców rymuje się z przekazywaniem komunikatów: komponentowe UI (React/Vue), aplikacje zdarzeniowe i nawet mikroserwisy komunikujące się przez HTTP lub kolejki. To nie to samo, ale pokazuje, jak zasadnicza idea Kaya (systemy jako współdziałające części) jest reinterpretowana w kontekście współczesnych ograniczeń.
Jeżeli szukasz praktycznego pomostu między historią a praktyką, ostatnia sekcja (zobacz /blog/practical-takeaways) zamienia te wpływy w nawyki projektowe, które możesz zastosować od razu.
Prace Kaya mogą brzmieć filozoficznie, ale przekładają się na bardzo praktyczne nawyki. Nie musisz używać Smalltalka — ani nawet „robić OOP” — żeby skorzystać. Celem jest budowanie oprogramowania, które pozostaje zrozumiałe w miarę rozwoju.
Gdy zaczynasz (lub refaktoryzujesz), spróbuj opisać system jako zestaw ról, które współpracują:
To trzyma uwagę na odpowiedzialnościach, a nie na „klasach, bo musimy mieć klasy”.
Zanim zaczniesz dyskutować o tabelach w bazie czy hierarchii klas, zdefiniuj wiadomości — co jedna część prosi drugą o zrobienie.
Przydatne ćwiczenie: napisz krótką „konwersację” dla jednej akcji użytkownika:
Dopiero potem decyduj, jak te role zaimplementować (klasy, moduły, serwisy). To bliższe naciskowi Kaya na przekazywanie komunikatów: najpierw zachowanie, potem struktura.
Kay cenił żywe systemy, w których zmiany widać szybko. W nowoczesnym zespole zwykle oznacza to:
Jeśli nie widzisz, co się zmieniło — albo czy to pomogło — działasz na oślep.
Jeśli budujesz z wykorzystaniem workflowu sterowanego czatem (np. w Koder.ai), ta sama rada obowiązuje: traktuj prompt i generowane wyniki jako sposób na szybszą iterację, ale trzymaj granice explicite i używaj zabezpieczeń jak snapshoty/rollback i eksport kodu, aby system pozostał zrozumiały w czasie.
Jeśli ta sekcja rezonuje, poznaj dalej:
Te tematy to mniej nostalgii, a więcej rozwijania wyczucia: budowania oprogramowania, które jest przyswajalne, adaptowalne i spójne jako system.
Alan Kay postulował inną relację z komputerami: zamiast kolejkowanych zadań wsadowych — interaktywny, osobisty medium do nauki i tworzenia.
Ten sposób myślenia bezpośrednio ukształtował oczekiwania, które dziś uważamy za oczywiste — natychmiastowa informacja zwrotna, manipulowalne interfejsy i oprogramowanie, które można eksplorować i modyfikować w trakcie pracy.
Dynabook był wizją przenośnego, osobistego komputera zaprojektowanego przede wszystkim dla nauki i twórczości (czytanie, pisanie, rysowanie, symulacje).
To nie tyle „przepowiednia tabletów”, ile określenie, jak powinno się czuć upodmiotowione korzystanie z komputera: użytkownicy jako autorzy, a nie tylko operatorzy.
W Smalltalku język, narzędzia i interfejs tworzyły spójne środowisko.
W praktyce oznacza to możliwość inspekcji działających obiektów, zmiany zachowania w locie, interaktywnego debugowania i kontynuowania pracy bez ciągłego przebudowywania i restartowania — skracając dystans między pomysłem a rezultatem.
Istota idei „obiektów i przekazywania komunikatów” nie sprowadza się do klas i dziedziczenia. To obiekty jako niezależne agenty, które komunikują się przez wysyłanie wiadomości.
W projektowaniu oznacza to definiowanie wyraźnych granic: wywołujący polegają na tym, jakie wiadomości obiekt przyjmuje, a nie na jego wewnętrznej strukturze danych.
Częsty błąd to traktowanie OOP jako taksonomii typów: wiele klas, głębokie dziedziczenie i współdzielone, mutowalne dane.
Lepsza zasada, zgodna z poglądami Kaya:
GUI sprawia, że praca z oprogramowaniem przypomina manipulowanie rzeczami (okna, przyciski, ikony). To naturalnie pasuje do modelu obiektowego, w którym każdy element UI ma stan i zachowanie.
Akcje użytkownika (kliknięcia, przeciągnięcia, naciśnięcia klawiszy) stają się zdarzeniami, czyli de facto wiadomościami wysyłanymi do obiektów, które mogą dalej przekazywać żądania po systemie.
Smalltalkowy image zapisuje całe działające środowisko: obiekty w pamięci, otwarte narzędzia, stan UI i bieżącą pracę.
Korzyści:
Wady:
Myślenie systemowe skupia się na zachowaniu w czasie: pętlach sprzężenia zwrotnego, reakcjach kaskadowych i tym, kto z kim rozmawia.
W praktyce prowadzi to do projektów z jaśniejszymi interfejsami (wiadomości) i mniejszą liczbą ukrytych zależności, bo traktuje aplikację jako zbiór współdziałających części — nie tylko izolowanych funkcji.
Stosuj projektowanie message-first dla jednego przepływu:
Współczesne narzędzia często rezonują z celami Kaya, choć implementują je inaczej:
To nie to samo co Smalltalk image, ale dążą do tej samej praktycznej korzyści: uczynić zmiany i naukę tanimi.
Checkout, PricingRules, Inventory, Payment).getTotal, isAvailable, authorize).Dopiero potem wybierz implementacje (klasy, moduły, serwisy). To podejście pozwala skorzystać z idei Kaya bez używania Smalltalka.