Blog naukowy. Zdobądź wiedzę z języków obcych, jazdy na łyżwach...

Programowanie obiektowe – Czy wystarczy mosiężna kula? cz. II

Coggins wraca do podstawowego problemu dotyczącego oprogramowania. Wskazuje, że jednym ze sposobów sprostania niezaspokojonym potrzebom związanym z oprogramowaniem jest zwiększenie liczby zajmujących się nimi osób przez rozwijanie umiejętności naszych klientów i włączanie ich do tych prac. To przemawia za projektowaniem od ogółu do szczegółu:

Gdy budujemy klasy bardziej „gruboziarniste” dotyczące koncepcji, nad którymi nasi klienci już pracują, mogą oni uczestniczyć w powstazoaniu projektu i zadazuać na jego temat pytania zv miarę rozwijania go. Mogą też współpracozoać przy opracowywaniu przykładów testozoych. Moich zospół- pracozunikózo – okidistów – nie obchodzą stosy: interesują ich opisy rogózo- ki w postaci zoielomianózo Legendre’a. Z małą skalą hermetyzacji zoiążą się małe korzyści. David Parnas, którego praca naukowa dala początek koncepcjom obiektowym, widzi sprawę inaczej. Napisał do mnie:

Odpowiedź jest prosta. Technologia obiektowa wiązała się z wieloma złożonymi językami. Zamiast uświadamiać ludziom, iż jest to rodzaj projek- toiuania, i uczyć ich zasad projektowania, tłumaczono, że polega ona na zastosowaniu określonego narzędzia. Języki jednak niewiele dają, jeżeli się nie wie, jak projektować. W efekcie powstają złe projekty, a ludzie nie potrafią w pełni wykorzystać możliwości danego języka. Jeśli dalej tak będzie, technologia obiektowa się nie przyjmie.

Koszty ponoszone z góry, korzyści uzyskiwane z dołu. Osobiście jestem przekonany, że metody obiektowe stanowią szczególnie ostry przypadek choroby występującej w wypadku wielu udoskonaleń metodycznych. Koszty ponoszone z góry są znaczne. Są to przede wszystkim koszty szkolenia programistów, żeby myśleli w zupełnie nowy sposób, a także dodatkowe nakłady poniesione na nadanie funkcjom formy klas uogólnionych. Korzyści, które uważam za rzeczywiste, a nie za hipotetyczne, występują w całym cyklu rozwojowym: jednakże spore korzyści uzyskuje się w trakcie budowania kolejnych programów, rozwijania ich i pielęgnacji. Coggins mówi: „Techniki obiektowe nie spowodują, że prace nad pierwszym projektem, czy drugim, będą przebiegać szybciej. Ale piąty w rodzinie pójdzie już błyskawicznie”22.

Inwestorzy każdego dnia ryzykują pieniądze, licząc na osiągnięcie w przyszłości przewidywanych acz wątpliwych korzyści. Jednakże w wielu firmach programistycznych wymaga to prawdziwej odwagi ze strony kierowników, o którą znacznie trudniej niż o kompetencje techniczne lub sprawność administracyjną. Jestem przekonany, że konieczność ponoszenia nakładów z góry i uzyskiwania korzyści z dołu jest największą przyczyną opóźnienia w rozpowszechnianiu technik obiektowych. Mimo to jednak w wielu środowiskach systematycznie język C++ zastępuje C.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.