Zpo-8-wyk-Slajd50: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Bwalter (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 1: Linia 1:
==Przykład(1)==
==Objawy przykrego zapachu ==


[[Image:zpo-8-wyk-Slajd50.PNG|Przykład(1)]]
[[Image:zpo-8-wyk-Slajd50.PNG|Objawy przykrego zapachu ]]




Drugie rozwiązanie polega na stworzeniu klasy-opakowania, która deleguje wywołania metod do pola będącego obiektem klasy Date. Należy jedynie pamiętać, że w tej postaci (o ile nie istnieje interfejs, który implementuje klasa źródłowa) rozszerzenie jest niezgodne pod względem typu z klasą źródłową. Oznacza to, że nie może do niego stosowana reguła podstawiania, np. nie może być użyty jako argument zamiast klasy źródłowej.
Jak mówi definicja, obecność przykrego zapachu wskazuje na potrzebę refaktoryzacji. Jednak jak stwierdzić, czy przykry zapach faktycznie występuje? Identyfikacja wymienionych na poprzednich slajdach naruszeń zasad projektowych nie jest łatwa, ponieważ ich występowanie nie jest związane prostą zależnością przyczynowo-skutkową z jednym objawem. Przeciwnie – ten sam przykry zapach może przejawiać się na różne sposoby, które niekoniecznie występują wspólnie.
 
Dlatego wyróżniono sześć odrębnych źródeł, które mogą dostarczać danych o obecności (lub jej wykluczeniu) danego przykrego zapachu. Są to:
* 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 jakości projektu. Metryki dostarczają liczbowej i łatwej do zinterpretowania informacji o wielu aspektach jakości projektu;
* analiza Abstrakcyjnego Drzewa Składniowego (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 się zidentyfikować wyłącznie poprzez analizę statyczną. Przykładem analizy dynamicznej może być wykonanie przypadków testowych;
* historia zmian kodu pochodząca z repozytorium zarządzania konfiguracją pozwala ocenić wpływ niektórych zmian na program.




[[zpo-8-wyk-Slajd49 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd51 | Następny slajd >>]]
[[zpo-8-wyk-Slajd49 | << Poprzedni slajd]] | [[zpo-8-wyk-toc|Spis treści ]] | [[zpo-8-wyk-Slajd51 | Następny slajd >>]]

Aktualna wersja na dzień 18:15, 4 lis 2006

Objawy przykrego zapachu

Objawy przykrego zapachu


Jak mówi definicja, obecność przykrego zapachu wskazuje na potrzebę refaktoryzacji. Jednak jak stwierdzić, czy przykry zapach faktycznie występuje? Identyfikacja wymienionych na poprzednich slajdach naruszeń zasad projektowych nie jest łatwa, ponieważ ich występowanie nie jest związane prostą zależnością przyczynowo-skutkową z jednym objawem. Przeciwnie – ten sam przykry zapach może przejawiać się na różne sposoby, które niekoniecznie występują wspólnie.

Dlatego wyróżniono sześć odrębnych źródeł, które mogą dostarczać danych o obecności (lub jej wykluczeniu) danego przykrego zapachu. Są to:

  • 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 jakości projektu. Metryki dostarczają liczbowej i łatwej do zinterpretowania informacji o wielu aspektach jakości projektu;
  • analiza Abstrakcyjnego Drzewa Składniowego (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 się zidentyfikować wyłącznie poprzez analizę statyczną. Przykładem analizy dynamicznej może być wykonanie przypadków testowych;
  • historia zmian kodu pochodząca z repozytorium zarządzania konfiguracją pozwala ocenić wpływ niektórych zmian na program.


<< Poprzedni slajd | Spis treści | Następny slajd >>