czwartek, stycznia 29

JSR294 – modułowość w Javie 7

Problem modułowości i reużywalności aplikacji pisanych w Javie znany jest nie od dziś. Chyba najważniejszą właściwością następnego wydania Javy (7.0) ma być modułowość sporego i czasami zbyt ciężkiego pakietu programistycznego JDK. Podkreślił to ostatnio także Mark Reinhold, główny architekt platformy Java Standard Edition, który jest odpowiedzialny za prace nad następną wersją. W swoim blogu zapowiedział inaugurację projektu Jigsaw, inicjatywy w ramach społeczności OpenJDK, której celem jest modułowość JDK 7 oraz praca nad specyfikacją JSR 294 "Improved Modularity Support in the Java Programming Language".

JSR 294 określa wprowadzenie tzw. superpakietów, a także rozszerzenie języka Java oraz wirtualnej maszyny Javy (JVM), w celu zagwarantowania możliwości tworzenia modularnego oprogramowania w Javie. Reinhold zamierza uwzględnić JSR 294 w Javie 7.
Kolejnymi specyfikacjami odnoszącymi się do tej tematyki są JSR 277 i JSR 291.
JSR 277 "Java Module System" wprowadza format dystrybucyjny oraz repozytorium dla pakietów Javy oraz przynależnych zasobów. Oprócz tego specyfikacja opisuje mechanizmy ładowania i integracji klas w czasie działania programu. Specyfikacja ta jest jednak krytykowana za zbyt małą elastyczność. JSR 277 nie będzie uwzględniona w Javie 7. Jak ktoś nie lubi czytać to więcej można się dowiedzieć z serwisu parleys.com, jest tam prezencja JSR-277 Java Module System


Z kolei specyfikacja JSR 291 "Dynamic Component Support for Java" została opublikowana w lutym 2006 roku przez firmę IBM. Określa ona standaryzację centralnych modułów frameworka OSGi w ramach JCP i osadzenie ich w platformie Java Standard Edition. Jako przykład służy tutaj obowiązująca w przypadku platformy JavaME specyfikacja JSR 232 "Mobile Operational Management". Celem JSR 291 jest zdefiniowanie dynamicznego frameworka, który obsługiwałby istniejące środowiska Java SE bazujące na dynamicznym modelu komponentów OSGi. Sun od samego początku podawał w wątpliwość konieczność wprowadzania tej specyfikacji, ponieważ koncepcja osadzenia podobna do JSR 291 została już opisana w specyfikacji wydanej przez konsorcjum OSGi. Mimo że pomysł OSGi został pierwotnie opracowany na platformie Javy, istnieją komponenty OSGi niezintegrowane z tym językiem. Ponieważ Reinhold nie wspomina o tej specyfikacji JSR 291, nie należy przypuszczać, aby została ona uwzględniona w Javie 7.


Jeżeli interesuje was problem modularności oprogramowania polecam linki (najlepiej oglądać w kolejności :P):

piątek, stycznia 2

Refaktoryzacja to...

witam;

Postawiłem sobie osobiście cel pisania o JavaFX, nawet rozpocząłem jakieś przymiarki, ostatecznie miałem napisać kilka słów o JSF + Seam, ale pewnego dnia udało mi się przeczytać książkę o czymś innym ...

Refaktoryzacja to zmiany wewnętrznej struktury kodu programu, które mają za zadanie zwiększyć czytelność oraz obniżyć koszt wprowadzania zmian. Mówi się że, poprawnie przeprowadzona refaktoryzacja nie zmienia sposobu działania aplikacji od strony użytkownika.

Ta prosta definicja pozwala zapoznać się terminem refaktoryzacji, ale formalna definicja podana przez D.Roberts'a w 1998 ma postać:

R = (pre; T; P)

gdzie:
- pre - asercja która musi być spełniona by przekształcenie R było prawdziwe;
- T - transformacja kodu programu;
- P - funkcja przekształcająca warunki początkowe na warunki końcowe, określa warunki końcowe, które są prawdziwe po przeprowadzeniu transformacji T;

Refaktoryzacja ma za zadanie wprowadzić zmiany w nasz kod, ale zmiana struktury programu może stanowić dla niego ogromne zagrożenie, jeżeli by po jej zakończeniu program miał działać inaczej. Dlatego najważniejszym warunkiem poprawnie przeprowadzonej refaktoryzacji, jest zapewnienie, że nie wprowadzi ona żadnych zmian do działa aplikacji;


Ale jak można zweryfikować poprawności wprowadzanych zmian, istnieją dwie metody weryfikacji poprawności przekształceń:
  • analityczna - wykorzystanie statycznych informacji; metoda nie wymaga uruchomienia programu
  • dynamiczna - weryfikacja przeprowadzana przy pomocy testów; wymaga uruchomienia aplikacji
Podział metod weryfikacji poprowadził do powstania podziały przekształceń na:
  • proste - najczęściej zautomatyzowana weryfikacja przy pomocy IDE
  • trudne - weryfikacja wymaga testowania przy pomocy własnoręcznie napisanych testów
Oczywiście w prawdziwym świecie nie jest łatwo i dlatego liczba przekształceń trudnych jest o wiele większa niż występowanie przekształceń prostych;


Dalsza część posta będzie parta o publikację Martin Fowler Refactoring: Improving the Design of Existing Code w swojej książce przedstawił podział przekształceń ze względu na sposoby weryfikacji:
  • proste (ok. 22) - można zweryfikować analitycznie
  • trudne (ok.50)
    • testowalne (ok. 25) - wymagają z góry znanych testów
    • nieokreślone (ok. 25) - wymagają dedykowanych testów


Fowler zdefiniował pojęcie bad smell czyli jeżeli coś źle pachnie należy to zmienić. Pojęcie jest luźną definicją dlatego też obejmuje najróżniejesze problemy związane ze strukturą kodu. Dlatego też lista bad smells obejmuje wiele niespokrewnionych ze sobą problemów.

Problemów takich jak:
  • Dublicate Code (Z duplikowany kod)
  • Long Method (Długa metoda)
  • Large Class (Nadmiernie rozbudowana klasa)
  • Long Parameter List (Długa lista parametrów)
  • Comments (Nadmierne komentarze)
  • Incomplet Library Class (Niekompletna klasa biblioteki)
  • Switch Statements (Skomplikowane instrukcje warunkowe)
  • Message Chains (Łańcuch wywołań przez delegację)
  • Data Class (Klasa z danymi)
  • Data Clumps (Zbitka danych)
  • Refused Bequest (Odrzucony spadek)
  • Inappropriate Intimacy (Niewłaściwa hermetyzacja)
  • Lazy Class (Bezużyteczna klasa)
  • Feature Envy (Zazdrość o funkcje)
  • Paraller Inheritance Hierarchies (Równoległe hierarchiczne dziedziczenie)
  • Middle Man (Pośrednik)
  • Divergent Change (Zmiany z wielu przyczyn)
  • Shotgun Surgery (Odpryskowa modyfikacja)
  • Speculative Generality (Spekulacyjne uogulnienie)
  • ... obiecuje, że za jakiś czas pojawi się opis wszystkich bad smells


Po tak 'pięknej' liście należy się zastanowić jak znajdować bad smell. Z tym problemem nie pozostajemy sami istnieje kilka źródeł, które mogą dostarczyć danych o ich obecności:
  • intuicja programisty, która jest niemierzalna i trudna do zdefiniowania, a jednak pełni bardzo ważną rolę w identyfikacji złych praktyk obiektowych

  • metryki, które są podstawowym mechanizmem ilościowej oceny jekości projektu. Metryki dostarczają liczbowej i łatwej do zinterpretowania informacji o wielu aspektach jakości projektu

  • analiza Abstrakcyjnego Drzewa Składowego AST, które jest graficzną reprezentacją rozbioru gramatycznego programu. Obecność lub brak określonych elementów w drzewie AST wskazuje na obecność lub wyklucza obecność niektórych zapachów

  • informacja o innych zapachach pozwala wykorzystać znane już fakty o innych przykrych zapachach

  • analiza dynamiczna, która pozwala określić atrybuty programu nie dające zidentyfikować wyłącznie poprzez analizę statyczną. Przykładem analizy dynamicznej może być wykonanie przypadków testowych

  • historia zmian kodu pochodząca z repozytorium zarzadzania konfiguracją pozwala ocenić wpływ niektórych zmian na program


Słowem podsumowania...
może post jest przydługi, ale mam nadzieję, że zawarte informacje w nim komuś się przydadzą. Mi pozwolił nazwać rzeczy które od dawna robiłem.