Wzorce projektowe są bardzo popularnym tematem wśród programistów. Zwykle rozmawia się o nich w kontekście języków obiektowych i dużych systemów. Jednak podobnie jak z innymi zagadnieniami dotyczącymi architektury – część wzorców da się z powodzeniem przenieść na grunt systemów embedded. W dzisiejszym wpisie opowiem o trzech wzorcach z najpopularniejszego katalogu wzorców – książki „Gang of four” – które mogą zrobić najwięcej dobrego w architekturze systemów embedded.

Dobra architektura nie powstaje od razu. Jest ona raczej wypracowana na bazie różnych doświadczeń. Jednak w większości systemów jest ona określana na sztywno na samym początku, kiedy jeszcze nie mamy wystarczającej wiedzy, aby zrobić ją dobrze. Jest to źródłem wielu problemów z utrzymaniem. Zamiast tego powinniśmy pogodzić się z faktem, że dobre rozwiązania wymagają czasu i umożliwić architekturze ewolucję.

Z czego składa się architektura? Z modułów i warstw. To jest intuicyjny podział wynikający z potrzeby dzielenia złożonych problemów na mniejsze i grupowania podobnych zadań. Jednak o ile co do samego istnienia warstw i modułów nikt nie ma zastrzeżeń, to strategie ich wydzielania zależą często tylko od naszej fantazji. Dzisiaj zdefiniujemy sobie czym są owe moduły i warstwy oraz w jaki sposób powinny być wydzielane. Od razu uprzedzam, że będę tutaj mówił o architekturze dużego systemu realizującego wiele zadań jednocześnie. Duża część projektów embedded jest na tyle prostych, że tak skomplikowana architektura byłaby w nich jedynie obciążeniem.

W systemach embedded zwykle skupiamy się na niskopoziomowych interakcjach ze sprzętem. Poznajemy nowe interfejsy, wykorzystujemy kolejne zewnętrzne układy i wykorzystujemy nowe rodziny procesorów. Jednak to z czym sobie naprawdę nie radzimy to poskromienie rosnącej złożoności tworzonych przez nas systemów. W większości systemów prawdziwym problemem jest architektura, czyli systematyczne podejście do radzenia sobie z tą złożonością. Jako branża embedded nie potrafiliśmy do tej pory stworzyć jasnych zasad tworzenia architektury i utrzymywania jej w projekcie. Zwykle dominują dwa podejścia – albo architektury nie ma wcale, albo tworzona jest na początku przed rozpoczęciem kodowania i okazuje się niepraktyczna. W tym wpisie dzielę się swoimi spostrzeżeniami na temat problemów z architekturą w embedded.