Szkielety, zręby, rusztowania, ruiny

Zbieram sobie spokojnie materiały do prezentacji o Inversion of Control w Springu (w sumie to raczej o Springu:) na potrzeby naszego JUG. Aż tu nagle... prowokujący post Piotrka.

Jako wstęp do pracy nad prezentacją o Springu, dziś będzie o frameworkach w ogóle.

Najpierw należy odróżnić framework od biblioteki. Biblioteka to będzie chyba zbiór reużywalnych i sprawdzonych kawałków kodu skupionych wokół jakiegoś problemu. Nie będę tutaj silił się na definicję, wiadomo o co chodzi (jeżeli ktoś się chce do niej przyczepić to proszę bardzo;P). Ogólnie sytuacja jest taka: masz zestaw klas czy procedur (w wersji oldskulowej) i radź sobie. Składaj je w coś większego.
Natomiast framework ma już swą formę. Jest rozwiązaniem ogólnym, w którym brakuje jedynie szczegółów, które to musimy właśnie zdefiniować. Coś jak wypełnianie szkieletu mięsem. Zazwyczaj zajmuje się powtarzalnymi szczegółami technicznymi - dla nas zostaje biznes. Przynajmniej takie są założenia;)
Jeszcze jedna kategoria: zaznaczam, że nie chcę wyjść na zarozumiałego dupka, który lepiej od twórców Springa wie czym jest Spring, ale wydaje mi się, że jest on biblioteką frameworków a nie frameworkiem.


Komentując posta podlinkowanego przez Piotrka... Rzeczywiście jest tak, że jakaś część programistów podchodzi do frameworków z oporem. Dziwne, bo wydaje mi się, że prędzej czy później każdy jakieś swoje nano-frameworki tworzy. Jest to chyba immanentna cecha programistów, którzy uchwycili w pewnym momencie Object Oriented. Najpierw zaczynasz od uogólnień i abstrakcji. Projekt cieszy swą elegancją i prostotą - cieszy to niestety tylko Ciebie i ew. paru kolegów. Później w razie potrzeby refaktoryzacja do paru wzorców projektowych oraz wyciągnięcie konfiguracji na zewnątrz kodu. Okazuje się, ze konfiguracji jest zbyt wiele (koszmar XML), więc idąc z duchem czasu stawiamy na Convention Over Configuration. I quasi-framework gotowy. Heh hiestety zazwyczaj jego życie trwa jeden projekt bo do innych się nie nadaje... jest zbyt mało ogólny - ale to szczegół.

Z drugiej strony... frameworki budzą niechęć. Z obserwacji wydaje mi się, że przyczyny mogą być różne:

ignorancja - w przypadku niektórych frameworków bez biegłości w OO i wzorcach projektowych może być niestety ciężko połapać się o co chodzi w danym frameworku. Przytłacza on swą pozorną (bo wynikającą z niewiedzy) złożonością. Patrząc bardziej ogólnie problem może polegać na niechęci do zmian i poznawania nowych rzeczy.

pycha - jest jakaś część programistów, która nie wyrosła jeszcze ze śpioszków i twierdzą, że każdą kupę potrafią zrobić sami. Więc radośnie wynajdują np ORM na nowo. Tworzą coś co już zostało napisane zamiast skupić się na rozwiązaniu problemu klienta (biznesowego problemu). Bo ja sam UMIE i nie potrzebuje tutaj niczyjej pomocy a wzorce są dla cieniasów - Nie no fajnie, ale to do cholery kosztuje! Oczywiście niektórzy z czasem dochodzą do poziomu na którym ich rozwiązania są reużywalne - powstają wówczas chałupnicze nano-frameworki domowej roboty. Pycha każe im sądzić, że są one lepsze i mają mniej bugów niż coś co powstało w silnym community. Patrząc bardziej ogólnie: pyszne Zosie Samosie gardzą nie tylko frameworkami ale i oldskulowymi bibliotekami - po prostu wszystkim czego same radośnie nie spłodziły.

lenistwo - lepiej samemu coś napisać niż wertować strony dokumentacji istniejącego frameworka. Do tego jeszcze tony konfiguracji (niestety nasz własny framework jeżeli ma być frameworkiem też będzie musiał być jakoś konfigurowalny:P). Oczywiście na krótką metę lub w małych projektach pisanie z palca może być bardziej opłacalne. Patrząc bardziej ogólnie: co z samorozwojem? Przyjrzenie się architekturze sprawdzonego rozwiązania zazwyczaj otwiera nowe furtki w mózgu - pewne konstrukcje projektowe mogą być na prawdę inspirujące.

Kwestia najważniejsza: tytułowe ruiny. Frameworki (nawet te poważne i "oficjalne") nie zawsze muszą być arcydziełem. Nie koniecznie muszą rzeczywiście wspierać nas w rozwiązaniu problemu. W praktyce mogą przeszkadzać i irytować. Np taki JSF - wydaje się być zaprojektowany przez doskonałych inżynierów oprogramowania, którzy jednak niestety chyba nigdy w życiu nie popełnili żadnej aplikacji webowej (choćby w php).

//===================
Dobry framework powinien być tak zaprojektowany aby można było wymienić w nim nie tylko "mięcho" ale również część niego samego, czyli "szkieletu". Stąd chyba w Springu tyle interfejsów w bardziej jak i mniej newralgicznych miejscach:)