Dziś miało być bardziej kolorowo… Ale czasami zadziała tzw. złośliwość rzeczy martwych i spowoduje, że pozostajemy bez sprawnego sprzętu 🙁 Tak więc mała zmiana planów: zamiast bawić się w pisanie widgetów, spróbujemy zastanowić się nad rozsądnym zaprojektowaniem ich struktury. Do dzieła!

Widget jako abstrakcja

Słowo “widget” samo w sobie definiuje jedynie ogólnie zbiór obiektów graficznych – bez konkretyzowania ich zadania czy kształtu. Mówiąc językiem developerów odzwierciedla pewną abstrakcję. Cóż bowiem znaczy stwierdzenie “narysuj widget” lub “stwórz widget“, jeśli nie będziemy posiadać precyzyjnej wiedzy na temat co dokładnie mamy narysować czy zbudować.

Z drugiej strony, niejako przypadkiem, stworzyliśmy szkic interfejsu jaki każdy widget powinien posiadać: zbuduj i narysuj 🙂 Osoby zaznajomione z Programowaniem Orientowanym Obiektowo (ang. OOP) zapewne już wiedzą dokładnie, że widget stanowi idealnego kandydata na tzw. klasę abstrakcyjną. Temat ten chciałbym rozwinąć w odrębnym artykule, w odniesieniu do języka C++.

Widget jako kontener

Czy widget może zawierać inne widgety? Oczywiście! Nawet nasza wstępna lista z poprzedniego artykułu zawiera widget typu Box, którego zadaniem jest tylko i wyłącznie “grupowanie” innych kontrolek.

Jaki ma sens tworzenie widgetu tylko po to, aby opakował inne? Czy to aby nie strata czasu i pracy?

Pozornie – tak. Obeszlibyśmy się również bez kontenerów. Mają one jednak jedną, ogromną zaletę. Widgety będące ich składnikami mogą “odziedziczyć” po swoim kontenerze np. krój czcionki czy kolorystykę. W ten sposób zamiast mozolnie tworzyć widget od zera, można bazować na nadrzędnych parametrach, dostarczanych przez kontener.

Na dziś starczy nam już rozważań, wymuszonych niejako problemami ze sprzętem. Mam nadzieję, że jutro uda się wskrzesić urządzenie z powrotem i pchnąć temat widgetów dalej.