[ Pobierz całość w formacie PDF ]
wprowadzenie zmian zazwyczaj nie stanowi problemu. Jeśli jednak mamy do czynie-
nia z coraz bardziej rozbudowanymi programami, to coraz trudniej je modyfikować.
Tego rodzaju aplikacje przypominają czasami ogromne domki z kart, a wyciągnięcie
tylko jednego elementu może spowodować zawalenie się całej konstrukcji.
Rozszerzalność jest potrzebna ze względu na to, że u podstaw każdego programu
komputerowego leży czynnik ludzki, co czyni go podatnym na błędy, które trzeba
pózniej poprawiać. Wezmy pod uwagę na przykład programy biznesowe (takie jak
informacyjne systemy zarządzania). Wystarczy, że zmienią się jakieś przepisy prawa
lub firma zostanie przejęta przez konkurencję, a już założenia, na których oparty był
system, przestaną być aktualne. Jest to dość sztampowy przykład, ale niewiele osób
zdaje sobie sprawę z tego, że z podobną sytuacją mamy do czynienia nawet w pro-
gramach naukowych, w przypadku których możemy zakładać, że za miesiąc lub dwa
będą nadal obowiązywały te same prawa fizyki co dzisiaj. Jednak może ulec zmianie
sposób, w jaki je pojmujemy, lub procedura modelowania pewnych zjawisk.
W tradycyjnym podejściu do inżynierii oprogramowania nie przykładano wy-
starczająco dużej wagi do zmian. Zamiast tego opierano się na idealistycznym po-
strzeganiu cyklu życia oprogramowania, w którym wymagania były zamrażane już na
etapie analizy potrzeb. Na dalszych etapach skupiano się już wyłącznie na projekto-
waniu i tworzeniu rozwiązania. Jest to zrozumiałe. Pierwszym krokiem na drodze
rozwoju inżynierii programowania było opracowanie przejrzystych technik formuło-
wania i rozwiązywania stałych, niezmiennych problemów. Dopiero pózniej zaczęto
się martwić, co należy robić w sytuacji, gdy problem ulega zmianie w czasie, kiedy
wciąż szukamy rozwiązania. Obecnie podstawowe techniki inżynierii oprogramowa-
nia są już opracowane i dlatego pora zająć się opisywanym problemem. Zmiany są
nieodłącznym elementem procesu tworzenia oprogramowania. Możemy mieć do czy-
nienia ze zmianami wymagań, sposobu ich pojmowania, algorytmów, sposobu pre-
zentacji danych lub technik implementacyjnych. Umożliwienie łatwego ich wprowa-
dzania jest głównym zadaniem techniki obiektowej i tematem przewodnim tej książki.
Choć wiele technik zwiększających rozszerzalność można prezentować na pro-
stych przykładach, ich znaczenie staje się jasne dopiero w przypadku większych pro-
jektów. Przy zwiększaniu rozszerzalności kluczową rolę odgrywają dwie zasady:
" Prostota projektu proste architektury zawsze łatwiej zaadaptować do zmian niż
złożone.
" Decentralizacja im większa autonomia poszczególnych modułów, tym więk-
sze prawdopodobieństwo, że prosta zmiana specyfikacji będzie wymagała zmo-
dyfikowania tylko jednego lub kilku modułów i nie wywoła reakcji łańcuchowej
w całym systemie.
34 ROZDZIAA 1. JAKOZ OPROGRAMOWANIA
Technika programowania zorientowanego obiektowo jest przede wszystkim tech-
niką tworzenia takich architektur systemów, które pomagają projektantom w tworzeniu
zdecentralizowanych programów o prostej strukturze (nawet jeśli są to duże projekty).
Prostota i decentralizacja to kluczowe zagadnienia, które będą się przewijały w naszej
dyskusji do czasu, aż w kolejnych rozdziałach sformułujemy zasady rządzące techniką
obiektową.
Przystosowanie do wielokrotnego użycia
Definicja przystosowania do wielokrotnego użycia
Przystosowanie do wielokrotnego użycia to zdolność elementów składowych opro-
gramowania do pełnienia roli elementów konstrukcyjnych wielu różnych aplikacji.
Potrzeba przystosowania do wielokrotnego użycia wynika z obserwacji, że w wielu
programach komputerowych przewijają się te same wzorce. Dlatego powinna istnieć
możliwość wykorzystania tych podobieństw, pozwalająca na uniknięcie ponownego
wynajdywania koła. Dostrzegając taki wzorzec, możemy wyodrębnić element pro-
gramu, który nadaje się do wykorzystania w wielu różnych projektach.
Przystosowanie do wielokrotnego użycia ma wpływ na wszystkie inne aspekty
jakości oprogramowania, ponieważ dzięki niemu nie trzeba pisać tak dużo kodu jak
dawniej i można skupić się (przy takim samym całkowitym koszcie projektu) na po-
prawianiu innych czynników, takich jak poprawność czy odporność.
Jest to przykład kolejnego zagadnienia, na które nie położono wystarczająco du-
żego nacisku w tradycyjnym pojmowaniu cyklu życia aplikacji. Powody historyczne
są tu takie same jak w poprzednim przypadku. Przyjęto, że najpierw trzeba znalezć
rozwiązanie jednego problemu, a dopiero potem można stosować je w odniesieniu do
innych problemów. Jednak rozrastanie się programów komputerowych i próba uczy-
nienia z informatyki prawdziwego przemysłu doprowadziły do tego, że przystosowanie
kodu do wielokrotnego użycia stało się palącą potrzebą.
[ Pobierz całość w formacie PDF ]