Czysty Kod. Podręcznik Dobrego Programisty 42l33

* Eratostenes z Cyrene, urodzony 276 p.n.e. w Cyrene, Libia -* zmarł 194 p.n.e. w Aleksandrii. Pierwszy człowiek, który obliczył * obwód Ziemi. Znany również z prac nad kalendarzem * z latami przestępnymi i prowadzenia biblioteki w Aleksandrii. *

* Algorytm jest dosyć prosty. Mamy tablicę liczb całkowitych * zaczynających się od 2. Wykreślamy wszystkie wielokrotności 2. Szukamy

92

ROZDZIAŁ 4.

* następnej niewykreślonej liczby i wykreślamy wszystkie jej wielokrotności. * Powtarzamy działania do momentu osiągnięcia pierwiastka kwadratowego z maksymalnej wartości. * * @author Alphonse * @version 13 Feb 2002 atp */ import java.util.*; public class GeneratePrimes {

/** * @param maxValue jest limitem generacji. */ public static int[] generatePrimes(int maxValue) { if (maxValue >= 2) // Jedyny prawidłowy przypadek. {

// Deklaracje. int s = maxValue + 1; // Rozmiar tablicy. boolean[] f = new boolean[s]; int i;

// Inicjalizacja tablicy wartościami true. for (i = 0; i < s; i++) f[i] = true;

// Usuwanie znanych liczb niebędących pierwszymi. f[0] = f[1] = false;

// Sito. int j; for (i = 2; i < Math.sqrt(s) + 1; i++) { if (f[i]) // Jeżeli i nie jest wykreślone, wykreślamy jego wielokrotności. { for (j = 2 * i; j < s; j += i) f[j] = false; // Wielokrotności nie są pierwsze. } }

// Ile mamy liczb pierwszych? int count = 0; for (i = 0; i < s; i++) { if (f[i]) count++; // Licznik trafień. } int[] primes = new int[count];

// Przeniesienie liczb pierwszych do wyniku. for (i = 0, j = 0; i < s; i++) { if (f[i]) // Jeżeli pierwsza. primes[j++] = i; } return primes; // Zwracamy liczby pierwsze. } else // maxValue < 2 return new int[0]; // Zwracamy pustą tablicę, jeżeli niewłaściwe dane wejściowe. } }

KOMENTARZE

93

Na listingu 4.8 zamieszczona jest przebudowana wersja tego samego modułu. Warto zauważyć, że znacznie ograniczona jest liczba komentarzy. W całym module znajdują się tylko dwa komentarze. Oba są z natury opisowe. L I S T I N G 4 . 8 . PrimeGenerator.java (przebudowany) /** * Klasa ta generuje liczby pierwsze do określonego przez użytkownika * maksimum. Użytym algorytmem jest sito Eratostenesa. * Mamy tablicę liczb całkowitych zaczynających się od 2. * Wyszukujemy pierwszą nieokreśloną liczbę i wykreślamy wszystkie jej * wielokrotności. Powtarzamy, aż nie będzie więcej wielokrotności w tablicy. */ public class PrimeGenerator { private static boolean[] crossedOut; private static int[] result; public static int[] generatePrimes(int maxValue) { if (maxValue < 2) return new int[0]; else { uncrossIntegersUpTo(maxValue); crossOutMultiples(); putUncrossedIntegersIntoResult(); return result; } } private static void uncrossIntegersUpTo(int maxValue) { crossedOut = new boolean[maxValue + 1]; for (int i = 2; i < crossedOut.length; i++) crossedOut[i] = false; } private static void crossOutMultiples() { int limit = determineIterationLimit(); for (int i = 2; i <= limit; i++) if (notCrossed(i)) crossOutMultiplesOf(i); } private static int determineIterationLimit() {

// Każda wielokrotność w tablicy ma podzielnik będący liczbą pierwszą // mniejszą lub równą pierwiastkowi kwadratowemu wielkości tablicy, // więc nie musimy wykreślać wielokrotności większych od tego pierwiastka. double iterationLimit = Math.sqrt(crossedOut.length); return (int) iterationLimit; } private static void crossOutMultiplesOf(int i) { for (int multiple = 2*i; multiple < crossedOut.length; multiple += i) crossedOut[multiple] = true;

94

ROZDZIAŁ 4.

} private static boolean notCrossed(int i) { return crossedOut[i] == false; } private static void putUncrossedIntegersIntoResult() { result = new int[numberOfUncrossedIntegers()]; for (int j = 0, i = 2; i < crossedOut.length; i++) if (notCrossed(i)) result[j++] = i; } private static int numberOfUncrossedIntegers() { int count = 0; for (int i = 2; i < crossedOut.length; i++) if (notCrossed(i)) count++; return count; } }

Można się spierać, że pierwszy komentarz jest niarowy, ponieważ czyta się go podobnie jak samą funkcję genratePrimes. Uważam jednak, że komentarz ułatwia czytelnikowi poznanie algorytmu, więc zdecydowałem o jego pozostawieniu. Drugi komentarz jest niemal na pewno niezbędny. Wyjaśnia powody zastosowania pierwiastka jako ograniczenia pętli. Można sprawdzić, że żadna z prostych nazw zmiennych ani inna struktura kodu nie pozwala na wyjaśnienie tego punktu. Z drugiej strony, użycie pierwiastka może być próżnością. Czy faktycznie oszczędzam dużo czasu przez ograniczenie liczby iteracji do pierwiastka liczby? Czy obliczenie pierwiastka nie zajmuje więcej czasu, niż uda się nam zaoszczędzić? Warto o tym pomyśleć. Zastosowanie pierwiastka jako limitu pętli zadowala siedzącego we mnie eksperta C i asemblera, ale nie jestem przekonany, że jest to warte czasu i energii osoby, która ma za zadanie zrozumieć ten kod.

Bibliografia [KP78]: Kernighan i Plaugher, The Elements of Programming Style, McGraw-Hill 1978.

KOMENTARZE

95

96

ROZDZIAŁ 4.

ROZDZIAŁ 5.

Formatowanie

, chcą być oczarowani elegancją, spójnością i zauważalną G dbałością o szczegóły. Chcemy ich zaskoczyć uporządkowaniem. Chcemy, aby ich brwi się uniosły, DY LUDZIE ZAGLĄDAJĄ POD MASKĘ PROJEKTU

gdy będą przeglądać moduły kodu. Chcemy, aby rozpoznali pracę profesjonalisty. Jeżeli jednak zobaczą wymieszaną masę kodu, która wygląda, jakby kod był pisany przez załogę pijanych marynarzy, mogą dojść do wniosku, że taki sam brak dbałości o szczegóły dotyczy innych aspektów projektu. Pamiętajmy, że kod powinien być ładnie sformatowany. Należy wybrać zbiór prostych zasad, które rządzą formatowaniem kodu, a następnie w konsekwentny sposób je stosować. Jeżeli pracujemy w zespole, to wszyscy jego członkowie powinni przyjąć zbiór zasad formatowania i stosować się do nich. Pomocne są narzędzia automatyczne, które stosują za nas te zasady formatowania.

97

Przeznaczenie formatowania Na początku chciałbym coś ustalić. Formatowanie kodu jest ważne. Jest zbyt ważne, aby je ignorować, i zbyt ważne, aby traktować je dogmatycznie. Formatowanie kodu ma zapewnić komunikację, a dobra komunikacja jest pierwszą zasadą biznesu zawodowego programisty. Być może ktoś stwierdzi, że pierwszą zasadą biznesu zawodowego programisty jest „zapewnienie działania”. Mam nadzieję jednak, że już teraz książka ta dostatecznie skompromitowała to założenie. Funkcje, które tworzymy dziś, z dużym prawdopodobieństwem mogą się zmienić w następnej wersji, ale czytelność naszego kodu będzie miała zbawienny wpływ na wszystkie zmiany, jakie zostaną kiedykolwiek wykonane. Odpowiedni styl kodowania i czytelność kodu zapewniają łatwość utrzymania i rozszerzania kodu. Nasz styl i dyscyplina przetrwają, nawet jeżeli nasz kod już nie. Jakie są więc zasady formatowania, które zapewniają uporządkowanie i czytelność kodu?

Formatowanie pionowe Zaczniemy od rozmiaru pionowego. Jak duży powinien być kod źródłowy? W języku Java rozmiar pliku jest ściśle związany z wielkością klasy. Wielkość klas przedstawialiśmy przy okazji dyskusji o klasach. Teraz rozważmy tylko wielkość plików. Jak duże są zwykle pliki źródłowe Java? Okazuje się, że różnice w zakresie wielkości i stylu kodu są znaczne (rys. 5.1).

R Y S U N E K 5 . 1 . Rozkład wielkości plików w skali logarytmicznej (wysokość prostokąta = sigma)

98

ROZDZIAŁ 5.

Przeanalizowano siedem różnych projektów — Junit, FitNesse, testNG, Time and Money, JDepend, Ant oraz Tomcat. Linie przechodzące przez prostokąty pokazują minimalną i maksymalną wielkość pliku w każdym projekcie. Prostokąt pokazuje średnio jedną trzecią (jedno standardowe odchylenie1) liczby plików. Środek prostokąta oznacza średnią. Tak więc średnia wielkość pliku w projekcie FitNesse wynosi około 65 wierszy, a około jedna trzecia plików ma od 40 do 100 i więcej wierszy. Największy plik w FitNesse ma około 400 wierszy, a najmniejszy 6 wierszy. Należy zwrócić uwagę, że jest to skala logarytmiczna, więc mała różnica w położeniu pionowym stanowi bardzo dużą różnicę w wielkości pliku. JUnit, FitNesse oraz Time and Money są zbudowane ze względnie małych plików. Żaden z nich nie zawiera plików powyżej 500 wierszy, a większość plików ma poniżej 200 wierszy. Tomcat i Ant mają z kolei część plików o długości kilku tysięcy wierszy, a około połowa ma ponad 200 wierszy. Co to oznacza? Wydaje się, że możliwe jest zbudowanie znaczącego systemu (FitNesse ma niemal 50 000 wierszy) z plików mających przeciętnie 200 wierszy, a nieprzekraczających 500 wierszy. Choć nie musi to być sztywna reguła, to jednak powinna być bardzo pożądana. Małe pliki są zwykle łatwiejsze do zrozumienia niż duże.

Metafora gazety Pomyślmy o dobrze napisanym artykule w gazecie. Czytamy go od góry do dołu. Na górze oczekujemy nagłówka, który informuje nas o temacie danego artykułu i pozwala zdecydować, czy chcemy przeczytać całość. Pierwszy akapit przedstawia zarys artykułu, nie zawiera szczegółów. Gdy kontynuujemy lekturę w dół kolumny, liczba szczegółów zwiększa się — są to daty, nazwiska, cytaty i twierdzenia. Chcemy, aby plik źródłowy był podobny do takiego artykułu w gazecie. Nazwa ma być prosta i sugestywna. Powinna wystarczyć nam do stwierdzenia, czy jesteśmy we właściwym module, czy nie. Górne partie pliku źródłowego mają zawierać algorytmy i koncepcje najwyższego poziomu. Liczba szczegółów powinna zwiększać się wraz ze schodzeniem w dół pliku, aż do funkcji oraz szczegółów na najniższym poziomie. Gazeta składa się z wielu artykułów — w większości bardzo małych. Niektóre są nieco większe. Niewiele artykułów zawiera tyle tekstu, aby wypełnić całą stronę. Powoduje to, że gazety są użyteczne. Jeżeli gazeta przedstawiałaby jedną długą historię, zawierającą niezorganizowane konglomeraty faktów, dat i nazwisk, po prostu nie dałoby się jej czytać.

Pionowe odstępy pomiędzy segmentami kodu Niemal każdy kod czyta się od lewej do prawej i od góry do dołu. Każdy wiersz reprezentuje wyrażenie lub klauzulę, a każda grupa wierszy reprezentuje kompletną myśl. Myśli te powinny być oddzielone od siebie pustymi wierszami. 1

Prostokąt pokazuje wielkość sigma/2 powyżej i poniżej średniej. Tak, wiem, że rozkład wielkości pliku nie jest normalny, więc odchylenie standardowe nie jest matematycznie dokładne. Jednak nie chodzi tutaj o precyzję — chcę przedstawić trend.

FORMATOWANIE

99

Jako przykład weźmy kod z listingu 5.1. Znajdują się w nim puste wiersze oddzielające deklarację pakietu, importy i każdą z funkcji. Ta bardzo prosta zasada daje zbawienny efekt dla wizualnego układu kodu. Każdy pusty wiersz jest graficzną wskazówką identyfikującą nową, osobną koncepcję. Gdy przewijamy listing w dół, oko zatrzymuje się na pierwszym wierszu znajdującym się po pustym. L I S T I N G 5 . 1 . BoldWidget.java package fitnesse.wikitext.widgets; import java.util.regex.*; public class BoldWidget extends ParentWidget { public static final String REGEXP = "'''.+?'''"; private static final Pattern pattern = Pattern.compile("'''(.+?)'''", Pattern.MULTILINE + Pattern.DOTALL ); public BoldWidget(ParentWidget parent, String text) throws Exception { super(parent); Matcher match = pattern.matcher(text); match.find(); addChildWidgets(match.group(1)); } public String render() throws Exception { StringBuffer html = new StringBuffer(""); html.append(childHtml()).append(""); return html.toString(); } }

Usunięcie tych pustych wierszy, tak jak na listingu 5.2, ma fatalny wpływ na czytelność kodu. L I S T I N G 5 . 2 . BoldWidget.java package fitnesse.wikitext.widgets; import java.util.regex.*; public class BoldWidget extends ParentWidget { public static final String REGEXP = "'''.+?'''"; private static final Pattern pattern = Pattern.compile("'''(.+?)'''", Pattern.MULTILINE + Pattern.DOTALL); public BoldWidget(ParentWidget parent, String text) throws Exception { super(parent); Matcher match = pattern.matcher(text); match.find(); addChildWidgets(match.group(1));} public String render() throws Exception { StringBuffer html = new StringBuffer(""); html.append(childHtml()).append(""); return html.toString(); } }

Efekt ten jest nawet bardziej zauważalny, gdy spojrzymy na te bloki kodu z większej odległości. W pierwszym przykładzie poszczególne grupy wierszy będą dostrzegalne, natomiast drugi przykład będzie wyglądał na wymieszany. Jedyną różnicą pomiędzy tymi dwoma listingami jest zastosowanie kilku odstępów w pionie.

100

ROZDZIAŁ 5.

Gęstość pionowa Jeżeli odstępy pozwalają na rozdzielenie koncepcji, to pionowe zagęszczenie pozwala wskazać związki. Dlatego wiersze kodu mające ze sobą ścisłe związki powinny być zagęszczone w pionie. Zwróćmy uwagę, jak bezużyteczne komentarze z listingu 5.3 łamią bliskie skojarzenie dwóch zmiennych instancyjnych. LISTING 5.3. public class ReporterConfig {

/** * Nazwa klasy nasłuchu raportu. */ private String m_className;

/** * Właściwości nasłuchu raportu. */ private List m_properties = new ArrayList (); public void addProperty(Property property) { m_properties.add(property); }

Listing 5.4 jest znacznie łatwiejszy do czytania. Można go objąć wzrokiem, przynajmniej ja tak to odczuwam. Można na niego spojrzeć i stwierdzić, że jest to klasa z dwoma zmiennymi i metodami, bez potrzeby przemieszczania wzroku po kodzie. Aby osiągnąć ten sam poziom zrozumienia w przypadku wcześniejszego listingu, nie wystarczy jedno spojrzenie na kod. LISTING 5.4. public class ReporterConfig { private String m_className; private List m_properties = new ArrayList (); public void addProperty(Property property) { m_properties.add(property); }

Odległość pionowa Czy kiedykolwiek szukałeś końca klasy, skakałeś z jednej funkcji do następnej, przewijałeś plik źródłowy w górę i w dół, próbując określić, jak są powiązane funkcje i jak działają, aby następnie znów zagubić się w labiryncie kodu? Czy kiedykolwiek śledziłeś łańcuch dziedziczenia dla definicji zmiennej lub funkcji? Jest to frustrujące, ponieważ chcemy zrozumieć, co robi system, a tracimy czas i energię na wyszukanie i zapamiętanie, gdzie znajdują się jego składniki. Koncepcje, które są ze sobą ściśle związane, powinny znajdować się w niewielkiej odległości od siebie [G10]. Jasne jest, że zasada ta nie może być stosowana w przypadku koncepcji znajdujących się w osobnych plikach. Jednak ściśle powiązane koncepcje nie powinny być umieszczane w różnych plikach, o ile nie ma ku temu specjalnych przesłanek. Jest to jeden z powodów, dla których należy unikać zmiennych chronionych. FORMATOWANIE

101

W przypadku tych koncepcji, które są ze sobą tak ściśle powiązane, że należą do tego samego pliku źródłowego, ich odległość od siebie jest miarą tego, jak dana funkcja jest ważna dla zrozumienia drugiej. Nie powinniśmy zmuszać czytelników do skakania po pliku źródłowym i klasach. Deklaracje zmiennych. Zmienne powinny być zadeklarowane tak blisko miejsca ich użycia, jak tylko to możliwe. Ponieważ nasze zmienne są bardzo krótkie, zmienne lokalne powinny znajdować się na początku każdej z funkcji, tak jak w tych długich funkcjach z Junit 4.3.1. private static void readPreferences() { InputStream is= null; try { is= new FileInputStream(getPreferencesFile()); setPreferences(new Properties(getPreferences())); getPreferences().load(is); } catch (IOException e) { try { if (is != null) is.close(); } catch (IOException e1) { } } }

Zmienne sterujące pętli powinny być deklarowane wewnątrz instrukcji pętli, tak jak w małych funkcjach z tego samego źródła. public int countTestCases() { int count= 0; for (Test each : tests) count += each.countTestCases(); return count; }

W rzadkich przypadkach zmienne mogą być deklarowane na początku bloku lub w dłuższej funkcji, bezpośrednio przed pętlą. Można spotkać zmienne z poniższego fragmentu w środku bardzo długiej funkcji z TestNG. ... for (XmlTest test : m_suite.getTests()) { TestRunner tr = m_runnerFactory.newTestRunner(this, test); tr.addListener(m_textReporter); m_testRunners.add(tr); invoker = tr.getInvoker(); for (ITestNGMethod m : tr.getBeforeSuiteMethods()) { beforeSuiteMethods.put(m.getMethod(), m); } for (ITestNGMethod m : tr.getAfterSuiteMethods()) { afterSuiteMethods.put(m.getMethod(), m); } } ...

Zmienne instancyjne z kolei powinny być deklarowane na początku klasy. Nie należy zwiększać odległości pionowej tych zmiennych, ponieważ w dobrze zaprojektowanej klasie są używane przez wiele metod klasy, o ile nie przez wszystkie. 102

ROZDZIAŁ 5.

Od dawna toczą się debaty na temat tego, gdzie powinny znajdować się zmienne instancyjne. W języku C++ powszechnie stosowaliśmy tak zwaną regułę nożyczek, zgodnie z którą umieszczaliśmy wszystkie zmienne instancyjne na końcu. Z kolei w języku Java powszechnie stosowaną konwencją jest umieszczanie wszystkich takich zmiennych na początku klasy. Nie widzę powodów, dla których mielibyśmy stosować się do którejkolwiek z tych konwencji. Najważniejsze dla zmiennych instancyjnych jest to, aby były zadeklarowane w jednym znanym miejscu. Każdy powinien wiedzieć, gdzie zajrzeć, aby zobaczyć deklaracje. Jako przykład weźmy dziwny przypadek klasy TestSuite z JUnit 4.3.1. Musiałem znacznie rozrzedzić tę klasę, aby zorientować się, jak ona działa. Jeżeli spojrzymy na środkową część listingu, zauważymy zadeklarowane tam dwie zmienne instancyjne. Trudno byłoby schować je w lepszym miejscu. Osoba czytająca ten kod mogłaby przypadkowo ominąć te deklaracje (tak jak ja). public class TestSuite implements Test { static public Test createTest(Class theClass, String name) { ... } public static Constructor getTestConstructor(Class theClass) throws NoSuchMethodException { ... } public static Test warning(final String message) { ... } private static String exceptionToString(Throwable t) { ... } private String fName; private Vector fTests= new Vector (10); public TestSuite() { } public TestSuite(final Class theClass) { ... } public TestSuite(Class theClass, String name) { ... } ... ... ... ... ... }

Funkcje zależne. Jeżeli jedna funkcja wywołuje inną, powinny być one położone blisko siebie, a funkcja wywołująca powinna być umieszczona powyżej wywoływanej, o ile jest to możliwe. Pozwala to osiągnąć naturalny przebieg programu. Jeżeli konwencja ta jest stosowana konsekwentnie, czytelnik będzie mógł zaufać nam, że definicja funkcji znajduje się zaraz po jej wywołaniu. Jako przykład weźmy fragment z FitNesse z listingu 5.5. Warto zwrócić uwagę, że funkcje umieszczone na górze wywołują te znajdujące się poniżej, które z kolei wywołują położone jeszcze niżej. Powoduje to, że łatwiej można znaleźć wywoływane funkcje, i znacznie poprawia czytelność całego modułu.

FORMATOWANIE

103

L I S T I N G 5 . 5 . WikiPageResponder.java public class WikiPageResponder implements SecureResponder { protected WikiPage page; protected PageData pageData; protected String pageTitle; protected Request request; protected PageCrawler crawler; public Response makeResponse(FitNesseContext context, Request request) throws Exception { String pageName = getPageNameOrDefault(request, "FrontPage"); loadPage(pageName, context); if (page == null) return notFoundResponse(context, request); else return makePageResponse(context); } private String getPageNameOrDefault(Request request, String defaultPageName) { String pageName = request.getResource(); if (StringUtil.isBlank(pageName)) pageName = defaultPageName; return pageName; } protected void loadPage(String resource, FitNesseContext context) throws Exception { WikiPagePath path = PathParser.parse(resource); crawler = context.root.getPageCrawler(); crawler.setDeadEndStrategy(new VirtualEnabledPageCrawler()); page = crawler.getPage(context.root, path); if (page != null) pageData = page.getData(); } private Response notFoundResponse(FitNesseContext context, Request request) throws Exception { return new NotFoundResponder().makeResponse(context, request); } private SimpleResponse makePageResponse(FitNesseContext context) throws Exception { pageTitle = PathParser.render(crawler.getFullPath(page)); String html = makeHtml(context); SimpleResponse response = new SimpleResponse(); response.setMaxAge(0); response.setContent(html); return response; } ...

Przy okazji mamy w tym fragmencie przykład rozmieszczania stałych na odpowiednim poziomie [G35]. Stała FrontPage mogłaby być umieszczona w funkcji getPageNameOrDefault, ale spowodowałoby to ukrycie znanej i oczekiwanej stałej w funkcji znajdującej się na zbyt niskim poziomie. Lepiej było przekazywać tę stałą w dół, z miejsca, gdzie jej definicja ma sens, do miejsca, w którym jest wykorzystywana.

104

ROZDZIAŁ 5.

Koligacja koncepcyjna. Niektóre fragmenty kodu chcemy umieszczać niedaleko innych fragmentów. Mają one określoną koligację koncepcyjną. Im silniejsza ta koligacja, tym mniejsza powinna być odległość pomiędzy tymi fragmentami. Jak można się przekonać, koligacja ta może bazować na bezpośredniej zależności, takiej jak wywoływanie jednej funkcji przez inną lub użycie zmiennej w funkcji. Istnieją również inne możliwości koligacji. Koligacja może wynikać z tego, że funkcje wykonują podobne operacje. Weźmy pod uwagę fragment kodu zaczerpnięty z Junit 4.3.1: public class Assert { static public void assertTrue(String message, boolean condition) { if (!condition) fail(message); } static public void assertTrue(boolean condition) { assertTrue(null, condition); } static public void assertFalse(String message, boolean condition) { assertTrue(message, !condition); } static public void assertFalse(boolean condition) { assertFalse(null, condition); } ...

Funkcje te mają silną koligację koncepcyjną, ponieważ współużytkują ten sam schemat nazewnictwa i wykonują odmiany tego samego zadania. Fakt, że wywołują się wzajemnie, jest mniej ważny. Nawet jeżeli nie robiłyby tego, nadal chcielibyśmy trzymać je razem.

Uporządkowanie pionowe Zwykle chcemy, aby w funkcji wywołania zależności były kierowane w dół. Inaczej mówiąc, wywoływana funkcja powinna znajdować się poniżej funkcji wywołującej 2. Daje to efekt przepływu sterowania w dół kodu źródłowego modułu, od wysokiego poziomu do niskiego. W artykule prasowym oczekujemy, że najważniejsze informacje znajdą się na początku, a następnie zostaną opisane z najmniejszą liczbą przeszkadzających detali. Oczekujemy, że najdrobniejsze szczegóły będą przedstawione na końcu. Podobnie w przypadku kodu — pozwala to nam zapoznać się z plikami źródłowymi i uzyskiwać ich obraz na podstawie kilku pierwszych funkcji, bez zagłębiania się w szczegóły. W taki sposób jest zorganizowany kod z listingu 5.5. Jeszcze lepszymi przykładami są listingi 15.5 i 3.7. 2

Jest to odwrotna sytuacja w stosunku do języków takich jak Pascal, C i C++, w których funkcje musiały być zdefiniowane lub co najmniej zadeklarowane przed ich użyciem.

FORMATOWANIE

105

Formatowanie poziome Jak długie powinny być wiersze? Aby odpowiedzieć na to pytanie, sprawdzimy długość wierszy w typowych programach. Ponownie przeanalizujemy siedem różnych projektów. Na rysunku 5.2 przedstawiony jest rozkład długości wierszy wszystkich siedmiu projektów. Regularność jest imponująca, szczególnie około 45 znaków. W rzeczywistości każda wartość od 20 do 60 reprezentuje około 1 procent całkowitej liczby wierszy. To jest 40 procent! Kolejne 30 procent to wiersze krótsze niż 10 znaków. Należy pamiętać, że jest to skala logarytmiczna, więc liniowy spadek długości powyżej 80 znaków jest naprawdę bardzo znaczący. Jasne jest, że programiści preferują krótkie wiersze.

R Y S U N E K 5 . 2 . Rozkład długości wierszy kodu Java

A zatem powinniśmy tworzyć krótkie wiersze. Stare ograniczenie Holleritha do 80 znaków jest zbyt restrykcyjne i osobiście nie mam nic przeciwko wierszom mającym 100, a nawet 120 znaków. Jednak wartości powyżej tej granicy są zbyt duże. Sam piszę programy tak, aby nigdy nie trzeba było przewijać ekranu edytora w prawo. Jednak obecnie monitory są bardzo szerokie, a młodsi programiści mogą tak zmniejszyć czcionkę, że uzyskują wiersze o długości 200 znaków. Nie jest to dobra praktyka. Ja staram się nie przekraczać długości 120 znaków.

Poziome odstępy i gęstość Odstępy poziome służą do kojarzenia elementów ściśle powiązanych i rozłączania elementów, które są ze sobą luźniej związane. Weźmy pod uwagę następującą funkcję:

106

ROZDZIAŁ 5.

private void measureLine(String line) { lineCount++; int lineSize = line.length(); totalChars += lineSize; lineWidthHistogram.addLine(lineSize, lineCount); recordWidestLine(lineSize); }

Operatory przypisania otoczyłem odstępami w celu ich wyróżnienia. Instrukcje przypisania mają dwa osobne główne elementy: lewą i prawą stronę. Odstępy powodują, że rozdzielenie to jest oczywiste. Z drugiej strony, nie dodaję odstępów pomiędzy nazwami funkcji a otwierającymi nawiasami. Funkcje i argumenty są ze sobą bardzo ściśle związane. Rozdzielenie ich spowodowałoby, że wyglądałyby na rozłączone, a nie złączone. Rozdzielam argumenty wywołania funkcji, aby zaznaczyć przecinek i pokazać, że argumenty są osobne. Innym zastosowaniem odstępów jest zaznaczenie kolejności wykonywania operatorów. public class Quadratic { public static double root1(double a, double b, double c) { double determinant = determinant(a, b, c); return (-b + Math.sqrt(determinant)) / (2*a); } public static double root2(int a, int b, int c) { double determinant = determinant(a, b, c); return (-b - Math.sqrt(determinant)) / (2*a); } private static double determinant(double a, double b, double c) { return b*b - 4*a*c; } }

Warto zwrócić uwagę, jak łatwo czyta się te wyrażenia. Wykładniki nie są oddzielone odstępami, ponieważ mają wysoki priorytet. Składniki są rozdzielone, ponieważ operacje dodawania i odejmowania mają niski priorytet. Niestety, większość narzędzi formatujących kod jest ślepa na priorytety operatorów i stosuje wszędzie takie same odstępy. Tak więc subtelne odstępy, takie jak tu przedstawione, zwykle są tracone po automatycznym sformatowaniu kodu.

Rozmieszczenie poziome Gdy byłem programistą asemblera3, stosowałem rozmieszczenie poziome w celu wyróżniania określonych struktur. Gdy zacząłem kodować w C, C++ i w końcu w Javie, nadal starałem się wyrównywać wszystkie nazwy zmiennych w zbiorze deklaracji lub wszystkie r-wartości w zbiorze instrukcji przypisania. Kod taki może wyglądać następująco:

3

Czy ja żartuję? Nadal jestem programistą asemblera. Można odsunąć chłopca od zabawek, ale trudno mu je zabrać!

FORMATOWANIE

107

public class FitNesseExpediter implements ResponseSender { private Socket socket; private InputStream input; private OutputStream output; private Request request; private Response response; private FitNesseContext context; protected long requestParsingTimeLimit; private long requestProgress; private long requestParsingDeadline; private boolean hasError; public FitNesseExpediter(Socket s, FitNesseContext context) throws Exception { this.context = context; socket = s; input = s.getInputStream(); output = s.getOutputStream(); requestParsingTimeLimit = 10000; }

Zauważyłem jednak, że tego typu wyrównywanie nie jest użyteczne. Wydaje się, że wyrównanie takie powoduje skupienie uwagi na niewłaściwych elementach i odciąga wzrok od właściwych. Na przykład w przedstawionej powyżej liście deklaracji mamy pokusę czytania listy zmiennych bez zwracania uwagi na ich typy. Podobnie w instrukcjach przypisania zwykle patrzymy na listę r-wartości, bez zwracania uwagi na operator przypisania. Co gorsza, automatyczne narzędzia formatujące zwykle eliminują tego rodzaju wyrównanie. Z tego powodu w końcu przestałem stosować ten typ formatowania. Obecnie preferuję niewyrównane deklaracje i przypisania, tak jak w poniższym przykładzie, ponieważ wskazują one na ważną niedoskonałość. Jeżeli mam długą listę, która powinna być wyrównana, występuje problem z szerokością listy, a nie z brakiem wyrównania. Długość listy deklaracji w FitNesseExpediter, znajdującej się poniżej, sugeruje konieczność podziału klasy. public class FitNesseExpediter implements ResponseSender { private Socket socket; private InputStream input; private OutputStream output; private Request request; private Response response; private FitNesseContext context; protected long requestParsingTimeLimit; private long requestProgress; private long requestParsingDeadline; private boolean hasError; public FitNesseExpediter(Socket s, FitNesseContext context) throws Exception { this.context = context; socket = s; input = s.getInputStream(); output = s.getOutputStream(); requestParsingTimeLimit = 10000; }

108

ROZDZIAŁ 5.

Wcięcia Plik źródłowy stanowi pewnego rodzaju hierarchię, a nie szablon. Znajdują się w nim informacje odnoszące się do pliku jako całości, do poszczególnych klas w pliku, do metod w klasach, do bloków w metodach oraz, rekurencyjnie, do bloków w blokach. Każdy poziom hierarchii jest zakresem, w którym są zadeklarowane nazwy oraz w którym są interpretowane deklaracje i instrukcje wykonywalne. Aby hierarchia ta była widoczna, wcinamy wiersze kodu źródłowego odpowiednio do pozycji w hierarchii. Instrukcje na poziomie pliku, takie jak większość deklaracji klas, nie są wcinane. Metody w klasach są wcinane jeden poziom w prawą stronę klasy. Implementacje tych metod znajdują się jeden poziom w prawo w stosunku do deklaracji metody. Implementacje bloków znajdują się jeden poziom w prawo w stosunku do bloku, w którym się znajdują, i tak dalej. Programiści polegają w znacznym stopniu na tym schemacie wcięć. Wyrównują oni wizualnie wiersze z lewej strony, aby sprawdzić, w którym zakresie się znajdują. Pozwala to szybko przeskakiwać zakresy, takie jak implementacje instrukcji if lub while, które nie odnoszą się do bieżącej sytuacji. Od lewej strony programiści szukają deklaracji metod, nowych zmiennych, a nawet nowych klas. Bez wcięć programy byłyby niemal nieczytelne dla ludzi. Spójrzmy na poniższe programy, które są pod względem składniowym i semantycznym identyczne: public class FitNesseServer implements SocketServer { private FitNesseContext context; public FitNesseServer(FitNesseContext context) { this.context = context; } public void serve(Socket s) { serve(s, 10000); } public void serve(Socket s, long requestTimeout) { try { FitNesseExpediter sender = new FitNesseExpediter(s, context); sender.setRequestParsingTimeLimit(requestTimeout); sender.start(); } catch(Exception e) { e.printStackTrace(); } } } ----public class FitNesseServer implements SocketServer { private FitNesseContext context; public FitNesseServer(FitNesseContext context) { this.context = context; } public void serve(Socket s) { serve(s, 10000); } public void serve(Socket s, long requestTimeout) { try { FitNesseExpediter sender = new FitNesseExpediter(s, context); sender.setRequestParsingTimeLimit(requestTimeout); sender.start(); } catch (Exception e) { e.printStackTrace(); } } }

FORMATOWANIE

109

Nasze oko może szybko określić strukturę wcięć w pliku. Można niemal natychmiast odszukać zmienne, konstruktory, akcesory i metody. Tylko kilka sekund zajmuje określenie, że jest to jakiś interfejs do gniazda z obsługą czasu oczekiwania. Wersja bez wcięć jest jednak niemal nieczytelna bez intensywnego studiowania. Łamanie wcięć. Czasami kuszące jest łamanie zasad wcięć w przypadku krótkich instrukcji if, krótkich pętli while lub krótkich funkcji. Wszędzie tam, gdzie uległem tej pokusie, niemal zawsze wracałem i dodawałem właściwe wcięcia. Dlatego należy unikać łączenia zakresów w jeden wiersz, tak jak w poniższym przykładzie: public class CommentWidget extends TextWidget { public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?"; public CommentWidget(ParentWidget parent, String text){super(parent, text);} public String render() throws Exception {return ""; } }

Polecam rozwinięcie kodu i wcięcie zakresów, tak jak poniżej: public class CommentWidget extends TextWidget { public static final String REGEXP = "^#[^\r\n]*(?:(?:\r\n)|\n|\r)?"; public CommentWidget(ParentWidget parent, String text) { super(parent, text); } public String render() throws Exception { return ""; } }

Puste zakresy Czasami treść instrukcji while lub for nie zawiera kodu, tak jak jest to pokazane poniżej. Nie lubię tego typu struktur i staram się ich unikać. Gdy nie mogę ich uniknąć, upewniam się, że pusta treść jest prawidłowo wcięta i otoczona klamrami. Nie zliczę, ile razy dałem się oszukać przez średnik siedzący cichutko na końcu pętli while w tym samym wierszu. Jeżeli nie zapewnimy, że średnik ten będzie widoczny, przez zastosowanie wcięcia w jego własnym wierszu, trudno będzie go zauważyć. while (dis.read(buf, 0, readBufferSize) != -1) ;

Zasady zespołowe Tytuł tego podrozdziału jest grą słów. Każdy programista ma własne ulubione zasady formatowania, ale jeżeli pracuje w zespole, zasady ustala zespół.

110

ROZDZIAŁ 5.

Zespół programistów powinien ustalić jeden styl formatowania, a następnie każdy członek zespołu powinien stosować ten styl. Oczekujemy, że program będzie miał jednorodny styl. Nie chcemy, aby wyglądał, jakby był napisany przez bandę niezgadzających się ze sobą indywiduów. Gdy w roku 2002 zacząłem pracę nad projektem FitNesse, usiadłem z zespołem w celu wypracowania stylu kodowania. Zajęło to około 10 minut. Zdecydowaliśmy, gdzie będziemy umieszczać klamry, jaka powinna być wielkość wcięcia, jak będziemy nazywać klasy, zmienne, metody i tak dalej. Następnie wpisaliśmy te zasady w formater kodu naszego IDE i od tego momentu je stosowaliśmy. Nie były to zasady, które preferuję; były to zasady, o których zdecydował zespół. Jako członek zespołu stosowałem je przy pisaniu kodu w projekcie FitNesse. Należy pamiętać, że dobre oprogramowanie składa się ze zbioru dokumentów, które dobrze się czyta. Muszą mieć one spójny i gładki styl. Muszą budzić zaufanie czytelnika, który uzna, że formatowanie, jakie zobaczy w jednym pliku źródłowym, będzie znaczyło to samo w innym. Ostatnią rzeczą, jaką chcemy zrobić, jest zwiększenie skomplikowania kodu przez jego pisanie przy użyciu kilku różnych odrębnych stylów.

Zasady formatowania wujka Boba Zasady formatowania stosowane przeze mnie są bardzo proste i zostały przedstawione w kodzie na listingu 5.6. Można go uznać za przykład tego, jak kod tworzy najlepszy dokument standardu kodowania. L I S T I N G 5 . 6 . CodeAnalyzer.java public class CodeAnalyzer implements JavaFileAnalysis { private int lineCount; private int maxLineWidth; private int widestLineNumber; private LineWidthHistogram lineWidthHistogram; private int totalChars; public CodeAnalyzer() { lineWidthHistogram = new LineWidthHistogram(); } public static List findJavaFiles(File parentDirectory) { List files = new ArrayList (); findJavaFiles(parentDirectory, files); return files; } private static void findJavaFiles(File parentDirectory, List files) { for (File file : parentDirectory.listFiles()) { if (file.getName().endsWith(".java")) files.add(file); else if (file.isDirectory()) findJavaFiles(file, files); } } public void analyzeFile(File javaFile) throws Exception { BufferedReader br = new BufferedReader(new FileReader(javaFile));

FORMATOWANIE

111

String line; while ((line = br.readLine()) != null) measureLine(line); } private void measureLine(String line) { lineCount++; int lineSize = line.length(); totalChars += lineSize; lineWidthHistogram.addLine(lineSize, lineCount); recordWidestLine(lineSize); } private void recordWidestLine(int lineSize) { if (lineSize > maxLineWidth) { maxLineWidth = lineSize; widestLineNumber = lineCount; } } public int getLineCount() { return lineCount; } public int getMaxLineWidth() { return maxLineWidth; } public int getWidestLineNumber() { return widestLineNumber; } public LineWidthHistogram getLineWidthHistogram() { return lineWidthHistogram; } public double getMeanLineWidth() { return (double)totalChars/lineCount; } public int getMedianLineWidth() { Integer[] sortedWidths = getSortedWidths(); int cumulativeLineCount = 0; for (int width : sortedWidths) { cumulativeLineCount += lineCountForWidth(width); if (cumulativeLineCount > lineCount/2) return width; } throw new Error("Nie można tu wejść"); } private int lineCountForWidth(int width) { return lineWidthHistogram.getLinesforWidth(width).size(); } private Integer[] getSortedWidths() { Set widths = lineWidthHistogram.getWidths(); Integer[] sortedWidths = (widths.toArray(new Integer[0])); Arrays.sort(sortedWidths); return sortedWidths; } }

112

ROZDZIAŁ 5.

ROZDZIAŁ 6.

Obiekty i struktury danych

korzystamy ze zmiennych prywatnych. Nie chcemy, aby ktokolwiek I na nich polegał. Chcemy zachować sobie swobodę zmian ich typu lub implementacji. Dlaczego STNIEJE POWÓD, DLA KTÓREGO

więc tak wielu programistów automatycznie dodaje gettery i settery do swoich obiektów, udostępniając zmienne prywatne tak, jakby były one publiczne?

Abstrakcja danych Zwróćmy uwagę na różnice pomiędzy listingiem 6.1 a listingiem 6.2. Oba reprezentują dane punktu w układzie kartezjańskim. A jednak w pierwszym przypadku implementacja jest udostępniona, a w drugim całkowicie ukryta.

113

L I S T I N G 6 . 1 . Punkt konkretny public class Point { public double x; public double y; }

L I S T I N G 6 . 2 . Punkt abstrakcyjny public interface Point { double getX(); double getY(); void setCartesian(double x, double y); double getR(); double getTheta(); void setPolar(double r, double theta); }

Najlepsze w kodzie z listingu 6.2 jest to, że nie ma sposobu na stwierdzenie, czy implementacja korzysta ze współrzędnych prostokątnych, czy kątowych. Być może całkowicie innych? A jednak interfejs niezawodnie reprezentuje strukturę danych. Co lepsze, reprezentuje więcej niż tylko strukturę danych. Metody pozwalają na wymuszenie zasad dostępu. Można niezależnie odczytywać poszczególne współrzędne, ale ustawianie współrzędnych musi być wykonywane jako atomowa (tzn. pojedyncza) operacja. Z drugiej strony, na listingu 6.1 jest bardzo wyraziście zaimplementowana klasa współrzędnych prostokątnych, która zmusza nas do niezależnego manipulowania tymi współrzędnymi. Powoduje to ujawnienie implementacji. W rzeczywistości implementacja ta byłaby również ujawniona, jeżeli zmienne byłyby prywatne i używalibyśmy setterów i getterów poszczególnych zmiennych. Ukrywanie implementacji nie sprowadza się do dodawania warstwy funkcji nad zmiennymi. Ukrywanie implementacji polega na tworzeniu abstrakcji! Klasa nie powinna po prostu przepychać zmiennych przez gettery i settery. Zamiast tego powinna udostępniać interfejs pozwalający użytkownikom na manipulowanie istotą danych bez konieczności znajomości jej implementacji. Spójrzmy na listingi 6.3 i 6.4. W pierwszym użyte są konkretne terminy informujące o poziomie paliwa w pojeździe, natomiast w drugim użyta jest abstrakcja poziomu procentowego. W konkretnym przypadku możemy być niemal pewni, że są to po prostu akcesory zmiennych. W przypadku abstrakcyjnym nie mamy pojęcia o formie danych. L I S T I N G 6 . 3 . Pojazd konkretny public interface Vehicle { double getFuelTankCapacityInGallons(); double getGallonsOfGasoline(); }

L I S T I N G 6 . 4 . Pojazd abstrakcyjny public interface Vehicle { double getPercentFuelRemaining(); }

114

ROZDZIAŁ 6.

W obu przedstawionych przypadkach zalecane jest stosowanie drugiego z przedstawionych kodów. Nie chcemy udostępniać szczegółów naszych danych. Zamiast tego powinniśmy opisywać dane abstrakcyjnymi terminami. Nie można tego osiągnąć przez proste użycie interfejsów oraz getterów i setterów. Konieczna jest dogłębna analiza w celu określenia najlepszego sposobu reprezentowania danych znajdujących się w obiektach. Najgorszą opcją jest ślepe dodanie getterów i setterów.

Antysymetria danych i obiektów Poniższe dwa przykłady pokazują różnice pomiędzy obiektami i strukturami danych. Obiekty ukrywają dane, tworząc abstrakcje, i udostępniają funkcje operujące na tych danych. Struktury danych udostępniają ich dane i nie mają znaczących funkcji. Przeczytajmy to jeszcze raz. Zwróćmy uwagę na komplementarną naturę tych dwóch definicji. Są one właściwie swoimi przeciwieństwami. Różnica ta może wydawać się nieznaczna, ale ma daleko idące implikacje. Jako przykład weźmy proceduralny kod kształtu z listingu 6.5. Klasa Geometry operuje na trzech klasach kształtu. Klasy kształtów są prostymi strukturami danych bez własnych operacji. Wszystkie operacje są zdefiniowane w klasie Geometry. L I S T I N G 6 . 5 . Kształt proceduralny public class Square { public Point topLeft; public double side; } public class Rectangle { public Point topLeft; public double height; public double width; } public class Circle { public Point center; public double radius; } public class Geometry { public final double PI = 3.141592653589793; public double area(Object shape) throws NoSuchShapeException { if (shape instanceof Square) { Square s = (Square)shape; return s.side * s.side; } else if (shape instanceof Rectangle) { Rectangle r = (Rectangle)shape; return r.height * r.width; } else if (shape instanceof Circle) { Circle c = (Circle)shape; return PI * c.radius * c.radius; } throw new NoSuchShapeException(); } }

OBIEKTY I STRUKTURY DANYCH

115

Czytelnicy, którzy preferują programowanie zorientowane obiektowo, mogą zmarszczyć brwi i narzekać, że jest to kod proceduralny — i będą mieli rację. Jednak to szyderstwo może być nie na miejscu. Zwróćmy uwagę, co się stanie, jeżeli dodamy funkcję perimeter() do klasy Geometry. Klasy kształtów pozostaną bez zmian! Wszystkie inne klasy korzystające z klas kształtów również się nie zmienią! Z drugiej strony, jeżeli dodamy nowy kształt, musimy zmienić wszystkie operujące na nim funkcje z Geometry. Przeczytajmy to ponownie. Trzeba zwrócić uwagę, że te dwa warunki są zupełnie przeciwstawne. Weźmy teraz przykład obiektowy z listingu 6.6. Metoda area() jest tu polimorficzna. Nie jest potrzebna klasa Geometry. Jeżeli więc dodamy nowy kształt, żadna z istniejących funkcji nie ulegnie zmianie, ale jeżeli dodamy nową funkcję, wszystkie kształty będą musiały być zmienione1! L I S T I N G 6 . 6 . Kształt polimorficzny public class Square implements Shape { private Point topLeft; private double side; public double area() { return side*side; } } public class Rectangle implements Shape { private Point topLeft; private double height; private double width; public double area() { return height * width; } } public class Circle implements Shape { private Point center; private double radius; public final double PI = 3.141592653589793; public double area() { return PI * radius * radius; } }

Ponownie widzimy komplementarną naturę tych dwóch definicji — są one swoimi przeciwieństwami! Pokazują podstawową różnicę pomiędzy obiektami i strukturami danych: Kod proceduralny (kod korzystający ze struktur danych) ułatwia dodawanie nowych funkcji bez zmiany istniejących struktur danych. Z kolei kod obiektowy ułatwia dodawanie nowych klas bez zmiany istniejących funkcji.

1

Istnieją sposoby obejścia tego problemu, dobrze znane doświadczonym projektantom obiektowym. Przykładem może być wzorzec Visitor lub podwójne rozsyłanie. Jednak techniki te są obciążone własnymi kosztami i zwykle dają w wyniku strukturę znaną z podejścia proceduralnego.

116

ROZDZIAŁ 6.

Prawdziwe jest również stwierdzenie odwrotne: Kod proceduralny utrudnia dodawanie nowych struktur danych, ponieważ muszą zostać zmienione wszystkie funkcje. Kod obiektowy utrudnia dodawanie nowych funkcji, ponieważ muszą zostać zmienione wszystkie klasy. Tak więc operacje, które są trudne do wykonania w sposób obiektowy, można łatwo zrealizować przy użyciu procedur, a operacje trudne do realizacji za pomocą procedur można łatwo wykonać za pomocą obiektów! A co zrobić w sytuacji, kiedy w złożonym systemie chcemy dodać nowy typ danych zamiast nowych funkcji? Dla takich przypadków najwłaściwsze jest zastosowanie technik obiektowych. Z drugiej strony, zdarza się również, że chcemy dodać nowe funkcje. W takich przypadkach najwłaściwszy wydaje się kod proceduralny i struktury danych. Doświadczeni programiści wiedzą, że twierdzenie, iż wszystko jest obiektem, to mit. Czasami faktycznie warto zastosować proste struktury danych z operującymi na nich procedurami.

Prawo Demeter Dobrze znana zasada, nazywana prawem Demeter2, mówi, że moduł powinien nie wiedzieć nic o wnętrzu obiektów, którymi manipuluje. Jak przedstawiliśmy w poprzednim punkcie, obiekty ukrywają swoje dane i udostępniają operacje. Oznacza to, że obiekt nie powinien udostępniać swojej struktury wewnętrznej przy użyciu akcesorów, ponieważ powoduje to udostępnienie, a nie ukrycie wewnętrznej struktury. Dokładniej rzecz ujmując, prawo Demeter głosi, że metoda f klasy C powinna wywoływać tylko metody z:  C, 

obiektu utworzonego przez f,



obiektu przekazanego jako argument do f,



obiektu umieszczonego w zmiennej instancyjnej klasy C.

Metoda nie powinna wywoływać metod z obiektów zwracanych przez jakąkolwiek z innych dozwolonych funkcji. Inaczej mówiąc, powinniśmy rozmawiać z przyjaciółmi, a nie z obcymi. W poniższym kodzie3 nie jest zachowane prawo Demeter (między innymi), ponieważ wywoływana jest metoda getScratchDir() z obiektu zwracanego przez getOptions(), a następnie wywoływana jest metoda getAbsolutePatch() na obiekcie zwracanym przez getScratchDir(). final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

2

http://en.wikipedia.org/wiki/Law_of_Demeter

3

Znalezionym gdzieś w bibliotekach Apache.

OBIEKTY I STRUKTURY DANYCH

117

Wraki pociągów Przedstawiony powyżej kod jest często nazywany wrakiem pociągu, ponieważ wygląda jak kilka wagonów kolejowych po zderzeniu. Tego rodzaju łańcuchy wywołań są uznawane za oznakę słabego stylu programowania i należy ich unikać [G36]. Najlepiej podzielić je w następujący sposób: Options opts = ctxt.getOptions(); File scratchDir = opts.getScratchDir(); final String outputDir = scratchDir.getAbsolutePath();

Czy te dwa fragmenty kodu naruszają prawo Demeter? Oczywiście wiemy, iż w tym module obiekt ctxt zawiera opcje, które zawierają katalog pośredni, który z kolei posiada ścieżkę bezwzględną. To sporo wiedzy jak na jedną funkcję. Wywołująca funkcja wie, w jaki sposób nawigować pomiędzy wieloma różnymi obiektami. To, czy naruszone jest prawo Demeter, zależy od tego, czy ctxt, Options i ScratchDir są obiektami, czy strukturami danych. Jeżeli są obiektami, to ich wewnętrzna struktura powinna być ukryta, a nie ujawniona, więc wiedza na temat jej budowy wewnętrznej jest jawnym naruszeniem prawa Demeter. Z drugiej strony, jeżeli ctxt, Options i ScratchDir są po prostu strukturami danych bez zdefiniowanych operacji, to w naturalny sposób ujawniają swoją strukturę wewnętrzną i prawo Demeter nie ma tu zastosowania. Zastosowanie funkcji akcesorów zwykle utrudnia dostrzeżenie problemu. Jeżeli kod zostałby napisany tak jak poniżej, to prawdopodobnie nie pytalibyśmy o naruszenie prawa Demeter. final String outputDir = ctxt.options.scratchDir.absolutePath;

Problem ten byłby znacznie mniej kłopotliwy, jeżeli struktury danych po prostu miałyby zmienne publiczne i nie zawierały funkcji, natomiast obiekty miałyby zmienne prywatne i funkcje publiczne. Jednak istnieją biblioteki i standardy (na przykład beans), które wymagają, aby nawet proste struktury danych miały akcesory i mutatory.

Hybrydy Przedstawione problemy często prowadzą do powstania struktur hybrydowych będących w połowie obiektami, a w połowie strukturami danych. Mają one funkcje wykonujące ważne operacje, ale mają również zmienne publiczne lub publiczne akcesory i mutatory, które oprócz tego, że realizują zamierzone operacje, udostępniają zmienne prywatne, co pozwala zewnętrznym funkcjom na użycie tych zmiennych w sposób, w jaki programy proceduralne używają struktur danych4. Takie hybrydy utrudniają dodawanie nowych funkcji, jak również utrudniają dodawanie nowych struktur danych. Mają najgorsze cechy z obu światów. Należy unikać ich tworzenia. Są one charakterystyczne dla tych projektów, w których autorzy nie są pewni — lub co gorsza, nie mają pojęcia — czy potrzebują ochrony funkcji, czy typów. 4

Jest to czasami nazywane „zazdrością o funkcje” (ang. Feature Envy) [Refactoring].

118

ROZDZIAŁ 6.

Ukrywanie struktury Załóżmy, że ctxt, options oraz scratchDir są obiektami ze zdefiniowanymi operacjami. W takim przypadku obiekty powinny ukrywać swoją wewnętrzną strukturę i nie powinniśmy mieć możliwości nawigowania po nich. W jaki sposób możemy więc otrzymać ścieżkę bezwzględną do katalogu pośredniego? ctxt.getAbsolutePathOfScratchDirectoryOption();

lub ctx.getScratchDirectoryOption().getAbsolutePath()

Pierwsza opcja może doprowadzić do eksplozji metod w obiekcie ctxt. W drugiej zakładamy, że getScratchDirectoryOption() zwraca strukturę danych, a nie obiekt. Żadna z tych opcji nie wygląda dobrze. Jeżeli ctxt jest obiektem, powinniśmy powiedzieć mu, aby coś zrobił; nie powinniśmy pytać go o szczegóły wewnętrzne. Dlaczego więc chcemy otrzymać ścieżkę bezwzględną do katalogu pośredniego? Co mamy zamiar z nią zrobić? Możemy się dowiedzieć tego z następującego kodu (znajdującego się wiele wierszy dalej) z tego samego modułu: String outFile = outputDir + "/" + className.replace('.', '/') + ".class"; FileOutputStream fout = new FileOutputStream(outFile); BufferedOutputStream bos = new BufferedOutputStream(fout);

Wymieszanie różnych poziomów szczegółowości [G34][G6] powoduje problemy. Kropki, ukośniki i obiekty File nie powinny być tak beztrosko mieszane ze sobą oraz z otaczającym je kodem. Ignorując ten problem, widzimy w końcu, że przeznaczeniem ścieżki bezwzględnej do katalogu pośredniego było utworzenie pliku roboczego o podanej nazwie. Czy obiekt ctxt może to zrobić za nas? BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

Wydaje się to rozsądną operacją, jaką obiekt może wykonać! Pozwala to ukryć szczegóły wewnętrzne obiektu ctxt i uniemożliwia funkcjom łamanie prawa Demeter przez nawigowanie pomiędzy obiektami, o których nie powinniśmy wiedzieć.

Obiekty transferu danych Kwintesencją postaci struktur danych jest klasa ze zmiennymi publicznymi niezawierająca funkcji. Czasami jest to nazywane obiektem transferu danych, czyli DTO. DTO są bardzo przydatnymi strukturami, szczególnie w przypadku komunikowania się z bazami danych, analizowania komunikatów z gniazd sieciowych i tak dalej. Często stają się pierwszym elementem serii przekształceń, które konwertują surowe dane z bazy danych na obiekty w kodzie aplikacji. Nieco częściej spotykaną jest postać bean, przedstawiona na listingu 6.7. Ma ona zmienne prywatne, na których operuje się za pomocą getterów i setterów. Ta quasi-hermetyzacja obiektów bean powoduje, że niektórzy puryści obiektowi czują się lepiej, ale nie ma ona żadnych dodatkowych zalet. OBIEKTY I STRUKTURY DANYCH

119

L I S T I N G 6 . 7 . address.java public class Address { private String street; private String streetExtra; private String city; private String state; private String zip; public Address(String street, String streetExtra, String city, String state, String zip) { this.street = street; this.streetExtra = streetExtra; this.city = city; this.state = state; this.zip = zip; } public String getStreet() { return street; } public String getStreetExtra() { return streetExtra; } public String getCity() { return city; } public String getState() { return state; } public String getZip() { return zip; } }

Active Record Active Record to specjalna forma DTO. Są to struktury danych ze zmiennymi publicznymi (lub dostępnymi w stylu bean), ale dodatkowo mają metody nawigacyjne, takie jak save i find. Zwykle obiekty Active Record są bezpośrednim tłumaczeniem z tabel bazy danych lub innych źródeł. Niestety, często zdarza się, że programiści traktują te struktury danych, jakby były pełnoprawnymi obiektami, i umieszczają w nich metody zasad biznesowych. Jest to dziwne, ponieważ powoduje powstanie hybrydy struktury danych i obiektu. Rozwiązaniem jest oczywiście traktowanie Active Record jako struktury danych i tworzenie osobnych obiektów, które zawierają zasady biznesowe i ukrywają ich dane wewnętrzne (którymi będą prawdopodobnie obiekty Active Record).

120

ROZDZIAŁ 6.

Zakończenie Obiekty udostępniają operacje i ukrywają dane. Ułatwia to dodawanie nowych rodzajów obiektów bez zmiany istniejących operacji, ale utrudnia dodawanie nowych operacji do istniejących obiektów. Struktury danych udostępniają dane i nie mają znaczących operacji. Ułatwia to dodawanie nowych operacji do istniejących struktur danych, ale utrudnia dodawanie nowych struktur danych do istniejących funkcji. W każdym systemie potrzebujemy czasami elastyczności w dodawaniu nowych typów danych, więc w tych częściach systemu powinniśmy korzystać głównie z obiektów. W innych przypadkach oczekujemy elastyczności w dodawaniu nowych operacji, więc w tych częściach systemu powinniśmy korzystać głównie z typów danych i procedur. W programowaniu nie należy kierować się uprzedzeniami, ale wybierać takie rozwiązanie, które umożliwi najlepszą realizację zadań.

Bibliografia [Refactoring]: Martin Fowler i inni, Refactoring: Improving the Design of Existing Code, AddisonWesley 1999.

OBIEKTY I STRUKTURY DANYCH

121

122

ROZDZIAŁ 6.

ROZDZIAŁ 7.

Obsługa błędów Michael Feathers

książce na temat czystego kodu może wydawać się nieporoR zumieniem. A jednak musimy zająć sięwtym tematem. Obsługa błędów jest po prostu częścią proOZDZIAŁ POŚWIĘCONY OBSŁUDZE BŁĘDÓW

gramowania. Dane wejściowe mogą być nieprawidłowe, a urządzenia mogą ulec uszkodzeniu. Mówiąc krótko, wszystko może pójść źle, a programista jest odpowiedzialny za takie skonstruowanie kodu, aby wykonywał to, co powinien. Połączenie tematu obsługi błędów z zagadnieniami czystego kodu powinno być oczywiste. Wiele zbiorów kodu jest całkowicie zdominowanych przez obsługę błędów. Mówiąc „zdominowanych”, nie mam na myśli tego, że kod ten realizuje wyłącznie obsługę błędów. Mam na myśli to, że niemal niemożliwe jest określenie, co ten kod tak naprawdę robi, ponieważ wszystko jest usiane obsługą błędów. Obsługa błędów jest ważna, ale jeżeli utrudnia zrozumienie logiki kodu, jest niewłaściwa. W tym rozdziale przedstawię kilka technik i założeń, z których możemy skorzystać przy pisaniu kodu, który jest zarówno czytelny, jak i solidny — kodu, który obsługuje błędy elegancko i stylowo.

123

Użycie wyjątków zamiast kodów powrotu W odległej przeszłości korzystaliśmy z wielu języków programowania nieposiadających wyjątków. W językach tych techniki obsługi i raportowania błędów były ograniczone. Można było ustawić znacznik błędu lub kod błędu, który następnie mógł być sprawdzany przez funkcję wywołującą. Podejście to jest przedstawione na listingu 7.1. L I S T I N G 7 . 1 . DeviceController.java public class DeviceController { ... public void sendShutDown() { DeviceHandle handle = getHandle(DEV1);

// Sprawdzenie stanu urządzenia. if (handle != DeviceHandle.INVALID) {

// Zapisanie stanu urządzenia w polu rekordu. retrieveDeviceRecord(handle);

// Jeżeli nie wstrzymane, wyłączenie. if (record.getStatus() != DEVICE_SUSPENDED) { pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle); } else { logger.log("Urządzenie wstrzymane. Nie można wyłączyć"); } } else { logger.log("Niewłaściwy uchwyt dla: " + DEV1.toString()); }

}

} ...

Rozwiązanie to jest jednak problematyczne, ponieważ powoduje bałagan w funkcji wywołującej. Musi ona sprawdzić błędy natychmiast po wykonaniu wywołania. Niestety, łatwo o tym zapomnieć. Z tego powodu w przypadku napotkania błędu lepiej zgłosić wyjątek. Kod wywołujący jest prostszy. Jego logika nie jest zanieczyszczona obsługą błędów. Na listingu 7.2 przedstawiony jest wcześniejszy kod, w którym metody wykrywające błąd zgłaszają wyjątek. L I S T I N G 7 . 2 . DeviceController.java (z wyjątkami) public class DeviceController { ... public void sendShutDown() { try { tryToShutDown(); } catch (DeviceShutDownError e) { logger.log(e); } } private void tryToShutDown() throws DeviceShutDownError { DeviceHandle handle = getHandle(DEV1); DeviceRecord record = retrieveDeviceRecord(handle);

}

124

pauseDevice(handle); clearDeviceWorkQueue(handle); closeDevice(handle);

ROZDZIAŁ 7.

private DeviceHandle getHandle(DeviceID id) { ... throw new DeviceShutDownError("Niewłaściwy uchwyt dla: " + id.toString()); ... } ... }

Jak widać, ta wersja kodu jest znacznie czytelniejsza. To nie jest jednak wyłącznie kwestia estetyki. Kod jest lepszy, ponieważ dwa problemy, które były ze sobą splątane, algorytm wyłączenia urządzenia i obsługi błędów, zostały rozdzielone. Łatwiej teraz zrozumieć każdą z nich.

Rozpoczynanie od pisania instrukcji try-catch-finally Jedną z najbardziej interesujących cech wyjątków jest to, że definiują one zakresy w naszym programie. Gdy wykonujemy kod w części try instrukcji try-catch-finally, zakładamy, że wykonanie może zostać w dowolnym momencie przerwane i wznowione w bloku catch. Dzięki temu bloki try są podobne do transakcji. Nasz blok catch ma za zadanie pozostawić program w stanie spójnym, niezależnie od tego, co stało się w try. Z tego powodu dobrą praktyką jest korzystanie z instrukcji try-catch-finally w przypadku tworzenia kodu, w którym mogą zostać zgłoszone wyjątki. Pomaga to zdefiniować operacje, jakich powinien oczekiwać użytkownik tego kodu, niezależnie od tego, co złego wydarzy się w czasie wykonywania kodu z try. Rozważmy następujący przykład. Chcemy napisać kod odwołujący się do pliku, z którego odczytuje serializowane obiekty. Zaczynamy od testu jednostkowego, który pokazuje, że w przypadku braku pliku otrzymujemy wyjątek. @Test(expected = StorageException.class) public void retrieveSectionShouldThrowOnInvalidFileName() { sectionStore.retrieveSection("invalid - file"); }

Test prowadzi nas do utworzenia następującego fragmentu: public List retrieveSection(String sectionName) {

// Zaślepka zwracanej wartości do momentu utworzenia implementacji. return new ArrayList (); }

Test zawiedzie, ponieważ nie zgłasza wyjątku. Następnie zmieniamy naszą implementację, aby spróbować odwołać się do nieprawidłowego pliku. Operacja ta zgłasza wyjątek: public List retrieveSection(String sectionName) { try { FileInputStream stream = new FileInputStream(sectionName) } catch (Exception e) { throw new StorageException("retrieval error", e); } return new ArrayList (); }

OBSŁUGA BŁĘDÓW

125

Test powiedzie się, ponieważ przechwyci wyjątek. Od tego momentu możemy zacząć modyfikowanie kodu. Możemy zawęzić typ przechwytywanego wyjątku, aby pasował do typu faktycznie zgłaszanego przez konstruktor FileInputStream: FileNotFoundException: public List retrieveSection(String sectionName) { try { FileInputStream stream = new FileInputStream(sectionName); stream.close(); } catch (FileNotFoundException e) { throw new StorageException("retrieval error”, e); } return new ArrayList (); }

Teraz, po zdefiniowaniu zakresu za pomocą struktury try-catch, możemy użyć TDD do zbudowania reszty potrzebnej logiki. Logika ta zostanie umieszczona pomiędzy utworzeniem FileInputStream a wywołaniem close i możemy w niej założyć, że wszystko przebiegnie prawidłowo. Spróbujmy napisać testy wymuszające wyjątki, a następnie dodać do procedury obsługi operacje pozwalające spełnić te testy. Spowoduje to konieczność zbudowania zakresu transakcji za pomocą bloku try, co pomoże nam utrzymać transakcyjną naturę tego zakresu.

Użycie niekontrolowanych wyjątków Debata jest zakończona. Przez lata programiści Javy debatowali nad zaletami i odpowiedzialnością kontrolowanych wyjątków. Gdy w pierwszej wersji języka Java zostały wprowadzone kontrolowane wyjątki, wydawało się to dobrym pomysłem. Sygnatura każdej metody powinna zawierać listę wszystkich wyjątków, jakie może przekazywać do wywołującego. Co więcej, wyjątki te były częścią typu metody. Kod po prostu nie skompilował się, jeżeli sygnatura nie odpowiadała temu, co robił kod. Z czasem zaczęliśmy myśleć, że kontrolowane wyjątki były świetnym pomysłem — dawały one pewne korzyści. Obecnie jednak jest jasne, że nie są one potrzebne do tworzenia solidnego oprogramowania. C# nie posiada kontrolowanych wyjątków i, pomimo wielu prób, C++ też ich nie posiada. Nie ma ich również w językach Python czy Ruby. Jednak we wszystkich tych językach możliwe jest pisanie solidnego oprogramowania. Z powodu istnienia tak wielu przykładów musieliśmy zdecydować — naprawdę — czy kontrolowane wyjątki są warte ich ceny. Jakiej ceny? Ceną kontrolowanych wyjątków jest naruszenie zasady otwarty-zamknięty1. Jeżeli zgłosimy kontrolowany wyjątek w metodzie naszego kodu, a instrukcja catch znajduje się trzy poziomy wyżej, musimy zadeklarować ten wyjątek w sygnaturze każdej metody pomiędzy naszym kodem a catch. Oznacza to, że zmiana wykonana na niskim poziomie oprogramowania wymusza zmiany na wielu wyższych poziomach. Zmienione moduły muszą zostać ponownie skompilowane i zainstalowane, nawet jeżeli zmiana bezpośrednio ich nie dotyczy.

1

[Martin].

126

ROZDZIAŁ 7.

Weźmy pod uwagę hierarchię wywołań w dużym systemie. Funkcje znajdujące się na górnym poziomie wywołują funkcje znajdujące się poniżej, które wywołują kolejne funkcje poniżej, i tak dalej. Załóżmy teraz, że jedna z funkcji najniższego poziomu została zmodyfikowana w taki sposób, że musi zgłosić wyjątek. Jeżeli ten wyjątek jest kontrolowany, to do sygnatury funkcji należy dodać klauzulę throws. Jednak oznacza to, że każda funkcja, która wywołuje naszą zmodyfikowaną funkcję, musi być również zmodyfikowana, aby przechwytywała nowy wyjątek — w przeciwnym wypadku należy dołączyć do jej sygnatury klauzulę throws. Operacje te realizowane są w nieskończoność! Końcowym wynikiem są kaskadowe zmiany zaczynające się na najniższym poziomie oprogramowania i kończące na najwyższym! Naruszona jest również hermetyzacja, ponieważ wszystkie funkcje w ścieżce muszą poznać szczegóły tego niskopoziomowego wyjątku. Jako że przeznaczeniem wyjątków jest umożliwienie obsługi błędów na odległość, trzeba uznać za porażkę fakt, że kontrolowane wyjątki niszczą w ten sposób hermetyzację. Kontrolowane wyjątki czasami mogą być użyteczne, na przykład gdy piszemy ważną bibliotekę. Konieczne jest wtedy ich przechwytywanie. Jednak w zwykłym programowaniu aplikacji koszt zależności jest większy niż ich zalety.

Dostarczanie kontekstu za pomocą wyjątków Każdy zgłaszany przez nas wyjątek powinien mieć wystarczającą ilość informacji na temat kontekstu, aby można było określić źródło i lokalizację błędu. W języku Java możemy uzyskać ślad stosu z dowolnego wyjątku; jednak ślad stosu nie zawiera informacji o przeznaczeniu nieudanej operacji. Trzeba tworzyć komunikaty błędów zawierające odpowiednie informacje i przekazywać je za pomocą wyjątków. Należy zamieścić w nich nieudaną operację i typ awarii. Jeżeli w naszej aplikacji stosujemy rejestrowanie, musimy przekazać wystarczające informacje, aby można było zarejestrować błąd w bloku catch.

Definiowanie klas wyjątków w zależności od potrzeb wywołującego Istnieje wiele sposobów klasyfikowania błędów. Możemy klasyfikować je w zależności od źródła: czy pochodzą one z tego komponentu, czy innego? Lub w zależności od typu: czy jest to awaria urządzenia, sieci, czy błąd programowy? Jednak gdy definiujemy klasy wyjątków w aplikacji, największą uwagę powinniśmy zwrócić na sposób ich przechwytywania. Spójrzmy na przykład słabej klasyfikacji wyjątków. Mamy tu instrukcję try-catch-finally do realizacji wywołania z zewnętrznej biblioteki. Obejmuje ona wszystkie wyjątki, jakie mogą zgłosić te wywołania: ACMEPort port = new ACMEPort(12); try { port.open(); } catch (DeviceResponseException e) {

OBSŁUGA BŁĘDÓW

127

reportPortError(e); logger.log("Wyjątek odpowiedzi urządzenia", e); } catch (ATM1212UnlockedException e) { reportPortError(e); logger.log("Wyjątek odblokowania", e); } catch (GMXError e) { reportPortError(e); logger.log("Wyjątek odpowiedzi urządzenia"); } finally { ... }

Ta instrukcja zawiera wiele duplikatów, ale nie powinniśmy być tym zaskoczeni. W większości przypadków obsługi wyjątków wykonywane operacje są względnie standardowe, niezależnie od faktycznej przyczyny. Musimy zarejestrować błąd i upewnić się, że możemy kontynuować. W tym przypadku, ponieważ wiemy, że wykonywane operacje są w przybliżeniu identyczne, niezależnie od wyjątku, możemy znacznie uprościć tworzony kod przez otoczenie wywoływanego API i upewnienie się, że zwraca wspólny typ wyjątku: LocalPort port = new LocalPort(12); try { port.open(); } catch (PortDeviceFailure e) { reportError(e); logger.log(e.getMessage(), e); } finally { ... }

Nasza klasa LocalPort jest prostą klasą osłonową, przechwytującą i przekształcającą wyjątki zgłaszane przez klasę ACMEPort: public class LocalPort { private ACMEPort innerPort; public LocalPort(int portNumber) { innerPort = new ACMEPort(portNumber); }

}

public void open() { try { innerPort.open(); } catch (DeviceResponseException e) { throw new PortDeviceFailure(e); } catch (ATM1212UnlockedException e) { throw new PortDeviceFailure(e); } catch (GMXError e) { throw new PortDeviceFailure(e); } } …

Tego rodzaju klasy osłonowe, jakie zdefiniowaliśmy dla ACMEPort, mogą być bardzo przydatne. Faktycznie, osłanianie API firm zewnętrznych jest dobrą praktyką. Gdy osłaniamy API firmy zewnętrznej, minimalizujemy zależności od niego — w przyszłości można będzie zdecydować się na przejście na inną bibliotekę bez ponoszenia zbytnich kosztów. Osłanianie ułatwia również tworzenie imitacji klas zewnętrznych dla potrzeb testowania własnego kodu.

128

ROZDZIAŁ 7.

Ostatnią zaletą osłaniania jest to, że nie jesteśmy przywiązani do określonych decyzji projektowych producenta API. Można zdefiniować API, które będzie dla nas komfortowe. We wcześniejszym przykładzie zdefiniowaliśmy jeden wyjątek dla awarii urządzenia port i okazało się, że możemy pisać znacznie czytelniejszy kod. Często jedna klasa wyjątków jest wystarczająca dla określonego obszaru kodu. Informacje wysyłane w wyjątku pozwalają nam rozróżniać błędy. Należy korzystać z różnych klas tylko w przypadkach, gdy chcemy przechwycić jeden wyjątek, a inny chcemy przepuścić.

Definiowanie normalnego przepływu Jeżeli stosujemy się do porad z wcześniejszych punktów, uzyskamy wyraźny rozdział między logiką biznesową a obsługą błędów. Kod zaczyna wyglądać jak czysty, schludny algorytm. Jednak proces dochodzenia do takiej formy powoduje spychanie wykrywania błędów na margines naszego programu. Osłaniamy zewnętrzne API tak, aby zgłaszały wyjątki, i definiujemy procedury obsługi w kodzie, aby można było obsłużyć każdą przerwaną operację. W większości przypadków jest to świetne podejście, ale zdarzają się sytuacje, w których możemy nie chcieć przerywać pracy. Rozważmy następujący przykład. Poniżej zamieszczony jest dziwny kod, w którym sumujemy wydatki w aplikacji księgowej: try { MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); m_total += expenses.getTotal(); } catch(MealExpensesNotFound e) { m_total += getMealPerDiem(); }

W tej firmie wszystkie wydatki na posiłki wchodzą do podsumowania. Jeżeli nie będzie takiego wydatku, pracownicy otrzymują ryczałt dzienny. Wyjątek zaciemnia logikę kodu. Czy nie byłoby lepiej, gdybyśmy nie musieli obsługiwać specjalnego przypadku? Wówczas kod będzie znacznie prostszy. Mógłby wyglądać tak: MealExpenses expenses = expenseReportDAO.getMeals(employee.getID()); m_total += expenses.getTotal();

Czy będziemy w stanie tak uprościć kod? Okazuje się, że tak. Zmienimy klasę ExpenseReportDAO tak, aby zawsze zwracała obiekt MealExpense. Jeżeli nie będą występowały wydatki na posiłki, zwracany będzie obiekt MealExpense zawierający wartość ryczałtu dziennego: public class PerDiemMealExpenses implements MealExpenses { public int getTotal() {

// Zwrócenie domyślnej wartości ryczałtu dziennego. } }

OBSŁUGA BŁĘDÓW

129

Jest to przykład wzorca specjalnego przypadku (ang. Special Case Pattern) [Fowler]. Tworzymy w nim klasę lub konfigurujemy obiekt, aby obsługiwał szczególny przypadek za nas. Po takiej operacji kod klienta nie będzie musiał obsługiwać sytuacji wyjątkowej. Obsługa ta jest hermetyzowana w obiekcie przypadku specjalnego.

Nie zwracamy null Uważam, że każde omówienie obsługi błędów powinno zawierać przedstawienie operacji, które powodują powstanie błędów. Pierwszą pozycją na liście jest zwracanie wartości null. Nie zliczę widzianych przeze mnie aplikacji, w których niemal każdy wiersz kodu zawierał test wartości null. Poniżej zamieszczony jest przykład takiego kodu: public void Item(Item item) { if (item != null) { ItemRegistry registry = peristentStore.getItemRegistry(); if (registry != null) { Item existing = registry.getItem(item.getID()); if (existing.getBillingPeriod().hasRetailOwner()) { existing.(item); } } } }

Gdy zwracamy wartość null, w rzeczywistości tworzymy sobie dodatkową pracę i powodujemy problemy w funkcjach wywołujących. W takich przypadkach brak jednego testu wartości null powoduje, że aplikacja wymyka się spod kontroli. Czy Czytelnik zauważył, że w drugim wierszu zagnieżdżonej instrukcji if nie ma kontroli wartości null? Co się stanie w trakcie działania programu, jeżeli persistentStore będzie null? Otrzymamy w takim przypadku wyjątek NullPointerException i albo ktoś przechwyci ten wyjątek na najwyższym poziomie, albo nie. W obu przypadkach jest to złe. Co można zrobić w odpowiedzi na wyjątek NullPointerException zgłoszony w głębi naszej aplikacji? Łatwo powiedzieć, że problem w powyższym kodzie wynika z braku kontroli wartości null, ale w rzeczywistości problem polega na tym, że jest ich zbyt dużo. Jeżeli mamy zamiar zwrócić null z metody, warto rozważyć zgłoszenie wyjątku lub zwrócenie obiektu specjalnego przypadku. Jeżeli wywołujemy metodę zwracającą null pochodzącą z zewnętrznego API, warto rozważyć osłonięcie tej metody inną, która zgłasza wyjątek lub zwraca obiekt specjalnego przypadku. W wielu sytuacjach obiekty specjalnych przypadków są prostym rozwiązaniem. Wyobraźmy sobie, że mamy następujący kod: List<Employee> employees = getEmployees(); if (employees != null) { for(Employee e : employees) { totalPay += e.getPay(); } }

130

ROZDZIAŁ 7.

Metoda getEmployees może zwrócić null, ale czy musi to robić? Jeżeli zmienimy getEmployees tak, aby zwracała pustą listę, możemy wyczyścić nasz kod: List<Employee> employees = getEmployees(); for(Employee e : employees) { totalPay += e.getPay(); }

Na szczęście Java posiada metodę Collections.emptyList() zwracającą predefiniowaną niezmienną listę, która może być wykorzystana do takich celów. public List<Employee> getEmployees() { if( .. brak pracowników .. ) return Collections.emptyList(); }

Jeżeli będziemy tworzyć kod w taki sposób, zmniejszymy możliwość powstawania wyjątków NullPointerException, a nasz kod będzie czytelniejszy.

Nie przekazujemy null Zwracanie wartości null z metod jest niedobrą praktyką, ale przekazywanie wartości null do metod jest jeszcze gorsze. O ile nie korzystamy z API, które oczekuje wartości null, i o ile mamy taką możliwość, powinniśmy unikać przekazywania null we własnym kodzie. Dlaczego? Rozważmy następujący przykład. Mamy tu prostą metodę, która oblicza odległość między dwoma punktami: public class MetricsCalculator { public double xProjection(Point p1, Point p2) { return (p2.x – p1.x) * 1.5; } ... }

Co się stanie, gdy ktoś przekaże null jako argument? calculator.xProjection(null, new Point(12, 13));

Oczywiście otrzymamy NullPointerException. Jak można to poprawić? Możemy utworzyć nowy typ wyjątku i zgłosić go: public class MetricsCalculator { public double xProjection(Point p1, Point p2) { if (p1 == null || p2 == null) { throw InvalidArgumentException( "Niewłaściwy argument dla MetricsCalculator.xProjection"); } return (p2.x – p1.x) * 1.5; } }

Czy tak jest lepiej? Być może jest to lepsze niż wyjątek wskaźnika null, ale należy pamiętać, że musimy zdefiniować procedurę obsługi zdarzenia InvalidArgumentException. Co powinna robić taka procedura? Czy istnieje właściwa akcja?

OBSŁUGA BŁĘDÓW

131

Istnieje inna opcja. Możemy skorzystać ze zbioru asercji. public class MetricsCalculator { public double xProjection(Point p1, Point p2) { assert p1 != null : "p1 nie może być null"; assert p2 != null : "p2 nie może być null"; return (p2.x – p1.x) * 1.5; } }

Jest to dobra dokumentacja, ale nie rozwiązuje problemu. Jeżeli ktoś przekaże null, otrzyma błąd wykonania. W większości języków programowania nie istnieje dobra metoda obsługi wartości null przypadkowo przekazanych przez wywołującą procedurę. Z tego powodu racjonalnym podejściem jest zakazanie przekazywania wartości null. W takim przypadku możemy tworzyć nasz kod, wiedząc, że null w liście argumentów jest symptomem problemu, co będzie skutkowało znacznie mniejszą liczbą pomyłek.

Zakończenie Czysty kod jest czytelny, ale musi być również solidny. Nie są to cele pozostające w konflikcie. Możemy pisać solidny czysty kod, jeżeli będziemy traktować obsługę błędów jako osobne zadanie, coś, co jest widziane niezależnie od głównej logiki. Takie podejście do problemu ułatwi konserwację kodu w przyszłości.

Bibliografia [Martin]: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall 2002.

132

ROZDZIAŁ 7.

ROZDZIAŁ 8.

Granice James Grenning

naszym systemie. Czasami kupujemy pakiety R firm zewnętrznych lub korzystamy z kodu open wsource. W innym przypadku polegamy na zespoZADKO KONTROLUJEMY WSZYSTKIE ELEMENTY KODU

łach z naszej firmy, które produkują dla nas komponenty lub podsystemy. W jakiś sposób musimy w czysty sposób zintegrować ten obcy kod z naszym. W tym rozdziale zapoznamy się z praktykami i technikami pozwalającymi na zachowanie czystych granic naszego oprogramowania.

133

Zastosowanie kodu innych firm Istnieje naturalne napięcie pomiędzy dostawcą interfejsu a jego użytkownikiem. Dostawcy pakietów i bibliotek starają się o szeroki zakres zastosowań, więc działają w wielu środowiskach i odwołują się do szerokiej gamy odbiorców. Z drugiej strony, użytkownicy żądają interfejsu, który jest przystosowany do ich konkretnych potrzeb. Takie napięcia mogą powodować problemy na granicach naszych systemów. Rozważmy przykład klasy java.util.Map. Jak wynika z analizy rysunku 8.1, Map ma bardzo szeroki interfejs z wieloma możliwościami. Oczywiście, siła i elastyczność to przydatne cechy, ale mogą również wiązać się z dużą odpowiedzialnością. Nasze aplikacje mogą na przykład wykorzystywać obiekty Map oraz je przesyłać. Naszym założeniem może być, że żaden z odbiorców naszych obiektów Map nie będzie z nich nic usuwał. Jednak bezpośrednio na początku listy metod mamy clear(). Każdy użytkownik obiektu Map ma możliwość wyczyszczenia go. Być może nasza konwencja projektowa dyktuje, że w obiekcie Map można przechowywać obiekty określonego typu, ale obiekty Map nie mogą w niezawodny sposób ograniczać typów obiektów w nich umieszczanych. Każdy zdeterminowany użytkownik może dodawać do Map elementy dowolnego typu.

R Y S U N E K 8 . 1 . Metody klasy Map

Jeżeli nasza aplikacja potrzebuje obiektu Map dla obiektów Sensor, do tworzenia kontenera wykorzystamy następujący kod: Map sensors = new HashMap();

Następnie, gdy w innej części kodu będziemy chcieli odwołać się do jego zawartości, użyjemy następującego kodu: Sensor s = (Sensor)sensors.get(sensorId );

134

ROZDZIAŁ 8.

Nie będziemy używać tego wywołania jednokrotnie, ale wiele razy w całym kodzie. Klient tego kodu jest odpowiedzialny za pobranie obiektu Object z Map i rzutowanie go na właściwy typ. To działa, ale nie jest czystym kodem. Dodatkowo kod ten nie opowiada historii, tak jak powinien. Niezawodność tego kodu może być znacznie poprawiona przez zastosowanie typów ogólnych, jak poniżej: Map<Sensor> sensors = new HashMap<Sensor>(); ... Sensor s = sensors.get(sensorId );

Nie rozwiązuje to jednak problemu dostarczania przez Map<Sensor> większych możliwości, niż potrzebujemy. Przekazywanie obiektu Map<Sensor> w całym systemie powoduje, że w przypadku jakiejkolwiek zmiany interfejsu Map konieczne będzie wprowadzenie zmian w wielu miejscach. Można myśleć, że taka zmiana jest mało prawdopodobna, ale należy pamiętać, że już zdarzyła się po dodaniu obsługi typów ogólnych w Java 5. Faktycznie, spotkałem się z systemami, w których zrezygnowano z użycia typów ogólnych z powodu konieczności wprowadzenia olbrzymiej liczby zmian, które były wymagane, aby można było skorzystać z interfejsu Map. Łatwiejszy sposób zastosowania Map jest przedstawiony poniżej. Żaden z użytkowników klasy Sensors nie będzie wiedział, czy typy ogólne zostały w niej użyte, czy nie. Wybór ten stał się (i zawsze był) szczegółem implementacji. public class Sensors { private Map sensors = new HashMap(); public Sensor getById(String id) { return (Sensor) sensors.get(id); }

// Odcinamy }

Interfejs graniczny (Map) został ukryty. Jego ewolucja będzie miała niewielki wpływ na pozostałe części aplikacji. Zastosowanie typów ogólnych nie stanowi już dużego problemu, ponieważ rzutowanie i zarządzanie typami jest obsłużone wewnątrz klasy Sensors. Interfejs ten jest również odpowiednio dostosowany i ograniczony, aby spełniał potrzeby aplikacji. Wynikowy kod jest przez to łatwiejszy do zrozumienia i trudniej popełnić pomyłkę. Klasa Sensors może wymuszać zasady projektowe i biznesowe. Nie sugerujemy jednak, aby każde użycie Map było w ten sposób hermetyzowane. Zamiast tego radzimy nie przekazywać obiektów Map (ani innych interfejsów granicznych) po całym systemie. Jeżeli korzystamy z interfejsu granicznego, takiego jak Map, należy korzystać z niego w klasie lub w bliskiej rodzinie klas, w których jest wykorzystywany. Należy unikać zwracania go lub wykorzystywania jako argument w publicznym API.

GRANICE

135

Przeglądanie i zapoznawanie się z granicami Kod firm zewnętrznych pozwala na dostarczenie większej liczby funkcji w krótszym czasie. Od czego zacząć, gdy będziemy chcieli wykorzystać obcy pakiet? Nie naszym zadaniem jest testowanie obcego kodu, ale w naszym interesie jest napisanie testów dla tego kodu, z którego korzystamy w projekcie. Załóżmy, że nie jest jasne, jak używać pewnej biblioteki obcej firmy. Możemy spędzić dzień lub dwa (albo więcej), czytając dokumentację i podejmując decyzję, jak będziemy korzystać z tej biblioteki. Następnie możemy napisać nasz kod wykorzystujący kod firmy zewnętrznej i sprawdzić, czy realizuje to, czego się spodziewaliśmy. Nie będzie niespodzianką, gdy spędzimy długie godziny na debugowaniu i próbach zorientowania się, czy błędy znajdują się w naszym kodzie, czy obcym. Uczenie się obcego kodu jest zawsze trudne. Integrowanie kodu obcego również jest trudne. Wykonywanie tych dwóch czynności jednocześnie jest podwójnie trudne. Być może warto spróbować innego podejścia? Zamiast eksperymentować z wykorzystaniem nowych funkcji w kodzie produkcyjnym, powinniśmy napisać kilka testów w celu skontrolowania naszego zrozumienia analizowanego kodu. Jim Newkirk nazywa to testami uczącymi1. W testach uczących wywołujemy API zewnętrzne tak, jak robilibyśmy to w naszej aplikacji. W rzeczywistości wykonujemy kontrolowane eksperymenty, sprawdzające naszą wiedzę na temat API. Testy skupiają się na elementach, które chcemy uzyskać z API.

Korzystanie z pakietu log4j Załóżmy, że chcemy użyć pakietu log4j z Apache zamiast naszego własnego pakietu rejestrowania. Pobieramy go i otwieramy stronę wprowadzającą dokumentacji. Bez dokładnej lektury jesteśmy w stanie napisać nasz pierwszy test, w którym oczekujemy wypisania słowa cześć na konsoli. @Test public void testLogCreate() { Logger logger = Logger.getLogger("MyLogger"); logger.info("cześć"); }

Po jego uruchomieniu program zgłasza błąd informujący, że potrzebujemy czegoś o nazwie Appender. Po krótkiej lekturze znajdujemy informację, że dostępna jest klasa ConsoleAppender. Tworzymy więc ConsoleAppender i sprawdzamy, czy odkryliśmy sekrety kierowania komunikatów na konsolę. @Test public void testLogAddAppender() { Logger logger = Logger.getLogger("MyLogger"); ConsoleAppender appender = new ConsoleAppender(); logger.addAppender(appender); logger.info("cześć"); } 1

[BeckTDD], s. 136 – 137.

136

ROZDZIAŁ 8.

Tym razem okazuje się, że Appender nie posiada strumienia wyjściowego. Dziwne — wydaje się logiczne, że go mamy. Z niewielką pomocą Google próbujemy czegoś takiego: @Test public void testLogAddAppender() { Logger logger = Logger.getLogger("MyLogger"); logger.removeAllAppenders(); logger.addAppender(new ConsoleAppender( new PatternLayout("%p %t %m%n"), ConsoleAppender.SYSTEM_OUT)); logger.info("cześć"); }

Tym razem program działa i na konsoli pojawia się komunikat cześć. Wydaje się dziwne, że musimy poinformować ConsoleAdapter, że ma pisać na konsolę. Co ciekawe, gdy usuniemy argument ConsoleAppender.SystemOut, komunikat nadal będzie wyświetlany. Gdy usuniemy PatternLayout, program znów zacznie informować o braku strumienia wyjściowego. Jest to bardzo dziwne działanie. Po dokładniejszym przyjrzeniu się dokumentacji zauważamy, że domyślny konstruktor ConsoleAdapter jest „nieskonfigurowany”, co nie wydaje się zbyt oczywiste ani użyteczne. Wygląda to na błąd lub co najmniej na niekonsekwencję w pakiecie log4j. Po dalszym szukaniu, czytaniu i testowaniu w końcu otrzymujemy kod z listingu 8.1. Wiele dowiedzieliśmy się na temat sposobu działania pakietu log4j i zawarliśmy tę wiedzę w zbiorze prostych testów jednostkowych. L I S T I N G 8 . 1 . LogTest.java public class LogTest { private Logger logger; @Before public void initialize() { logger = Logger.getLogger("logger"); logger.removeAllAppenders(); Logger.getRootLogger().removeAllAppenders(); } @Test public void basicLogger() { BasicConfigurator.configure(); logger.info("basicLogger"); }

}

@Test public void addAppenderWithStream() { logger.addAppender(new ConsoleAppender( new PatternLayout("%p %t %m%n"), ConsoleAppender.SYSTEM_OUT)); logger.info("addAppenderWithStream"); } @Test public void addAppenderWithoutStream() { logger.addAppender(new ConsoleAppender( new PatternLayout("%p %t %m%n"))); logger.info("addAppenderWithoutStream"); }

GRANICE

137

Teraz wiemy już, jak należy zainicjować prosty system rejestrowania na konsoli, i możemy umieścić tę wiedzę we własnej klasie, aby pozostała część aplikacji była izolowana od interfejsu granicznego log4j.

Zalety testów uczących Testy uczące nic nie kosztują. I tak musimy nauczyć się używanego API, a pisanie takich testów jest prostym sposobem uzyskania tej wiedzy. Testy uczące są precyzyjnymi eksperymentami, które pomagają nam zwiększyć wiedzę. Testy uczące nie tylko są bezpłatne, ale również przynoszą wymierne korzyści. Gdy pojawi się nowa wersja pakietu zewnętrznego, uruchamiamy testy uczące i sprawdzamy, czy wystąpią różnice w działaniu. Testy te pozwalają sprawdzić, czy używane przez nas obce pakiety działają tak, jak tego oczekujemy. Po zintegrowaniu obcego kodu z własnym nie mamy gwarancji, że ten zewnętrzny kod będzie nadal spełniał nasze oczekiwania. Jego autorzy mogli zmienić swój kod w taki sposób, aby spełniał inne oczekiwania. Poprawiają oni błędy i dodają nowe funkcje. Każda nowa wersja niesie ze sobą nowe zagrożenia. Jeżeli pakiet firmy zewnętrznej zmieni się w taki sposób, że będzie niezgodny z naszymi testami, natychmiast się o tym dowiemy. Niezależnie od tego, czy potrzebujemy wiedzy zdobywanej za pomocą testów uczących, czy nie, powinniśmy pokryć kod graniczny testami, które sprawdzają interfejs w taki sam sposób, jak dzieje się to w kodzie produkcyjnym. Bez tych testów granicznych możemy np. korzystać ze starej wersji biblioteki dłużej, niż jest to potrzebne.

Korzystanie z nieistniejącego kodu Istnieje również inny rodzaj granicy, która oddziela znane od nieznanego. Często spotykamy się z takimi fragmentami kodu, w których nasza wiedza jest wystawiona na próbę. Czasami to, co znajduje się po drugiej stronie granicy, jest nieznane (przynajmniej chwilowo). Czasami decydujemy się, aby nie zaglądać za granicę. Kilka lat temu byłem członkiem zespołu tworzącego oprogramowanie dla systemu komunikacji radiowej. Istniał w nim podsystem „Transmitter”, o którym niewiele wiedzieliśmy, a osoby odpowiedzialne za ten podsystem nie wpadły jeszcze na pomysł, aby zdefiniować interfejs. Nie chcieliśmy być przez to blokowani, więc zaczęliśmy pracę od odległych części kodu. Wiedzieliśmy dokładnie, gdzie kończy się nasz, a zaczyna ich świat. W czasie naszej pracy czasami odbijaliśmy się od tej granicy. Pomimo że mgła i chmury ignorancji przesłaniały nasz widok poza granicę, w czasie pracy określiliśmy, jaki chcielibyśmy mieć interfejs graniczny. Chcieliśmy przekazać do transmitera mniej więcej taką informację: Ustaw transmiter na przekazanej częstotliwości i wyemituj analogową reprezentację danych przychodzących w tym strumieniu. 138

ROZDZIAŁ 8.

Nie wiedzieliśmy, jak powinno być to zrobione, ponieważ API nie zostało jeszcze zaprojektowane. Zdecydowaliśmy więc popracować później nad szczegółami. Aby nie blokować prac, zdefiniowaliśmy własny interfejs. Nadaliśmy mu jakąś chwytliwą nazwę, coś jak Transmitter. Dodaliśmy do niej metodę transmit, która oczekiwała przekazania częstotliwości i strumienia danych. Był to interfejs, którego oczekiwaliśmy. Główną zaletą tworzenia oczekiwanego interfejsu jest to, że pozostaje on pod naszą kontrolą. Pozwala to na zachowanie większej czytelności kodu i ukierunkowanie go na wykonywaną akcję. Na rysunku 8.2 można zobaczyć, że odizolowaliśmy klasy CommunicationsController od API transmitera (który był poza naszą kontrolą i nie był jeszcze zdefiniowany). Przez użycie interfejsu specyficznego dla interfejsu nasz kod CommunicationsController pozostał czysty i komunikatywny. Po zdefiniowaniu API transmitera napisaliśmy klasę TransmitterAdapter łatającą dziurę. Adapter2 hermetyzował interakcję z API i zapewniał jedno miejsce zmian w przypadku ewolucji API.

R Y S U N E K 8 . 2 . Przewidywanie klas transmitera

Projekt ten pozwolił na utworzenie bardzo wygodnego szwu3 w kodzie, co ułatwia testowanie. Przy użyciu odpowiedniej klasy FakeTransmitter mogliśmy przetestować klasy CommunicationsController. Mogliśmy również utworzyć testy graniczne po uzyskaniu TransmitterAPI, aby upewnić się, że prawidłowo korzystamy z tego API.

Czyste granice Na granicach dzieją się interesujące zdarzenia. Wśród nich są m.in. zmiany. Dobry projekt oprogramowania przyjmuje zmiany bez ogromnych nakładów i ponownej pracy. Gdy korzystamy z kodu pozostającego poza naszą kontrolą, musimy użyć specjalnych metod w celu ochrony naszych inwestycji, które zapewniają, że przyszłe modyfikacje nie będą zbyt kosztowne. Kod na tych granicach wymaga jasnej separacji i testów definiujących oczekiwania. Powinniśmy unikać sytuacji, w której zbyt wiele naszego kodu korzysta ze szczegółów zdefiniowanych w obcym kodzie. Lepiej polegać na czymś, co my możemy kontrolować, niż na czymś, czego nie możemy kontrolować, ponieważ kończy się to... kontrolowaniem nas. 2

Patrz wzorzec Adapter w [GOF].

3

Więcej informacji na temat szwów można znaleźć w [WELC].

GRANICE

139

Zarządzamy granicami z obcym kodem przez ograniczenie do minimum miejsc w kodzie odwołujących się do niego. Możemy hermetyzować ten kod tak, jak zrobiliśmy to w Map, lub użyć adaptera w celu konwersji naszego perfekcyjnego interfejsu na dostarczony interfejs. W obu przypadkach kod lepiej do nas przemawia, promuje wewnętrzne spójne nazewnictwo na granicach i posiada mniej punktów konserwacji w przypadku zmiany zewnętrznego kodu.

Bibliografia [BeckTDD]: Kent Beck, Test Driven Development, Addison-Wesley 2003. [GOF]: Gamma, Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley 1996. [WELC]: Working Effectively with Legacy Code, Addison-Wesley 2004.

140

ROZDZIAŁ 8.

ROZDZIAŁ 9.

Testy jednostkowe

ostatnich dziesięciu lat. W roku 1997 nikt nie słyN szał o programowaniu sterowanym testamiw czasie (ang. Test Driven Development). Dla znacznej większoASZA PROFESJA PRZESZŁA ZNACZNE ZMIANY

ści z nas testy jednostkowe były krótkimi fragmentami kodu, które pisaliśmy w celu upewnienia się, że nasze programy działają. Z mozołem pisaliśmy klasy i metody, a następnie tworzyliśmy fragmenty kodu do ich przetestowania. Zwykle wymagało to użycia jakiegoś programu sterującego, który pozwalał ręcznie sterować napisanym kodem. W latach dziewięćdziesiątych pisałem program w języku C++ dla wbudowanego systemu czasu rzeczywistego. Program był prostym stoperem o następującej sygnaturze: void Timer::ScheduleCommand(Command* theCommand, int milliseconds)

141

Pomysł był dosyć prosty, metoda execute obiektu Command wywoływała nowy wątek po zdefiniowanej liczbie milisekund. Powstał problem, jak go przetestować. Skleciłem więc prosty program sterujący, który nasłuchiwał zdarzeń klawiatury. Po każdym wpisaniu znaku planowane było wykonanie polecenia wpisującego ten sam znak pięć sekund później. Następnie wystukiwałem rytmiczną melodię na klawiaturze i melodia ta była odtwarzana na ekranie po pięciu sekundach. „I … want-a-girl … just … like-the-girl-who-marr … ied … dear … old … dad”. Faktycznie nuciłem tę melodię, naciskając klawisz „.”, a potem ponownie ją nuciłem, gdy kropki pojawiały się na ekranie. To był mój test! Gdy sprawdziłem, że kod działa, i pokazałem to moim kolegom, skasowałem kod testu. Jak powiedziałem, nasza profesja przeszła znaczne zmiany. Obecnie napisałbym test, który upewniłby mnie, że każdy fragment i zakątek kodu działa tak, jak tego oczekuję. Wyizolowałbym swój kod z systemu operacyjnego, zamiast wywoływać standardowe funkcje stopera. Użyłbym imitacji tych funkcji stopera, aby mieć pełną kontrolę nad czasem. Zaplanowałbym polecenia, które ustawiałyby znaczniki, a następnie po upływie określonego czasu kontrolowałbym te znaczniki, upewniając się, że zmieniły swój stan na właściwy dla czasu, jaki bym ustawił. Gdy testy byłyby wykonywane prawidłowo, upewniłbym się, że może je bez trudu uruchomić każdy, kto będzie chciał korzystać z mojego kodu. Upewniłbym się, że testy i sprawdzany przez nie kod znajdują się w tym samym pakiecie kodu źródłowego. Tak, przeszliśmy długą drogę, ale musimy pójść jeszcze dalej. Metodologie Agile oraz TDD zachęciły wielu programistów do pisania automatycznych testów jednostkowych i każdego dnia ich liczba rośnie. Jednak w owczym pędzie do korzystania z testów wielu programistów nie zdaje sobie sprawy z kilku bardziej subtelnych i istotnych cech dobrych testów.

Trzy prawa TDD Obecnie wszyscy wiedzą, że TDD zakłada pisanie testów jednostkowych na początku, przed napisaniem kodu produkcyjnego. Jednak zasada ta jest tylko wierzchołkiem góry lodowej. Możemy zdefiniować następujące trzy prawa1: Pierwsze prawo. Nie można zacząć pisać kodu produkcyjnego do momentu napisania niespełnianego testu jednostkowego. Drugie prawo. Nie można napisać więcej testów jednostkowych, które są wystarczające do niespełnienia testu, a brak kompilacji jest jednocześnie nieudanym testem. 1

Robert C. Martin, Professionalism and Test-Driven Development, Object Mentor, IEEE Software, maj – czerwiec 2007 (Vol. 24, No. 3), s. 32 – 36, http://doi.ieeecomputersociety.org/10.1109/MS.2007.85.

142

ROZDZIAŁ 9.

Trzecie prawo. Nie można pisać większej ilości kodu produkcyjnego, niż wystarczy do spełnienia obecnie niespełnianego testu. Te trzy prawa zamykają nas w cyklu, który trwa prawdopodobnie trzydzieści sekund. Testy i kod produkcyjny są pisane razem, a testy są wykonywane kilka sekund wcześniej niż kod produkcyjny. Jeżeli będziemy w ten sposób pracować, napiszemy kilkanaście testów każdego dnia, setki każdego miesiąca i tysiące testów co rok. Testy te będą pokrywać niemal cały kod produkcyjny. Ogromna liczba tych testów, które będą podobnej objętości co kod produkcyjny, może prowadzić do poważnych problemów z zarządzaniem projektem.

Zachowanie czystości testów Kilka lat temu zostałem poproszony o kierowanie zespołem, który wcześniej zdecydował, że jego kod testujący nie powinien być utrzymywany zgodnie z tymi samymi standardami jakości co kod produkcyjny. Programiści dali sobie przyzwolenie na łamanie reguł w testach jednostkowych. Myślą przewodnią było „szybki i brudny”. Zmienne nie musiały mieć odpowiednich nazw, funkcje testujące nie musiały być krótkie i opisowe. Ich kod testujący nie musiał być odpowiednio zaprojektowany i właściwie podzielony. Dopóki kod testu działał i pokrywał kod produkcyjny, był wystarczająco dobry. Część Czytelników może sympatyzować z tymi decyzjami. Być może w dalekiej przeszłości pisali oni testy podobne do mojego testu klasy Timer. Jednak pomiędzy tego rodzaju odrzucanymi testami a automatycznymi testami jednostkowymi istnieje ogromna przepaść. Tak więc podobnie w kierowanym przeze mnie zespole moglibyśmy zdecydować, że posiadanie „brudnych” testów jest lepsze niż ich brak. Jednak zespół ten nie zorientował się, że korzystanie z takich testów odpowiada... brakowi testów, o ile nie jest czymś gorszym. Problem wynika z tego, że testy muszą się zmieniać wraz z ewoluowaniem kodu produkcyjnego. Im gorsze są testy, tym trudniej je zmieniać. Im bardziej zagmatwany jest kod testujący, tym większe prawdopodobieństwo, że spędzimy więcej czasu na dodawaniu nowych testów do pakietu niż na pisaniu nowego kodu produkcyjnego. Wraz z modyfikowaniem kodu produkcyjnego stare testy przestają się wykonywać, a bałagan w kodzie testującym utrudnia doprowadzenie ich do stanu zgodnego z kodem produkcyjnym. Dlatego testy zaczynają być postrzegane jako stale zwiększająca się odpowiedzialność. W kolejnych wersjach koszt utrzymania zestawu testów w moim zespole stale wzrastał. W końcu stał się największą uciążliwością dla programistów. Gdy kierownicy pytali, dlaczego ich oszacowania są tak duże, programiści winili za to testy. W końcu zostali zmuszeni do całkowitego usunięcia zestawu testów. Jednak bez zestawu testów utraciliśmy możliwość upewnienia się, że zmiany w bazie kodu działają w oczekiwany sposób. Bez zestawu testów nie mogliśmy upewnić się, że zmiany w jednej części systemu nie spowodują błędu w innych jego częściach. Dlatego liczba defektów zaczęła wzrastać.

TESTY JEDNOSTKOWE

143

Gdy liczba nieoczekiwanych defektów zaczęła wzrastać, programiści zaczęli obawiać się wprowadzania zmian. Przestali czyścić swój kod produkcyjny, ponieważ obawiali się, że zmiany wprowadzą więcej szkody niż pożytku. Ich kod produkcyjny zaczął się psuć. W końcu zostali bez testów, z zagmatwanym i zawierającym błędy kodem produkcyjnym, sfrustrowanymi klientami oraz poczuciem, że ich praca nad testami poszła na marne. W pewnym stopniu mieli rację. Ich praca przy testach zawiodła. Jednak ich decyzja o pozwoleniu na tworzenie zagmatwanych testów była zalążkiem porażki. Gdyby ich testy były utrzymywane w odpowiednim stanie, praca przy testach nie poszłaby na marne. Mogę to powiedzieć z dużą pewnością, ponieważ brałem udział w projektach i kierowałem wieloma zespołami, które z dużym sukcesem korzystały z czystych testów jednostkowych. Morał z tej historii jest prosty: kod testów jest tak samo ważny jak kod produkcyjny. Nie jest to obywatel drugiej kategorii. Wymaga przemyślenia, zaprojektowania i uwagi. Musi być utrzymywany zgodnie z takimi samymi zasadami co kod produkcyjny.

Testy zwiększają możliwości Jeżeli nie będziemy zachowywali czystości testów, utracimy je. Bez nich utracimy jedyną rzecz, która zapewnia elastyczność kodu produkcyjnego. Tak, dobrze przeczytaliście. To właśnie testy jednostkowe zapewniają elastyczność, łatwość utrzymania i ponownego wykorzystania kodu. Powód jest prosty. Jeżeli mamy testy, nie musimy bać się wprowadzania zmian do kodu! Bez testów każda zmiana jest potencjalnym błędem. Niezależnie od tego, jak elastyczna jest nasza architektura, niezależnie od tego, jak dobrze partycjonowany jest nasz projekt, bez testów będziemy obawiali się wprowadzać zmiany z powodu strachu przed wprowadzeniem niewykrytych błędów. Jednak gdy testy są używane, obawa ta znika niemal zupełnie. Im lepsze jest pokrycie kodu testami, tym obawa jest mniejsza. Można niemal bezkarnie wprowadzać zmiany do kodu, którego architektura nie jest doskonała, a projekt jest zagmatwany i niejasny. Można nawet bez obawy poprawiać tę architekturę i projekt! Tak więc posiadanie zestawu testów automatycznych obejmujących kod produkcyjny jest kluczowe w utrzymaniu projektu i architektury w możliwie najlepszym stanie. Testy znacznie zwiększają możliwości, ponieważ pozwalają na zmiany. Jeżeli nasze testy są zagmatwane, to możliwości zmiany kodu są zmniejszone i zaczynamy tracić możliwość poprawiania struktury kodu. Im gorsze są nasze testy, tym bardziej zagmatwany staje się kod. W końcu tracimy testy, a nasz kod zaczyna się psuć.

Czyste testy Co sprawia, że testy są czyste? Trzy elementy: czytelność, czytelność i jeszcze raz czytelność. Czytelność jest prawdopodobnie ważniejsza w przypadku testów jednostkowych niż w kodzie produkcyjnym. Co sprawia, że testy są czytelne? Te same elementy, które powodują, że każdy

144

ROZDZIAŁ 9.

kod jest czytelny — klarowność, prostota i spójność kodu. W teście chcemy wyrazić możliwie dużo przy użyciu możliwie niewielu wyrażeń. Przeanalizujmy kod z listingu 9.1, pochodzący z FitNesse. Testy te są trudne do zrozumienia i powinny być poprawione. Po pierwsze, mamy tu ogromną ilość powtarzanego kodu [G5] w powtarzanych wywołaniach addPage oraz assertSubString. Co ważniejsze, kod ten jest przeładowany szczegółami, które niekorzystnie wpływają na jasność wyrażeń w testach. L I S T I N G 9 . 1 . SerializedPageResponderTest.java public void testGetPageHieratchyAsXml() throws Exception { crawler.addPage(root, PathParser.parse("PageOne")); crawler.addPage(root, PathParser.parse("PageOne.ChildOne")); crawler.addPage(root, PathParser.parse("PageTwo")); request.setResource("root"); request.addInput("type", "pages"); Responder responder = new SerializedPageResponder(); SimpleResponse response = (SimpleResponse) responder.makeResponse( new FitNesseContext(root), request); String xml = response.getContent(); assertEquals("text/xml", response.getContentType()); assertSubString(" PageOne ", xml); assertSubString(" PageTwo ", xml); assertSubString(" ChildOne ", xml); } public void testGetPageHieratchyAsXmlDoesntContainSymbolicLinks() throws Exception { WikiPage pageOne = crawler.addPage(root, PathParser.parse("PageOne")); crawler.addPage(root, PathParser.parse("PageOne.ChildOne")); crawler.addPage(root, PathParser.parse("PageTwo")); PageData data = pageOne.getData(); WikiPageProperties properties = data.getProperties(); WikiPageProperty symLinks = properties.set(Symboliage.PROPERTY_NAME); symLinks.set("SymPage", "PageTwo"); pageOne.commit(data); request.setResource("root"); request.addInput("type", "pages"); Responder responder = new SerializedPageResponder(); SimpleResponse response = (SimpleResponse) responder.makeResponse( new FitNesseContext(root), request); String xml = response.getContent(); assertEquals("text/xml", response.getContentType()); assertSubString(" PageOne ", xml); assertSubString(" PageTwo ", xml); assertSubString(" ChildOne ", xml); assertNotSubString("SymPage", xml); } public void testGetDataAsHtml() throws Exception { crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");

TESTY JEDNOSTKOWE

145

request.setResource("TestPageOne"); request.addInput("type", "data"); Responder responder = new SerializedPageResponder(); SimpleResponse response = (SimpleResponse) responder.makeResponse( new FitNesseContext(root), request); String xml = response.getContent(); assertEquals("text/xml", response.getContentType()); assertSubString("test page", xml); assertSubString("
Dla przykładu spójrzmy na wywołania PathParser. Przekształcają one ciąg znaków w obiekt PagePath wykorzystywany przez mechanizm przeszukiwania. Transformacja ta jest niepotrzebna do testowania i jedynie zaciemnia nasze intencje. Szczegóły konieczne do utworzenia obiektu responder oraz zbierania i rzutowania response są również tylko szumem. Następnie znajduje się tam mechanizm budowania URL żądania na podstawie obiektu resource oraz argumentu (pomagałem pisać ten kod, więc mogę swobodnie go krytykować). W końcu kod ten nie był zaprojektowany do czytania. Biedny Czytelnik zostanie zarzucony wieloma szczegółami, jakie musi zrozumieć, aby testy miały sens. Popatrzmy teraz na ulepszone testy z listingu 9.2. Testy te wykonują dokładnie te same zadania, ale zostały przebudowane do czystszej i bardziej zrozumiałej postaci. L I S T I N G 9 . 2 . SerializedPageResponderTest.java (przebudowany) public void testGetPageHierarchyAsXml() throws Exception { makePages("PageOne", "PageOne.ChildOne", "PageTwo"); submitRequest("root", "type:pages");

}

assertResponseIsXML(); assertResponseContains( " PageOne ", " PageTwo ", " ChildOne " );

public void testSymbolicLinksAreNotInXmlPageHierarchy() throws Exception { WikiPage page = makePage("PageOne"); makePages("PageOne.ChildOne", "PageTwo"); addLinkTo(page, "PageTwo", "SymPage"); submitRequest("root", "type:pages");

}

assertResponseIsXML(); assertResponseContains( " PageOne ", " PageTwo ", " ChildOne " ); assertResponseDoesNotContain("SymPage");

public void testGetDataAsXml() throws Exception { makePageWithContent("TestPageOne", "test page"); submitRequest("TestPageOne", "type:data");

}

146

assertResponseIsXML(); assertResponseContains("test page", "

ROZDZIAŁ 9.

Struktura tych testów powoduje, że wzorzec BUILD-OPERATE-CHECK2 jest oczywisty. Każdy z tych testów jest podzielony na trzy części. Pierwsza część buduje dane testowe, druga operuje na danych testowych, a trzecia kontroluje, by operacja dała oczekiwane wyniki. Należy zwrócić uwagę, że większość irytujących szczegółów została wyeliminowana. Testy idą w dobrym kierunku i korzystają tylko z tych typów danych i funkcji, które są faktycznie potrzebne. Każdy, kto czyta te testy, powinien móc zorientować się, co się dzieje, bez konieczności analizowania mnóstwa szczegółów.

Języki testowania specyficzne dla domeny Testy z listingu 9.2 demonstrują technikę budowania języka specyficznego dla domeny na potrzeby naszych testów. Zamiast korzystać z API stosowanego przez programistów do manipulowania systemem, budujemy zbiór funkcji i narzędzi wykorzystujących to API, które pozwalają na wygodniejsze pisanie testów, które z kolei są łatwiejsze do czytania. Te funkcje i narzędzia stają się specjalizowanym API wykorzystywanym przez testy. Są one językiem testowania wykorzystywanym przez programistów przy pisaniu testów oraz wspierającym osoby czytające później testy. Takie API nie jest zaprojektowane od początku; raczej ewoluowało ze stale przebudowywanego kodu testowego, który stał się zbyt zatłoczony przez szczegóły. Podobnie jak przebudowaliśmy kod z listingu 9.1 na ten z listingu 9.2, zdyscyplinowani programiści przebudowują swój kod testowy na bardziej zwięzłe i czytelne formy.

Podwójny standard Wspomniany przeze mnie na początku tego rozdziału zespół miał rację w jednej sprawie. Kod w API testowym faktycznie ma inny zbiór standardów inżynierskich niż kod produkcyjny. Musi nadal być prosty, zwięzły i czytelny, ale nie musi być tak wydajny jak kod produkcyjny. W końcu działa on w środowisku testowym, a nie produkcyjnym, a te dwa środowiska mają całkiem inne wymagania. Przeanalizujmy kod z listingu 9.3. Napisałem te testy jako część systemu kontrolowania środowiska, którego prototyp opracowałem. Bez wchodzenia w szczegóły można powiedzieć, że testy te kontrolują, czy alarm niskiej temperatury, ogrzewacz i wentylator są włączone, gdy temperatura jest „wyraźnie zbyt niska”. L I S T I N G 9 . 3 . EnvironmentControllerTest.java @Test public void turnOnLoTempAlarmAtThreashold() throws Exception { hw.setTemp(WAY_TOO_COLD); controller.tic(); assertTrue(hw.heaterState()); assertTrue(hw.blowerState()); assertFalse(hw.coolerState()); assertFalse(hw.hiTempAlarm()); assertTrue(hw.loTempAlarm()); } 2

http://fitnesse.org/FitNesse.AcceptanceTestPatterns

TESTY JEDNOSTKOWE

147

Mamy tu oczywiście wiele szczegółów. Na przykład do czego służy funkcja tic? W rzeczywistości nie przejmowałbym się tym w czasie czytania tych testów. Obawiałbym się raczej tego, czy końcowy stan systemu jest spójny, gdy temperatura jest „wyraźnie zbyt niska”. Należy zauważyć, że gdy czytamy testy, nasze oko musi skakać pomiędzy nazwą sprawdzanego stanu a czujnikiem sprawdzanego stanu. Widzimy heaterState i nasze oko prześlizguje się w lewo do assertTrue. Widzimy coolerState i nasze oko musi skierować się w lewo do assertFalse. Jest to nużące i zawodne. Powoduje, że testy są trudne do czytania. Znacznie poprawiłem czytelność tych testów przez przekształcenie ich na postać z listingu 9.4. L I S T I N G 9 . 4 . EnvironmentControllerTest.java (przebudowany) @Test public void turnOnLoTempAlarmAtThreshold() throws Exception { wayTooCold(); assertEquals("HBchL", hw.getState()); }

Oczywiście, ukryłem szczegóły funkcji tic przez utworzenie funkcji wayTooCold. Zauważamy jednak dziwny ciąg znaków w assertEquals. Wielka litera oznacza „włączony”, a mała „wyłączony”; litery są zawsze w następującej kolejności: {heater, blower, cooler, hi-temp-alarm, lo-temp-alarm}. Pomimo że jest to bliskie naruszenia zasady odwzorowania mentalnego3, w tym przypadku wydaje się działaniem właściwym. Należy zauważyć, że gdy znamy znaczenie, nasze oko prześlizguje się po tym ciągu znaków i możemy szybko zinterpretować wyniki. Czytanie testów staje się niemal przyjemnością. Spójrzmy na listing 9.5 i przekonajmy się, jak łatwo można zrozumieć znajdujące się tam testy. L I S T I N G 9 . 5 . EnvironmentControllerTest.java (większy fragment) @Test public void turnOnCoolerAndBlowerIfTooHot() throws Exception { tooHot(); assertEquals("hBChl", hw.getState()); } @Test public void turnOnHeaterAndBlowerIfTooCold() throws Exception { tooCold(); assertEquals("HBchl", hw.getState()); } @Test public void turnOnHiTempAlarmAtThreshold() throws Exception { wayTooHot(); assertEquals("hBCHl", hw.getState()); } @Test public void turnOnLoTempAlarmAtThreshold() throws Exception { wayTooCold(); assertEquals("HBchL", hw.getState()); } 3

„Unikanie odwzorowania mentalnego” w rozdziale 2.

148

ROZDZIAŁ 9.

Funkcja getState jest zamieszczona na listingu 9.6. Warto zwrócić uwagę, że kod ten nie jest zbyt efektywny. Aby poprawić jego efektywność, prawdopodobnie musiałbym użyć klasy StringBuffer. L I S T I N G 9 . 6 . MockControlHardware.java public String getState() { String state = ""; state += heater ? "H" : "h"; state += blower ? "B" : "b"; state += cooler ? "C" : "c"; state += hiTempAlarm ? "H" : "h"; state += loTempAlarm ? "L" : "l"; return state; }

Zastosowanie StringBuffer jest mało eleganckie. Nawet w kodzie produkcyjnym unikam ich, jeżeli koszt jest niewielki, a można się zgodzić, że koszt w kodzie z listingu 9.6 jest niewielki. Jednak aplikacja ta wchodzi w skład wbudowanego systemu czasu rzeczywistego, a najprawdopodobniej zasoby komputera i pamięć są bardzo ograniczone. Środowisko testowe nie jest jednak tak ograniczone. Taka jest natura podwójnych standardów. Istnieją operacje, których nigdy nie użylibyśmy w środowisku produkcyjnym, ale są całkowicie dozwolone w środowisku testowym. Zwykle jest to związane z efektywnością obliczeniową i pamięciową. Jednak nigdy nie są to problemy z czystością kodu.

Jedna asercja na test Istnieje szkoła programowania4 twierdząca, że każda funkcja testowa w JUnit powinna mieć jedną instrukcję asercji. Zasada ta może wydawać się drakońska, ale jej zalety są widoczne na listingu 9.5. Poszczególne testy zawierają pojedynczą konkluzję, którą można szybko i łatwo zrozumieć. Co jednak z listingiem 9.2? Wydaje się nierozsądne, że możemy dosyć łatwo łączyć asercje, których wynikiem jest XML i które zawierają określone podciągi. Możemy jednak podzielić test na dwa osobne testy, z których każdy będzie miał własną asercję, tak jak na listingu 9.7. L I S T I N G 9 . 7 . SerializedPageResponderTest.java (pojedyncze asercje) public void testGetPageHierarchyAsXml() throws Exception { givenPages("PageOne", "PageOne.ChildOne", "PageTwo"); whenRequestIsIssued("root", "type:pages"); thenResponseShouldBeXML(); } public void testGetPageHierarchyHasRightTags() throws Exception { givenPages("PageOne", "PageOne.ChildOne", "PageTwo"); whenRequestIsIssued("root", "type:pages"); thenResponseShouldContain( " PageOne ", " PageTwo ", " ChildOne " ); }

4

Patrz wpis na blogu Dave’a Astela: http://www.artima.com/weblogs/viewpost.jsp?thread=35578.

TESTY JEDNOSTKOWE

149

Zwróćmy uwagę, że zmieniłem nazwy funkcji, aby korzystały z często stosowanej konwencji givenwhen-then5. Powoduje to, że testy są jeszcze łatwiejsze w czytaniu. Niestety, tego typu rozdzielenie testów powoduje powstanie dużej ilości powtórzonego kodu. Możemy wyeliminować te powtórzenia przez zastosowanie wzorca szablonu metody6 (ang. Template Method) i umieszczenie części given-then w klasie bazowej, a części then w poszczególnych klasach pochodnych. Można również utworzyć całkowicie osobne klasy testów i umieścić części given oraz then w funkcji @Before, a części when w każdej funkcji @Test. Jednak wydaje się nieracjonalne użycie tak wielu mechanizmów do rozwiązania niewielkiego problemu. Osobiście najbardziej lubię wielokrotne asercje z listingu 9.2. Uważam, że zasada jednej asercji jest dobrą wskazówką7. Zwykle staram się tworzyć specyficzny dla domeny język testowania, który je wspiera, tak jak w przypadku kodu z listingu 9.5. Jednak nie obawiam się umieszczać więcej niż jednej asercji w teście. Uważam, że możemy jedynie stwierdzić, iż liczba asercji w teście powinna być zminimalizowana.

Jedna koncepcja na test Lepszą zasadą dotyczącą testów jest obejmowanie jednej koncepcji w każdej funkcji testowej. Nie potrzebujemy długich funkcji testowych, które kolejno testują jedną rzecz za drugą. Przykład takiego testu jest zamieszczony na listingu 9.8. Test ten powinien być podzielony na trzy niezależne testy, ponieważ sprawdzane są trzy niezależne kwestie. Złączenie ich w tej samej funkcji wymusza na Czytelniku konieczność sprawdzania, w której sekcji się znajduje i co jest w niej testowane. LISTING 9.8. /** * Różne testy metody addMonths(). */ public void testAddMonths() { SerialDate d1 = SerialDate.createInstance(31, 5, 2004); SerialDate d2 = SerialDate.addMonths(1, d1); assertEquals(30, d2.getDayOfMonth()); assertEquals(6, d2.getMonth()); assertEquals(2004, d2.getYYYY()); SerialDate d3 = SerialDate.addMonths(2, d1); assertEquals(31, d3.getDayOfMonth()); assertEquals(7, d3.getMonth()); assertEquals(2004, d3.getYYYY()); SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1)); assertEquals(30, d4.getDayOfMonth()); assertEquals(7, d4.getMonth()); assertEquals(2004, d4.getYYYY()); }

5

[RSpec].

6

[GOF].

7

„Trzymaj się kodu!”.

150

ROZDZIAŁ 9.

Te trzy funkcje testowe powinny prawdopodobnie wyglądać następująco: 

Mamy ostatni dzień miesiąca mającego 31 dni (tak jak maj): 1. Gdy dodamy jeden miesiąc, tak że ostatnim dniem tego miesiąca jest 30 (tak jak czerwiec), to data powinna być 30 tego miesiąca, a nie 31. 2. Gdy dodamy do tej daty dwa miesiące, tak aby wynikowy miesiąc miał 31 dni, to data powinna być 31.



Mamy ostatni dzień miesiąca mającego 30 dni (tak jak czerwiec): 1. Gdy dodamy jeden miesiąc, tak aby ostatni dzień tego miesiąca miał 31 dni, to wynikowa data powinna być 30, a nie 31.

Na podstawie takich założeń można zauważyć, że istnieje ogólna zasada ukrywania testów. Gdy zwiększymy miesiąc, data nie może być większa niż ostatni dzień miesiąca. Powoduje to, że zwiększenie miesiąca w przypadku 28 lutego powinno dać w wyniku 20 marca. Tego testu brakuje, a byłby on przydatny. Tak więc to nie wielokrotne asercje z listingu 9.8 powodują problem. Problemem jest raczej testowanie więcej niż jednej koncepcji. Dlatego najlepszą zasadą jest minimalizacja liczby asercji dla koncepcji i testowanie tylko jednej koncepcji na funkcję testową.

F.I.R.S.T.8 Czyste testy powinny spełniać pięć innych zasad, które tworzą powyższy akronim: Szybkie (Fast). Testy powinny być szybkie. Powinny działać szybko. Gdy testy działają powoli, nie chcemy ich uruchamiać zbyt często. Jeżeli nie uruchamiamy ich zbyt często, nie znajdziemy problemów wystarczająco szybko, aby można było łatwo je poprawić. Nie czujemy się wystarczająco pewnie, aby czyścić nasz kod. W końcu kod zaczyna się psuć. Niezależne (Independent). Testy nie powinny zależeć od siebie. Jeden test nie powinien konfigurować warunków do następnego testu. Powinniśmy być w stanie uruchamiać każdy test niezależnie i uruchamiać testy w dowolnie wybranym porządku. Jeśli testy zależą od siebie, to gdy nie uda się pierwszy test, powstaje kaskada awarii, co utrudnia diagnozę i ukrywa awarie na niższym poziomie. Powtarzalne (Repeatable). Testy powinny być powtarzalne w każdym środowisku. Powinniśmy być w stanie uruchomić testy w środowisku produkcyjnym, środowisku zapewnienia jakości oraz na naszym laptopie w trakcie podróży pociągiem do domu. Jeżeli nasze testy nie są powtarzalne w każdym środowisku, to zawsze będziemy mieli wymówkę, gdy się nie powiodą. Okazuje się również, że możemy mieć kłopoty z uruchomieniem testów, gdy nie jest dostępne dane środowisko.

8

Materiały szkoleniowe mentora obiektowego.

TESTY JEDNOSTKOWE

151

Samokontrolujące się (Self-Validating). Testy powinny mieć jeden parametr wyjściowy typu logicznego. Mogą one się powieść lub nie. Nie powinniśmy musieć czytać plików dzienników w celu sprawdzenia, czy testy się powiodły. Nie powinniśmy ręcznie porównywać dwóch plików testowych w celu sprawdzenia, czy test się powiódł. Jeżeli testy nie kontrolują się samodzielnie, to awaria może stać się subiektywna i uruchomienie testów będzie wymagać długiego procesu ręcznej analizy. O czasie (Timely). Testy powinny być pisane w odpowiednim momencie. Testy jednostkowe powinny być pisane bezpośrednio przed tworzeniem testowanego kodu produkcyjnego. Jeżeli piszemy testy po kodzie produkcyjnym, może się okazać, że jest on trudny do przetestowania. Można zdecydować, że pewna część kodu produkcyjnego jest zbyt trudna do przetestowania. Nie można zaprojektować kodu produkcyjnego tak, aby nie dał się przetestować.

Zakończenie Niniejszy rozdział stanowi zaledwie zarys problematyki testowania kodu. Faktycznie, można napisać całą książkę na temat czystych testów. Testy są tak ważne dla jakości projektu, jak sam kod produkcyjny. Prawdopodobnie są nawet ważniejsze, ponieważ zapewniają i rozszerzają elastyczność, łatwość utrzymania i ponownego użycia kodu produkcyjnego. Tak więc testy powinny być stale utrzymywane w czystości. Należy zapewnić, że będą czytelne i zwięzłe. Warto opracować API testujące, które posłuży jako język specyficzny dla domeny, pomagający w pisaniu testów. Jeżeli pozwolimy na zepsucie testów, nasz kod również będzie się psuł. Testy należy utrzymywać w czystości.

Bibliografia [RSpec]: Aslak Hellesøy, David Chelimsky, RSpec: Behavior Driven Development for Ruby Programmers, Pragmatic Bookshelf 2008. [GOF]: Gamma, Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley 1996.

152

ROZDZIAŁ 9.

ROZDZIAŁ 10.

Klasy we współpracy z Jeffem Langrem

skupialiśmy się na odpowiednim zapisywaniu wierszy i bloków kodu. D Zajmowaliśmy się prawidłową kompozycją funkcji oraz ich wzajemnymi relacjami. Jednak pomimo O TEJ PORY W KSIĄŻCE

całego zaangażowania w zapewnienie ekspresywności instrukcji kodu, jak również zbudowanych z niego funkcji, nadal nie mamy czystego kodu; musimy poświęcić uwagę wyższym poziomom organizacji kodu. Zajmijmy się czystością klas.

Organizacja klas Zgodnie ze standardową konwencją języka Java klasy powinny zaczynać się od listy zmiennych. Publiczne stałe statyczne, jeżeli występują, powinny być zapisane jako pierwsze. W dalszej kolejności zapisywane są prywatne zmienne statyczne, a po nich prywatne zmienne instancyjne. Rzadko istnieje dobry powód korzystania ze zmiennych publicznych. 153

Po liście zmiennych powinny znajdować się funkcje publiczne. Prywatne funkcje użytkowe wywoływane przez funkcje publiczne zwykle umieszczamy po funkcjach publicznych. Jest to zgodne z zasadą zstępującą i pomaga czytać program jak artykuł w gazecie.

Hermetyzacja Zazwyczaj nasze zmienne i funkcje użytkowe pozostają prywatne, ale nie jesteśmy fanatykami tego rozwiązania. Czasami zmieniamy zmienną lub funkcję na chronioną, aby była dostępna dla testu. Dla nas to testy ustalają zasady. Jeżeli test w tym samym pakiecie potrzebuje wywołać funkcję lub odwołać się do zmiennej, zmieniamy jej zasięg na chroniony lub dostępny w ramach pakietu. Jednak na początku zawsze szukamy sposobu na zachowanie prywatności. Rozluźnianie zasady prywatności jest ostatnim możliwym rozwiązaniem.

Klasy powinny być małe! Pierwsza zasada dotycząca klas mówi, że powinny być małe. Druga zasada — że powinny być mniejsze, niż są. Nie, nie mamy zamiaru powtarzać dokładnie takiego samego tekstu z rozdziału „Funkcje”. Jednak podobnie jak w przypadku funkcji, podstawową zasadą projektowania klas jest zachowanie małych rozmiarów. Podobnie jak w przypadku funkcji, naszym natychmiastowym pytaniem jest zawsze: „Jak małe?”. W przypadku funkcji mierzyliśmy ich rozmiar, zliczając linie fizyczne. W przypadku klas korzystamy z innej metryki. Zliczamy tzw. odpowiedzialności1. Na listingu 10.1 przedstawiony jest szkielet klasy SuperDashboard, która udostępnia 70 metod publicznych. Większość programistów zgodzi się, że jest ona zbyt duża. Niektórzy programiści mogą określać SuperDashboard jako „klasę boską”. L I S T I N G 1 0 . 1 . Zbyt wiele odpowiedzialności public class SuperDashboard extends JFrame implements MetaData public String getCustomizerLanguagePath() public void setSystemConfigPath(String systemConfigPath) public String getSystemConfigDocument() public void setSystemConfigDocument(String systemConfigDocument) public boolean getGuruState() public boolean getNoviceState() public boolean getOpenSourceState() public void showObject(MetaObject object) public void showProgress(String s) public boolean isMetadataDirty() public void setIsMetadataDirty(boolean isMetadataDirty) public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public void setMouseSelectState(boolean isMouseSelected) public boolean isMouseSelected()

1

[RDD].

154

ROZDZIAŁ 10.

public LanguageManager getLanguageManager() public Project getProject() public Project getFirstProject() public Project getLastProject() public String getNewProjectName() public void setComponentSizes(Dimension dim) public String getCurrentDir() public void setCurrentDir(String newDir) public void updateStatus(int dotPos, int markPos) public Class[] getDataBaseClasses() public MetadataFeeder getMetadataFeeder() public void addProject(Project project) public boolean setCurrentProject(Project project) public boolean removeProject(Project project) public MetaProjectHeader getProgramMetadata() public void resetDashboard() public Project loadProject(String fileName, String projectName) public void setCanSaveMetadata(boolean canSave) public MetaObject getSelectedObject() public void deselectObjects() public void setProject(Project project) public void editorAction(String actionName, ActionEvent event) public void setMode(int mode) public FileManager getFileManager() public void setFileManager(FileManager fileManager) public ConfigManager getConfigManager() public void setConfigManager(ConfigManager configManager) public ClassLoader getClassLoader() public void setClassLoader(ClassLoader classLoader) public Properties getProps() public String getHome() public String getBaseDir() public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() public MetaObject pasting( MetaObject target, MetaObject pasted, MetaProject project) public void processMenuItems(MetaObject metaObject) public void processMenuSeparators(MetaObject metaObject) public void processTabPages(MetaObject metaObject) public void processPlacement(MetaObject object) public void processCreateLayout(MetaObject object) public void updateDisplayLayer(MetaObject object, int layerIndex) public void propertyEditedRepaint(MetaObject object) public void processDeleteObject(MetaObject object) public boolean getAttachedToDesigner() public void processProjectChangedState(boolean hasProjectChanged) public void processObjectNameChanged(MetaObject object) public void runProject() public void setAçowDragging(boolean allowDragging) public boolean allowDragging() public boolean isCustomizing() public void setTitle(String title) public IdeMenuBar getIdeMenuBar() public void showHelper(MetaObject metaObject, String propertyName)

// ... Wiele kolejnych niepublicznych metod ... }

Co można powiedzieć w przypadku, gdy klasa SuperDashboard będzie zawierała wyłącznie metody z listingu 10.2?

KLASY

155

L I S T I N G 1 0 . 2 . Wystarczająco mała? public class SuperDashboard extends JFrame implements MetaData public Component getLastFocusedComponent() public void setLastFocused(Component lastFocused) public int getMajorVersionNumber() public int getMinorVersionNumber() public int getBuildNumber() }

Pięć metod to niezbyt dużo, prawda? W tym przypadku, pomimo małej liczby metod, SuperDashboard ma zbyt wiele odpowiedzialności. Nazwa klasy powinna opisywać pełnione przez nią odpowiedzialności. W rzeczywistości nazewnictwo jest prawdopodobnie pierwszym sposobem na pomoc w określeniu wielkości klasy. Jeżeli nie możemy utworzyć spójnej nazwy klasy, prawdopodobnie jest ona zbyt duża. Im bardziej ogólna jest nazwa klasy, tym większe prawdopodobieństwo, że ma wiele odpowiedzialności. Na przykład nazwy klas zawierające takie słowa, jak Processor, Manager lub Super, często wskazują na niefortunną agregację odpowiedzialności. Powinniśmy być w stanie napisać krótki opis klasy, używając około 25 słów, bez wykorzystania słów „jeżeli”, „oraz”, „lub” czy też „ale”. Jak można opisać SuperDashboard? „Klasa SuperDashboard zapewnia dostęp do komponentu mającego ostatnio fokus oraz pozwala śledzić wersję i numer kompilacji”. Słowo „oraz” jest podpowiedzią, że SuperDashboard ma zbyt dużo odpowiedzialności.

Zasada pojedynczej odpowiedzialności Zasada pojedynczej odpowiedzialności (SRP)2 zakłada, że klasa lub moduł powinny mieć jeden i tylko jeden powód do zmiany. Zasada ta zarówno definiuje odpowiedzialność, jak i daje wskazówki odnośnie do wielkości klas. Klasy powinny mieć jedną odpowiedzialność — jeden powód do zmiany. Pozornie mała klasa SuperDashboard z listingu 10.2 ma dwa powody do zmiany. Po pierwsze, śledzi ona informacje o wersji, które będą prawdopodobnie aktualizowane przy każdym wydaniu oprogramowania. Po drugie, zarządza komponentami Java Swing (dziedziczy po JFrame, reprezentacji głównego okna GUI w bibliotece Swing). Pewne jest, że będziemy chcieli zmienić numer wersji po zmianie fragmentu kodu Swing, ale w odwrotnej sytuacji — niekoniecznie. Możemy zmieniać informacje o wersji w przypadku wprowadzania zmian w innych fragmentach kodu systemu. Próba identyfikacji odpowiedzialności (powodów zmiany) często pomaga nam rozpoznać i utworzyć lepsze abstrakcje w naszym kodzie. Można bez trudu wydzielić trzy metody z klasy SuperDashboard, operujące na informacjach o wersji, do zewnętrznej klasy o nazwie Version (patrz listing 10.3). Klasa Version jest konstrukcją, która z dużym prawdopodobieństwem może być ponownie wykorzystywana w innych aplikacjach!

2

Więcej na temat tej zasady można przeczytać w [PPP].

156

ROZDZIAŁ 10.

L I S T I N G 1 0 . 3 . Klasa o jednej odpowiedzialności public class public int public int public int }

Version { getMajorVersionNumber() getMinorVersionNumber() getBuildNumber()

SRP jest jedną z najważniejszych koncepcji w projektowaniu obiektowym. Jest to również jedna z najprostszych koncepcji do zrozumienia oraz stosowania. Co jednak dziwne, jest jedną z najczęściej łamanych zasad projektowania. Regularnie spotykamy się z klasami, które wykonują zbyt dużo rzeczy. Dlaczego? Doprowadzenie do tego, aby program działał, i tworzenie czystego oprogramowania to dwa bardzo różne zadania. Nasz umysł ma ograniczone możliwości, więc bardziej skupiamy się na doprowadzeniu kodu do stanu, w którym działa, niż na jego organizacji i czystości. Jest to całkowicie właściwe. Utrzymanie rozdziału zadań jest ważne zarówno dla procesu programowania, jak i dla naszych programów. Problem wynika z tego, że wielu z nas uważa pracę za zakończoną po doprowadzeniu kodu do działania. Nie zajmujemy się drugim zadaniem — zapewnieniem organizacji i czystości kodu. Przechodzimy do kolejnego problemu, zamiast zajmować się dzieleniem przeciążonych klas na rozłączone jednostki z jedną odpowiedzialnością. Jednocześnie wielu programistów boi się, że zbyt wiele małych i jednozadaniowych klas utrudni zrozumienie całego systemu. Obawiają się, że będą musieli przechodzić z klasy do klasy w celu sprawdzenia, w jaki sposób można wykonać większe zadanie. Jednak system z wieloma małymi klasami nie ma więcej zmiennych części niż system z kilkoma dużymi klasami. System z kilkoma dużymi klasami wymaga dokładnie tyle samo nauki. Należy więc postawić pytanie: Czy wolimy przechowywać nasze narzędzia w skrzynkach z wieloma małymi szufladkami zawierającymi określone elementy, czy wolimy kilka szuflad, do których po prostu wrzucamy narzędzia? Każdy większy system będzie zawierał dużą ilość kodu logiki i będzie skomplikowany. Podstawowym celem zarządzania tą złożonością jest jej organizacja, aby programista wiedział, gdzie szukać określonych elementów, i w danym momencie musiał analizować jedynie elementy bezpośrednio związane z problemem. Dla porównania, system z większymi, wielozadaniowymi klasami zawsze zmusza nas do przedzierania się przez wiele elementów, których w danym momencie nie potrzebujemy. Powtórzmy to jeszcze raz: wolimy, gdy nasze systemy składają się z wielu małych klas, a nie kilku dużych. Każda mała klasa hermetyzuje jedną odpowiedzialność, ma jeden powód zmiany i dla osiągnięcia oczekiwanego działania systemu współpracuje z niewielką liczbą innych klas.

KLASY

157

Spójność Klasy powinny mieć niewielką liczbę zmiennych instancyjnych. Każda z metod klasy powinna manipulować jedną lub kilkoma tymi zmiennymi. Zwykle im większą liczbą zmiennych manipuluje klasa, tym bardziej spójna z klasą jest ta metoda. Klasa, w której każda zmienna jest wykorzystywana w każdej metodzie, jest maksymalnie spójna. Zwykle nie jest zalecane ani możliwe tworzenie takich maksymalnie spójnych klas; z drugiej strony, spójność powinna być wysoka. Gdy spójność jest wysoka, oznacza to, że metody i zmienne klasy są wzajemnie zależne i tworzą logiczną całość. Jako przykład weźmy implementację klasy Stack z listingu 10.4. Jest to tylko bardzo spójna klasa. W przypadku jej trzech metod jedynie size() nie korzysta z obu zmiennych. L I S T I N G 1 0 . 4 . Stack.java — spójna klasa public class Stack { private int topOfStack = 0; List elements = new LinkedList (); public int size() { return topOfStack; } public void push(int element) { topOfStack++; elements.add(element); } public int pop() throws PoppedWhenEmpty { if (topOfStack == 0) throw new PoppedWhenEmpty(); int element = elements.get(--topOfStack); elements.remove(topOfStack); return element; } }

Strategia tworzenia małych funkcji oraz krótkich list parametrów czasami prowadzi do wykorzystywania zmiennych instancyjnych używanych przez podzbiory metod. W takim przypadku niemal zawsze oznacza to, że przynajmniej jedna nowa klasa chce się uwolnić z bieżącej klasy. Powinniśmy spróbować podzielić zmienne i metody na dwie lub więcej klas, aby nowe klasy były bardziej spójne.

Utrzymywanie spójności powoduje powstanie wielu małych klas Sam akt podziału dużych funkcji na mniejsze powoduje zwiększenie liczby klas. Weźmy pod uwagę dużą funkcję z zadeklarowanymi w niej wieloma zmiennymi. Załóżmy, że chcemy wydzielić małą część tej funkcji do osobnej funkcji. Jednak kod, jaki chcemy wydzielić, korzysta z czterech zmiennych zadeklarowanych w funkcji. Czy musimy przekazać wszystkie te zmienne do nowej funkcji jako argumenty?

158

ROZDZIAŁ 10.

Nie musimy! Jeżeli zmienimy te cztery zmienne na zmienne instancyjne klasy, będziemy mogli wydzielić kod bez przekazywania jakichkolwiek zmiennych. Bardzo łatwo będzie podzielić funkcję na mniejsze części. Niestety, oznacza to również, że nasze klasy utracą spójność, ponieważ będzie się w nich gromadziło coraz więcej zmiennych, które istnieją tylko po to, aby kilka funkcji wspólnie z nich korzystało. Czekaj, czekaj! Jeżeli istnieje niewiele funkcji, które współużytkują określone zmienne, czy nie należy utworzyć z nich osobnej klasy? Oczywiście, że tak. Gdy klasy tracą spójność, należy je podzielić! Tak więc podział dużej funkcji na mniejsze często daje nam również możliwość wydzielenia kilku mniejszych klas. Pozwala to na lepszą organizację programu i zapewnienie bardziej przejrzystej struktury. Aby przedstawić, o co mi chodzi, skorzystam z od dawna znanego przykładu zamieszczonego w doskonałej książce Knutha, Literate Programming3. Na listingu 10.5 przedstawione jest tłumaczenie na język Java programu Knutha PrintPrimes. Aby być uczciwym wobec Knutha, muszę nienić, że program ten nie został przez niego napisany, ale jest wynikiem działania jego narzędzia WWW. Korzystam z niego, ponieważ jest to doskonały materiał do podziału dużej funkcji na mniejsze funkcje i klasy. L I S T I N G 1 0 . 5 . PrintPrimes.java package literatePrimes; public class PrintPrimes { public static void main(String[] args) { final int M = 1000; final int RR = 50; final int CC = 4; final int WW = 10; final int ORDMAX = 30; int P[] = new int[M + 1]; int PAGENUMBER; int PAGEOFFSET; int ROWOFFSET; int C; int J; int K; boolean JPRIME; int ORD; int SQUARE; int N; int MULT[] = new int[ORDMAX + 1]; J = 1; K = 1; P[1] = 2; ORD = 2; SQUARE = 9; while (K < M) { do { J = J + 2; if (J == SQUARE) { 3

[Knuth92].

KLASY

159

ORD = ORD + 1; SQUARE = P[ORD] * P[ORD]; MULT[ORD - 1] = J; } N = 2; JPRIME = true; while (N < ORD && JPRIME) { while (MULT[N] < J) MULT[N] = MULT[N] + P[N] + P[N]; if (MULT[N] == J) JPRIME = false; N = N + 1; } } while (!JPRIME); K = K + 1; P[K] = J; } { PAGENUMBER = 1; PAGEOFFSET = 1; while (PAGEOFFSET <= M) { System.out.println("Pierwsze " + M + " liczb pierwszych --- strona " + PAGENUMBER); System.out.println(""); for (ROWOFFSET = PAGEOFFSET; ROWOFFSET < PAGEOFFSET + RR; ROWOFFSET++){ for (C = 0; C < CC;C++) if (ROWOFFSET + C * RR <= M) System.out.format("%10d", P[ROWOFFSET + C * RR]); System.out.println(""); } System.out.println("\f"); PAGENUMBER = PAGENUMBER + 1; PAGEOFFSET = PAGEOFFSET + RR * CC; } } } }

Program ten, zapisany w jednej funkcji, jest skomplikowany. Ma ściśle powiązaną, głęboko zagnieżdżoną strukturę i sporo dziwnych zmiennych. Co najwyżej można podzielić jedną dużą funkcję na kilka mniejszych. Na listingach od 10.6 do 10.8 przedstawiony jest wynik podziału kodu z listingu 10.5 na mniejsze klasy i funkcje, jak również wynik wyboru znaczących nazw dla tych klas, funkcji i zmiennych. L I S T I N G 1 0 . 6 . PrimePrinter.java (przebudowany) package literatePrimes; public class PrimePrinter { public static void main(String[] args) { final int NUMBER_OF_PRIMES = 1000; int[] primes = PrimeGenerator.generate(NUMBER_OF_PRIMES); final int ROWS_PER_PAGE = 50; final int COLUMNS_PER_PAGE = 4; RowColumnPagePrinter tablePrinter = new RowColumnPagePrinter(ROWS_PER_PAGE, COLUMNS_PER_PAGE, "Pierwsze " + NUMBER_OF_PRIMES + " liczb pierwszych");

160

ROZDZIAŁ 10.

tablePrinter.print(primes); } }

L I S T I N G 1 0 . 7 . RowColumnPagePrinter.java package literatePrimes; import java.io.PrintStream; public class RowColumnPagePrinter { private int rowsPerPage; private int columnsPerPage; private int numbersPerPage; private String pageHeader; private PrintStream printStream; public RowColumnPagePrinter(int rowsPerPage, int columnsPerPage, String pageHeader) { this.rowsPerPage = rowsPerPage; this.columnsPerPage = columnsPerPage; this.pageHeader = pageHeader; numbersPerPage = rowsPerPage * columnsPerPage; printStream = System.out; } public void print(int data[]) { int pageNumber = 1; for (int firstIndexOnPage = 0; firstIndexOnPage < data.length; firstIndexOnPage += numbersPerPage) { int lastIndexOnPage = Math.min(firstIndexOnPage + numbersPerPage - 1, data.length - 1); printPageHeader(pageHeader, pageNumber); printPage(firstIndexOnPage, lastIndexOnPage, data); printStream.println("\f"); pageNumber++; } } private void printPage(int firstIndexOnPage, int lastIndexOnPage, int[] data) { int firstIndexOfLastRowOnPage = firstIndexOnPage + rowsPerPage - 1; for (int firstIndexInRow = firstIndexOnPage; firstIndexInRow <= firstIndexOfLastRowOnPage; firstIndexInRow++) { printRow(firstIndexInRow, lastIndexOnPage, data); printStream.println(""); } } private void printRow(int firstIndexInRow, int lastIndexOnPage, int[] data) { for (int column = 0; column < columnsPerPage; column++) { int index = firstIndexInRow + column * rowsPerPage; if (index <= lastIndexOnPage) printStream.format("%10d", data[index]); }

KLASY

161

} private void printPageHeader(String pageHeader, int pageNumber) { printStream.println(pageHeader + " --- Strona " + pageNumber); printStream.println(""); } public void setOutput(PrintStream printStream) { this.printStream = printStream; } }

L I S T I N G 1 0 . 8 . PrimeGenerator.java package literatePrimes; import java.util.ArrayList; public class PrimeGenerator { private static int[] primes; private static ArrayList multiplesOfPrimeFactors; protected static int[] generate(int n) { primes = new int[n]; multiplesOfPrimeFactors = new ArrayList (); set2AsFirstPrime(); checkOddNumbersForSubsequentPrimes(); return primes; } private static void set2AsFirstPrime() { primes[0] = 2; multiplesOfPrimeFactors.add(2); } private static void checkOddNumbersForSubsequentPrimes() { int primeIndex = 1; for (int candidate = 3; primeIndex < primes.length; candidate += 2) { if (isPrime(candidate)) primes[primeIndex++] = candidate; } } private static boolean isPrime(int candidate) { if (isLeastRelevantMultipleOfNextLargerPrimeFactor(candidate)) { multiplesOfPrimeFactors.add(candidate); return false; } return isNotMultipleOfAnyPreviousPrimeFactor(candidate); } private static boolean isLeastRelevantMultipleOfNextLargerPrimeFactor(int candidate) { int nextLargerPrimeFactor = primes[multiplesOfPrimeFactors.size()]; int leastRelevantMultiple = nextLargerPrimeFactor * nextLargerPrimeFactor; return candidate == leastRelevantMultiple; } private static boolean isNotMultipleOfAnyPreviousPrimeFactor(int candidate) {

162

ROZDZIAŁ 10.

for (int n = 1; n < multiplesOfPrimeFactors.size(); n++) { if (isMultipleOfNthPrimeFactor(candidate, n)) return false; } return true; } private static boolean isMultipleOfNthPrimeFactor(int candidate, int n) { return candidate == smallestOddNthMultipleNotLessThanCandidate(candidate, n); } private static int smallestOddNthMultipleNotLessThanCandidate(int candidate, int n) { int multiple = multiplesOfPrimeFactors.get(n); while (multiple < candidate) multiple += 2 * primes[n]; multiplesOfPrimeFactors.set(n, multiple); return multiple; } }

Pierwszą rzeczą, jaką zauważamy, jest fakt, że program stał się znacznie dłuższy. Wzrósł z niewiele ponad jednej strony do niemal trzech. Istnieje kilka przyczyn tego wzrostu objętości kodu. Po pierwsze, przebudowany program korzysta z dłuższych, bardziej opisowych nazw zmiennych. Po drugie, przebudowany program korzysta z deklaracji funkcji i klas jako sposobu dodawania komentarzy do kodu. Po trzecie, wykorzystaliśmy odstępy i techniki formatowania pozwalające zachować czytelność programu. Warto zauważyć, że program został podzielony na trzy główne odpowiedzialności. Główny program znajduje się w samej klasie PrimePrinter. Jej odpowiedzialnością jest obsługa środowiska wykonania. Zmienia się ona, gdy zmieniają się wywołania metod. Jeżeli program ten zostałby na przykład skonwertowany na usługę SOAP, zmieniona zostałaby ta klasa. Klasa RowColumnPagePrinter obsługuje wszystkie operacje formatowania list liczb na stronach o określonej liczbie wierszy i kolumn. Jeżeli zmiany będzie wymagało formatowanie danych wyjściowych, zostanie zmodyfikowana ta klasa. Klasa PrimeGenerator obsługuje wszystkie operacje generowania listy liczb pierwszych. Należy zauważyć, że nie jest przewidziane tworzenie tego obiektu. Klasa jest po prostu użytecznym zakresem, w którym można zadeklarować zmienne i zapewnić ich ukrycie. Klasa ta zostanie zmieniona, jeżeli zmieni się algorytm obliczania liczb pierwszych. To nie było ponowne napisanie programu! Nie zaczęliśmy od pustego ekranu i nie napisaliśmy programu od podstaw. W rzeczywistości, jeżeli przyjrzymy się dokładniej tym dwóm programom, okaże się, że korzystają z tego samego algorytmu i tych samych mechanizmów. Zmianą, jaką wprowadziliśmy, było dodanie zestawu testów precyzyjnie weryfikujących działanie pierwszego programu. Następnie wprowadzono wiele małych zmian, jedna po drugiej. Po każdej zmianie program był uruchamiany w celu upewnienia się, że jego działanie nie zmieniło się.

KLASY

163

Organizowanie zmian W większości systemów jedynym stałym elementem są zmiany. Każda zmiana powoduje zagrożenie, że pozostała część systemu przestanie działać w zaplanowany sposób. W czystym systemie organizujemy swoje klasy w taki sposób, aby zredukować ryzyko zmian. Klasa Sql z listingu 10.9 jest wykorzystywana do generowania prawidłowo sformatowanego zapytania SQL na podstawie metadanych. Jest ona w trakcie rozwoju i między innymi nie obsługuje operacji SQL update. Gdy przyszedł czas na dodanie do klasy Sql obsługi zapytania update, musieliśmy „otworzyć” tę klasę, aby wprowadzić modyfikacje. Z otwieraniem klasy zawsze związane jest pewne ryzyko. Każda modyfikacja klasy może spowodować błąd w innym fragmencie kodu klasy. Musi ona zostać w pełni przetestowana. L I S T I N G 1 0 . 9 . Klasa, która musi być otwarta na zmiany public class Sql { public Sql(String table, Column[] columns) public String create() public String insert(Object[] fields) public String selectAll() public String findByKey(String keyColumn, String keyValue) public String select(Column column, String pattern) public String select(Criteria criteria) public String preparedInsert() private String columnList(Column[] columns) private String valuesList(Object[] fields, final Column[] columns) private String selectWithCriteria(String criteria) private String placeholderList(Column[] columns) }

Gdy dodajemy nowy rodzaj wyrażenia, klasa Sql musi zostać zmieniona. Musi ulec zmianie również w momencie, gdy zmienimy szczegóły jednego typu wyrażenia — na przykład jeżeli musimy zmodyfikować zapytanie select, aby obsługiwało podzapytania. Dwa powody zmiany oznaczają, że klasa Sql narusza zasadę SRP. Możemy zauważyć to naruszenie SRP na podstawie prostego organizacyjnego punktu widzenia. Metoda przedstawiona dla Sql pokazuje, że istnieją metody prywatne, takie jak selectWithCriteria, które odnoszą się tylko do instrukcji select. Metody prywatne, które odnoszą się tylko do małej części klasy, mogą być przydatne do lokalizowania potencjalnych obszarów usprawnienia. Jednak podstawową zachętą do podjęcia akcji powinna być sama zmiana systemu. Jeżeli klasa Sql jest uznana za logicznie kompletną, nie ma konieczności rozdzielania odpowiedzialności. Jeżeli nie potrzebujemy funkcji update w dającej się przewidzieć przyszłości, powinniśmy zostawić klasę Sql. Jednak gdy zdecydujemy się otworzyć klasę, powinniśmy rozważyć poprawienie naszego projektu. Przyjmijmy rozwiązanie takie jak na listingu 10.10. Każda metoda interfejsu publicznego, zdefiniowana w poprzedniej klasie Sql z listingu 10.9, została przeniesiona do osobnej klasy dziedziczącej po klasie Sql. Metody prywatne, takie jak valuesList, zostały przeniesione bezpośrednio tam, gdzie są potrzebne. Wspólne operacje prywatne zostały wydzielone do pary klas narzędziowych, Where oraz ColumnList. 164

ROZDZIAŁ 10.

L I S T I N G 1 0 . 1 0 . Zbiór zamkniętych klas abstract public class Sql { public Sql(String table, Column[] columns) abstract public String generate(); } public class CreateSql extends Sql { public CreateSql(String table, Column[] columns) @Override public String generate() } public class SelectSql extends Sql { public SelectSql(String table, Column[] columns) @Override public String generate() } public class InsertSql extends Sql { public InsertSql(String table, Column[] columns, Object[] fields) @Override public String generate() private String valuesList(Object[] fields, final Column[] columns) } public class SelectWithCriteriaSql extends Sql { public SelectWithCriteriaSql( String table, Column[] columns, Criteria criteria) @Override public String generate() } public class SelectWithMatchSql extends Sql { public SelectWithMatchSql( String table, Column[] columns, Column column, String pattern) @Override public String generate() } public class FindByKeySql extends Sql public FindByKeySql( String table, Column[] columns, String keyColumn, String keyValue) @Override public String generate() } public class PreparedInsertSql extends Sql { public PreparedInsertSql(String table, Column[] columns) @Override public String generate() { private String placeholderList(Column[] columns) } public class Where { public Where(String criteria) public String generate() } public class ColumnList { public ColumnList(Column[] columns) public String generate() }

Kod w każdej klasie stał się niezwykle prosty. Wymagany czas skupienia w celu zrozumienia każdej z klas skurczył się niemal do zera. Ryzyko, że jedna funkcja spowoduje błąd w innej, wyraźnie zmalało. Z punktu widzenia testów znacznie prostszym zadaniem stało się sprawdzenie każdego fragmentu tego rozwiązania, ponieważ klasy są izolowane od siebie.

KLASY

165

Równie ważne jest to, że gdy przyjdzie czas na dodanie instrukcji update, żadna z istniejących klas nie będzie wymagała zmiany! Kod pozwalający na budowanie instrukcji update umieścimy w nowej klasie dziedziczącej po Sql, o nazwie UpdateSql. Żaden inny kod systemu nie ulegnie uszkodzeniu z powodu wprowadzenia tej zmiany. Nasza zrestrukturyzowana logika klasy Sql łączy najlepsze cechy obu światów. Wspiera ona SRP. Wspiera również inną ważną zasadę projektowania obiektowego, zasadę otwarty-zamknięty, czyli O4. Klasy powinny być otwarte na rozszerzanie, ale zamknięte dla modyfikacji. Nasza zmieniona klasa Sql jest otwarta na dodawanie nowych funkcji przez dziedziczenie, a zmiany te możemy wykonywać bez konieczności otwierania pozostałych klas. Po prostu dorzucamy naszą klasę UpdateSql do pakietu. Powinniśmy tak konstruować systemy, aby przy ich aktualizowaniu o nowe lub zmienione funkcje nie było konieczne wprowadzanie zbyt wielu dodatkowych modyfikacji. W idealnym systemie wprowadzamy nowe funkcje przez jego rozszerzanie, a nie wprowadzanie zmian do istniejącego kodu.

Izolowanie modułów kodu przed zmianami Potrzeby wymuszają zmiany, dlatego kod podlega modyfikacji. Podstawy programowania obiektowego mówią, że występują klasy konkretne, zawierające szczegóły implementacji (kod), oraz klasy abstrakcyjne, które reprezentują wyłącznie koncepcje. W przypadku gdy klasa klienta zależy od szczegółów klasy konkretnej, istnieje ryzyko, że szczegóły te mogą ulec zmianie. Aby zabezpieczyć się przed wpływem tych szczegółów, wprowadzamy interfejsy i klasy abstrakcyjne. Zależności od szczegółów klas konkretnych powodują problemy z testowaniem systemu. Jeżeli budujemy klasę Portfolio, która zależy od zewnętrznego API TokyoStockExchange, do dziedziczenia wartości portfela, nasze przypadki testowe są obciążone zmiennością tego wyszukiwania. Trudno napisać test, jeżeli co pięć minut otrzymujemy inną odpowiedź! Zamiast projektowania klasy Portfolio, która bezpośrednio zależy od TokyoStockExchange, powinniśmy utworzyć interfejs StockExchange, który zawiera jedną metodę: public interface StockExchange { Money currentPrice(String symbol); }

Klasę TokyoStockExchange projektujemy tak, aby implementowała ten interfejs. Musimy się również upewnić, że konstruktor Portfolio jako argumentu oczekuje referencji do StockExchange: public Portfolio { private StockExchange exchange; public Portfolio(StockExchange exchange) { this.exchange = exchange; }

// … }

4

[PPP].

166

ROZDZIAŁ 10.

Teraz możemy utworzyć testową implementację interfejsu StockExchange, która emuluje TokyoStockExchange. Taka testowa implementacja zwraca stałą wartość dla dowolnego przekazanego symbolu akcji. Jeżeli nasz test demonstruje zakup pięciu akcji firmy Microsoft do naszego portfela, możemy użyć implementacji testowej zwracającej zawsze wartość 100 dolarów za akcję. Nasza testowa implementacja interfejsu StockExchange sprowadza się do zwykłego wyszukania w tablicy. Możemy teraz napisać test, który oczekuje, aby całkowita wartość portfela wynosiła 500 dolarów. public class PortfolioTest { private FixedStockExchangeStub exchange; private Portfolio portfolio; @Before protected void setUp() throws Exception { exchange = new FixedStockExchangeStub(); exchange.fix("MSFT", 100); portfolio = new Portfolio(exchange); }

}

@Test public void GivenFiveMSFTTotalShouldBe500() throws Exception { portfolio.add(5, "MSFT"); Assert.assertEquals(500, portfolio.value()); }

Jeżeli moduły systemu są wystarczająco niezależne, aby można było je testować w ten sposób, to cały system jest również bardziej elastyczny i ułatwia ponowne wykorzystanie kodu. Brak sprzężeń oznacza, że elementy systemu są lepiej izolowane od siebie oraz od zmian. Izolacja ta ułatwia zrozumienie każdego elementu systemu. Przez minimalizację sprzężeń nasze klasy są zgodne z inną zasadą projektowania klas, znaną jako zasada odwrócenia zależności (DIP)5. Zasada ta głosi, że klasy powinny zależeć od abstrakcji, a nie klas konkretnych. Nasza klasa Portfolio nie zależy już od szczegółów implementacji klasy TokyoStockExchange, ale od interfejsu StockExchange. Interfejs StockExchange reprezentuje abstrakcyjną koncepcję odpytania o bieżącą cenę akcji. Abstrakcja ta izoluje wszystkie szczegóły uzyskiwania tej ceny, w tym również tego, skąd jest uzyskiwana cena.

Bibliografia [RDD]: Rebecca Wirfs-Brock i inni, Object Design: Roles, Responsibilities, and Collaborations, Addison-Wesley 2002. [PPP]: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall 2002. [Knuth92]: Donald E. Knuth, Literate Programming, Center for the Study of language and Information, Leland Stanford Junior University 1992. 5

[PPP].

KLASY

167

168

ROZDZIAŁ 10.

ROZDZIAŁ 11.

Systemy Dr Kevin Dean Wampler

Złożoność zabija. Zatruwa życie programistów i utrudnia planowanie, budowanie i testowanie produktów. Ray Ozzie, CTO, Microsoft Corporation

169

Jak budowałbyś miasto? Czy można samodzielnie zarządzać wszystkimi szczegółami jakiegoś dużego systemu? Prawdopodobnie nie. Nawet zarządzanie istniejącym miastem wykracza poza możliwości jednej osoby. Jednak miasta funkcjonują (w większości przypadków). Funkcjonują, ponieważ istnieją zespoły ludzi, którzy zarządzają określonymi częściami miasta, systemem wodociągowym, systemem zasilania, sterowania ruchem, pilnowaniem prawa, numerami budynków i tak dalej. Część z tych ludzi jest odpowiedzialna za ogólną koncepcję, natomiast inni skupiają się na szczegółach. Miasta funkcjonują, ponieważ wypracowane zostały odpowiednie poziomy abstrakcji i modularności, które pozwalają poszczególnym osobom i zarządzanym przez nie „komponentom” pracować efektywnie, bez konieczności rozumienia działania wszystkich mechanizmów. Choć zespoły programistyczne są również podobnie zorganizowane, systemy, nad którymi pracują, często nie mają podobnej separacji zadań i poziomów abstrakcji. Czysty kod pozwala nam osiągnąć to na niższych poziomach abstrakcji. W tym rozdziale zajmiemy się sposobami zachowania czystości na wyższym poziomie abstrakcji — na poziomie systemu.

Oddzielenie konstruowania systemu od jego używania Na początek trzeba zauważyć, że konstruowanie i używanie to zupełnie inne procesy. W czasie, gdy piszę te słowa, z mojego okna w Chicago widzę budowę nowego hotelu. Obecnie jest to nagie cementowe pudło z żurawiami konstrukcyjnymi oraz windami przyczepionymi na jego ścianach. Wszyscy pracujący tam ludzie noszą kaski i ubrania robocze. Po mniej więcej roku hotel zostanie ukończony. Żurawie i winda znikną. Budynek będzie czysty, obudowany atrakcyjną wizualnie szklaną elewacją. Pracownicy i goście hotelu również będą wyglądali inaczej. Systemy oprogramowania powinny oddzielić proces uruchamiania, w którym są budowane obiekty aplikacji i łączone ze sobą zależności, od logiki działania, która jest wykorzystywana po uruchomieniu. Proces uruchomienia jest problemem, który musi być rozwiązany w każdej aplikacji. Jest to pierwszy problem, jaki przeanalizujemy w tym rozdziale. Jedną z najstarszych i najważniejszych technik projektowania jest rozdzielenie problemów. Niestety, w większości aplikacji problem ten nie jest wydzielony. Kod dla procesu uruchamiania jest tworzony ad hoc i jest wymieszany z logiką działania. Poniżej przedstawiony jest typowy przykład: public Service getService() { if (service == null) service = new MyServiceImpl(...); // Odpowiednie wartości domyślne dla większości przypadków? return service; }

Jest to idiom późnej inicjalizacji (wartościowania), który ma kilka zalet. Nie ponosimy kosztu utworzenia, jeżeli aktualnie korzystamy z takiego obiektu, a w wyniku zastosowania tego mechanizmu czas uruchomienia może być mniejszy. Zapewnia on również, że nigdy nie zostanie zwrócona wartość null.

170

ROZDZIAŁ 11.

Jednak powoduje to wbudowanie zależności od MyServiceImpl i wszystkich elementów wymaganych przez konstruktor (które tu pominąłem). Nie możemy skompilować kodu bez rozwiązania tych zależności, nawet jeżeli w rzeczywistości nie korzystamy w czasie jego działania z obiektów tego typu! Problemem może być testowanie. Jeżeli MyServiceImpl jest ciężkim obiektem, musimy się upewnić, że przed wywołaniem metod w czasie testowania jednostkowego do pola usługi przypisane zostały odpowiednie obiekty Test Double1 lub Mock. Ponieważ kod konstrukcyjny jest wymieszany z normalnym przetwarzaniem, powinniśmy przetestować wszystkie ścieżki wykonania (na przykład test null i jego bloku). Posiadanie obu tych odpowiedzialności oznacza, że metoda wykonuje więcej niż jedną operację, więc łamie ona zasadę pojedynczej odpowiedzialności. Jednak chyba gorsze dla nas jest to, że nie wiemy, czy MyServiceImpl jest właściwym obiektem dla wszystkich przypadków. Zapisałem to w komentarzu. Dlaczego klasa zawierająca tę metodę musi znać kontekst globalny? Czy kiedykolwiek będziemy wiedzieć, jaki jest właściwy obiekt do wykorzystania w tym miejscu? Czy jest możliwe, że jeden typ będzie odpowiedni dla wszystkich możliwych kontekstów? Jedno wystąpienie późnej inicjalizacji nie jest oczywiście poważnym problemem. Jednak zwykle w aplikacji tego typu idiom występuje wiele razy. Dlatego globalna strategia konfiguracji (jeżeli istnieje) jest rozsiana w całej aplikacji, zachowując niewielką modularność, i często jest wielokrotnie powielana. Jeżeli aktywnie budujemy odpowiednio skonstruowane i solidne systemy, nie powinniśmy pozwalać niewielkim, wygodnym idiomom na złamanie modularności. Proces tworzenia obiektów i jego konfiguracji nie jest wyjątkiem. Powinniśmy zmodularyzować ten proces, oddzielając go od normalnej logiki działania, oraz upewnić się, że mamy globalną, spójną strategię rozwiązywania głównych zależności.

Wydzielenie modułu main Jednym ze sposobów oddzielenia konstrukcji od używania jest proste przeniesienie wszystkich aspektów tworzenia do main lub modułów wywoływanych przez main oraz zaprojektowanie pozostałych części systemu tak, aby zakładały, że wszystkie obiekty są odpowiednio utworzone i skonfigurowane (patrz rysunek 11.1).

R Y S U N E K 1 1 . 1 . Wydzielenie konstrukcji do main()

1

[Mezzaros07].

SYSTEMY

171

Przebieg sterowania jest łatwy w śledzeniu. Funkcja main buduje wszystkie niezbędne obiekty systemu, a następnie przekazuje je do aplikacji, która po prostu z nich korzysta. Należy zwrócić uwagę na kierunek strzałek zależności przechodzących przez barierę pomiędzy main i aplikacją. Wszystkie wskazują w jednym kierunku, od main na zewnątrz. Oznacza to, że aplikacja nie ma żadnych informacji o funkcji main ani o procesie tworzenia. Po prostu oczekuje, że wszystko zostało prawidłowo zbudowane.

Fabryki Czasami konieczne jest, aby aplikacja była odpowiedzialna za to, kiedy zostanie utworzony obiekt. Na przykład w systemie przetwarzania zamówień aplikacja musi utworzyć obiekty LineItem w celu dodania ich do Order. W takim przypadku możemy skorzystać ze wzorca fabryki abstrakcyjnej 2 (ang. Abstract Factory) w celu przekazania aplikacji kontroli nad tym, kiedy należy zbudować obiekty LineItem, ale szczegóły jego tworzenia pozostaną oddzielone od kodu aplikacji (patrz rysunek 11.2).

R Y S U N E K 1 1 . 2 . Oddzielenie konstrukcji za pomocą fabryki abstrakcyjnej

I w tym przypadku powinniśmy zauważyć, że wszystkie zależności są skierowane z main do aplikacji OrderProcessing. Oznacza to, że aplikacja jest oddzielona od szczegółów tworzenia obiektu LineItem. Funkcja ta jest dostępna w LineItemFactoryImplementation, która znajduje się na rysunku po stronie main. Dzięki temu aplikacja ma pełną kontrolę nad momentem utworzenia obiektu LineItem, a nawet może przekazywać do konstruktora argumenty specyficzne dla aplikacji.

Wstrzykiwanie zależności Zaawansowanym mechanizmem oddzielania konstrukcji od użytkowania jest wstrzykiwanie zależności (ang. Dependency Injection — DI), będące zastosowaniem odwrócenia sterowania (ang. Inversion of Control — IoC) do zarządzania zależnościami3. Odwrócenie sterowania przenosi drugorzędne odpowiedzialności z obiektu do innego obiektu, dedykowanego do tych zadań, przez co zapewnia się zachowanie zasady pojedynczej odpowiedzialności. W kontekście zarządzania zależnościami 2

[GOF].

3

Przykłady można znaleźć w [Fowler].

172

ROZDZIAŁ 11.

obiekt nie powinien być odpowiedzialny za samodzielne tworzenie zależności. Powinien przekazać tę odpowiedzialność do innego „autorytarnego” mechanizmu, odwracając w ten sposób sterowanie. Ponieważ konfiguracja jest problemem globalnym, ten autorytarny mechanizm zwykle będzie modułem „main” lub specjalizowanym kontenerem. Wyszukiwanie JNDI jest „częściową” implementacją DI, w której obiekt odpytuje serwer katalogu w celu dostarczenia „usługi” odpowiadającej określonej nazwie. MyService myService = (MyService)(jndiContext.lookup("NameOfMyService"));

Obiekt wywołujący nie steruje rodzajem zwracanego obiektu (o ile oczywiście implementuje on odpowiedni interfejs), ale wywołujący obiekt nadal aktywnie rozwiązuje zależności. Prawdziwe wstrzykiwanie zależności idzie o krok dalej. Klasa nie wykonuje bezpośrednich kroków w celu rozwiązania jej zależności — jest całkowicie pasywna. Zamiast tego udostępnia metody ustawiające lub argumenty konstruktora (albo oba te mechanizmy), które są używane do wstrzykiwania zależności. W czasie procesu konstrukcji kontener DI tworzy wymagane obiekty (zwykle na żądanie) i korzysta z argumentów konstruktora lub metod ustawiających do dowiązania zależności. To, które zależne obiekty są w rzeczywistości użyte, jest definiowane w pliku konfiguracyjnym lub programowo w specjalizowanym module konstrukcyjnym. Najlepszym znanym kontenerem DI dla języka Java jest Spring Framework4. W pliku XML definiujemy, które obiekty należy ze sobą połączyć, a następnie w kodzie Java pytamy o określone obiekty z użyciem ich nazwy. Odpowiedni przykład zostanie przedstawiony w dalszej części rozdziału. Co jednak z zaletami późnej inicjalizacji? W przypadku DI idiom ten jest czasami przydatny. Po pierwsze, większość kontenerów DI nie tworzy obiektów do momentu, aż są potrzebne. Po drugie, wiele z tych kontenerów udostępnia mechanizmy wywoływania fabryk abstrakcyjnych lub pośredników konstrukcji, które mogą być użyte do późnego wartościowania lub podobnych optymalizacji5.

Skalowanie w górę Miasta wyrastają z miasteczek, które z kolei rozwijają się z osad. Na początku drogi są wąskie i niewygodne, następnie są utwardzane, a z czasem poszerzane. Małe budynki i puste przestrzenie są zastępowane większymi budynkami, których część w końcu zostanie zastąpiona drapaczami chmur. Na początku niedostępne są takie usługi jak energia, woda, odprowadzanie ścieków, a nawet internet (ech!). Usługi te są dodawane wraz ze wzrostem populacji i gęstości budynków. Wzrost ten nie przebiega bezboleśnie. Ile razy jechaliśmy zderzak w zderzak przez miejsce, w którym był prowadzony projekt „ulepszania” drogi, i pytaliśmy się: „Dlaczego nie zbudowano od razu drogi o odpowiedniej szerokości?”. 4

Patrz [Spring]. Istnieje również biblioteka Spring.NET.

5

Nie należy zapominać, że późne tworzenie i wartościowanie jest tylko optymalizacją, i to prawdopodobnie przedwczesną!

SYSTEMY

173

Jednak nie może się to dziać w inny sposób. Kto uzasadni wydanie góry pieniędzy na sześciopasmową autostradę przez środek małego miasteczka, które prawdopodobnie kiedyś się powiększy? Kto chciałby mieć taką drogę w swoim miasteczku? Mitem jest, że możemy otrzymać „właściwe systemy za pierwszym razem”. Zamiast tego powinniśmy wdrażać tylko obecne potrzeby, a następnie przebudowywać i rozszerzać system, aby spełniał potrzeby w przyszłości. Jest to esencja wielokrotnej i iteracyjnej solidności. Programowanie sterowane testami, przebudowywanie oraz tworzenie czystego kodu pozwala na pracę na poziomie kodu. Co jednak można powiedzieć o poziomie systemowym? Czy architektura systemu wymaga wstępnego planowania? Czy nie może ona zwiększać się przyrostowo od prostej do złożonej? Systemy oprogramowania są inne niż fizyczne systemy. Ich architektury mogą się zwiększać przyrostowo, jeżeli zapewnimy odpowiednią separację problemów. Jak się okazuje, ulotna natura systemów programowych pozwala na takie planowanie. Na początek przedstawimy negatywny przykład architektury, w której problemy zostały nieodpowiednio odseparowane. Oryginalne architektury EJB1 oraz EJB2 nie rozdzielały odpowiednio problemów i przez to wprowadzały niepotrzebne bariery wzrostu organicznego. Weźmy jako przykład Entity Bean dla trwałej klasy Bank. Entity Bean jest pamięciową reprezentacją danych relacyjnych, czyli, mówiąc inaczej, wiersza w tabeli. Po pierwsze, konieczne było zdefiniowanie lokalnych (wewnątrz procesu) lub zdalnych (w osobnym środowisku JVM) interfejsów używanych przez klientów. Na listingu 11.1 przedstawiony jest przykładowy interfejs lokalny. L I S T I N G 1 1 . 1 . Lokalny interfejs EJB2 dla EJB Bank package com.example.banking; import java.util.Collections; import javax.ejb.*; public interface BankLocal extends java.ejb.EJBLocalObject { String getStreetAddr1() throws EJBException; String getStreetAddr2() throws EJBException; String getCity() throws EJBException; String getState() throws EJBException; String getZipCode() throws EJBException; void setStreetAddr1(String street1) throws EJBException; void setStreetAddr2(String street2) throws EJBException; void setCity(String city) throws EJBException; void setState(String state) throws EJBException; void setZipCode(String zip) throws EJBException; Collection gets() throws EJBException; void sets(Collection s) throws EJBException; void add(DTO DTO) throws EJBException; }

174

ROZDZIAŁ 11.

Przedstawionych jest tu kilka atrybutów adresu banku oraz kolekcja kont prowadzonych przez bank, z których każde będzie posiadało własne dane obsługiwane przez osobny EJB . Na listingu 11.2 przedstawiona jest odpowiednia implementacja klasy Bank. L I S T I N G 1 1 . 2 . Implementacja Entity Bean w EJB2 package com.example.banking; import java.util.Collections; import javax.ejb.*; public abstract class Bank implements javax.ejb.EntityBean {

// Logika biznesowa... public abstract String getStreetAddr1(); public abstract String getStreetAddr2(); public abstract String getCity(); public abstract String getState(); public abstract String getZipCode(); public abstract void setStreetAddr1(String street1); public abstract void setStreetAddr2(String street2); public abstract void setCity(String city); public abstract void setState(String state); public abstract void setZipCode(String zip); public abstract Collection gets(); public abstract void sets(Collection s); public void add(DTO DTO) { InitialContext context = new InitialContext(); HomeLocal Home = context.lookup("HomeLocal"); Local = Home.create(DTO); Collection s = gets(); s.add(); }

// Logika kontenera EJB. public public public public

abstract void setId(Integer id); abstract Integer getId(); Integer ejbCreate(Integer id) { ... } void ejbPostCreate(Integer id) { ... }

// Pozostała część musi być zaimplementowana, ale z reguły metody są puste: public public public public public public public

void void void void void void void

setEntityContext(EntityContext ctx) {} unsetEntityContext() {} ejbActivate() {} ejbivate() {} ejbLoad() {} ejbStore() {} ejbRemove() {}

}

Nie zamieszczamy tu odpowiedniego interfejsu LocalHome, czyli fabryki wykorzystywanej do tworzenia obiektów, ani możliwych metod wyszukujących dla klasy Bank. Na koniec musimy napisać w XML-u jeden lub więcej deskryptorów instalacyjnych, które definiują szczegóły mapowania obiektowo-relacyjnego dla magazynu, oczekiwane działanie transakcji, ograniczenia bezpieczeństwa i tak dalej. Logika biznesowa jest ściśle złączona z „kontenerem” aplikacji EJB2. Konieczne jest dziedziczenie po typach kontenera i trzeba napisać wiele metod cyklu życia, wymaganych przez kontener.

SYSTEMY

175

Z powodu tego sprzężenia z ciężkim kontenerem wyizolowanie testów jednostkowych jest trudne. Konieczne jest napisanie imitacji kontenera, co jest trudne, lub marnowanie wiele czasu na instalowanie EJB i wykonywanie testów na rzeczywistym serwerze. Ponowne użycie kodu poza architekturą EJB2 jest niemożliwe z powodu tego ścisłego sprzężenia. Nawet programowanie obiektowe jest ograniczone. Jeden bean nie może dziedziczyć po innym. Zwróćmy uwagę na kod dodawania nowego konta. Standardem w EJB2 jest definiowanie „obiektów transferu danych” (DTO), które są w rzeczywistości strukturami bez żadnych operacji. Zwykle prowadzi to do powstania niarowych typów przechowujących dokładnie te same dane i wymaga kodu zapewniającego kopiowanie danych z jednego obiektu do drugiego.

Separowanie (rozcięcie) problemów Architektura EJB2 w niektórych obszarach zbliża się do separacji problemów. Na przykład wymagane działanie transakcji, zabezpieczeń i niektóre zachowania mechanizmów trwałości są deklarowane w deskryptorze instalacji, niezależnie od kodu źródłowego. Należy zauważyć, że problemy takie jak trwałość obiektów zwykle mają tendencję do przechodzenia przez naturalne granice obiektów domeny. Zazwyczaj chcemy zapisać wszystkie obiekty z użyciem tej samej strategii, na przykład korzystając z określonego systemu DBMS6 zamiast płaskich plików, korzystając z określonej strategii nazewnictwa dla tabeli i kolumn, z użyciem spójnej semantyki obiektowej i tak dalej. W teorii można opisywać naszą strategię trwałości w modularny, hermetyzowany sposób. Jednak w praktyce musimy powielić właściwie ten sam kod, implementujący strategię trwałości, w wielu obiektach. Do tego typu zagadnień stosujemy określenie rozcięcie problemów. I w tym przypadku biblioteka trwałości może być modularna, jak również modularna może być nasza logika domeny, traktowana osobno. Problemy wynikają z przecięcia tych domen. W rzeczywistości sposób, w jaki architektura EJB obsługuje trwałość obiektów, bezpieczeństwo aplikacji i transakcje, „przewiduje” programowanie zorientowane aspektowo (AOP)7, które jest ogólnym podejściem do przywracania modularności w przypadku rozcięcia problemów. W AOP konstrukcje modularne nazywane aspektami definiują te punkty systemu, których działanie należy zmienić w pewien spójny sposób, tak by obsługiwały określone zagadnienie. Specyfikacja ta jest wykonywana z użyciem zwięzłego mechanizmu deklaratywnego lub programowego. W przypadku mechanizmu trwałości obiektów możemy zadeklarować, które obiekty i atrybuty (lub ich wzorce) powinny być utrwalane, a następnie wydelegować zadanie utrwalania do odpowiedniej biblioteki. Zadanie modyfikowania jest realizowane przez bibliotekę AOP nieinwazyjnie8 dla docelowego kodu. Zapoznamy się teraz z trzema mechanizmami aspektowymi lub podobnymi do aspektowych w języku Java. 6

Systemy zarządzania bazą danych.

7

Więcej informacji na temat aspektów można znaleźć w [AOSD], a informacje na temat Aspect-J w [AspectJ] i [Colyer].

8

Czyli nie ma potrzeby edycji docelowego kodu źródłowego.

176

ROZDZIAŁ 11.

Pośredniki Java Mechanizm pośredników Java jest odpowiedni dla prostych przypadków, takich jak otaczanie wywołań metody w pojedynczych obiektach lub klasach. Jednak dynamiczne pośredniki zapewniane w JDK operują tylko na interfejsach. Aby zapewnić pośredniczenie dla klas, należy skorzystać z bibliotek manipulujących kodem wynikowym, takim jak CGLIB, ASM lub Javassist9. Na listingu 11.3 przedstawiony jest szkielet pośrednika Java zapewniającego obsługę trwałości dla naszej aplikacji Bank, obsługujący tylko metody pobierania i ustawiania list kont. L I S T I N G 1 1 . 3 . Przykład pośrednika JDK // Bank.java (pominięte nazwy pakietów...). import java.utils.*;

// Abstrakcja banku. public interface Bank { Collection < rel="nofollow"> gets(); void sets(Collection < rel="nofollow"> s); }

// BankImpl.java import java.utils.*;

// Obiekt "Plain Old Java Object" (POJO) implementujący abstrakcję. public class BankImpl implements Bank { private List < rel="nofollow"> s; public Collection < rel="nofollow"> gets() { return s; } public void sets(Collection < rel="nofollow"> s) { this.s = new ArrayList < rel="nofollow"> (); for ( : s) { this.s.add(); } } }

// BankProxyHandler.java import java.lang.reflect.*; import java.util.*;

// "InvocationHandler" wymagany przez API pośrednika. public class BankProxyHandler implements InvocationHandler { private Bank bank; public BankHandler (Bank bank) { this.bank = bank; }

// Metoda zdefiniowana w InvocationHandler public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { String methodName = method.getName(); if (methodName.equals("gets")) { bank.sets(getsFromDatabase()); 9

Patrz [CGLIB], [ASM] i [Javassist].

SYSTEMY

177

return bank.gets(); } else if (methodName.equals("sets")) { bank.sets((Collection < rel="nofollow"> ) args[0]); setsToDatabase(bank.gets()); return null; } else { ... } }

// Tutaj sporo szczegółów: protected Collection < rel="nofollow"> getsFromDatabase() { ... } protected void setsToDatabase(Collection < rel="nofollow"> s) { ... } }

// W innym miejscu... Bank bank = (Bank) Proxy.newProxyInstance( Bank.class.getClassLoader(), new Class[] { Bank.class }, new BankProxyHandler(new BankImpl()));

Zdefiniowaliśmy interfejs Bank, który został osłonięty za pomocą pośrednika, oraz Plain-Old Java Object (POJO), BankImpl, implementujący logikę biznesową (obiekty POJO zostaną przedstawione w dalszej części rozdziału). API pośrednika wymaga zastosowania obiektu InvocationHandler, który przekazuje wywołania metod do implementacji Bank. Nasz BankProxyHandler korzysta z API refleksji do odwzorowania ogólnych wywołań metod na metody w BankImpl. Mamy tu bardzo dużo kodu i jest on dosyć skomplikowany nawet dla prostego przypadku10. Użycie jednej z bibliotek manipulujących kodem wynikowym jest podobnie złożone. Taka objętość kodu i jego skomplikowanie to dwie poważne wady pośredników. Powodują one, że trudniej tworzyć czysty kod! Dodatkowo pośredniki nie zapewniają mechanizmów specyfikowania dostępnych systemowo „punktów” obsługi, które są niezbędne w prawdziwym rozwiązaniu AOP11.

Czyste biblioteki Java AOP Na szczęście większość zadań pośredników może być obsłużona automatycznie przez narzędzia. Pośredniki są używane wewnętrznie w kilku bibliotekach Java, na przykład Spring AOP oraz JBoss AOP, do implementowania aspektów w czystym języku Java12. W Spring logikę pisze się w postaci obiektów Plain-Old Java Objects. Obiekty POJO są ukierunkowane na swoją domenę. Nie mają one zależności z bibliotekami typu enterprise (ani innymi domenami). Dzięki temu są koncepcyjnie prostsze i łatwiejsze do testowania. Ich względna prostota ułatwia sprawdzenie, czy prawidłowo implementują odpowiednie problemy użytkownika, oraz ich utrzymanie i ewolucję kodu do obsługi kolejnych problemów w przyszłości. 10

Bardziej szczegółowe przykłady API pośredników i przykłady jego zastosowania można znaleźć w [Goetz].

11

AOP jest czasami mylone z technikami jego implementacji, takimi jak przechwytywanie metod i „osłanianie” za pomocą pośredników. Prawdziwą wartością AOP jest możliwość specyfikowania zachowań systemowych w spójny i modularny sposób.

12

Patrz [Spring] oraz [JBoss]. „Czysta Java” oznacza, że nie zastosowano AspectJ.

178

ROZDZIAŁ 11.

Wymaganą infrastrukturę aplikacji, w tym zagadnienia rozcięcia problemów, takie jak trwałość, transakcje, bezpieczeństwo, buforowanie, przełączanie w czasie awarii i tak dalej, dołączamy przez zastosowanie deklaratywnych plików konfiguracyjnych lub API. W wielu przypadkach faktycznie specyfikujemy aspekty bibliotek Spring lub JBoss, natomiast biblioteki obsługują mechanikę zastosowania pośredników Java lub bibliotek kodu wynikowego w sposób niewidoczny dla użytkownika. Deklaracje te sterują kontenerem wstrzykiwania zależności (DI), który tworzy na żądanie większość obiektów i łączy je ze sobą. Na listingu 11.4 przedstawiony jest typowy fragment pliku konfiguracyjnego Spring V2.5, app.xml13. L I S T I N G 1 1 . 4 . Plik konfiguracyjny Spring 2.X ... ...

Każdy „bean” jest podobny do jednej części lalki matrioszki — obiekt domeny Bank posiada jako pośrednika (czyli jest opakowany przez) obiekt dostępu do danych (DAO), który z kolei ma jako pośrednika sterownik JDBC źródła danych (patrz rysunek 11.3).

R Y S U N E K 1 1 . 3 . „Lalka matrioszka” z dekoratorów

Klient uważa, że wykonuje metodę gets() obiektu Bank, ale w rzeczywistości komunikuje się z najbardziej zewnętrznym ze zbioru dekoratorów14 rozszerzających podstawowe funkcje POJO Bank. Możemy również dodać kolejne dekoratory dla transakcji, buforowania i innych mechanizmów.

13

Zaadaptowany z http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25.

14

[GOF].

SYSTEMY

179

W aplikacji konieczne jest użycie tylko kilku wierszy kodu do odpytania kontenera DI o obiekty najwyższego poziomu w systemie, zgodnie z definicją w pliku XML. XmlBeanFactory bf = new XmlBeanFactory(new ClassPathResource("app.xml", getClass())); Bank bank = (Bank) bf.getBean("bank");

Dzięki temu, że wymaganych jest tak niewiele wierszy kodu specyficznego dla Spring, aplikacja jest niemal całkowicie odłączona od Spring, co eliminuje problem ścisłego złączenia z systemami takimi jak EJB2. Choć XML może być rozwlekły i mało czytelny15, „zasady” zdefiniowane w tych plikach konfiguracyjnych są prostsze niż skomplikowana logika pośredników i aspektów, która jest ukrywana i tworzona automatycznie. Tego typu architektura jest tak kusząca, że biblioteki podobne do Spring doprowadziły do całkowitego przebudowania standardu EJB w wersji 3. EJB w większości korzysta z modelu Spring deklaratywnego wspierania rozcięcia problemów, z użyciem plików konfiguracyjnych XML oraz (lub) adnotacji Java 5. Na listingu 11.5 przedstawiony jest nasz obiekt Bank zapisany w EJB316. L I S T I N G 1 1 . 5 . EJB Bank w EJB3 package com.example.banking.model; import javax.persistence.*; import java.util.ArrayList; import java.util.Collection; @Entity @Table(name = "BANKS") public class Bank implements java.io.Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) private int id; @Embeddable // Obiekt "wbudowany" w wiersz bazy danych dla obiektu Bank. public class Address { protected String streetAddr1; protected String streetAddr2; protected String city; protected String state; protected String zipCode; } @Embedded private Address address; @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy="bank") private Collection < rel="nofollow"> s = new ArrayList < rel="nofollow"> (); public int getId() { return id; } public void setId(int id) { 15

Przykład może być uproszczony z użyciem mechanizmów wykorzystujących konwencję przed konfiguracją oraz adnotacje Java 5 do redukcji ilości wymaganej logiki „połączeń”.

16

Zaadaptowany z http://www.onjava.com/pub/a/onjava/2006/05/17/standardizing-with-ejb3-java-persistence-api.html.

180

ROZDZIAŁ 11.

this.id = id; } public void add( ) { .setBank(this); s.add(); } public Collection < rel="nofollow"> gets() { return s; } public void sets(Collection < rel="nofollow"> s) { this.s = s; } }

Ten kod jest znacznie czystszy od wcześniejszego kodu EJB2. Niektóre szczegóły encji nadal się w nim znajdują, umieszczone w adnotacjach. Jednak dzięki temu, że żadna informacja nie znajduje się poza adnotacjami, kod jest czysty, jasny i przez to łatwy do testowania i utrzymania. Jeżeli będzie to wymagane, niektóre lub wszystkie informacje dotyczące trwałości z adnotacji mogą być przeniesione do deskryptorów instalacji XML, co pozwoli pozostawić czyste obiekty POJO. Jeżeli szczegóły odwzorowania trwałości nie zmieniają się często, wiele zespołów wybiera korzystanie z adnotacji, ponieważ ten mechanizm ma znacznie mniej wad w porównaniu z inwazyjnym sposobem programowania w EJB2.

Aspekty w AspectJ Na koniec przedstawione zostanie najbogatsze narzędzie rozdzielania problemów za pomocą języka AspectJ17 — rozszerzenie języka Java, zapewniające „pierwszej klasy” obsługę aspektów do konstrukcji modularności. Rozwiązanie oparte na użyciu czystego języka Java, zapewniane przez Spring AOP oraz JBoss AOP, w zupełności wystarcza w znaczącej większości przypadków wykorzystania aspektów. Jednak AspectJ zapewnia bardzo przydatny i zaawansowany zestaw narzędzi do rozdzielania problemów. Wadą AspectJ jest potrzeba zastosowania kilku nowych narzędzi i nauczenia się nowych konstrukcji języka i idiomów. Problemy z adaptacją zostały częściowo ograniczone przez ostatnio wprowadzoną „postać adnotacji” dla AspectJ, w której adnotacje Java 5 zostały użyte do definiowania aspektów z użyciem czystego kodu Java. Dodatkowo Spring Framework posiada kilka funkcji, które znacznie ułatwiają zastosowanie aspektów bazujących na adnotacjach w przypadku zespołów mających niewielkie doświadczenie w AspectJ. Pełne omówienie rozszerzenia AspectJ wykracza poza zakres tej książki. Więcej informacji na ten temat można znaleźć w [AspectJ], [Colyer] oraz [Spring].

17

Patrz [AspectJ] oraz [Colyer].

SYSTEMY

181

Testowanie architektury systemu Siła rozdzielania problemów z użyciem metod aspektowych nie może być niedoceniana. Jeżeli możemy napisać logikę domeny naszej aplikacji z użyciem obiektów POJO, odłączonych na poziomie kodu od problemów architektury, to możliwe jest testowanie naszej architektury. Można również w razie potrzeby poddawać ją zmianom, z prostej tworząc całkiem skomplikowaną, przez adaptowanie nowych technologii. Nie jest konieczne wykonywanie wielkiego projektu od podstaw18 (ang. Big Design Up Front — BDUF). W rzeczywistości projektowanie BDUF jest nawet szkodliwe, ponieważ uniemożliwia adaptowanie zmian m.in. z powodu psychologicznego oporu autora przed zaprzepaszczeniem wcześniejszej pracy oraz z powodu sposobu, w jaki wybory architektoniczne wpływają na dalsze myślenie o projekcie. Architekci budynków muszą korzystać z BDUF, ponieważ nie da się wprowadzać radykalnych zmian architektonicznych w dużych strukturach fizycznych w czasie trwania ich budowy19. Jednak oprogramowanie posiada własną fizykę20, w której możliwe jest wprowadzanie radykalnych zmian, jeżeli struktura oprogramowania efektywnie rozdziela problemy. Oznacza to, że można rozpocząć projekt oprogramowania, korzystając z „naiwnie prostej”, ale rozłączonej architektury, i dostarczając szybko użytkownikom działające rozwiązania, a następnie dodając coraz więcej elementów infrastruktury w procesie skalowania w górę. Niektóre z największych na świecie witryn WWW osiągnęły wysoką dostępność i wydajność przez zastosowanie skomplikowanych mechanizmów buforowania danych, bezpieczeństwa, wirtualizacji itp. w sposób efektywny i elastyczny, ponieważ minimalnie sprzężone projekty były odpowiednio proste na każdym poziomie abstrakcji. Oczywiście nie oznacza to, że idziemy w kierunku projektu „bez steru”. Mamy pewne oczekiwania co do zakresu, celów i harmonogramu projektu, jak również ogólną wizję struktury wynikowego systemu. Jednak musimy utrzymywać możliwość zmiany kierunku w odpowiedzi na zmieniające się okoliczności. Wczesna architektura EJB jest jednym z najlepiej znanych API, które są przeprojektowane i nie umożliwiają rozdzielenia problemów. Nawet dobrze zaprojektowane API może być przesadne, jeżeli nie jest ono naprawdę potrzebne. Dobre API powinno w większości przypadków znikać z widoku, aby zespół spędzał większość swojego czasu na implementowaniu rozwiązań dla użytkownika. W przeciwnym razie ograniczenia architektury będą zmniejszały efektywność dostarczania klientom optymalnych rozwiązań. Podsumujmy ten długi opis: Optymalna architektura systemu składa się z modularnych domen problemów; każda z nich jest implementowana z użyciem zwykłych obiektów, np. POJO. Osobne domeny są integrowane ze sobą przy użyciu minimalnie inwazyjnych narzędzi aspektowych lub podobnych. Architektura ta może być testowana, podobnie jak kod. 18

Nie należy mylić tego z dobrą praktyką projektowania od podstaw — BDUF jest praktyką projektowania wszystkiego od początku, przed rozpoczęciem implementowania czegokolwiek.

19

Nadal stosowane jest iteracyjne analizowanie i dyskusja nad detalami, nawet po rozpoczęciu budowy.

20

Termin fizyka oprogramowania został po raz pierwszy użyty w [Kolence].

182

ROZDZIAŁ 11.

Optymalizacja podejmowania decyzji Modularność i rozdzielenie problemów umożliwiają decentralizowane zarządzanie i podejmowanie decyzji. W odpowiednio dużym systemie, niezależnie od tego, czy jest to miasto, czy projekt oprogramowania, jedna osoba nie może podejmować wszystkich decyzji. Wszyscy wiemy, że najlepiej rozdzielać odpowiedzialność między najbardziej kwalifikowane osoby. Często zapominamy, że również najlepiej opóźniać decyzję do ostatniego możliwego momentu. Nie jest to lenistwo ani brak odpowiedzialności — pozwala to nam dokonać wyboru z użyciem najbardziej aktualnych informacji. Zbyt wczesna decyzja jest decyzją podjętą na podstawie nieoptymalnych informacji. Mamy w takim przypadku znacznie mniej informacji od klienta, wiedzy dotyczącej projektu i doświadczenia z naszymi wyborami implementacyjnymi. Solidność zapewniana przez system POJO z modularnymi problemami pozwala na podejmowanie optymalnych decyzji na czas, przy czym decyzje te bazują na najbardziej aktualnej wiedzy. Zmniejszona jest również złożoność tych decyzji.

Korzystaj ze standardów, gdy wnoszą realną wartość Fantastycznie jest patrzeć na plac budowy, zarówno ze względu na szybkość, z jaką powstają nowe budynki (nawet w środku zimy), jak i na nadzwyczajne projekty, jakie są możliwe do realizacji z użyciem dzisiejszych technologii. Budownictwo jest dojrzałym przemysłem korzystającym z wysoce zoptymalizowanych części, metod i standardów, które ewoluowały przez setki lat. Wiele zespołów używało architektury EJB2, ponieważ był to standard, nawet jeżeli wystarczyło zastosować prostsze projekty. Spotkałem się z zespołami, które miały obsesję na punkcie mocno przereklamowanych standardów i przestawały się skupiać na dostarczaniu wartości swoim klientom. Standardy pozwalają na wielokrotne wykorzystywanie pomysłów i komponentów, zatrudnianie osób o odpowiednim doświadczeniu, hermetyzację dobrych pomysłów i łączenie ze sobą komponentów. Jednak proces tworzenia standardów może zajmować zbyt wiele czasu, przez co część z nich traci kontakt z faktycznymi potrzebami ich użytkowników — potrzebami, które te standardy miały zaspokajać.

Systemy wymagają języków dziedzinowych Budownictwo, podobnie jak większość dziedzin technologii, wytworzyło bogaty język ze słownictwem, idiomami oraz wzorcami21, które pozwalają na przekazywanie istotnych informacji w jasny i zwięzły sposób. W przypadku oprogramowania ostatnio odnowiło się zainteresowanie tworzeniem języków dziedzinowych (DSL)22 — osobnych, niewielkich języków skryptowych lub API w standardowych językach, pozwalających na napisanie kodu, który czyta się jak porządnie skomponowaną prozę. 21

Na informatykę największy wpływ miała praca [Alexander].

22

Patrz na przykład [DSL]. [JMock] jest dobrym przykładem API Java do tworzenia DSL.

SYSTEMY

183

Dobry język DSL minimalizuje „przepaść komunikacyjną” pomiędzy koncepcją domeny a implementującym ją kodem, podobnie jak solidne praktyki optymalizują komunikację wewnątrz zespołu oraz z udziałowcami projektu. Jeżeli implementujemy logikę domeny w tym samym języku, którego używa ekspert w zakresie domeny, zmniejszamy ryzyko niewłaściwej konwersji domeny na implementację. Używane efektywnie języki DSL podnoszą poziom abstrakcji ponad idiomy kodu i wzorce projektowe. Pozwalają programistom na odcyfrowanie przeznaczenia kodu na odpowiednim poziomie abstrakcji. Języki dziedzinowe pozwalają wszystkim poziomom abstrakcji i wszystkim domenom w aplikacji na korzystanie z POJO — począwszy od zasad wysokiego poziomu, na szczegółach niskiego poziomu skończywszy.

Zakończenie Systemy również muszą być czyste. Inwazyjna architektura przytłacza logikę domeny i niekorzystnie wpływa na jej solidność. Gdy logika domeny jest zaburzona, spada jakość działania systemu, ponieważ błędy znacznie łatwiej ukrywają się w aplikacji, a implementacja rozwiązań staje się trudniejsza. W efekcie spada wydajność i zalety TDD są tracone. Intencje powinny być jasne na wszystkich poziomach abstrakcji. Zdarza się to tylko wtedy, gdy korzystamy z POJO oraz mechanizmów zbliżonych do aspektowych w celu nieinwazyjnego zastosowania innych implementacji problemów. Niezależnie od tego, czy projektujemy systemy, czy indywidualne moduły, nigdy nie należy zapominać o korzystaniu z najprostszych skutecznych mechanizmów.

Bibliografia [Alexander]: Christopher Alexander, A Timeless Way of Building, Oxford University Press, New York 1979. [AOSD]: Aspect-Oriented Software Development, http://aosd.net. [ASM]: Strona główna ASM, http://asm.objectweb.org. [AspectJ]: http://eclipse.org/aspectj. [CGLIB]: Code Generation Library, http://cglib.sourceforge.net. [Colyer]: Adrian Colyer, Andy Clement, George Hurley, Mathew Webster, Eclipse AspectJ, Person Education, Inc., Upper Saddle River, New York 2005.

184

ROZDZIAŁ 11.

[DSL]: Język dziedzinowy, http://en.wikipedia.org/wiki/Domainspecific_programming_language lub http://pl.wikipedia.org/wiki/J%C4%99zyk_dziedzinowy. [Fowler]: Inversion of Control Containers and the Dependency Injection pattern, http://martinfowler.com/ articles/injection.html. [Goetz]: Brian Goetz, Java Theory and Practice: Decorating with Dynamic Proxies, http://www.ibm.com/ developerworks/java/library/j-jtp08305.html. [Javassist]: Strona główna Javassist, http://www.csg.is.titech.ac.jp/~chiba/javassist. [JBoss]: Strona główna JBoss, http://jboss.org. [JMock]: Jmock — A Lightweight Mock Object Library for Java, http://jmock.org. [Kolence]: Kenneth W. Kolence, Software physics and computer performance measurements, Proceedings of the ACM annual conference — Volume 2, Boston, Massachusetts, s. 1024 – 1040, 1972. [Spring]: The Spring Framework, http://www.springframework.org. [Mezzaros07]: Gerard Mezzaros, XUnit Patterns, Addison-Wesley 2007. [GOF]: Gamma i inni, Elements of Reusable Object Oriented Software, Addison-Wesley 1996.

SYSTEMY

185

186

ROZDZIAŁ 11.

ROZDZIAŁ 12.

Powstawanie projektu Jeff Langr

Uzyskiwanie czystości projektu przez jego rozwijanie Co by było, gdyby dostępne były cztery proste zasady, które pomagałyby tworzyć dobre projekty? Co by było, gdyby korzystanie z tych zasad dawało wgląd w strukturę i projekt kodu, ułatwiając stosowanie takich zasad, jak SRP i DIP? Co by było, gdyby te cztery zasady ułatwiały powstawanie dobrych projektów? Wielu z nas uważa, że cztery zasady prostego projektu1 opracowane przez Kenta Becka są znaczącą pomocą przy tworzeniu dobrze zaprojektowanego oprogramowania.

1

[XPE].

187

Według Kenta projekt jest „prosty”, jeżeli spełnia następujące zasady: 

Przechodzi wszystkie testy.



Nie zawiera powtórzeń.



Wyraża intencje programisty.



Minimalizuje liczbę klas i metod.

Zasady te są zamieszczone zgodnie z hierarchią ważności.

Zasada numer 1 prostego projektu — system przechodzi wszystkie testy Po pierwsze i najważniejsze, projekt musi dać w wyniku system działający w zamierzony sposób. System może mieć doskonały projekt na papierze, ale jeżeli nie istnieje prosty sposób na weryfikowanie, czy działa on w oczekiwany sposób, to cały projekt papierowy jest niewiele warty. System, który jest dokładnie testowany i przechodzi za każdym razem wszystkie testy, jest systemem testowalnym. Można przytoczyć oczywiste, ale ważne zdanie: systemy, które nie są testowalne, nie są również weryfikowalne. Z kolei system, którego nie można zweryfikować, nie powinien być nigdy instalowany. Na szczęście zadanie doprowadzenia do testowalności systemu kieruje nas w stronę projektu, w którym klasy są małe i jednozadaniowe. Po prostu łatwiej jest testować klasy, które spełniają SRP. Im więcej testów napiszemy, tym częściej będziemy tworzyć konstrukcje łatwe w testowaniu. Tak więc zapewnienie pełnej testowalności systemu pomaga w tworzeniu lepszych projektów. Ścisłe sprzężenie utrudnia pisanie testów. Podobnie, im więcej testów napiszemy, tym częściej będziemy korzystać z zasad takich jak DIP i narzędzi takich jak interfejsy wstrzykiwania zależności i abstrakcji zapewniających minimalizację sprzężeń. Nasze projekty staną się jeszcze lepsze. Co ciekawe, działanie zgodnie z prostą i oczywistą zasadą mówiącą, że musimy mieć testy i stale je wykonywać, wpływa na zgodność systemu z podstawowymi celami obiektowości — niskiego sprzężenia i wysokiej spójności. Pisanie testów prowadzi do tworzenia lepszych projektów.

Zasady numer 2 – 4 prostego projektu — przebudowa Gdy mamy zbudowane testy, jesteśmy przygotowani do zapewnienia czystości kodu i klas. Realizujemy to przez przyrostową przebudowę kodu. Po dodaniu każdego wiersza kodu powinniśmy się zatrzymać i pomyśleć o nowym projekcie. Czy właśnie go nie zepsuliśmy? Jeżeli tak, należy poprawić kod i wykonać testy w celu pokazania, że niczego nie uszkodziliśmy. W rzeczywistości posiadanie tych testów eliminuje obawę, że proces czyszczenia kodu uszkodzi go!

188

ROZDZIAŁ 12.

W czasie operacji przebudowy możemy stosować dowolne techniki z bogatej wiedzy na temat dobrych projektów oprogramowania. Możemy zwiększać spójność projektu, zmniejszać sprzężenia, rozdzielać problemy, modularyzować mechanizmy, skracać funkcje i klasy, tworzyć lepsze nazwy i tak dalej. Tu również stosujemy trzy ostatnie zasady prostego projektu — eliminujemy powtórzenia, zapewniamy wyrazistość kodu i minimalizujemy liczbę klas i metod.

Brak powtórzeń Powtórzenia są wrogiem publicznym w dobrze zaprojektowanym systemie. Reprezentują one dodatkową pracę, dodatkowe ryzyko i dodatkową niepotrzebną złożoność. Powtórzenia pojawiają się w wielu formach. Wiersze kodu wyglądające dokładnie tak samo są oczywiście powtórzeniami. Wiersze kodu, które są podobne, często mogą być przekształcone tak, aby wyglądały bardziej podobnie, dzięki czemu mogą być one łatwiej przebudowane. Powtórzenia mogą również istnieć w innych formach, jak na przykład powtórzenia implementacji. Możemy mieć dwie metody w kolekcji klas: int size() {} boolean isEmpty() {}

Możemy mieć osobne implementacje dla każdej z tych metod. Metoda isEmpty może zwracać wartość logiczną, natomiast size wartość licznika. Można również wyeliminować powtórzenia przez związanie isEmpty z definicją size: boolean isEmpty() { return 0 == size(); }

Tworzenie czystego systemu wymaga eliminowania powtórzeń, nawet jeżeli jest to tylko kilka wierszy kodu. Weźmy pod uwagę następujący kod: public void scaleToOneDimension( float desiredDimension, float imageDimension) { if (Math.abs(desiredDimension - imageDimension) < errorThreshold) return; float scalingFactor = desiredDimension / imageDimension; scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f); RenderedOp newImage = ImageUtilities.getScaledImage( image, scalingFactor, scalingFactor); image.dispose(); System.gc(); image = newImage; } public synchronized void rotate(int degrees) { RenderedOp newImage = ImageUtilities.getRotatedImage( image, degrees); image.dispose(); System.gc(); image = newImage; }

Aby zachować czystość systemu, powinniśmy wyeliminować małe powtórzenia pomiędzy metodami scaleToDimension a rotate:

POWSTAWANIE PROJEKTU

189

public void scaleToOneDimension( float desiredDimension, float imageDimension) { if (Math.abs(desiredDimension - imageDimension) < errorThreshold) return; float scalingFactor = desiredDimension / imageDimension; scalingFactor = (float)(Math.floor(scalingFactor * 100) * 0.01f); replaceImage(ImageUtilities.getScaledImage( image, scalingFactor, scalingFactor)); } public synchronized void rotate(int degrees) { replaceImage(ImageUtilities.getRotatedImage(image, degrees)); } private void replaceImage(RenderedOp newImage) { image.dispose(); System.gc(); image = newImage; }

Gdy wyodrębniamy wspólne części na tak niskim poziomie, zaczynamy rozpoznawać naruszenia SRP. Możemy więc przenieść nowe, wyekstrahowane metody do innej klasy. Pozwala to poprawić przejrzystość kodu. Inna osoba z zespołu może rozpoznać możliwość utworzenia dalszej abstrakcji w nowej metodzie i ponownie ją wykorzystać w innym kontekście. Takie „ponowne użycie w małej skali” może spowodować znaczące zmniejszenie złożoności systemu. Jeżeli będziemy widzieć, w jaki sposób ponownie wykorzystywać kod w małej skali, to znacznie prostsze będzie jego wykorzystanie w większej skali. Zastosowanie wzorca szablonu metody2 (ang. Template Method) jest często stosowaną techniką usuwania powtórzeń na wysokim poziomie. Na przykład: public class VacationPolicy { public void accrueUSDivisionVacation() {

// Kod obliczający urlopy, bazujący na godzinach przepracowanych do daty. // ... // Kod sprawdzający, czy urlop spełnia minimalne wymagania z USA. // ... // Kod zapisujący urlop w systemie płacowym. // … } public void accrueEUDivisionVacation() {

// Kod obliczający urlopy, bazujący na godzinach przepracowanych do daty. // ... // Kod sprawdzający, czy urlop spełnia minimalne wymagania przepisów Unii Europejskiej. // ... // Kod zapisujący urlop w systemie płacowym. // ... } }

Kod w metodach accrueUSDivisionVacation oraz accrueEuropeanDivisionVacation jest w większości taki sam, z wyjątkiem obliczania wartości minimalnych. Ten fragment algorytmu zmienia się w zależności od typu pracownika.

2

[GOF].

190

ROZDZIAŁ 12.

Te oczywiste powtórzenia można wyeliminować przez zastosowanie wzorca szablonu metody. abstract public class VacationPolicy { public void accrueVacation() { calculateBaseVacationHours(); alterForLegalMinimums(); applyToPayroll(); }

}

private void calculateBaseVacationHours() { /* ... */ }; abstract protected void alterForLegalMinimums(); private void applyToPayroll() { /* ... */ };

public class USVacationPolicy extends VacationPolicy { @Override protected void alterForLegalMinimums() {

// Kod specyficzny dla USA. }

}

public class EUVacationPolicy extends VacationPolicy { @Override protected void alterForLegalMinimums() {

// Kod specyficzny dla UE. }

}

Dziedziczenie wypełnia „dziurę” w algorytmie accrueVacation, dostarczając jedyny fragment informacji, który nie jest powtarzany.

Wyrazistość kodu Większość z nas ma doświadczenie w pracy z zawiłym kodem. Większość z nas napisała nieco takiego kodu. Łatwo napisać kod, który sami możemy zrozumieć, ponieważ w czasie pisania dokładnie rozumiemy problem, który próbujemy rozwiązać. Inne osoby, które konserwują kod, nie muszą mieć tak głębokiego rozeznania. Większość kosztu oprogramowania przypada na jego długoterminowe utrzymanie. Aby zminimalizować potencjalne defekty, jakie są wprowadzane przez zmiany, niezbędne jest zrozumienie tego, co realizuje system. Wraz ze wzrostem stopnia skomplikowania systemu coraz więcej czasu zajmuje programistom zrozumienie jego działania, a dodatkowo istnieje stale zwiększające się niebezpieczeństwo niewłaściwego zrozumienia. Dlatego kod powinien jasno wyrażać intencje autora. Im jaśniejszy jest kod napisany przez autora, tym mniej czasu inne osoby będą potrzebowały na jego zrozumienie. Pozwala to na ograniczenie defektów i zmniejszenie kosztu utrzymania kodu. Co zatem można zrobić, by kod był czytelny? Można wybierać sugestywne nazwy. Chcemy móc usłyszeć nazwę klasy lub funkcji i nie być zaskoczonym, gdy odkryjemy ich odpowiedzialności. Można również tworzyć niewielkie funkcje i klasy. Małe klasy i funkcje są zwykle łatwiejsze do nazwania, napisania i zrozumienia. Można również korzystać ze standardowej nomenklatury. Wzorce projektowe dla przykładu są w większości przeznaczone do poprawiania komunikacji i wyrazistości kodu. Przez stosowanie standardowych nazw wzorców, takich jak Command lub Visitor w nazwach klas implementujących te wzorce, możemy jasno opisywać nasz projekt dla innych programistów. POWSTAWANIE PROJEKTU

191

Dobrze napisane testy jednostkowe są również ekspresyjne. Podstawowym celem testów jest zapewnienie dokumentacji przez przykład. Ten, kto czyta nasze testy, powinien móc szybko zrozumieć przeznaczenie klasy. Jednak najważniejszym sposobem na osiągnięcie wyrazistości kodu jest próbowanie. Zbyt często zajmujemy się wyłącznie tym, aby kod działał prawidłowo, i przechodzimy do następnego problemu, nie zaprzątając sobie głowy kwestią czytelności kodu. Należy pamiętać, że najprawdopodobniej tą następną osobą będziemy my sami. Dlatego warto być dumnym ze swojej pracy. Warto spędzić nieco czasu nad każdą funkcją i klasą — wybrać lepsze nazwy, podzielić dużą funkcję na mniejsze i ogólnie przywiązywać większą wagę do tego, co tworzymy. Uwaga jest cennym zasobem.

Minimalne klasy i metody Nawet tak podstawowe koncepcje, jak eliminacja powtórzeń, wyrazistość kodu czy też SRP, mogą być pojmowane zbyt dosłownie. W procesie tworzenia małych klas i metod możemy utworzyć zbyt wiele niewielkich klas i metod. Dlatego zasada ta sugeruje, aby równocześnie zachowywać niewielką liczbę funkcji i klas. Duża liczba klas i metod jest czasami wynikiem bezcelowego dogmatyzmu. Weźmy jako przykład standard kodowania, który zakłada tworzenie interfejsu dla każdej klasy, lub programistę, który uważa, że pola i operacje muszą być zawsze rozdzielone na klasy danych i klasy operacji. Nie tędy droga. Naszym celem jest zachowanie możliwie małego systemu, przy jednoczesnym ograniczaniu liczby funkcji i klas. Należy jednak pamiętać, że zasada ta ma najniższy priorytet z czterech zasad prostego projektu. Tak więc choć utrzymanie niskiej liczby klas i funkcji jest ważne, ważniejsze jest posiadanie testów, eliminowanie powtórzeń i wyrazistość kodu.

Zakończenie Czy istnieje zbiór prostych zasad, które mogą zastąpić doświadczenie? Oczywiście nie. Z drugiej strony, praktyki opisane w tym rozdziale i całej książce są wykrystalizowaną postacią wielu dekad doświadczenia zdobywanego przez autorów. Korzystanie z praktyki prostego projektu może i powinno zachęcać i skłaniać programistów do stosowania dobrych praktyk oraz wzorców, których w innym przypadku uczyliby się latami.

Bibliografia [XPE]: Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley 1999. [GOF]: Gamma i inni, Elements of Reusable Object Oriented Software, Addison-Wesley 1996.

192

ROZDZIAŁ 12.

ROZDZIAŁ 13.

Współbieżność Brett L. Schuchert

Obiekty są abstrakcją przetwarzania. Wątki są abstrakcją harmonogramów. James O. Coplien1

1

Z korespondencji prywatnej.

193

— bardzo trudne. Znacznie łatwiej pisać P kod, który wykonuje się w jednym wątku. Równietrudne łatwo można pisać kod wielowątkowy, który ISANIE CZYSTYCH PROGRAMÓW WSPÓŁBIEŻNYCH JEST

wygląda świetnie na pierwszy rzut oka, ale zawiera błędy na niższych poziomach. Taki kod działa prawidłowo do momentu, gdy system zostanie poddany większemu obciążeniu. W tym rozdziale przedstawimy potrzebę programowania współbieżnego oraz związane z tym trudności. Przedstawimy kilka zaleceń pozwalających poradzić sobie z tymi trudnościami oraz pisać czysty kod współbieżny. Na koniec zajmiemy się problemami związanymi z testowaniem kodu współbieżnego. Współbieżność kodu jest złożonym zagadnieniem, które może być tematem osobnej książki. W tej książce przedstawimy go w dwóch etapach: w niniejszym rozdziale zawarte jest wprowadzenie do zagadnienia, a bardziej szczegółowy samouczek zamieściliśmy w dodatku A, „Współbieżność II”. Jeżeli Czytelnik jest po prostu ciekaw zagadnień związanych ze współbieżnością, to ten rozdział jest wystarczający. Jeżeli konieczne jest dogłębne zrozumienie współbieżności, lektura samouczka jest niezbędna.

W jakim celu stosować współbieżność? Współbieżność jest strategią rozdzielania. Pomaga nam oddzielić to, co jest wykonywane, od tego, kiedy jest wykonywane. W aplikacji jednowątkowej co i kiedy są tak ściśle powiązane, że stan całej aplikacji może być często określony wyłącznie na podstawie zapisu stosu. Programista debugujący taki system może ustawić punkty zatrzymania lub ich sekwencję i będzie wiedział, jaki jest stan systemu w czasie, gdy zostanie zatrzymany. Rozłączenie tego, co jest wykonywane, od tego, kiedy jest wykonywane, może znakomicie poprawić zarówno wydajność, jak i strukturę aplikacji. Ze strukturalnego punktu widzenia aplikacja jest podobna do wielu współpracujących ze sobą komputerów zamiast jednej wielkiej pętli głównej. Pozwala to łatwiej zrozumieć system i oferuje wiele wydajnych sposobów na rozdzielenie problemów. Jako przykład weźmy standardowy model aplikacji WWW z użyciem serwletów. Systemy te działają pod parasolem kontenera WWW lub EJB, który częściowo zarządza za nas współbieżnością. Serwlety są wykonywane asynchronicznie w momencie przyjęcia żądania WWW. Programista serwletu nie musi zarządzać wszystkimi przychodzącymi żądaniami. W zasadzie każdy serwlet wykonuje się w osobnym małym świecie i jest odłączony od działania innych serwletów. Oczywiście, jeżeli byłoby to proste, rozdział ten byłby niepotrzebny. W rzeczywistości oddzielenie zapewniane przez kontenery WWW jest dalekie od doskonałości. Programiści serwletów muszą być uważni i ostrożni przy programowaniu, aby ich współbieżne programy były prawidłowe. Pomimo tego strukturalne zalety modelu serwletów są znaczne. Jednak struktura nie jest jedynym motywem wykorzystywania współbieżności. Niektóre systemy mają narzucone ograniczenia na czas odpowiedzi i przepustowość, które wymagają ręcznego kodowania rozwiązań współbieżnych. Dla przykładu weźmy jednowątkowy agregator informacji, który zbiera informacje z wielu różnych witryn WWW i łączy te informacje w dzienne podsumowanie. 194

ROZDZIAŁ 13.

Ponieważ system jest jednowątkowy, odpytuje kolejne witryny, kończąc przeszukiwanie jednej przed rozpoczęciem następnej. Jedno uruchomienie musi się zakończyć w czasie krótszym niż 24 godziny. Jednak gdy dodawanych jest coraz więcej witryn WWW, czas ten rośnie, i w końcu zebranie wszystkich danych zajmuje ponad 24 godziny. Aplikacja jednowątkowa potrzebuje bardzo dużo czasu na oczekiwanie zakończenia operacji wejścia-wyjścia przez gniazdo WWW. Możemy poprawić wydajność takiej aplikacji przez użycie algorytmu wielowątkowego, który jednocześnie przegląda więcej niż jedną witrynę WWW. Innym przykładem zastosowania współbieżności może być system obsługujący jednego użytkownika jednocześnie, wymagający tylko sekundy na obsłużenie użytkownika. Taki system dosyć szybko reaguje w przypadku wielu użytkowników, ale wraz ze wzrostem ich liczby czas odpowiedzi systemu zwiększa się. Żaden użytkownik nie ma ochoty czekać w kolejce za 150 innymi! Możemy poprawić czas odpowiedzi takiego systemu przez obsługę wielu użytkowników jednocześnie. Współbieżność może również znaleźć zastosowanie w systemie interpretującym duże zbiory danych, który może dać pełne rozwiązanie po przetworzeniu wszystkich zbiorów. Prawdopodobnie każdy zbiór danych jest przetwarzany przez inny komputer, więc wiele zbiorów danych jest przetwarzanych równolegle.

Mity i nieporozumienia Mamy więc kuszące powody stosowania współbieżności. Jednak jak wcześniej wspomnieliśmy, współbieżność jest trudna. Jeżeli nie będziemy ostrożni, możemy doprowadzić do wielu nieprzyjemnych sytuacji. Przeanalizujmy poniższe często spotykane mity i nieporozumienia: 

Współbieżność zawsze poprawia wydajność. Współbieżność może czasami poprawić wydajność aplikacji, ale tylko w przypadkach, gdy program traci dużo czasu na oczekiwaniu na wykonanie pewnych procesów i gdy ten czas można podzielić pomiędzy wiele wątków lub wiele procesorów.



Projekt nie zmienia się, jeżeli piszemy programy współbieżne. W rzeczywistości projekt algorytmu współbieżnego może być całkowicie inny niż projekt systemu jednowątkowego. Rozdzielenie co od kiedy zwykle ma ogromny wpływ na strukturę systemu.



Zrozumienie problemów ze współbieżnością nie jest ważne w przypadku korzystania z takiego kontenera jak WWW lub EJB. W rzeczywistości powinniśmy doskonale wiedzieć, co robi nasz kontener i jak chronić się przed problemami współbieżnej modyfikacji oraz zakleszczeń działania kodu, które zostaną przedstawione w dalszej części rozdziału.

Dalej mamy kilka bardziej wyważonych stwierdzeń związanych z pisaniem programów współbieżnych: 

Współbieżność wymaga pewnych narzutów, zarówno na wydajność, jak i na pisanie dodatkowego kodu.



Prawidłowa obsługa współbieżności jest złożona, nawet w przypadku prostych problemów. WSPÓŁBIEŻNOŚĆ

195



Błędy współbieżności często nie są powtarzalne, więc zwykle są ignorowane jako jednorazowe2, choć w rzeczywistości są prawdziwymi defektami.



Współbieżność często wymaga podstawowych zmian w strategii projektu.

Wyzwania Co powoduje, że programowanie współbieżne jest tak trudne? Weźmy jako przykład taką prostą klasę: public class X { private int lastIdUsed; public int getNextId() { return ++lastIdUsed; } }

Załóżmy, że tworzymy obiekt X, ustawiamy pole lastIdUsed na 42, a następnie współdzielimy ten obiekt między dwa wątki. Załóżmy teraz, że oba te wątki wywołują metodę getNextId(); istnieją trzy możliwe wyniki: 

wątek I otrzymuje wartość 43, wątek II otrzymuje wartość 44, lastUsedId jest równe 44;



wątek I otrzymuje wartość 44, wątek II otrzymuje wartość 43, lastUsedId jest równe 44;



wątek I otrzymuje wartość 43, wątek II otrzymuje wartość 43, lastUsedId jest równe 43.

Zaskakujący trzeci wynik3 występuje, gdy dwa wątki napotkają się. Dzieje się to, ponieważ istnieje wiele możliwych ścieżek, które mogą być wybrane przez te dwa wątki w czasie wykonywania jednego wiersza kodu Java, a część z tych ścieżek generuje niewłaściwe wyniki. Ile jest takich różnych ścieżek? Aby rzetelnie odpowiedzieć na to pytanie, musimy zrozumieć, co robi kompilator JIT z wygenerowanym kodem i co w modelu pamięci Java jest uznawane za atomowe. Dla tych dwóch wątków wykonujących metodę getNextId na podstawie właśnie wygenerowanego kodu bajtowego występuje 12 870 różnych możliwych ścieżek wykonania 4. Jeżeli zmienimy typ zmiennej lastIdUsed z int na long, liczba możliwych ścieżek zwiększy się do 2 704 156. Oczywiście, większość ścieżek wygeneruje prawidłowe wyniki. Problemem jest jednak, że niektóre nie dadzą prawidłowych wyników.

Zasady obrony współbieżności Przedstawimy teraz serię zasad i technik obrony naszych systemów przed problemami ze współbieżnym kodem. 2

Promienie kosmiczne, szumy i tak dalej.

3

Patrz „Kopiemy głębiej” w dodatku A.

4

Patrz „Możliwe ścieżki wykonania” w dodatku A.

196

ROZDZIAŁ 13.

Zasada pojedynczej odpowiedzialności Zasada SRP5 mówi, że dana metoda (klasa, komponent) powinna mieć jeden powód do zmiany. Projekt współbieżności jest na tyle złożony, aby być powodem do zmiany, i dlatego warto go oddzielić od reszty kodu. Niestety, zbyt często implementacja szczegółów współbieżności jest wbudowywana bezpośrednio w pozostały kod produkcyjny. Warto wziąć pod uwagę następujące zagadnienia: 

Kod związany ze współbieżnością ma własny cykl produkcji, zmian i dostrajania.



Kod związany ze współbieżnością ma własne wyzwania, które różnią się od tych z kodu niewspółbieżnego i często są trudniejsze.



Liczba sposobów, na które źle napisany kod współbieżny może zawieść, powoduje, że jest on wystarczającym wyzwaniem, nawet bez otaczającego go kodu aplikacji.

Zalecenie: Kod związany ze współbieżnością powinniśmy oddzielić od pozostałego kodu6.

Wniosek — ograniczenie zakresu danych Jak widzieliśmy, dwa wątki modyfikujące to samo pole współużytkowanego obiektu mogą wpływać na siebie, powodując nieoczekiwane działanie. Jednym z rozwiązań jest zastosowanie słowa kluczowego synchronized w celu ochrony sekcji krytycznej kodu wykorzystującego współużytkowane obiekty. Ważne jest, aby ograniczać liczbę takich sekcji krytycznych. Im więcej mamy miejsc, w których modyfikowane są wspólne dane, tym większe prawdopodobieństwo, że: 

zapomnimy ochronić jedno lub więcej takich miejsc — w efekcie powodując uszkodzenie całego kodu modyfikującego te wspólne dane;



wystąpi powtórzenie zadań wymaganych do upewnienia się, że wszystko jest efektywnie chronione (naruszenie zasady DRY7);



trudno będzie określić źródło awarii, które i tak jest wystarczająco trudne do znalezienia.

Zalecenie: Należy wziąć sobie do serca zagadnienie hermetyzacji danych i w znacznym stopniu ograniczyć dostęp do danych, które mogą być współużytkowane.

Wniosek — korzystanie z kopii danych Dobrym sposobem na eliminowanie współużytkowanych danych jest... unikanie ich współużytkowania. W niektórych przypadkach możliwe jest kopiowanie obiektów i traktowanie ich jako tylko do odczytu. W innych przypadkach może być możliwe kopiowanie obiektów, zbieranie wyników z wielu wątków w tych kopiach, a następnie łączenie wyników w jednym wątku.

5

[PPP].

6

Patrz „Przykład klient-serwer” w dodatku A.

7

[PRAG].

WSPÓŁBIEŻNOŚĆ

197

Jeżeli istnieje prosty sposób na uniknięcie współużytkowania obiektów, wynikowy kod będzie ze znacznie mniejszym prawdopodobieństwem powodował błędy. Można się jednak obawiać o koszt tworzenia dodatkowych obiektów. Warto poeksperymentować w celu określenia, czy faktycznie jest to problemem. Jednak jeżeli wykorzystanie kopii obiektów pozwala na uniknięcie synchronizacji, oszczędności na uniknięciu koniecznej blokady zwykle będą większe niż narzut wymagany na dodatkowe tworzenie i usuwanie obiektu.

Wniosek — wątki powinny być na tyle niezależne, na ile to tylko możliwe Warto rozważyć pisanie kodu wątków w taki sposób, aby każdy wątek działał we własnym świecie, nie współużytkując danych z pozostałymi wątkami. Każdy wątek przetwarza jedno żądanie klienta, a wszystkie wymagane dane pochodzą z niewspółużytkowanego źródła i są przechowywane jako zmienne lokalne. Powoduje to, że wątki te działają tak, jakby były jedynym wątkiem na świecie, i dlatego nie potrzebują synchronizacji. Na przykład klasy dziedziczące po HttpSevlet otrzymują wszystkie dane jako parametry przekazane do metod doGet oraz doPost. Powoduje to, że każdy serwlet działa jako osobna maszyna. Dopóki kod w serwlecie korzysta wyłącznie ze zmiennych lokalnych, nie ma możliwości, aby wystąpiły błędy synchronizacji. Oczywiście, większość aplikacji korzystających z serwletów i tak korzysta ze współużytkowanych zasobów, na przykład połączeń z bazą danych. Zalecenie: Warto spróbować podzielić dane na niezależne podzbiory, na których mogą działać niezależne wątki, być może działające na różnych procesorach.

Poznaj używaną bibliotekę W stosunku do poprzedniej wersji język Java 5 oferuje wiele usprawnień programowania współbieżnego. Pisząc kod korzystający z wątków za pomocą języka Java 5, należy rozważyć następujące zagadnienia: 

Zastosowanie dostarczanych kolekcji bezpiecznych dla wątków.



Użycie wykonawców do uruchamiania niezwiązanych ze sobą zadań.



Stosowanie rozwiązań nieblokujących wszędzie tam, gdzie jest to możliwe.



Wykorzystywanie kilku klas z biblioteki nie jest bezpieczne dla wątków.

Kolekcje bezpieczne dla wątków Gdy Java była młodym językiem, Doug Lea napisał doskonałą książkę8 Concurrent Programming in Java. W książce tej przedstawił proces tworzenia kilku kolekcji bezpiecznych dla wątków, które później stały się częścią JDK i zostały umieszczone w pakiecie java.util.concurrent. Kolekcje z tego pakietu są bezpieczne w przypadkach operacji wielowątkowych i działają odpowiednio szybko. 8

[Lea99].

198

ROZDZIAŁ 13.

Faktycznie implementacja ConcurrentHashMap w niemal każdej sytuacji działa szybciej niż HashMap. Pozwala ona na jednoczesny zapis i odczyt oraz udostępnia metody wspierające często używane operacje złożone, które w pozostałych przypadkach nie są bezpieczne dla wątków. Jeżeli środowiskiem instalacyjnym jest Java 5, należy korzystać z ConcurrentHashMap. Dostępnych jest również kilka innych klas pozwalających na obsługę zaawansowanych projektów wielowątkowych. Kilka przykładów przedstawiono poniżej. ReentrantLock

Blokada, która może być nałożona w jednej metodzie i zwolniona w innej.

Semaphore

Implementacja klasycznego semafora, czyli blokady z licznikiem.

CountDownLatch

Blokada, która oczekuje na określoną liczbę zdarzeń przed ponownym uruchomieniem wszystkich wątków oczekujących na niej. Pozwala ona, aby wszystkie wątki miały możliwość wystartowania w mniej więcej tym samym momencie.

Zalecenie: Warto zapoznać się z dostępnymi klasami. W przypadku języka Java należy zapoznać się z java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks.

Poznaj modele wykonania Istnieje kilka różnych sposobów na partycjonowanie działania w aplikacjach współbieżnych. Przed ich przedstawieniem musimy zapoznać się z kilkoma podstawowymi definicjami. Zasoby związane

Zasoby stałej wielkości i liczby używane w środowisku współbieżnym. Przykładem mogą być połączenia z bazą danych oraz bufory odczytu i zapisu o stałej wielkości.

Wzajemne wykluczanie

Tylko jeden wątek może odwoływać się do danych współużytkowanych w danym momencie.

Zagłodzenie

Jeden wątek z grupy wątków nie może działać przez zbyt długi czas lub ciągle. Na przykład dopuszczenie, aby szybko działające wątki zawsze pierwsze przechodziły przez blokadę, powoduje zagłodzenie wolniej działających wątków, jeżeli nie ma końca strumienia szybko działających wątków.

Zakleszczenie

Co najmniej dwa wątki czekają na zakończenie innego z oczekujących wątków. Każdy wątek posiada zasób, który jest wymagany przez inny wątek, i żaden nie może się zakończyć, dopóki nie uzyska innego zasobu.

Uwięzienie

Wątki są wstrzymane, ale każdy z nich próbuje znaleźć „inną drogę”. Z powodu rezonansu wątki próbujące iść dalej nie są w stanie zrobić tego przez niernie długi czas — lub też nigdy.

Mając te definicje, możemy przedstawić różne modele wykonania kodu używane w programowaniu współbieżnym.

Producent-konsument9 Co najmniej jeden wątek producent wykonuje pewne zadania i umieszcza wyniki w buforze lub kolejce. Co najmniej jeden wątek konsument odbiera te wyniki i wykonuje na nich operacje. Kolejka pomiędzy producentami i konsumentami jest zasobem związanym. Oznacza to, że producenci muszą

9

http://pl.wikipedia.org/wiki/Problem_producenta_i_konsumenta

WSPÓŁBIEŻNOŚĆ

199

czekać na wolne miejsce w kolejce przed zapisem, a konsumenci muszą czekać, aż w kolejce będzie coś do skonsumowania. Koordynacja pomiędzy producentami i konsumentami poprzez kolejkę wymaga zastosowania sygnalizacji przez producenta i konsumenta. Producent zapisuje do kolejki i sygnalizuje, że kolejka nie jest już pusta. Konsumenci odczytują z kolejki i sygnalizują, że kolejka nie jest już pełna. Obie strony oczekują na informację, że mogą kontynuować pracę.

Czytelnik-pisarz10 Gdy mamy współużytkowany zasób, który przede wszystkim służy jako źródło informacji dla czytelników, ale jest okazjonalnie aktualizowany przez pisarzy, problemem jest przepustowość. Położenie nacisku na przepustowość może powodować zagłodzenie i akumulację oczekujących informacji. Umożliwienie aktualizacji może zmniejszać przepustowość. Koordynacja czytelników, aby nie czytali czegoś, co jest aktualizowane przez pisarza, i odwrotnie, jest zadaniem trudnym do wyważenia. Pisarze zwykle blokują wielu czytelników przez długi czas, powodując problemy z przepustowością. Wyzwaniem jest zbilansowanie potrzeb zarówno czytelników, jak i pisarzy, aby zapewnić prawidłowe działanie, rozsądną przepustowość i uniknąć zagłodzenia. Prosta strategia wymaga, aby pisarze przed wykonaniem aktualizacji czekali, dopóki nie będzie żadnego czytelnika. Jeżeli będzie występował stały strumień czytelników, pisarz zostanie zagłodzony. Z drugiej strony, jeżeli pisarze będą działali często i będą mieli duży priorytet, spadnie przepustowość. Rozwiązanie tego problemu polega na znalezieniu równowagi i uniknięciu problemów ze współbieżną aktualizacją.

Ucztujący filozofowie11 Wyobraźmy sobie kilku filozofów siedzących wokół okrągłego stołu. Po lewej stronie każdego filozofa znajduje się widelec. Na środku stołu znajduje się duża misa spaghetti. Filozofowie spędzają swój czas na myśleniu, o ile nie są głodni. Gdy są głodni, chwytają za widelce leżące po obu stronach i zaczynają jeść. Filozofowie nie mogą jeść, jeżeli nie trzymają dwóch widelców. Jeżeli filozof siedzący po prawej stronie używa jednego z potrzebnych widelców, głodny filozof musi poczekać, dopóki ten po prawej nie skończy jeść i nie odłoży widelców. Gdy filozof jest najedzony, odkłada swoje widelce na stół i czeka, aż znów będzie głodny. Gdy zamienimy filozofów na wątki i widelce na zasoby, problem stanie się podobny do wielu aplikacji korporacyjnych, w których procesy rywalizują o zasoby. Jeżeli system taki nie będzie odpowiednio zaprojektowany, tego rodzaju rywalizacja będzie powodowała zakleszczenia, uwięzienia oraz spadek przepustowości i efektywności systemu. Większość problemów współbieżnych, z jakimi się spotykamy, jest odmianą jednej z tych trzech sytuacji. Warto zapoznać się z tymi algorytmami i napisać ich rozwiązania, dzięki czemu, gdy napotkamy na konkretny problem współbieżności, będziemy lepiej przygotowani do jego rozwiązania. Zalecenie: Warto nauczyć się podstawowych algorytmów i zrozumieć ich rozwiązania. 10

http://pl.wikipedia.org/wiki/Problem_czytelnik%C3%B3w_i_pisarzy

11

http://pl.wikipedia.org/wiki/Problem_ucztuj%C4%85cych_filozof%C3%B3w

200

ROZDZIAŁ 13.

Uwaga na zależności pomiędzy synchronizowanymi metodami Zależności pomiędzy synchronizowanymi metodami powodują subtelne błędy w kodzie współbieżnym. Język Java posiada notację synchronized, która pozwala chronić poszczególne metody. Jeżeli jednak mamy więcej metod synchronizowanych w tej samej klasie współużytkowanej, to system może być napisany nieprawidłowo12. Zalecenie: Unikaj używania więcej niż jednej metody w obiekcie współużytkowanym. Zdarzają się jednak przypadki, gdy konieczne jest użycie więcej niż jednej metody we współużytkowanym obiekcie. W takim przypadku istnieją trzy sposoby na zapewnienie prawidłowego działania kodu. 

Blokowanie po stronie klienta — klient blokuje serwer przed wywołaniem pierwszej metody i blokada ta jest utrzymywana przez czas wykonywania kodu ostatniej metody.



Blokowanie po stronie serwera — wewnątrz serwera tworzona jest metoda, która blokuje serwer, wywołuje wszystkie potrzebne metody, a następnie zdejmuje blokadę. Klient musi wywołać nową metodę.



Serwer adaptujący — tworzony jest pośrednik zapewniający blokowanie. Jest to przykład blokowania po stronie serwera, w którym oryginalny serwer nie może być zmieniany.

Tworzenie małych sekcji synchronizowanych Słowo kluczowe synchronized wprowadza blokadę. Wszystkie sekcje kodu chronione przez tę samą blokadę mają zagwarantowane, że w danym momencie tylko jeden wątek będzie wykonywał chronioną sekcję. Blokady są kosztowne, ponieważ powodują opóźnienia i dodają narzut. Dlatego nie należy nadużywać instrukcji synchronized. Z drugiej strony, sekcje krytyczne13 muszą być chronione. Dlatego powinniśmy projektować nasz kod z minimalną możliwą liczbą sekcji krytycznych. Niektórzy naiwni programiści próbują to osiągnąć, tworząc bardzo duże sekcje krytyczne. Jednak rozciąganie synchronizacji poza minimalną sekcję krytyczną zwiększa rywalizację o zasoby i obniża wydajność systemu14. Zalecenie: Sekcje synchronizowane powinny być jak najmniejsze.

12

Patrz „Zależności pomiędzy metodami mogą uszkodzić kod współbieżny” w dodatku A.

13

Sekcja krytyczna jest dowolną sekcją kodu, która musi być chroniona przed jednoczesnym użyciem, aby działanie programu było prawidłowe.

14

Patrz „Zwiększanie przepustowości” w dodatku A.

WSPÓŁBIEŻNOŚĆ

201

Pisanie prawidłowego kodu wyłączającego jest trudne Konstruowanie systemów, które mają działać w nieskończoność, różni się od tworzenia czegoś, co działa przez chwilę, a następnie elegancko się wyłącza. Eleganckie wyłączenie może być trudne do osiągnięcia. Często spotykanymi problemami są zakleszczenia15 wątków oczekujących na sygnał kontynuowania, który nigdy nie nadejdzie. Wyobraźmy sobie system z wątkiem głównym, który generuje kilka wątków potomnych i czeka na ich zakończenie, po czym zwalnia zasoby i kończy pracę. Co się stanie, gdy wątek potomny ulegnie zakleszczeniu? Wątek główny będzie oczekiwał bez przerwy i system nigdy nie zostanie wyłączony. Weźmy też pod uwagę podobny system, który został poinstruowany o konieczności zakończenia pracy. Wątek główny powiadamia wszystkie wątki potomne, aby przerwały swoje zadania i zakończyły się. Co się stanie, jeżeli dwa z tych wątków potomnych działają jako para producent-konsument? Załóżmy, że producent otrzymał sygnał z wątku głównego i szybko zakończył pracę. Konsument może oczekiwać na komunikat od producenta i być zablokowany w stanie, w którym nie może odebrać sygnału wyłączenia. Wątek utknie, czekając na producenta, i nie będzie mógł zakończyć pracy, co uniemożliwi również zakończenie pracy wątku głównego. Tego typu sytuacje nie są niczym szczególnym. Jeżeli więc musimy napisać kod współbieżny, który wymaga eleganckiego zakończenia, należy oczekiwać, że spędzimy sporo czasu na prawidłowym zrealizowaniu takiego zakończenia. Zalecenie: Należy stosować wczesne wyłączanie i wczesne uruchamianie. Zwykle zajmuje to więcej czasu, niż oczekujemy. Warto przejrzeć istniejące algorytmy, ponieważ prawdopodobnie jest to trudniejsze, niż myślisz.

Testowanie kodu wątków Udowadnianie, że kod jest prawidłowy, jest niepraktyczne. Testowanie nie gwarantuje poprawności. Jednak dobre testy pozwalają zminimalizować ryzyko. To wszystko jest prawdą w przypadku rozwiązań jednowątkowych. Gdy tylko istnieją co najmniej dwa wątki korzystające z tego samego kodu i pracujące na współużytkowanych danych, wszystko staje się znacznie bardziej skomplikowane. Zalecenie: Warto pisać testy, które mają możliwość ujawnienia problemów, a następnie należy je często uruchamiać, korzystając z różnych konfiguracji programowych i systemowych oraz różnego obciążenia. Jeżeli w jakichkolwiek okolicznościach test zawiedzie, należy zlokalizować błąd. Nie należy ignorować awarii tylko dlatego, że w następnym uruchomieniu test wykonał się prawidłowo.

15

Patrz „Zakleszczenia” w dodatku A.

202

ROZDZIAŁ 13.

Należy tu wziąć pod uwagę wiele elementów. Poniżej zamieszczone są bardziej precyzyjne zalecenia. 

Traktujemy przypadkowe awarie jako potencjalne problemy z wielowątkowością.



Na początku uruchamiamy kod niekorzystający z wątków.



Nasz kod wątków powinien dać się włączać.



Nasz kod wątków powinien dać się dostrajać.



Uruchamiamy więcej wątków, niż mamy do dyspozycji procesorów.



Uruchamiamy testy na różnych platformach.



Uzbrajamy nasz kod w elementy próbujące wywołać awarie i wymuszające awarie.

Traktujemy przypadkowe awarie jako potencjalne problemy z wielowątkowością Kod wielowątkowy powoduje, że awarii ulegają elementy, które „po prostu nie mogą zawieść”. Większość programistów nie ma intuicyjnego poczucia, w jaki sposób wątki współdziałają z pozostałą częścią kodu (w tym autorzy). Błędy w kodzie wątków mogą się ujawniać raz na tysiąc lub milion wykonań. Próby ich powtórzenia mogą być frustrujące. Często prowadzi to do tego, że programiści kwalifikują błąd jako efekt promieniowania kosmicznego, wybryku sprzętu lub innego rodzaju „sytuacji jednorazowej”. Najlepiej założyć, że sytuacje jednorazowe nie istnieją. Im dłużej są one ignorowane, tym więcej kodu korzysta z potencjalnie nieprawidłowego podejścia. Zalecenie: Nie należy ignorować awarii systemu, kwalifikując je jako jednorazowe.

Na początku uruchamiamy kod niekorzystający z wątków Może to się wydawać oczywiste, ale warto to powtórzyć. Należy upewnić się, że kod działa poza środowiskiem wielowątkowym. Zwykle oznacza to, że tworzymy obiekty POJO, które będą wywoływane przez nasze wątki. Obiekty POJO nie mają informacji o wątkach i dzięki temu mogą być testowane poza środowiskiem wielowątkowym. Im więcej elementów systemu jest umieszczonych w tych obiektach, tym lepiej. Zalecenie: Nie warto w tym samym czasie szukać błędów w kodzie jednowątkowym i wielowątkowym. Należy sprawdzić, czy kod działa poza wątkiem.

Nasz kod wątków powinien dać się włączać Warto pisać kod wspierający współbieżność w taki sposób, że może być uruchomiony w kilku konfiguracjach: 

Jeden wątek, kilka wątków, różna liczba w zależności od sposobu wykonania.



Kod wątków współdziałający zarówno z rzeczywistym, jak i testowym środowiskiem.

WSPÓŁBIEŻNOŚĆ

203



Wykonanie w środowisku testowym działającym szybko, powoli lub ze zmienną szybkością.



Konfigurowanie testów w taki sposób, aby można było określać liczbę iteracji.

Zalecenie: Warto tak napisać kod wątków, aby był dowolnie dołączany, by można było go uruchamiać w różnych konfiguracjach.

Nasz kod wątków powinien dać się dostrajać Uzyskanie właściwej równowagi wątków zwykle wymaga wielu prób. Jak najwcześniej należy znaleźć sposoby na sterowanie wydajnością systemu w różnych konfiguracjach. Takim sposobem może być łatwa zmiana liczby wątków. Warto rozważyć możliwość zmiany ich liczby w czasie działania systemu. Przydatny może być również mechanizm automatycznego dostrajania w zależności od przepustowości i obciążenia systemu.

Uruchamiamy więcej wątków, niż mamy do dyspozycji procesorów Gdy system przełącza się pomiędzy zadaniami, zdarzają się różne sytuacje. Aby wymusić przełączanie zadań, należy uruchomić więcej wątków, niż mamy do dyspozycji procesorów lub rdzeni. Im częściej są przełączane zadania, tym większe prawdopodobieństwo, że wykryjemy kod, w którym brakuje sekcji krytycznej, lub kod powodujący zakleszczenie.

Uruchamiamy testy na różnych platformach W roku 2007 tworzyliśmy kurs programowania współbieżnego. Sam kurs zakładał wykorzystanie przede wszystkim systemu OS X. W czasie lekcji korzystaliśmy też z Windows XP działającego na maszynie wirtualnej. Testy pisane w celu pokazania sytuacji błędnych nie były tak często wykonywane nieprawidłowo w środowisku XP, jak w środowisku OS X. We wszystkich przypadkach wiedzieliśmy, że testowany kod był nieprawidłowy. Ilustruje to fakt, że różne systemy operacyjne mają różne zasady wielowątkowości, które wpływają na wykonywanie kodu. Kod wielowątkowy działa inaczej w różnych środowiskach16. Powinniśmy wykonywać testy w każdym potencjalnym środowisku instalacyjnym. Zalecenie: Kod wielowątkowy powinniśmy uruchamiać na wszystkich docelowych platformach — i to często.

16

Czy wiesz, że model wielowątkowości w języku Java nie gwarantuje wielowątkowości z wywłaszczaniem? Nowoczesne systemy operacyjne obsługują wielowątkowość z wywłaszczaniem, więc mamy ją „za darmo”. Pomimo tego nie jest ona gwarantowana przez JVM.

204

ROZDZIAŁ 13.

Uzbrajamy nasz kod w elementy próbujące wywołać awarie i wymuszające awarie Nie jest niczym niezwykłym fakt, że w kodzie współbieżnym ukrywają się błędy. Proste testy po prostu nie są w stanie ich ujawnić. Często ukrywają się w czasie normalnego przetwarzania. Mogą się one ujawniać jednokrotnie co kilka godzin, dni lub tygodni! Powodem tego, że błędy współbieżności mogą być rzadkie, sporadyczne i trudne do powtórzenia, jest to, że tylko kilka ścieżek wykonania z tysięcy możliwych ścieżek przez wrażliwą sekcję może zawieść. Dlatego prawdopodobieństwo wyboru niewłaściwej ścieżki może być bardzo niskie. Powoduje to, że wykrywanie błędów i debugowanie jest bardzo trudne. Jak można zwiększyć szanse przechwycenia takich rzadkich przypadków? Można uzbroić nasz kod i wymusić działanie w różnej kolejności przez dodanie wywołań takich metod, jak Object.wait(), Object.sleep(), Object.yield() oraz Object.priority(). Każda z tych metod może wpływać na kolejność wykonania, zwiększając możliwość wykrycia błędu. Będzie lepiej, gdy nieprawidłowy kod zawiedzie wcześniej i możliwie często. Istnieją dwie możliwości instrumentacji kodu: 

ręczna,



automatyczna.

Instrumentacja ręczna Do naszego kodu możemy ręcznie wstawiać wywołania wait(), sleep(), yield() oraz priority(). Może to być właściwe działanie, gdy testujemy szczególnie oporny fragment kodu. Poniżej mamy przykład takiego działania: public synchronized String nextUrlOrNull() { if(hasNext()) { String url = urlGenerator.next(); Thread.yield(); // Wstawione do testowania. updateHasNext(); return url; } return null; }

Wstawione wywołanie yield() zmienia ścieżkę wywołania kodu i być może powoduje awarię kodu w miejscu, w którym wcześniej wykonywał się prawidłowo. Jeżeli kod ulegnie awarii, nie jest to spowodowane dodaniem wywołania yield()17. Kod już wcześniej zawierał błąd, a teraz po prostu go ujawniliśmy. 17

Jednak nie do końca. Ponieważ JVM nie gwarantuje wielowątkowości z wywłaszczaniem, określony algorytm może zawsze działać w systemach niewywłaszczających wątków. Sytuacja odwrotna jest również możliwa, ale z innych powodów.

WSPÓŁBIEŻNOŚĆ

205

Z podejściem tym wiąże się kilka problemów: 

Konieczne jest ręczne znalezienie odpowiednich miejsc.



Skąd będziemy wiedzieli, gdzie umieścić wywołanie i jakiego rodzaju?



Pozostawienie takiego kodu w środowisku produkcyjnym niepotrzebnie spowalnia kod.



Jest to metoda śrutówki. Możemy znaleźć błąd lub nie. I tak nie mamy wielkich szans.

Potrzebujemy sposobu na korzystanie z tego podejścia w czasie testowania, a nie produkcji. Potrzebujemy również sposobu na modyfikowanie konfiguracji pomiędzy uruchomieniami, co zwiększa szanse znalezienia błędów. Jasne jest, że gdy podzielimy nasz system na obiekty POJO, które nie mają informacji o wątkach, i klasy sterujące wątkami, łatwiej będzie znaleźć odpowiednie miejsca instrumentacji kodu. Co więcej, możemy utworzyć wiele różnych elementów testowych, które wywołują POJO w różnych reżimach wywołań sleep, yield i innych.

Instrumentacja automatyczna Możemy skorzystać z narzędzi takich jak Aspect-Oriented Framework, CGLIB lub ASM do programowej instrumentacji naszego kodu. Możemy na przykład skorzystać z klasy z jedną metodą: public class ThreadJigglePoint { public static void jiggle() { } }

Można dodać jej wywołania w różnych miejscach kodu: public synchronized String nextUrlOrNull() { if(hasNext()) { ThreadJiglePoint.jiggle(); String url = urlGenerator.next(); ThreadJiglePoint.jiggle(); updateHasNext(); ThreadJiglePoint.jiggle(); return url; } return null; }

Teraz można użyć prostego aspektu, który losowo wybiera jedną z możliwości: wywołanie sleep, yield lub niewywoływanie niczego. Można również skorzystać z klasy ThreadJigglePoint mającej dwie implementacje. Pierwsza implementacja jigle nic nie robi i jest używana w produkcji. Druga generuje liczbę losową wybierającą pomiędzy sleep, yield lub niewywoływaniem niczego. Jeżeli uruchomimy nasz test tysiąc razy z losowym wytrząsaniem, możemy ujawnić niektóre błędy. Jeżeli test zostanie wykonany prawidłowo, będziemy mogli powiedzieć, że przynajmniej wykazaliśmy się należytą starannością. Choć to rozwiązanie jest dosyć proste, może być rozsądną opcją w porównaniu z zastosowaniem bardziej skomplikowanych narzędzi. 206

ROZDZIAŁ 13.

Dostępny jest program ConTest18 opracowany w IBM, który działa podobnie, ale jego użycie jest znacznie bardziej skomplikowane. Naszym celem jest wstrząsanie kodem tak, aby wątki wykonywały się za każdym razem w innej kolejności. Kombinacja dobrze napisanych testów i wstrząsów może zdecydowanie zwiększyć szanse znalezienia błędów. Zalecenie: Warto korzystać ze strategii wstrząsania w celu upolowania błędów.

Zakończenie Trudno uzyskać prawidłowy kod współbieżny. Kod, który jest prosty do analizy, może stać się koszmarem, gdy wymieszamy go z wieloma wątkami i współużytkowanymi danymi. Jeżeli chcemy zmierzyć się z kodem współbieżnym, musimy rygorystycznie przestrzegać pisania czystego kodu, ponieważ w przeciwnym razie zderzymy się z subtelnymi i niezbyt częstymi awariami. Po pierwsze i najważniejsze, należy stosować zasadę pojedynczej odpowiedzialności. Należy podzielić nasz system na obiekty POJO, które oddzielają kod obsługi wątków od kodu nieobsługującego wątków. Przy testowaniu kodu obsługi wątków należy upewnić się, że testujemy tylko ten problem. Wynika z tego, że kod obsługi wątków powinien być mały i ściśle ukierunkowany. Znane są możliwe źródła problemów z wielowątkowością: wiele wątków działa na wspólnych danych lub korzysta ze wspólnej puli zasobów. Przypadki brzegowe, takie jak czyste wyłączenie lub zakończenie iteracji pętli, mogą być szczególnie kłopotliwe. Warto zapoznać się z biblioteką i podstawowymi algorytmami. Konieczne jest zrozumienie, w jaki sposób funkcje oferowane przez bibliotekę wspierają rozwiązywanie problemów podobnych do podstawowych algorytmów. Należy nauczyć się rozpoznawania regionów kodu, które muszą być odizolowane i zablokowane. Nie należy blokować regionów kodu, które nie muszą być zablokowane. Należy unikać wywoływania jednej blokowanej sekcji z innej. Wymaga to głębokiego zrozumienia tego, czy dany element jest, czy nie jest współużytkowany. Liczba współużytkowanych obiektów i zakres współużytkowania powinny być możliwie małe. Projekt obiektów zawierających współużytkowane dane powinien być zmieniony tak, aby przyjmować klienty, zamiast wymuszać na nich zarządzanie stanem współużytkowanym. Na pewno będą ujawniały się problemy. Te problemy, które nie zostaną ujawnione odpowiednio wcześnie, często są interpretowane jako przypadki jednorazowe. Te tak zwane przypadki jednorazowe zwykle ujawniają się pod obciążeniem systemu lub — pozornie — losowo. Z tego powodu musimy zapewnić, by nasz kod obsługi wątków można było uruchamiać w wielu konfiguracjach oraz na

18

http://www.alphaworks.ibm.com/tech/contest

WSPÓŁBIEŻNOŚĆ

207

wielu platformach w sposób ciągły i powtarzalny. Możliwość testowania, która wynika naturalnie z trzech praw TDD, zakłada pewien poziom dołączania i pozwala obsługiwać niezbędny kod uruchomieniowy w szerokim zakresie konfiguracji. Znacznie poprawimy nasze szanse znalezienia nieprawidłowego kodu, jeżeli poświęcimy trochę czasu na jego instrumentację. Można to zrobić ręcznie lub skorzystać z technologii automatycznych. Warto w to zainwestować możliwie wcześnie. Nasz kod korzystający z wątków powinien — przed przekazaniem go do produkcji — działać tak długo, jak tylko to możliwe.

Bibliografia [Lea99]: Doug Lea, Concurrent Programming in Java: Design Principles and Patterns, wydanie drugie, Prentice Hall 1999. [PPP]: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall 2002. [PRAG]: Andrew Hunt, Dave Thomas, The Pragmatic Programmer, Addison-Wesley 2000.

208

ROZDZIAŁ 13.

ROZDZIAŁ 14.

Udane oczyszczanie kodu Analiza przypadku procesora argumentów wiersza polecenia

oczyszczania kodu modułu, w którym wystąpiły proR blemy ze skalowaniem. Przedstawimy,udanego w jaki sposób moduł ten został przebudowany i wyczyszOZDZIAŁ TEN JEST ANALIZĄ PRZYPADKU

czony. Większość z nas od czasu do czasu musi analizować argumenty wiersza polecenia. Jeżeli nie mamy wygodnego narzędzia, to po prostu przeglądamy tablicę ciągów przekazaną do funkcji main. Dostępnych jest kilka niezłych narzędzi pochodzących z różnych źródeł, ale żadne nie oferowało wszystkich oczekiwanych przez nas możliwości. Z tego powodu zdecydowaliśmy się napisać własny moduł. Nazwałem go Args.

209

Jest on bardzo prosty w użyciu. Tworzymy klasę Args z argumentami wejściowymi oraz ciągiem formatującym, a następnie odczytujemy wartości argumentów z obiektu Args. Weźmy pod uwagę następujący prosty przykład: L I S T I N G 1 4 . 1 . Proste zastosowanie klasy Args public static void main(String[] args) { try { Args arg = new Args("l,p#,d*", args); boolean logging = arg.getBoolean('l'); int port = arg.getInt('p'); String directory = arg.getString('d'); executeApplication(logging, port, directory); } catch (ArgsException e) { System.out.printf("Błąd argumentów: %s\n", e.errorMessage()); } }

Jak widać, jest to bardzo proste. Tworzymy obiekt klasy Args z dwoma parametrami. Pierwszym jest ciąg formatu lub schematu: "l,p#,d*". Definiuje on trzy argumenty wiersza polecenia. Pierwszy, -l, jest argumentem logicznym. Drugi, -p, jest argumentem całkowitym. Trzeci, -d, jest argumentem tekstowym. Drugim parametrem konstruktora Args jest po prostu tablica argumentów wiersza polecenia przekazana do main. Jeżeli konstruktor wykona się bez zgłoszenia wyjątku ArgsException, to wiemy, że przekazany wiersz polecenia został zanalizowany i że można korzystać z obiektu Args. Metody getBoolean, getInteger i getString pozwalają na odczytywanie wartości argumentów przy użyciu ich nazw. Jeżeli wystąpi problem w ciągu formatującym albo w samych argumentach wiersza polecenia, zgłaszany jest wyjątek ArgsException. Dokładny opis tego, co poszło źle, można odczytać za pomocą metody errorMessage z wyjątku.

Implementacja klasy Args Na listingu 14.2 przedstawiona jest implementacja klasy Args. Proszę o jego uważne przeczytanie. Ciężko pracowałem nad stylem i strukturą, więc mam nadzieję, że jest warta emulowania. L I S T I N G 1 4 . 2 . Args.java package com.objectmentor.utilities.args; import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; import java.util.*; public class Args { private Map marshalers; private Set argsFound; private ListIterator<String> currentArgument; public Args(String schema, String[] args) throws ArgsException { marshalers = new HashMap (); argsFound = new HashSet ();

210

ROZDZIAŁ 14.

parseSchema(schema); parseArgumentStrings(Arrays.asList(args)); } private void parseSchema(String schema) throws ArgsException { for (String element : schema.split(",")) if (element.length() > 0) parseSchemaElement(element.trim()); } private void parseSchemaElement(String element) throws ArgsException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (elementTail.length() == 0) marshalers.put(elementId, new BooleanArgumentMarshaler()); else if (elementTail.equals("*")) marshalers.put(elementId, new StringArgumentMarshaler()); else if (elementTail.equals("#")) marshalers.put(elementId, new IntegerArgumentMarshaler()); else if (elementTail.equals("##")) marshalers.put(elementId, new DoubleArgumentMarshaler()); else if (elementTail.equals("[*]")) marshalers.put(elementId, new StringArrayArgumentMarshaler()); else throw new ArgsException(INVALID_ARGUMENT_FORMAT, elementId, elementTail); } private void validateSchemaElementId(char elementId) throws ArgsException { if (!Character.isLetter(elementId)) throw new ArgsException(INVALID_ARGUMENT_NAME, elementId, null); } private void parseArgumentStrings(List<String> argsList) throws ArgsException { for (currentArgument = argsList.listIterator(); currentArgument.hasNext();) { String argString = currentArgument.next(); if (argString.startsWith("-")) { parseArgumentCharacters(argString.substring(1)); } else { currentArgument.previous(); break; } } } private void parseArgumentCharacters(String argChars) throws ArgsException { for (int i = 0; i < argChars.length(); i++) parseArgumentCharacter(argChars.charAt(i)); } private void parseArgumentCharacter(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) { throw new ArgsException(UNEXPECTED_ARGUMENT, argChar, null); } else { argsFound.add(argChar); try { m.set(currentArgument); } catch (ArgsException e) { e.setErrorArgumentId(argChar); throw e; }

UDANE OCZYSZCZANIE KODU

211

} } public boolean has(char arg) { return argsFound.contains(arg); } public int nextArgument() { return currentArgument.nextIndex(); } public boolean getBoolean(char arg) { return BooleanArgumentMarshaler.getValue(marshalers.get(arg)); } public String getString(char arg) { return StringArgumentMarshaler.getValue(marshalers.get(arg)); } public int getInt(char arg) { return IntegerArgumentMarshaler.getValue(marshalers.get(arg)); } public double getDouble(char arg) { return DoubleArgumentMarshaler.getValue(marshalers.get(arg)); } public String[] getStringArray(char arg) { return StringArrayArgumentMarshaler.getValue(marshalers.get(arg)); } }

Warto zauważyć, że można czytać ten kod od góry do dołu bez skakania po kodzie lub wyszukiwania jakichś elementów. Jedynym elementem, którego trzeba szukać, jest definicja ArgumentMarshaler, którą rozmyślnie pozostawiłem bez zmian. Po uważnym przeczytaniu kodu powinniśmy rozumieć, jakie jest przeznaczenie interfejsu ArgumentMarshaler i klasy, która go implementuje. Kilka z nich przedstawiono poniżej (listingi od 14.3 do 14.6). L I S T I N G 1 4 . 3 . ArgumentMarshaler.java public interface ArgumentMarshaler { void set(Iterator<String> currentArgument) throws ArgsException; }

L I S T I N G 1 4 . 4 . BooleanArgumentMarshaler.java public class BooleanArgumentMarshaler implements ArgumentMarshaler { private boolean booleanValue = false; public void set(Iterator<String> currentArgument) throws ArgsException { booleanValue = true; } public static boolean getValue(ArgumentMarshaler am) { if (am != null && am instanceof BooleanArgumentMarshaler) return ((BooleanArgumentMarshaler) am).booleanValue; else return false; } }

212

ROZDZIAŁ 14.

L I S T I N G 1 4 . 5 . StringArgumentMarshaler.java import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; public class StringArgumentMarshaler implements ArgumentMarshaler { private String stringValue = ""; public void set(Iterator<String> currentArgument) throws ArgsException { try { stringValue = currentArgument.next(); } catch (NoSuchElementException e) { throw new ArgsException(MISSING_STRING); } } public static String getValue(ArgumentMarshaler am) { if (am != null && am instanceof StringArgumentMarshaler) return ((StringArgumentMarshaler) am).stringValue; else return ""; } }

L I S T I N G 1 4 . 6 . IntegerArgumentMarshaler.java import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; public class IntegerArgumentMarshaler implements ArgumentMarshaler { private int intValue = 0; public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); intValue = Integer.parseInt(parameter); } catch (NoSuchElementException e) { throw new ArgsException(MISSING_INTEGER); } catch (NumberFormatException e) { throw new ArgsException(INVALID_INTEGER, parameter); } } public static int getValue(ArgumentMarshaler am) { if (am != null && am instanceof IntegerArgumentMarshaler) return ((IntegerArgumentMarshaler) am).intValue; else return 0; } }

Pozostałe interfejsy dziedziczące po ArgumentMarshaler dla typów double i tablic String po prostu powielają ten wzorzec. Pozostawię je do wykonania jako ćwiczenie. Problematyczny może być jeszcze jeden fragment — definicja stałych kodów błędów. Znajdują się one w klasie ArgsException (listing 14.7).

UDANE OCZYSZCZANIE KODU

213

L I S T I N G 1 4 . 7 . ArgsException.java import static com.objectmentor.utilities.args.ArgsException.ErrorCode.*; public class ArgsException extends Exception { private char errorArgumentId = '\0'; private String errorParameter = null; private ErrorCode errorCode = OK; public ArgsException() {} public ArgsException(String message) {super(message);} public ArgsException(ErrorCode errorCode) { this.errorCode = errorCode; } public ArgsException(ErrorCode errorCode, String errorParameter) { this.errorCode = errorCode; this.errorParameter = errorParameter; } public ArgsException(ErrorCode errorCode, char errorArgumentId, String errorParameter) { this.errorCode = errorCode; this.errorParameter = errorParameter; this.errorArgumentId = errorArgumentId; } public char getErrorArgumentId() { return errorArgumentId; } public void setErrorArgumentId(char errorArgumentId) { this.errorArgumentId = errorArgumentId; } public String getErrorParameter() { return errorParameter; } public void setErrorParameter(String errorParameter) { this.errorParameter = errorParameter; } public ErrorCode getErrorCode() { return errorCode; } public void setErrorCode(ErrorCode errorCode) { this.errorCode = errorCode; } public String errorMessage() { switch (errorCode) { case OK: return "TILT: Niedostępne."; case UNEXPECTED_ARGUMENT: return String.format("Nieoczekiwany argument -%c.", errorArgumentId); case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgumentId); case INVALID_INTEGER:

214

ROZDZIAŁ 14.

return String.format("Argument -%c oczekuje liczby całkowitej, a był '%s'.", errorArgumentId, errorParameter); case MISSING_INTEGER: return String.format("Nie można znaleźć parametru całkowitego dla -%c.", errorArgumentId); case INVALID_DOUBLE: return String.format("Argument -%c oczekuje liczby double, a był '%s'.", errorArgumentId, errorParameter); case MISSING_DOUBLE: return String.format("Nie można znaleźć parametru double dla -%c.", errorArgumentId); case INVALID_ARGUMENT_NAME: return String.format("'%c' nie jest prawidłową nazwą argumentu.", errorArgumentId); case INVALID_ARGUMENT_FORMAT: return String.format("'%s' nie jest prawidłowym formatem argumentu.", errorParameter); } return ""; } public enum ErrorCode { OK, INVALID_ARGUMENT_FORMAT, UNEXPECTED_ARGUMENT, INVALID_ARGUMENT_NAME, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, MISSING_DOUBLE, INVALID_DOUBLE} }

Jak widać, sporo kodu potrzeba do zrealizowania szczegółów tego prostego zagadnienia. Jednym z powodów jest zastosowanie dosyć rozwlekłego języka. Java, język o statycznych typach, wymaga użycia wielu słów w celu usatysfakcjonowania systemu typów. W językach takich jak Ruby, Python lub Smalltalk program ten byłby znacznie mniejszy1. Proszę o ponowne przeczytanie kodu. Szczególną uwagę proponuję zwrócić na sposób nazywania elementów programu, rozmiar funkcji oraz formatowanie kodu. Jeżeli Czytelnik jest doświadczonym programistą, może mieć uwagi do niektórych części stylu i struktury. Jednak można powiedzieć, że jako całość program ten jest ładnie napisany i ma czystą strukturę. Na przykład powinno być oczywiste, w jaki sposób możemy dodać nowy typ argumentu, np. argument daty lub argument liczby zespolonej, a jego dodanie powinno zająć niewiele czasu i wysiłku. Mówiąc krótko, wymagałoby to napisania nowej klasy implementującej ArgumentMarshaler oraz nowej funkcji getXXX i nowego elementu case w funkcji parseSchemaElement. Prawdopodobnie konieczne będzie również dodanie nowego ArgsException.ErrorCode i nowego komunikatu błędu.

Jak to napisałem? Proszę teraz o szczególną uwagę. Nie napisałem tego programu od początku do końca w jego obecnej postaci. Co ważniejsze, nie oczekuję, że ktokolwiek będzie w stanie pisać czyste i eleganckie programy w jednym przebiegu. Jeżeli nauczyliśmy się czegokolwiek w kilku ostatnich dekadach, to przede wszystkim tego, że programowanie jest bardziej rzemiosłem niż sztuką. Aby pisać czysty kod, musimy na początku napisać brudny kod, a następnie go oczyścić. 1

Ostatnio przepisałem ten moduł na Ruby. Miał on około 1/7 wielkości przedstawionego tu modułu i nieco lepszą strukturę.

UDANE OCZYSZCZANIE KODU

215

Nie powinno to być dla nas niespodzianką. Nauczyliśmy się tej prawdy w szkole podstawowej, gdy nasi nauczyciele próbowali (zwykle w męczarniach) nauczyć nas pisania szkiców prac. Uczyli nas procesu, w którym powinniśmy napisać zgrubny szkic, następnie drugi szkic, a potem kilka kolejnych szkiców, aż otrzymamy ostateczną wersję. Próbowali nam w ten sposób pokazać, że pisanie czystych tekstów to długi proces wielu poprawek. Większość młodych programistów (podobnie jak większość absolwentów) nie stosuje się do tej porady. Uważają oni, że ich podstawowym celem jest napisanie działającego programu. Gdy „już działa”, przechodzą do następnego zadania, pozostawiając ten „działający” program w dowolnym stanie, który doprowadził do jego „działania”. Większość doświadczonych programistów wie, że jest to zawodowe samobójstwo.

Args — zgrubny szkic Na listingu 14.8 przedstawiona jest wcześniejsza wersja klasy Args. Ona „działa”. Jest jednak mocno zagmatwana. L I S T I N G 1 4 . 8 . Args.java (pierwszy szkic) import java.text.ParseException; import java.util.*; public class Args { private String schema; private String[] args; private boolean valid = true; private Set unexpectedArguments = new TreeSet (); private Map booleanArgs = new HashMap (); private Map stringArgs = new HashMap (); private Map intArgs = new HashMap (); private Set argsFound = new HashSet (); private int currentArgument; private char errorArgumentId = '\0'; private String errorParameter = "TILT"; private ErrorCode errorCode = ErrorCode.OK; private enum ErrorCode { OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT} public Args(String schema, String[] args) throws ParseException { this.schema = schema; this.args = args; valid = parse(); } private boolean parse() throws ParseException { if (schema.length() == 0 && args.length == 0) return true; parseSchema(); try { parseArguments(); } catch (ArgsException e) { } return valid; }

216

ROZDZIAŁ 14.

private boolean parseSchema() throws ParseException { for (String element : schema.split(",")) { if (element.length() > 0) { String trimmedElement = element.trim(); parseSchemaElement(trimmedElement); } } return true; } private void parseSchemaElement(String element) throws ParseException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (isBooleanSchemaElement(elementTail)) parseBooleanSchemaElement(elementId); else if (isStringSchemaElement(elementTail)) parseStringSchemaElement(elementId); else if (isIntegerSchemaElement(elementTail)) { parseIntegerSchemaElement(elementId); } else { throw new ParseException( String.format("Argument: %c ma niewłaściwy format: %s.", elementId, elementTail), 0); } } private void validateSchemaElementId(char elementId) throws ParseException { if (!Character.isLetter(elementId)) { throw new ParseException( "Zły znak:" + elementId + "w formacie Args: " + schema, 0); } } private void parseBooleanSchemaElement(char elementId) { booleanArgs.put(elementId, false); } private void parseIntegerSchemaElement(char elementId) { intArgs.put(elementId, 0); } private void parseStringSchemaElement(char elementId) { stringArgs.put(elementId, ""); } private boolean isStringSchemaElement(String elementTail) { return elementTail.equals("*"); } private boolean isBooleanSchemaElement(String elementTail) { return elementTail.length() == 0; } private boolean isIntegerSchemaElement(String elementTail) { return elementTail.equals("#"); } private boolean parseArguments() throws ArgsException { for (currentArgument = 0; currentArgument < args.length; currentArgument++) { String arg = args[currentArgument]; parseArgument(arg); }

UDANE OCZYSZCZANIE KODU

217

return true; } private void parseArgument(String arg) throws ArgsException { if (arg.startsWith("-")) parseElements(arg); } private void parseElements(String arg) throws ArgsException { for (int i = 1; i < arg.length(); i++) parseElement(arg.charAt(i)); } private void parseElement(char argChar) throws ArgsException { if (setArgument(argChar)) argsFound.add(argChar); else { unexpectedArguments.add(argChar); errorCode = ErrorCode.UNEXPECTED_ARGUMENT; valid = false; } } private boolean setArgument(char argChar) throws ArgsException { if (isBooleanArg(argChar)) setBooleanArg(argChar, true); else if (isStringArg(argChar)) setStringArg(argChar); else if (isIntArg(argChar)) setIntArg(argChar); else return false; return true; } private boolean isIntArg(char argChar) {return intArgs.containsKey(argChar);} private void setIntArg(char argChar) throws ArgsException { currentArgument++; String parameter = null; try { parameter = args[currentArgument]; intArgs.put(argChar, new Integer(parameter)); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar; errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (NumberFormatException e) { valid = false; errorArgumentId = argChar; errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw new ArgsException(); } } private void setStringArg(char argChar) throws ArgsException { currentArgument++; try { stringArgs.put(argChar, args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar;

218

ROZDZIAŁ 14.

errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } } private boolean isStringArg(char argChar) { return stringArgs.containsKey(argChar); } private void setBooleanArg(char argChar, boolean value) { booleanArgs.put(argChar, value); } private boolean isBooleanArg(char argChar) { return booleanArgs.containsKey(argChar); } public int cardinality() { return argsFound.size(); } public String usage() { if (schema.length() > 0) return "-[" + schema + "]"; else return ""; } public String errorMessage() throws Exception { switch (errorCode) { case OK: throw new Exception("TILT: Niedostępne."); case UNEXPECTED_ARGUMENT: return unexpectedArgumentMessage(); case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgumentId); case INVALID_INTEGER: return String.format("Argument -%c oczekuje liczby całkowitej, a był '%s'.", errorArgumentId, errorParameter); case MISSING_INTEGER: return String.format("Nie można znaleźć parametru całkowitego dla -%c.", errorArgumentId); } return ""; } private String unexpectedArgumentMessage() { StringBuffer message = new StringBuffer("Argument(y) -"); for (char c : unexpectedArguments) { message.append(c); } message.append(" nieoczekiwany."); return message.toString(); } private boolean falseIfNull(Boolean b) { return b != null && b; } private int zeroIfNull(Integer i) { return i == null ? 0 : i; }

UDANE OCZYSZCZANIE KODU

219

private String blankIfNull(String s) { return s == null ? "" : s; } public String getString(char arg) { return blankIfNull(stringArgs.get(arg)); } public int getInt(char arg) { return zeroIfNull(intArgs.get(arg)); } public boolean getBoolean(char arg) { return falseIfNull(booleanArgs.get(arg)); } public boolean has(char arg) { return argsFound.contains(arg); } public boolean isValid() { return valid; } private class ArgsException extends Exception { } }

Mam nadzieję, że początkową reakcją na tę masę kodu było: „Mam nadzieję, że nie zostawi tego w takiej postaci!”. Jeżeli taka była Twoja reakcja, to pamiętaj, jak inne osoby reagują na kod, który pozostawisz w formie zgrubnego szkicu. „Zgrubny szkic” to najłagodniejsze określenie tego typu kodu. Jest to po prostu praca w toku. Ogromna liczba zmiennych instancyjnych jest zniechęcająca. Dziwne napisy, takie jak TILT, obiekty HashSet oraz TreeSet, bloki try-catch-catch jeszcze bardziej pogarszają sprawę. Nie chciałem pisać takiego stosu śmieci. W rzeczywistości starałem się utrzymać rozsądną organizację. Można się o tym przekonać na podstawie wyboru nazw funkcji i zmiennych oraz na podstawie tego, że istnieje zgrubna struktura programu. Jednak jasne jest, że problem mi uciekł. Bałagan stale przyrastał. Wcześniejsze wersje nie wyglądały tak źle. Na listingu 14.9 przedstawiona jest wcześniejsza wersja, w której działały tylko argumenty Boolean. L I S T I N G 1 4 . 9 . Args.java (tylko Boolean) package com.objectmentor.utilities.getopts; import java.util.*; public class Args { private String schema; private String[] args; private boolean valid; private Set unexpectedArguments = new TreeSet (); private Map booleanArgs = new HashMap (); private int numberOfArguments = 0;

220

ROZDZIAŁ 14.

public Args(String schema, String[] args) { this.schema = schema; this.args = args; valid = parse(); } public boolean isValid() { return valid; } private boolean parse() { if (schema.length() == 0 && args.length == 0) return true; parseSchema(); parseArguments(); return unexpectedArguments.size() == 0; } private boolean parseSchema() { for (String element : schema.split(",")) { parseSchemaElement(element); } return true; } private void parseSchemaElement(String element) { if (element.length() == 1) { parseBooleanSchemaElement(element); } } private void parseBooleanSchemaElement(String element) { char c = element.charAt(0); if (Character.isLetter(c)) { booleanArgs.put(c, false); } } private boolean parseArguments() { for (String arg : args) parseArgument(arg); return true; } private void parseArgument(String arg) { if (arg.startsWith("-")) parseElements(arg); } private void parseElements(String arg) { for (int i = 1; i < arg.length(); i++) parseElement(arg.charAt(i)); } private void parseElement(char argChar) { if (isBoolean(argChar)) { numberOfArguments++; setBooleanArg(argChar, true); } else unexpectedArguments.add(argChar); } private void setBooleanArg(char argChar, boolean value) { booleanArgs.put(argChar, value); }

UDANE OCZYSZCZANIE KODU

221

private boolean isBoolean(char argChar) { return booleanArgs.containsKey(argChar); } public int cardinality() { return numberOfArguments; } public String usage() { if (schema.length() > 0) return "-["+schema+"]"; else return ""; } public String errorMessage() { if (unexpectedArguments.size() > 0) { return unexpectedArgumentMessage(); } else return ""; } private String unexpectedArgumentMessage() { StringBuffer message = new StringBuffer("Argument(y) -"); for (char c : unexpectedArguments) { message.append(c); } message.append(" nieoczekiwany."); return message.toString(); } public boolean getBoolean(char arg) { return booleanArgs.get(arg); } }

Choć można w tym kodzie znaleźć wiele miejsc wymagających zmiany, w całości nie wygląda tak źle. Jest zwarty, prosty i łatwy do zrozumienia. Jednak można tu łatwo zauważyć zalążki późniejszej sterty śmieci. Dosyć jasno widać, w jaki sposób rozrósł się późniejszy bałagan. Warto zauważyć, że w późniejszym bałaganie mamy tylko o dwa typy argumentów więcej: String oraz integer. Dodanie tylko dwóch typów miało negatywny wpływ na kod. Coś, co było możliwe do utrzymania, zmieniło się w coś, co byłoby wypełnione błędami. Dodałem tylko dwa typy argumentów. Na początku dodałem argument String, co dało w efekcie następujący kod: L I S T I N G 1 4 . 1 0 . Args.java (Boolean oraz String) package com.objectmentor.utilities.getopts; import java.text.ParseException; import java.util.*; public class Args { private String schema; private String[] args; private boolean valid = true;

222

ROZDZIAŁ 14.

private Set unexpectedArguments = new TreeSet (); private Map booleanArgs = new HashMap (); private Map stringArgs = new HashMap (); private Set argsFound = new HashSet (); private int currentArgument; private char errorArgument = '\0'; enum ErrorCode { OK, MISSING_STRING} private ErrorCode errorCode = ErrorCode.OK; public Args(String schema, String[] args) throws ParseException { this.schema = schema; this.args = args; valid = parse(); } private boolean parse() throws ParseException { if (schema.length() == 0 && args.length == 0) return true; parseSchema(); parseArguments(); return valid; } private boolean parseSchema() throws ParseException { for (String element : schema.split(",")) { if (element.length() > 0) { String trimmedElement = element.trim(); parseSchemaElement(trimmedElement); } } return true; } private void parseSchemaElement(String element) throws ParseException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (isBooleanSchemaElement(elementTail)) parseBooleanSchemaElement(elementId); else if (isStringSchemaElement(elementTail)) parseStringSchemaElement(elementId); } private void validateSchemaElementId(char elementId) throws ParseException { if (!Character.isLetter(elementId)) { throw new ParseException( "Zły znak:" + elementId + "w formacie Args: " + schema, 0); } } private void parseStringSchemaElement(char elementId) { stringArgs.put(elementId, ""); } private boolean isStringSchemaElement(String elementTail) { return elementTail.equals("*"); } private boolean isBooleanSchemaElement(String elementTail) {

UDANE OCZYSZCZANIE KODU

223

return elementTail.length() == 0; } private void parseBooleanSchemaElement(char elementId) { booleanArgs.put(elementId, false); } private boolean parseArguments() { for (currentArgument = 0; currentArgument < args.length; currentArgument++) { String arg = args[currentArgument]; parseArgument(arg); } return true; } private void parseArgument(String arg) { if (arg.startsWith("-")) parseElements(arg); } private void parseElements(String arg) { for (int i = 1; i < arg.length(); i++) parseElement(arg.charAt(i)); } private void parseElement(char argChar) { if (setArgument(argChar)) argsFound.add(argChar); else { unexpectedArguments.add(argChar); valid = false; } } private boolean setArgument(char argChar) { boolean set = true; if (isBoolean(argChar)) setBooleanArg(argChar, true); else if (isString(argChar)) setStringArg(argChar, ""); else set = false; return set; } private void setStringArg(char argChar, String s) { currentArgument++; try { stringArgs.put(argChar, args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgument = argChar; errorCode = ErrorCode.MISSING_STRING; } } private boolean isString(char argChar) { return stringArgs.containsKey(argChar); } private void setBooleanArg(char argChar, boolean value) { booleanArgs.put(argChar, value); }

224

ROZDZIAŁ 14.

private boolean isBoolean(char argChar) { return booleanArgs.containsKey(argChar); } public int cardinality() { return argsFound.size(); } public String usage() { if (schema.length() > 0) return "-[" + schema + "]"; else return ""; } public String errorMessage() throws Exception { if (unexpectedArguments.size() > 0) { return unexpectedArgumentMessage(); } else switch (errorCode) { case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgument); case OK: throw new Exception("TILT: Niedostępne."); } return ""; } private String unexpectedArgumentMessage() { StringBuffer message = new StringBuffer("Argument(y) -"); for (char c : unexpectedArguments) { message.append(c); } message.append(" nieoczekiwany."); return message.toString(); } public boolean getBoolean(char arg) { return falseIfNull(booleanArgs.get(arg)); } private boolean falseIfNull(Boolean b) { return b == null ? false : b; } public String getString(char arg) { return blankIfNull(stringArgs.get(arg)); } private String blankIfNull(String s) { return s == null ? "" : s; } public boolean has(char arg) { return argsFound.contains(arg); } public boolean isValid() { return valid; } }

UDANE OCZYSZCZANIE KODU

225

Jak widać, kod zaczął się wymykać spod kontroli. Nadal nie jest zły, ale jasne jest, że bałagan zaczął narastać. Jest to już stos, ale jeszcze niewypełniony śmieciami. Wystarczyło dodanie obsługi argumentów typu integer, aby stos zaczął ropieć i fermentować.

Zatrzymałem się Miałem do dodania co najmniej dwa kolejne typy argumentów i od razu mogłem stwierdzić, że sprawy będą miały się jeszcze gorzej. Jeżeli bez zastanowienia parłbym naprzód, prawdopodobnie byłbym w stanie doprowadzić ten kod do prawidłowego działania, ale pozostawiając za sobą zbyt duży bałagan, aby można było go łatwo poprawić. Jeżeli struktura tego kodu miała być kiedykolwiek możliwa do utrzymania, był to najwyższy czas, aby ją poprawić. Dlatego wstrzymałem dodawanie funkcji i zacząłem przebudowę. Po dodaniu obsługi argumentów typu String i integer wiedziałem już, że każdy typ argumentu wymaga nowego kodu w trzech głównych miejscach. Po pierwsze, każdy typ argumentu wymaga pewnego sposobu analizy elementów schematu w celu wybrania obiektu HashMap dla danego typu. Następnie każdy typ argumentów musi być pobrany z ciągu wiersza polecenia i skonwertowany na jego właściwy typ. Na koniec każdy typ argumentów wymaga metody getXXX, która zwraca wywołującemu właściwy typ. Wiele różnych typów i wszystkie mają podobne metody — dla mnie to brzmi jak klasa. W ten sposób powstała koncepcja klasy ArgumentMarshaler.

O przyrostowości Jednym z najlepszych sposobów na zrujnowanie programu jest wprowadzenie do jego struktury ogromnych zmian w imię usprawnień. Niektóre programy nigdy nie podnoszą się po takich „usprawnieniach”. Problem wynika z tego, że bardzo trudno uzyskać takie samo działanie, jak przed „usprawnieniami”. Aby tego uniknąć, korzystam z dyscypliny programowania sterowanego testami (TDD). Jedną z podstawowych doktryn tego podejścia jest zachowanie działania systemu przez cały czas. Inaczej mówiąc, przy użyciu TDD nie mogę wprowadzić zmian do systemu, które przerywają jego działanie. Każda wprowadzona zmiana musi zachować poprzednie działanie systemu. Aby to osiągnąć, potrzebuję zbioru testów automatycznych, które mogę uruchomić w celu sprawdzenia, czy działanie systemu nie zmieniło się. Dla klasy Args napisałem zbiór testów jednostkowych i akceptacyjnych już w czasie budowania sterty śmieci. Testy jednostkowe były napisane w języku Java i istrowane przez JUnit. Testy akceptacyjne były napisane jako strony wiki w FitNesse. Mogłem uruchomić te testy w dowolnym momencie i jeżeli wykonywały się prawidłowo, byłem pewny, że system działa w zdefiniowany sposób. Zacząłem więc wprowadzać sporo niewielkich zmian. Każda zmiana przybliżała strukturę systemu w kierunku koncepcji użycia ArgumentMarshaler. Jednak po wprowadzeniu każdej zmiany system stale działał. Pierwszą zmianą, jaką wykonałem, było wstawienie szkieletu ArgumentMarshaller na szczyt sterty śmieci (listing 14.11).

226

ROZDZIAŁ 14.

L I S T I N G 1 4 . 1 1 . ArgumentMarshaller dodany do Args.java private class ArgumentMarshaler { private boolean booleanValue = false; public void setBoolean(boolean value) { booleanValue = value; } public boolean getBoolean() {return booleanValue;} } private class BooleanArgumentMarshaler extends ArgumentMarshaler { } private class StringArgumentMarshaler extends ArgumentMarshaler { } private class IntegerArgumentMarshaler extends ArgumentMarshaler { } }

Jasne jest, że nie spowodowało to powstania żadnego błędu. Następnie wprowadziłem jak najprostszą modyfikację, która nie powinna spowodować dużych usterek w kodzie. Zmieniłem HashMap dla argumentów Boolean, aby przechowywał obiekty ArgumentMarshaler. private Map booleanArgs = new HashMap ();

Spowodowało to błąd w kilku instrukcjach, które szybko poprawiłem. ... private void parseBooleanSchemaElement(char elementId) { booleanArgs.put(elementId, new BooleanArgumentMarshaler()); } ... private void setBooleanArg(char argChar, boolean value) { booleanArgs.get(argChar).setBoolean(value); } ... public boolean getBoolean(char arg) { return falseIfNull(booleanArgs.get(arg).getBoolean()); }

Warto zauważyć, że zmiany te znajdują się dokładnie w tych obszarach, które wcześniej wymieniłem: metody parse, set oraz get dla danego typu argumentu. Niestety, pomimo tak niewielkich zmian niektóre testy przestały działać. Jeżeli spojrzymy uważnie na getBoolean, zauważymy, że jeżeli wywołamy ją z argumentem 'y', a nie będzie argumentu y, to booleanArgs.get('y') zwróci null, a funkcja zgłosi NullPointerException. Funkcja falseIfNull została użyta do ochrony przed taką sytuacją, ale wprowadzona przeze mnie zmiana spowodowała, że funkcja ta przestała być ważna. Przyrostowość wymaga, abym szybko doprowadził do działania kodu, przed wprowadzeniem jakichkolwiek innych zmian. W rzeczywistości poprawka nie była taka trudna. Po prostu przesunąłem kontrolę wartości null. Nie było już wartości boolean będącej null, którą musiałem sprawdzać; był teraz obiekt ArgumentMarshaller.

UDANE OCZYSZCZANIE KODU

227

Po pierwsze, usunąłem falseIfNull, zastępując ją funkcją getBoolean. Była teraz bezużyteczna, więc wyeliminowałem całą funkcję. Testy były przerywane w ten sam sposób, więc byłem pewny, że nie wprowadziłem żadnych nowych błędów. public boolean getBoolean(char arg) { return booleanArgs.get(arg).getBoolean(); }

Następnie podzieliłem funkcję na dwa wiersze i umieściłem ArgumentMarshaler w osobnej zmiennej o nazwie argumentMarshaler. Musiałem zająć się jednak długą nazwą zmiennej; była ona mocno niarowa i zaciemniała funkcję. Skróciłem ją więc do am [N5]. public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = booleanArgs.get(arg); return am.getBoolean(); }

Następnie dodałem kod wykrywania wartości null. public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = booleanArgs.get(arg); return am != null && am.getBoolean(); }

Argumenty typu String Dodanie argumentów String było bardzo podobne do dodawania argumentów boolean. Musiałem zmienić HashMap oraz doprowadzić do prawidłowego działania funkcji parse, set oraz get. Nie powinno tu być żadnych niespodzianek, być może poza umieszczeniem całej implementacji szeregowania w klasie bazowej ArgumentMarshaler zamiast rozproszenia jej w klasach pochodnych. private Map stringArgs = new HashMap (); ... private void parseStringSchemaElement(char elementId) { stringArgs.put(elementId, new StringArgumentMarshaler()); } ... private void setStringArg(char argChar) throws ArgsException { currentArgument++; try { stringArgs.get(argChar).setString(args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar; errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } } ... public String getString(char arg) { Args.ArgumentMarshaler am = stringArgs.get(arg); return am == null ? "" : am.getString(); } ... private class ArgumentMarshaler { private boolean booleanValue = false;

228

ROZDZIAŁ 14.

private String stringValue; public void setBoolean(boolean value) { booleanValue = value; } public boolean getBoolean() { return booleanValue; } public void setString(String s) { stringValue = s; } public String getString() { return stringValue == null ? "" : stringValue; } }

Ponownie zmiany te były wprowadzane jedna po drugiej i w taki sposób, że testy stale działały, choć nie przechodziły. Gdy test nie przechodził, upewniałem się, że przed przejściem do następnej zmiany będzie on przechodził prawidłowo. Teraz moje intencje powinny być już widoczne. Gdy obecne funkcje szeregowania znajdują się w klasie bazowej ArgumentMarshaler, zaczynam przesuwać je do klas pochodnych. Powoduje to, że wszystko działa, przy jednoczesnej stopniowej zmianie kształtu programu. Oczywistym krokiem było przeniesienie funkcji dla argumentu int do ArgumentMarshaler. I tym razem nie było żadnych niespodzianek. private Map intArgs = new HashMap (); ... private void parseIntegerSchemaElement(char elementId) { intArgs.put(elementId, new IntegerArgumentMarshaler()); } ... private void setIntArg(char argChar) throws ArgsException { currentArgument++; String parameter = null; try { parameter = args[currentArgument]; intArgs.get(argChar).setInteger(Integer.parseInt(parameter)); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar; errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (NumberFormatException e) { valid = false; errorArgumentId = argChar; errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw new ArgsException(); } } ... public int getInt(char arg) { Args.ArgumentMarshaler am = intArgs.get(arg); return am == null ? 0 : am.getInteger();

UDANE OCZYSZCZANIE KODU

229

} ... private class ArgumentMarshaler { private boolean booleanValue = false; private String stringValue; private int integerValue; public void setBoolean(boolean value) { booleanValue = value; } public boolean getBoolean() { return booleanValue; } public void setString(String s) { stringValue = s; } public String getString() { return stringValue == null ? "" : stringValue; } public void setInteger(int i) { integerValue = i; } public int getInteger() { return integerValue; } }

Gdy wszystkie funkcje szeregowania znalazły się w ArgumentMarshaler, zacząłem przenosić odpowiednie funkcje do jego klas pochodnych. Pierwszym krokiem było przeniesienie funkcji setBoolean do BooleanArgumentMarshaller i upewnienie się, że jest wywoływana prawidłowo. Utworzyłem więc abstrakcyjną metodę set. private abstract class ArgumentMarshaler { protected boolean booleanValue = false; private String stringValue; private int integerValue; public void setBoolean(boolean value) { booleanValue = value; } public boolean getBoolean() { return booleanValue; } public void setString(String s) { stringValue = s; } public String getString() { return stringValue == null ? "" : stringValue; } public void setInteger(int i) { integerValue = i; }

230

ROZDZIAŁ 14.

public int getInteger() { return integerValue; } public abstract void set(String s); }

Następnie zaimplementowałem metodę set w BooleanArgumentMarshaller. private class BooleanArgumentMarshaler extends ArgumentMarshaler { public void set(String s) { booleanValue = true; } }

Na koniec zastąpiłem wywołanie setBoolean wywołaniem set. private void setBooleanArg(char argChar, boolean value) { booleanArgs.get(argChar).set("true"); }

Testy nadal były wykonywane prawidłowo. Ponieważ zmiana ta spowodowała, że set została przeniesiona do BooleanArgumentMarshaler, usunąłem metodę setBoolean z klasy bazowej ArgumentMarshaler. Należy zwrócić uwagę, że abstrakcyjna funkcja set oczekuje argumentu String, ale implementacja w BooleanArgumentMarshaller nie korzysta z niego. Umieściłem tam ten argument, ponieważ wiedziałem, że StringArgumentMarshaller oraz IntegerArgumentMarshaller będą z niego korzystały. Następnie chciałem przenieść metodę get do BooleanArgumentMarshaler. Przenoszenie funkcji get jest zawsze mało eleganckie, ponieważ zwracanym typem zawsze musi być Object i w tym przypadku jest on rzutowany na Boolean. public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = booleanArgs.get(arg); return am != null && (Boolean)am.get(); }

Aby kod się kompilował, dodałem funkcję get do ArgumentMarshaler. private abstract class ArgumentMarshaler { ... public Object get() { return null; } }

Kod ten kompiluje się i oczywiście nie przechodzi testów. Aby testy znów przechodziły, wystarczyło utworzyć abstrakcyjną metodę get i zaimplementować ją w BooleanAgumentMarshaler. private abstract class ArgumentMarshaler { protected boolean booleanValue = false; ... public abstract Object get(); }

UDANE OCZYSZCZANIE KODU

231

private class BooleanArgumentMarshaler extends ArgumentMarshaler { public void set(String s) { booleanValue = true; } public Object get() { return booleanValue; } }

Kolejny raz testy działają prawidłowo. Tak więc get i set są przeniesione do BooleanArgument Marshaler! Pozwoliło mi to usunąć starą funkcję getBoolean z ArgumentMarshaler, przenieść chronioną zmienną booleanValue do BooleanArgumentMarshaler i zmienić jej widoczność na private. Ten sam szablon zmian zastosowałem dla typu String. Przeniosłem funkcje set i get, usunąłem nieużywane funkcje i przeniosłem zmienne. private void setStringArg(char argChar) throws ArgsException { currentArgument++; try { stringArgs.get(argChar).set(args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar; errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } } ... public String getString(char arg) { Args.ArgumentMarshaler am = stringArgs.get(arg); return am == null ? "" : (String) am.get(); } ... private abstract class ArgumentMarshaler { private int integerValue; public void setInteger(int i) { integerValue = i; } public int getInteger() { return integerValue; } public abstract void set(String s); }

public abstract Object get(); private class BooleanArgumentMarshaler extends ArgumentMarshaler { private boolean booleanValue = false; public void set(String s) { booleanValue = true; } public Object get() { return booleanValue; } }

232

ROZDZIAŁ 14.

private class StringArgumentMarshaler extends ArgumentMarshaler { private String stringValue = ""; public void set(String s) { stringValue = s; } public Object get() { return stringValue; } } private class IntegerArgumentMarshaler extends ArgumentMarshaler { public void set(String s) { } public Object get() { return null; } } }

Na koniec powtórzyłem proces dla argumentów integer. Było to nieco bardziej skomplikowane, ponieważ liczby całkowite muszą być analizowane, a operacja parse może zgłosić wyjątek. Jednak wynik jest lepszy, ponieważ cała obsługa NumberFormatException została umieszczona w IntegerArgumentMarshaler. private boolean isIntArg(char argChar) {return intArgs.containsKey(argChar);} private void setIntArg(char argChar) throws ArgsException { currentArgument++; String parameter = null; try { parameter = args[currentArgument]; intArgs.get(argChar).set(parameter); } catch (ArrayIndexOutOfBoundsException e) { valid = false; errorArgumentId = argChar; errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (ArgsException e) { valid = false; errorArgumentId = argChar; errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw e; } } ... private void setBooleanArg(char argChar) { try { booleanArgs.get(argChar).set("true"); } catch (ArgsException e) { } } ... public int getInt(char arg) { Args.ArgumentMarshaler am = intArgs.get(arg); return am == null ? 0 : (Integer) am.get(); } ... private abstract class ArgumentMarshaler {

UDANE OCZYSZCZANIE KODU

233

public abstract void set(String s) throws ArgsException; public abstract Object get();

} ... private class IntegerArgumentMarshaler extends ArgumentMarshaler { private int intValue = 0; public void set(String s) throws ArgsException { try { intValue = Integer.parseInt(s); } catch (NumberFormatException e) { throw new ArgsException(); } } public Object get() { return intValue; } }

Oczywiście, testy stale były realizowane prawidłowo. Następnie zająłem się usunięciem różnych odwzorowań z algorytmu. Dzięki temu cały system stał się bardziej ogólny. Jednak nie mogłem ich usunąć przez proste skasowanie, ponieważ system przestałby działać. Zamiast tego dodałem nową zmienną Map do klasy ArgumentMarshaler i jedna po drugiej zmieniałem metody, aby korzystały z niej zamiast z oryginalnych zmiennych. public class Args { ... private Map booleanArgs = new HashMap (); private Map stringArgs = new HashMap (); private Map intArgs = new HashMap (); private Map marshalers = new HashMap (); ... private void parseBooleanSchemaElement(char elementId) { ArgumentMarshaler m = new BooleanArgumentMarshaler(); booleanArgs.put(elementId, m); marshalers.put(elementId, m); } private void parseIntegerSchemaElement(char elementId) { ArgumentMarshaler m = new IntegerArgumentMarshaler(); intArgs.put(elementId, m); marshalers.put(elementId, m); } private void parseStringSchemaElement(char elementId) { ArgumentMarshaler m = new StringArgumentMarshaler(); stringArgs.put(elementId, m); marshalers.put(elementId, m); }

Oczywiście, testy nadal były wykonywane prawidłowo. Następnie zmieniłem isBooleanArg z takiej postaci: private boolean isBooleanArg(char argChar) { return booleanArgs.containsKey(argChar); }

234

ROZDZIAŁ 14.

na taką: private boolean isBooleanArg(char argChar) { ArgumentMarshaler m = marshalers.get(argChar); return m instanceof BooleanArgumentMarshaler; }

Testy nadal były wykonywane prawidłowo. Tak więc wprowadziłem tę samą zmianę do isIntArg oraz isStringArg. private boolean isIntArg(char argChar) { ArgumentMarshaler m = marshalers.get(argChar); return m instanceof IntegerArgumentMarshaler; } private boolean isStringArg(char argChar) { ArgumentMarshaler m = marshalers.get(argChar); return m instanceof StringArgumentMarshaler; }

Testy nadal były wykonywane prawidłowo. Dzięki temu wyeliminowałem powielone wywołania marshalers.get: private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (isBooleanArg(m)) setBooleanArg(argChar); else if (isStringArg(m)) setStringArg(argChar); else if (isIntArg(m)) setIntArg(argChar); else return false; }

return true;

private boolean isIntArg(ArgumentMarshaler m) { return m instanceof IntegerArgumentMarshaler; } private boolean isStringArg(ArgumentMarshaler m) { return m instanceof StringArgumentMarshaler; } private boolean isBooleanArg(ArgumentMarshaler m) { return m instanceof BooleanArgumentMarshaler; }

Sprawiło to, że nie było powodu istnienia metod isxxxArgs. Więc wbudowałem je: private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m instanceof BooleanArgumentMarshaler) setBooleanArg(argChar); else if (m instanceof StringArgumentMarshaler) setStringArg(argChar); else if (m instanceof IntegerArgumentMarshaler) setIntArg(argChar); else return false; return true; }

UDANE OCZYSZCZANIE KODU

235

Następnie zacząłem korzystać ze zmiennych marshalers w funkcjach set, usuwając jednocześnie kontenery Map. Zacząłem od argumentów logicznych. private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m instanceof BooleanArgumentMarshaler) setBooleanArg(m); else if (m instanceof StringArgumentMarshaler) setStringArg(argChar); else if (m instanceof IntegerArgumentMarshaler) setIntArg(argChar); else return false; return true; } ... private void setBooleanArg(ArgumentMarshaler m) { try { m.set("true"); // Było: booleanArgs.get(argChar).set("true"); } catch (ArgsException e) { } }

Testy nadal działały prawidłowo, więc to samo zrobiłem z typami String i integer. Pozwoliło mi to zintegrować część nieeleganckiego kodu zarządzania wyjątkami w funkcji setArgument. private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); try { if (m instanceof BooleanArgumentMarshaler) setBooleanArg(m); else if (m instanceof StringArgumentMarshaler) setStringArg(m); else if (m instanceof IntegerArgumentMarshaler) setIntArg(m); else return false; } catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } return true; } private void setIntArg(ArgumentMarshaler m) throws ArgsException { currentArgument++; String parameter = null; try { parameter = args[currentArgument]; m.set(parameter); } catch (ArrayIndexOutOfBoundsException e) { errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (ArgsException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw e; } }

236

ROZDZIAŁ 14.

private void setStringArg(ArgumentMarshaler m) throws ArgsException { currentArgument++; try { m.set(args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } }

Byłem bliski usunięcia starych zmiennych Map. Musiałem jeszcze zmienić funkcję getBoolean z postaci: public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = booleanArgs.get(arg); return am != null && (Boolean) am.get(); }

na taką: public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); boolean b = false; try { b = am != null && (Boolean) am.get(); } catch (ClassCastException e) { b = false; } return b; }

Ta ostatnia zmiana mogła być niespodzianką. Dlaczego nagle zdecydowałem się obsługiwać ClassCastException? Powodem było to, że miałem zestaw testów jednostkowych i osobne testy akceptacyjne w FitNesse. Okazało się, że testy FitNesse sprawdzają, iż gdy wywołamy getBoolean na argumencie innym niż logiczny, otrzymamy wartość false. Testy jednostkowe tego nie robiły. Do tego momentu uruchamiałem wyłącznie testy jednostkowe2. Ta ostatnia zmiana pozwoliła mi wyodrębnić ostatnie zastosowanie mapy boolean: private void parseBooleanSchemaElement(char elementId) { ArgumentMarshaler m = new BooleanArgumentMarshaler();

booleanArgs.put(elementId, m); marshalers.put(elementId, m); }

Teraz mogłem usunąć zmienną Map dla typu boolean. public class Args { ...

private Map booleanArgs = new HashMap (); private Map stringArgs = new HashMap (); private Map intArgs = new HashMap (); 2

Aby zapobiec tego typu niespodziankom, dodałem nowy test jednostkowy wywołujący wszystkie testy FitNesse.

UDANE OCZYSZCZANIE KODU

237

private Map marshalers = new HashMap (); ...

Następnie przeniosłem argumenty String i integer w ten sam sposób i nieco wyczyściłem kod obsługi argumentów logicznych. private void parseBooleanSchemaElement(char elementId) { marshalers.put(elementId, new BooleanArgumentMarshaler()); } private void parseIntegerSchemaElement(char elementId) { marshalers.put(elementId, new IntegerArgumentMarshaler()); } private void parseStringSchemaElement(char elementId) { marshalers.put(elementId, new StringArgumentMarshaler()); } ... public String getString(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? "" : (String) am.get(); } catch (ClassCastException e) { return ""; } } public int getInt(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? 0 : (Integer) am.get(); } catch (Exception e) { return 0; } } ... public class Args { ... private Map stringArgs = new HashMap (); private Map intArgs = new HashMap (); private Map marshalers = new HashMap (); ...

Wbudowałem trzy metody parse, ponieważ nie realizowały już zbyt wielu operacji: private void parseSchemaElement(String element) throws ParseException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (isBooleanSchemaElement(elementTail)) marshalers.put(elementId, new BooleanArgumentMarshaler()); else if (isStringSchemaElement(elementTail)) marshalers.put(elementId, new StringArgumentMarshaler()); else if (isIntegerSchemaElement(elementTail)) { marshalers.put(elementId, new IntegerArgumentMarshaler()); } else { throw new ParseException(String.format( "Argument: %c ma niewłaściwy format: %s.", elementId, elementTail), 0); } }

238

ROZDZIAŁ 14.

Spójrzmy teraz, jak wygląda to w całości. Na listingu 14.12 przedstawiona jest bieżąca postać klasy Args. L I S T I N G 1 4 . 1 2 . Args.java (po pierwszej przebudowie) package com.objectmentor.utilities.getopts; import java.text.ParseException; import java.util.*; public class Args { private String schema; private String[] args; private boolean valid = true; private Set unexpectedArguments = new TreeSet (); private Map marshalers = new HashMap (); private Set argsFound = new HashSet (); private int currentArgument; private char errorArgumentId = '\0'; private String errorParameter = "TILT"; private ErrorCode errorCode = ErrorCode.OK; private enum ErrorCode { OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT} public Args(String schema, String[] args) throws ParseException { this.schema = schema; this.args = args; valid = parse(); } private boolean parse() throws ParseException { if (schema.length() == 0 && args.length == 0) return true; parseSchema(); try { parseArguments(); } catch (ArgsException e) { } return valid; } private boolean parseSchema() throws ParseException { for (String element : schema.split(",")) { if (element.length() > 0) { String trimmedElement = element.trim(); parseSchemaElement(trimmedElement); } } return true; } private void parseSchemaElement(String element) throws ParseException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (isBooleanSchemaElement(elementTail)) marshalers.put(elementId, new BooleanArgumentMarshaler()); else if (isStringSchemaElement(elementTail)) marshalers.put(elementId, new StringArgumentMarshaler()); else if (isIntegerSchemaElement(elementTail)) { marshalers.put(elementId, new IntegerArgumentMarshaler()); } else {

UDANE OCZYSZCZANIE KODU

239

throw new ParseException(String.format( "Argument: %c ma niewłaściwy format: %s.", elementId, elementTail), 0); } } private void validateSchemaElementId(char elementId) throws ParseException { if (!Character.isLetter(elementId)) { throw new ParseException( "Zły znak:" + elementId + "w formacie Args: " + schema, 0); } } private boolean isStringSchemaElement(String elementTail) { return elementTail.equals("*"); } private boolean isBooleanSchemaElement(String elementTail) { return elementTail.length() == 0; } private boolean isIntegerSchemaElement(String elementTail) { return elementTail.equals("#"); } private boolean parseArguments() throws ArgsException { for (currentArgument=0; currentArgument<args.length; currentArgument++) { String arg = args[currentArgument]; parseArgument(arg); } return true; } private void parseArgument(String arg) throws ArgsException { if (arg.startsWith("-")) parseElements(arg); } private void parseElements(String arg) throws ArgsException { for (int i = 1; i < arg.length(); i++) parseElement(arg.charAt(i)); } private void parseElement(char argChar) throws ArgsException { if (setArgument(argChar)) argsFound.add(argChar); else { unexpectedArguments.add(argChar); errorCode = ErrorCode.UNEXPECTED_ARGUMENT; valid = false; } } private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); try { if (m instanceof BooleanArgumentMarshaler) setBooleanArg(m); else if (m instanceof StringArgumentMarshaler) setStringArg(m); else if (m instanceof IntegerArgumentMarshaler) setIntArg(m); else return false; } catch (ArgsException e) {

240

ROZDZIAŁ 14.

valid = false; errorArgumentId = argChar; throw e;

}

} return true;

private void setIntArg(ArgumentMarshaler m) throws ArgsException { currentArgument++; String parameter = null; try { parameter = args[currentArgument]; m.set(parameter); } catch (ArrayIndexOutOfBoundsException e) { errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (ArgsException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw e; } } private void setStringArg(ArgumentMarshaler m) throws ArgsException { currentArgument++; try { m.set(args[currentArgument]); } catch (ArrayIndexOutOfBoundsException e) { errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } } private void setBooleanArg(ArgumentMarshaler m) { try { m.set("true"); } catch (ArgsException e) { } } public int cardinality() { return argsFound.size(); } public String usage() { if (schema.length() > 0) return "-[" + schema + "]"; else return ""; } public String errorMessage() throws Exception { switch (errorCode) { case OK: throw new Exception("TILT: Niedostępne."); case UNEXPECTED_ARGUMENT: return unexpectedArgumentMessage(); case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgumentId); case INVALID_INTEGER: return String.format("Argument -%c oczekuje liczby całkowitej, a był '%s'.", errorArgumentId, errorParameter); case MISSING_INTEGER:

UDANE OCZYSZCZANIE KODU

241

return String.format("Nie można znaleźć parametru całkowitego dla -%c.", errorArgumentId);

}

} return "";

private String unexpectedArgumentMessage() { StringBuffer message = new StringBuffer("Argument(y) -"); for (char c : unexpectedArguments) { message.append(c); } message.append(" nieoczekiwany."); return message.toString(); } public boolean getBoolean(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); boolean b = false; try { b = am != null && (Boolean) am.get(); } catch (ClassCastException e) { b = false; } return b; } public String getString(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? "" : (String) am.get(); } catch (ClassCastException e) { return ""; } } public int getInt(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? 0 : (Integer) am.get(); } catch (Exception e) { return 0; } } public boolean has(char arg) { return argsFound.contains(arg); } public boolean isValid() { return valid; } private class ArgsException extends Exception { } private abstract class ArgumentMarshaler { public abstract void set(String s) throws ArgsException; public abstract Object get(); } private class BooleanArgumentMarshaler extends ArgumentMarshaler { private boolean booleanValue = false; public void set(String s) { booleanValue = true; }

242

ROZDZIAŁ 14.

public Object get() { return booleanValue; } } private class StringArgumentMarshaler extends ArgumentMarshaler { private String stringValue = ""; public void set(String s) { stringValue = s; } public Object get() { return stringValue; } } private class IntegerArgumentMarshaler extends ArgumentMarshaler { private int intValue = 0; public void set(String s) throws ArgsException { try { intValue = Integer.parseInt(s); } catch (NumberFormatException e) { throw new ArgsException(); } } public Object get() { return intValue; } } }

Po tak dużej ilości pracy efekt trochę rozczarowuje. Struktura jest nieco lepsza, ale nadal mamy te wszystkie zmienne na górze, nadal w setArgument znajduje się okropna konstrukcja case, a wszystkie funkcje set są naprawdę brzydkie. Nie wspominam tu nawet o przetwarzaniu błędów. Przed nami wciąż sporo pracy. Naprawdę chciałem usunąć instrukcje case zależne od typu z setArgument [G23]. Chciałbym, aby setArgument był jedynym wywołaniem ArgumentMarshaler.set. Oznacza to, że powinienem przenieść setIntArg, setStringArg oraz setBooleanArg do odpowiednich klas dziedziczących po ArgumentMarshaler. Ale wtedy pojawił się problem. Jeżeli spojrzymy na setIntArg, okaże się, że korzysta z dwóch zmiennych instancyjnych: args oraz currentArg. Aby przenieść setIntArg do BooleanArgumentMarshaler, musiałbym przekazywać zarówno args, jak i currentArgs jako argumenty funkcji. Jest to nieeleganckie rozwiązanie [F1]. Wolę przekazywać jeden argument zamiast dwóch. Na szczęście istnieje proste rozwiązanie. Możemy skonwertować tablicę args na list i przekazać do funkcji set jej Iterator. Poniższy kod wykonuje dziesięć kroków, pozwalających na spełnienie testu po teście. Zamieszczę tu tylko ostateczny wynik. Czytelnik powinien zorientować się, jakie były poszczególne małe kroki. public class Args { private String schema;

private String[] args; private boolean valid = true; private Set unexpectedArguments = new TreeSet ();

UDANE OCZYSZCZANIE KODU

243

private Map marshalers = new HashMap (); private Set argsFound = new HashSet (); private Iterator<String> currentArgument; private char errorArgumentId = '\0'; private String errorParameter = "TILT"; private ErrorCode errorCode = ErrorCode.OK; private List<String> argsList; private enum ErrorCode { OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT} public Args(String schema, String[] args) throws ParseException { this.schema = schema; argsList = Arrays.asList(args); valid = parse(); } private boolean parse() throws ParseException { if (schema.length() == 0 && argsList.size() == 0) return true; parseSchema(); try { parseArguments(); } catch (ArgsException e) { } return valid; } --private boolean parseArguments() throws ArgsException { for (currentArgument = argsList.iterator(); currentArgument.hasNext();) { String arg = currentArgument.next(); parseArgument(arg); } return true; } --private void setIntArg(ArgumentMarshaler m) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); m.set(parameter); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (ArgsException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw e; } } private void setStringArg(ArgumentMarshaler m) throws ArgsException { try { m.set(currentArgument.next()); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } }

244

ROZDZIAŁ 14.

Były to proste zmiany, dzięki którym testy nadal działały. Teraz zacząłem przenosić funkcje set do odpowiednich klas podrzędnych. Na początek konieczne było wprowadzenie następującej zmiany w setArgument: private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { if (m instanceof BooleanArgumentMarshaler) setBooleanArg(m); else if (m instanceof StringArgumentMarshaler) setStringArg(m); else if (m instanceof IntegerArgumentMarshaler) setIntArg(m);

else return false;

}

} catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } return true;

Zmiana ta była istotna, ponieważ zamierzałem całkowicie wyeliminować łańcuch if-else. Dlatego chciałem wyodrębnić z niego kontrolę błędu. Teraz możemy rozpocząć przenoszenie funkcji set. Funkcja setBooleanArg jest najprostsza, więc zaczniemy od niej. Naszym celem jest zmiana setBooleanArg na zwykłe przekazanie wywołania do BooleanArgumentMarshaler. private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { if (m instanceof BooleanArgumentMarshaler) setBooleanArg(m, currentArgument); else if (m instanceof StringArgumentMarshaler) setStringArg(m); else if (m instanceof IntegerArgumentMarshaler) setIntArg(m); } catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } return true; } --private void setBooleanArg(ArgumentMarshaler m, Iterator<String> currentArgument) throws ArgsException {

try { m.set("true");

catch (ArgsException e) { } }

UDANE OCZYSZCZANIE KODU

245

Czy nie dodawaliśmy wcześniej tego przetwarzania wyjątku? Dodawanie elementów, aby je później usunąć, jest dosyć częste w procesie przebudowywania. Wykonywanie niewielkich kroków oraz konieczność zachowania działania testów powodują, że często przesuwa się fragmenty kodu. Przebudowa podobna jest do układania kostki Rubika. Do osiągnięcia większego celu używa się wielu małych kroków. Każdy krok pozwala na następny. Dlaczego przekazywaliśmy iterator, gdy setBooleanArg wcale go nie potrzebuje? Ponieważ setIntArg oraz setStringArg będą go potrzebowały! Oprócz tego, ponieważ chciałem uruchamiać te funkcje przez metodę abstrakcyjną w ArgumentMarshaler, musiałem przekazać ją do setBooleanArg. Obecnie setBooleanArg jest bezużyteczna. Jeżeli mielibyśmy funkcję set w ArgumentMarshaler, moglibyśmy wywoływać ją bezpośrednio. Czas więc napisać tę funkcję! Pierwszym krokiem jest napisanie nowej metody abstrakcyjnej w ArgumentMarshaler. private abstract class ArgumentMarshaler { public abstract void set(Iterator<String> currentArgument) throws ArgsException; public abstract void set(String s) throws ArgsException; public abstract Object get(); }

Oczywiście, spowoduje to, że wszystkie klasy pochodne przestaną działać. Dlatego konieczne będzie dodanie w każdej z nich nowej metody. private class BooleanArgumentMarshaler extends ArgumentMarshaler { private boolean booleanValue = false; public void set(Iterator<String> currentArgument) throws ArgsException { booleanValue = true; } public void set(String s) {

booleanValue = true; } public Object get() { return booleanValue; } } private class StringArgumentMarshaler extends ArgumentMarshaler { private String stringValue = ""; public void set(Iterator<String> currentArgument) throws ArgsException { } public void set(String s) { stringValue = s; } public Object get() { return stringValue; } } private class IntegerArgumentMarshaler extends ArgumentMarshaler { private int intValue = 0;

246

ROZDZIAŁ 14.

public void set(Iterator<String> currentArgument) throws ArgsException { }

}

}

public void set(String s) throws ArgsException { try { intValue = Integer.parseInt(s); } catch (NumberFormatException e) { throw new ArgsException(); } public Object get() { return intValue; }

Teraz możemy wyeliminować setBooleanArg! private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { if (m instanceof BooleanArgumentMarshaler) m.set(currentArgument); else if (m instanceof StringArgumentMarshaler) setStringArg(m); else if (m instanceof IntegerArgumentMarshaler) setIntArg(m); } catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } return true; }

Wszystkie testy wykonują się prawidłowo, a funkcja set została przeniesiona do BooleanArgument Marshaler! Teraz możemy wykonać to samo dla typu String i integer. private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { if (m instanceof BooleanArgumentMarshaler) m.set(currentArgument); else if (m instanceof StringArgumentMarshaler) m.set(currentArgument); else if (m instanceof IntegerArgumentMarshaler) m.set(currentArgument); } catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } return true; } --private class StringArgumentMarshaler extends ArgumentMarshaler { private String stringValue = ""; public void set(Iterator<String> currentArgument) throws ArgsException {

UDANE OCZYSZCZANIE KODU

247

try { stringValue = currentArgument.next(); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_STRING; throw new ArgsException(); } } public void set(String s) { } public Object get() { return stringValue; } } private class IntegerArgumentMarshaler extends ArgumentMarshaler { private int intValue = 0; public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); set(parameter); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (ArgsException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw e; } } public void set(String s) throws ArgsException { try { intValue = Integer.parseInt(s); } catch (NumberFormatException e) { throw new ArgsException(); } } public Object get() { return intValue; } }

I teraz coup de grace — wybór w zależności od typu może być usunięty! Touché! private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { m.set(currentArgument); return true; } catch (ArgsException e) { valid = false; errorArgumentId = argChar; throw e; } }

248

ROZDZIAŁ 14.

Możemy już usunąć część niepotrzebnych funkcji w IntegerArgumentMarshaler i nieco posprzątać. private class IntegerArgumentMarshaler extends ArgumentMarshaler { private int intValue = 0 public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); intValue = Integer.parseInt(parameter); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (NumberFormatException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_INTEGER; throw new ArgsException(); } } public Object get() { return intValue; } }

Możemy również przekształcić ArgumentMarshaler w interfejs. private interface ArgumentMarshaler { void set(Iterator<String> currentArgument) throws ArgsException; Object get(); }

Teraz zobaczymy, jak łatwo można dodać nowy typ argumentu do naszej struktury. Powinno to wymagać niewielu zmian, które to zmiany powinny być izolowane. Na początek zacznijmy od dodania nowego przypadku testowego, który sprawdza, czy argument double działa prawidłowo. public void testSimpleDoublePresent() throws Exception { Args args = new Args("x##", new String[] {"-x","42.3"}); assertTrue(args.isValid()); assertEquals(1, args.cardinality()); assertTrue(args.has('x')); assertEquals(42.3, args.getDouble('x'), .001); }

Teraz wyczyścimy kod analizy schematu i dodamy operację wykrywania ## dla argumentów typu double. private void parseSchemaElement(String element) throws ParseException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (elementTail.length() == 0) marshalers.put(elementId, new BooleanArgumentMarshaler()); else if (elementTail.equals("*")) marshalers.put(elementId, new StringArgumentMarshaler()); else if (elementTail.equals("#")) marshalers.put(elementId, new IntegerArgumentMarshaler()); else if (elementTail.equals("##")) marshalers.put(elementId, new DoubleArgumentMarshaler()); else

UDANE OCZYSZCZANIE KODU

249

throw new ParseException(String.format( "Argument: %c ma niewłaściwy format: %s.", elementId, elementTail), 0); }

Następnie napiszemy klasę DoubleArgumentMarshaler. private class DoubleArgumentMarshaler implements ArgumentMarshaler { private double doubleValue = 0; public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); doubleValue = Double.parseDouble(parameter); } catch (NoSuchElementException e) { errorCode = ErrorCode.MISSING_DOUBLE; throw new ArgsException(); } catch (NumberFormatException e) { errorParameter = parameter; errorCode = ErrorCode.INVALID_DOUBLE; throw new ArgsException(); } } public Object get() { return doubleValue; } }

Wymusza to na nas dodanie nowej wartości ErrorCode. private enum ErrorCode { OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT, MISSING_DOUBLE, INVALID_DOUBLE}

Potrzebujemy również funkcji getDouble. public double getDouble(char arg) { Args.ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? 0 : (Double) am.get(); } catch (Exception e) { return 0.0; } }

Wszystkie testy są wykonywane prawidłowo! Poszło całkiem bezboleśnie. Teraz możemy się upewnić, że kod przetwarzania błędów działa prawidłowo. Następny przypadek testowy kontroluje, czy zostanie zadeklarowany błąd, jeżeli do argumentu ## zostanie przekazany ciąg niedający się zanalizować. public void testInvalidDouble() throws Exception { Args args = new Args("x##", new String[] {"-x","Czterdzieści dwa"}); assertFalse(args.isValid()); assertEquals(0, args.cardinality()); assertFalse(args.has('x')); assertEquals(0, args.getInt('x')); assertEquals("Argument -x oczekuje wartości double, a było 'Czterdzieści dwa'.", args.errorMessage()); } ---

250

ROZDZIAŁ 14.

public String errorMessage() throws Exception { switch (errorCode) { case OK: throw new Exception("TILT: Niedostępne."); case UNEXPECTED_ARGUMENT: return unexpectedArgumentMessage(); case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgumentId); case INVALID_INTEGER: return String.format("Argument -%c oczekuje liczby całkowitej, a był '%s'.", errorArgumentId, errorParameter); case MISSING_INTEGER: return String.format("Nie można znaleźć parametru całkowitego dla -%c.", errorArgumentId); case INVALID_DOUBLE: return String.format("Argument -%c oczekuje liczby double, a był '%s'.", errorArgumentId, errorParameter); case MISSING_DOUBLE: return String.format("Nie można znaleźć parametru double dla -%c.", errorArgumentId); } return ""; }

Wszystkie testy są wykonywane prawidłowo! Następny test sprawdza, czy prawidłowo wykrywamy brakujący argument double. public void testMissingDouble() throws Exception { Args args = new Args("x##", new String[]{"-x"}); assertFalse(args.isValid()); assertEquals(0, args.cardinality()); assertFalse(args.has('x')); assertEquals(0.0, args.getDouble('x'), 0.01); assertEquals("Nie można znaleźć parametru double dla -x.", args.errorMessage()); }

Ten również działa, jak oczekiwaliśmy. Napisaliśmy go tylko dla zachowania kompletności kodu. Kod wyjątków jest dosyć brzydki i nie należy naprawdę do klasy Args. Zgłaszamy również ParseException, który na pewno nie należy do nas. Połączymy więc wszystkie wyjątki w jedną klasę ArgsException i przeniesiemy ją do osobnego modułu. public class ArgsException extends Exception { private char errorArgumentId = '\0'; private String errorParameter = "TILT"; private ErrorCode errorCode = ErrorCode.OK; public ArgsException() {} public ArgsException(String message) {super(message);} public enum ErrorCode { OK, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, UNEXPECTED_ARGUMENT, MISSING_DOUBLE, INVALID_DOUBLE} } --public class Args { ... private char errorArgumentId = '\0';

UDANE OCZYSZCZANIE KODU

251

private String errorParameter = "TILT"; private ArgsException.ErrorCode errorCode = ArgsException.ErrorCode.OK; private List<String> argsList; public Args(String schema, String[] args) throws ArgsException { this.schema = schema; argsList = Arrays.asList(args); valid = parse(); } private boolean parse() throws ArgsException { if (schema.length() == 0 && argsList.size() == 0) return true; parseSchema(); try { parseArguments(); } catch (ArgsException e) { } return valid; } private boolean parseSchema() throws ArgsException { ... } private void parseSchemaElement(String element) throws ArgsException { ... else throw new ArgsException( String.format("Argument: %c ma niewłaściwy format: %s.", elementId,elementTail)); } private void validateSchemaElementId(char elementId) throws ArgsException { if (!Character.isLetter(elementId)) { throw new ArgsException( "Zły znak:" + elementId + "w formacie Args: " + schema); } } ... private void parseElement(char argChar) throws ArgsException { if (setArgument(argChar)) argsFound.add(argChar); else { unexpectedArguments.add(argChar); errorCode = ArgsException.ErrorCode.UNEXPECTED_ARGUMENT; valid = false; } } ... private class StringArgumentMarshaler implements ArgumentMarshaler { private String stringValue = ""; public void set(Iterator<String> currentArgument) throws ArgsException { try { stringValue = currentArgument.next(); } catch (NoSuchElementException e) { errorCode = ArgsException.ErrorCode.MISSING_STRING; throw new ArgsException();

252

ROZDZIAŁ 14.

} } public Object get() { return stringValue; } } private class IntegerArgumentMarshaler implements ArgumentMarshaler { private int intValue = 0; public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); intValue = Integer.parseInt(parameter); } catch (NoSuchElementException e) { errorCode = ArgsException.ErrorCode.MISSING_INTEGER; throw new ArgsException(); } catch (NumberFormatException e) { errorParameter = parameter; errorCode = ArgsException.ErrorCode.INVALID_INTEGER; throw new ArgsException(); } } public Object get() { return intValue; } } private class DoubleArgumentMarshaler implements ArgumentMarshaler { private double doubleValue = 0; public void set(Iterator<String> currentArgument) throws ArgsException { String parameter = null; try { parameter = currentArgument.next(); doubleValue = Double.parseDouble(parameter); } catch (NoSuchElementException e) { errorCode = ArgsException.ErrorCode.MISSING_DOUBLE; throw new ArgsException(); } catch (NumberFormatException e) { errorParameter = parameter; errorCode = ArgsException.ErrorCode.INVALID_DOUBLE; throw new ArgsException(); } } public Object get() { return doubleValue; } } }

Teraz jest ładnie. Jedynym wyjątkiem zgłaszanym przez Args jest ArgsException. Przeniesienie ArgsException do osobnego modułu spowodowało, że możemy przenieść wiele dodatkowego kodu obsługi błędów do tego modułu, osobnego względem modułu Args. Zapewnia on naturalne i oczywiste miejsce na umieszczenie całego tego kodu i naprawdę pomaga wyczyścić moduł Args.

UDANE OCZYSZCZANIE KODU

253

Dzięki temu wyjątki i kod obsługi błędów pozostają całkowicie oddzielone od modułu Args (patrz listingi 14.13 do 14.16). Zostało to osiągnięte w serii 30 małych kroków, pomiędzy którymi testy stale były wykonywane prawidłowo. L I S T I N G 1 4 . 1 3 . ArgsTest.java package com.objectmentor.utilities.args; import junit.framework.TestCase; public class ArgsTest extends TestCase { public void testCreateWithNoSchemaOrArguments() throws Exception { Args args = new Args("", new String[0]); assertEquals(0, args.cardinality()); } public void testWithNoSchemaButWithOneArgument() throws Exception { try { new Args("", new String[]{"-x"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.UNEXPECTED_ARGUMENT, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); } } public void testWithNoSchemaButWithMultipleArguments() throws Exception { try { new Args("", new String[]{"-x", "-y"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.UNEXPECTED_ARGUMENT, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); } } public void testNonLetterSchema() throws Exception { try { new Args("*", new String[]{}); fail("Konstruktor Args powinien zgłosić wyjątek"); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.INVALID_ARGUMENT_NAME, e.getErrorCode()); assertEquals('*', e.getErrorArgumentId()); } } public void testInvalidArgumentFormat() throws Exception { try { new Args("f~", new String[]{}); fail("Konstruktor Args powinien zgłosić wyjątek"); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.INVALID_FORMAT, e.getErrorCode()); assertEquals('f', e.getErrorArgumentId()); } } public void testSimpleBooleanPresent() throws Exception { Args args = new Args("x", new String[]{"-x"}); assertEquals(1, args.cardinality());

254

ROZDZIAŁ 14.

assertEquals(true, args.getBoolean('x')); } public void testSimpleStringPresent() throws Exception { Args args = new Args("x*", new String[]{"-x", "param"}); assertEquals(1, args.cardinality()); assertTrue(args.has('x')); assertEquals("param", args.getString('x')); } public void testMissingStringArgument() throws Exception { try { new Args("x*", new String[]{"-x"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.MISSING_STRING, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); } } public void testSpacesInFormat() throws Exception { Args args = new Args("x, y", new String[]{"-xy"}); assertEquals(2, args.cardinality()); assertTrue(args.has('x')); assertTrue(args.has('y')); } public void testSimpleIntPresent() throws Exception { Args args = new Args("x#", new String[]{"-x", "42"}); assertEquals(1, args.cardinality()); assertTrue(args.has('x')); assertEquals(42, args.getInt('x')); } public void testInvalidInteger() throws Exception { try { new Args("x#", new String[]{"-x", "Czterdzieści dwa"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.INVALID_INTEGER, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); assertEquals("Czterdzieści dwa", e.getErrorParameter()); } } public void testMissingInteger() throws Exception { try { new Args("x#", new String[]{"-x"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.MISSING_INTEGER, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); } } public void testSimpleDoublePresent() throws Exception { Args args = new Args("x##", new String[]{"-x", "42.3"}); assertEquals(1, args.cardinality()); assertTrue(args.has('x')); assertEquals(42.3, args.getDouble('x'), .001); } public void testInvalidDouble() throws Exception { try {

UDANE OCZYSZCZANIE KODU

255

new Args("x##", new String[]{"-x", "Czterdzieści dwa"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.INVALID_DOUBLE, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); assertEquals("Czterdzieści dwa", e.getErrorParameter()); } } public void testMissingDouble() throws Exception { try { new Args("x##", new String[]{"-x"}); fail(); } catch (ArgsException e) { assertEquals(ArgsException.ErrorCode.MISSING_DOUBLE, e.getErrorCode()); assertEquals('x', e.getErrorArgumentId()); } } }

L I S T I N G 1 4 . 1 4 . ArgsExceptionTest.java public class ArgsExceptionTest extends TestCase { public void testUnexpectedMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.UNEXPECTED_ARGUMENT, 'x', null); assertEquals("Argument -x nieoczekiwany.", e.errorMessage()); } public void testMissingStringMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.MISSING_STRING, 'x', null); assertEquals("Nie można znaleźć parametru znakowego dla -x.", e.errorMessage()); } public void testInvalidIntegerMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.INVALID_INTEGER, 'x', "Czterdzieści dwa"); assertEquals("Argument -x oczekuje liczby całkowitej 'Czterdzieści dwa'.", e.errorMessage()); } public void testMissingIntegerMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.MISSING_INTEGER, 'x', null); assertEquals("Nie można znaleźć parametru całkowitego dla -x.", e.errorMessage()); } public void testInvalidDoubleMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.INVALID_DOUBLE, 'x', "Czterdzieści dwa"); assertEquals("Argument -x oczekuje liczby double, a był 'Czterdzieści dwa'.", e.errorMessage()); } public void testMissingDoubleMessage() throws Exception { ArgsException e = new ArgsException(ArgsException.ErrorCode.MISSING_DOUBLE, 'x', null); assertEquals("Nie można znaleźć parametru double dla -x.", e.errorMessage()); } }

256

ROZDZIAŁ 14.

L I S T I N G 1 4 . 1 5 . ArgsException.java public class ArgsException extends Exception { private char errorArgumentId = '\0'; private String errorParameter = "TILT"; private ErrorCode errorCode = ErrorCode.OK; public ArgsException() {} public ArgsException(String message) {super(message);} public ArgsException(ErrorCode errorCode) { this.errorCode = errorCode; } public ArgsException(ErrorCode errorCode, String errorParameter) { this.errorCode = errorCode; this.errorParameter = errorParameter; } public ArgsException(ErrorCode errorCode, char errorArgumentId, String errorParameter) { this.errorCode = errorCode; this.errorParameter = errorParameter; this.errorArgumentId = errorArgumentId; } public char getErrorArgumentId() { return errorArgumentId; } public void setErrorArgumentId(char errorArgumentId) { this.errorArgumentId = errorArgumentId; } public String getErrorParameter() { return errorParameter; } public void setErrorParameter(String errorParameter) { this.errorParameter = errorParameter; } public ErrorCode getErrorCode() { return errorCode; } public void setErrorCode(ErrorCode errorCode) { this.errorCode = errorCode; } public String errorMessage() throws Exception { switch (errorCode) { case OK: throw new Exception("TILT: Niedostępne."); case UNEXPECTED_ARGUMENT: return String.format("Nieoczekiwany argument -%c.", errorArgumentId); case MISSING_STRING: return String.format("Nie można znaleźć parametru znakowego dla -%c.", errorArgumentId); case INVALID_INTEGER: return String.format("Argument -%c oczekuje liczby całkowitej, a był '%s'.", errorArgumentId, errorParameter); case MISSING_INTEGER:

UDANE OCZYSZCZANIE KODU

257

return String.format("Nie można znaleźć parametru całkowitego dla -%c.", errorArgumentId); case INVALID_DOUBLE: return String.format("Argument -%c oczekuje liczby double, a był '%s'.", errorArgumentId, errorParameter); case MISSING_DOUBLE: return String.format("Nie można znaleźć parametru double dla -%c.", errorArgumentId); } return ""; } public enum ErrorCode { OK, INVALID_FORMAT, UNEXPECTED_ARGUMENT, INVALID_ARGUMENT_NAME, MISSING_STRING, MISSING_INTEGER, INVALID_INTEGER, MISSING_DOUBLE, INVALID_DOUBLE} }

L I S T I N G 1 4 . 1 6 . Args.java public class Args { private String schema; private Map marshalers = new HashMap (); private Set argsFound = new HashSet (); private Iterator<String> currentArgument; private List<String> argsList; public Args(String schema, String[] args) throws ArgsException { this.schema = schema; argsList = Arrays.asList(args); parse(); } private void parse() throws ArgsException { parseSchema(); parseArguments(); } private boolean parseSchema() throws ArgsException { for (String element : schema.split(",")) { if (element.length() > 0) { parseSchemaElement(element.trim()); } } return true; } private void parseSchemaElement(String element) throws ArgsException { char elementId = element.charAt(0); String elementTail = element.substring(1); validateSchemaElementId(elementId); if (elementTail.length() == 0) marshalers.put(elementId, new BooleanArgumentMarshaler()); else if (elementTail.equals("*")) marshalers.put(elementId, new StringArgumentMarshaler()); else if (elementTail.equals("#")) marshalers.put(elementId, new IntegerArgumentMarshaler()); else if (elementTail.equals("##")) marshalers.put(elementId, new DoubleArgumentMarshaler()); else throw new ArgsException(ArgsException.ErrorCode.INVALID_FORMAT, elementId, elementTail);

258

ROZDZIAŁ 14.

} private void validateSchemaElementId(char elementId) throws ArgsException { if (!Character.isLetter(elementId)) { throw new ArgsException(ArgsException.ErrorCode.INVALID_ARGUMENT_NAME, elementId, null); } } private void parseArguments() throws ArgsException { for (currentArgument = argsList.iterator(); currentArgument.hasNext();) { String arg = currentArgument.next(); parseArgument(arg); } } private void parseArgument(String arg) throws ArgsException { if (arg.startsWith("-")) parseElements(arg); } private void parseElements(String arg) throws ArgsException { for (int i = 1; i < arg.length(); i++) parseElement(arg.charAt(i)); } private void parseElement(char argChar) throws ArgsException { if (setArgument(argChar)) argsFound.add(argChar); else { throw new ArgsException(ArgsException.ErrorCode.UNEXPECTED_ARGUMENT, argChar, null); } } private boolean setArgument(char argChar) throws ArgsException { ArgumentMarshaler m = marshalers.get(argChar); if (m == null) return false; try { m.set(currentArgument); return true; } catch (ArgsException e) { e.setErrorArgumentId(argChar); throw e; } } public int cardinality() { return argsFound.size(); } public String usage() { if (schema.length() > 0) return "-[" + schema + "]"; else return ""; } public boolean getBoolean(char arg) { ArgumentMarshaler am = marshalers.get(arg); boolean b = false; try { b = am != null && (Boolean) am.get();

UDANE OCZYSZCZANIE KODU

259

} catch (ClassCastException e) { b = false; } return b; } public String getString(char arg) { ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? "" : (String) am.get(); } catch (ClassCastException e) { return ""; } } public int getInt(char arg) { ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? 0 : (Integer) am.get(); } catch (Exception e) { return 0; } } public double getDouble(char arg) { ArgumentMarshaler am = marshalers.get(arg); try { return am == null ? 0 : (Double) am.get(); } catch (Exception e) { return 0.0; } }

}

public boolean has(char arg) { return argsFound.contains(arg); }

Zmiany w klasie Args w większości polegały na usunięciu pewnych elementów. Sporo kodu przenieśliśmy z Args do ArgsException. Świetnie. Dodatkowo przenieśliśmy klasy ArgumentMarshaler do osobnych plików. Jeszcze lepiej! Większość dobrych projektów programowych dotyczy partycjonowania — tworzenia odpowiednich miejsc, w których można umieścić różne części kodu. Takie rozdzielenie problemów powoduje, że kod jest znacznie prostszy do zrozumienia i utrzymania. Szczególnie interesująca jest metoda errorMessage z ArgsException. Jasne było, że umieszczenie komunikatów błędów formatowania w Args było naruszeniem SRP. Klasa Args powinna dotyczyć przetwarzania argumentów, a nie formatowania komunikatów błędów. Jednak czy faktycznie ma sens umieszczanie formatowania komunikatów błędów w ArgsException? W zasadzie jest to kompromis. Użytkownicy, którzy nie chcą korzystać z komunikatów błędów dostarczanych przez ArgsException, mogą napisać własne. Jednak wygoda posiadania gotowych komunikatów błędów nie jest bez znaczenia. Teraz powinno być jasne, że jesteśmy bardzo blisko końcowego rozwiązania, przedstawionego na początku tego rozdziału. Ostatnie przekształcenia pozostawię do wykonania jako ćwiczenie.

260

ROZDZIAŁ 14.

Zakończenie Nie wystarczy napisać działający kod. Działający kod jest często fatalnie napisany. Programiści, którym wystarcza jedynie działający kod, działają nieprofesjonalnie. Mogą oni obawiać się, że nie będą mieli czasu na poprawienie struktury i projektu swojego kodu, ale nie mogą się z tym zgodzić. Nic nie ma tak głębokiego i w długim czasie degradującego wpływu na prowadzenie projektu, jak zły kod. Złe harmonogramy mogą być zmodyfikowane, złe wymagania przedefiniowane. Złą dynamikę zespołu da się poprawić. Jednak zły kod psuje się, stając się coraz większym ciężarem dla zespołu. Widziałem wiele zespołów, które się rozsypywały, ponieważ w pośpiechu tworzyły złośliwe bagnisko kodu, który na zawsze zdeterminował ich przeznaczenie. Oczywiście, nieudany kod można wyczyścić. Jednak jest to bardzo kosztowne. Wraz z psuciem się kodu moduły przeplatają się ze sobą, tworząc wiele ukrytych i zagmatwanych zależności. Wyszukiwanie i przerywanie starych zależności jest czasochłonnym i żmudnym zadaniem. Z drugiej strony, zachowanie czystości kodu jest względnie łatwe. Jeżeli narobimy bałaganu w kodzie rano, łatwo możemy go posprzątać po południu. Jednak jeszcze łatwiej jest posprzątać od razu, gdy tylko nabałaganimy. Tak więc rozwiązaniem jest ciągłe zachowywanie czystości i maksymalnej prostoty kodu. Nigdy nie pozwalajmy, by zaczął się psuć.

UDANE OCZYSZCZANIE KODU

261

262

ROZDZIAŁ 14.

ROZDZIAŁ 15.

Struktura biblioteki JUnit

bibliotek języka Java. Jest on oparty na prostej koncepcji, precyJ zyjnej definicji i eleganckiej implementacji. Jak jednak wygląda jego kod? W tym rozdziale poddamy UNIT JEST JEDNĄ Z NAJSŁYNNIEJSZYCH

krytyce przykładowy kod biblioteki JUnit.

263

Biblioteka JUnit JUnit ma wielu autorów, ale powstał na podstawie pracy Kent Becka i Erica Gamma w czasie ich wspólnego lotu do Atlanty. Kent chciał się nauczyć języka Java, a Eric chciał poznać bibliotekę testów dla języka Smalltalk, której autorem był Kent. „Co mogło być bardziej naturalnego dla maniaków uwięzionych w fotelach, jak tylko wyciągnąć swoje laptopy i zacząć kodować?”1. Po trzech godzinach pracy na wysokim pułapie napisali oni podstawy JUnit. Moduł, którym się zajmiemy, jest sprytnym kawałkiem kodu pomagającym identyfikować błędy porównania napisów. Nosi on nazwę ComparisonCompactor. Analizując dwa różniące się napisy, takie jak ABCDE i ABXDE, wskazuje on różnice przez wygenerowanie ciągu takiego jak <...B[X]D...>. Omówimy to dokładniej nieco dalej, a najlepszym wyjaśnieniem będą przypadki testowe. Spójrzmy więc na kod z listingu 15.1, który szczegółowo wyjaśnia wymagania dotyczące tego modułu. Możemy ocenić strukturę testów. Czy nie mogły być one prostsze lub bardziej oczywiste? L I S T I N G 1 5 . 1 . ComparisonCompactorTest.java package junit.tests.framework; import junit.framework.ComparisonCompactor; import junit.framework.TestCase; public class ComparisonCompactorTest extends TestCase { public void testMessage() { String failure= new ComparisonCompactor(0, "b", "c").compact("a"); assertTrue("a oczekiwane:<[b]> a było:<[c]>".equals(failure)); } public void testStartSame() { String failure= new ComparisonCompactor(1, "ba", "bc").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testEndSame() { String failure= new ComparisonCompactor(1, "ab", "cb").compact(null); assertEquals("oczekiwane:<[a]b> a było:<[c]b>", failure); } public void testSame() { String failure= new ComparisonCompactor(1, "ab", "ab").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testNoContextStartAndEndSame() { String failure= new ComparisonCompactor(0, "abc", "adc").compact(null); assertEquals("oczekiwane:<...[b]...> a było:<...[d]...>", failure); } public void testStartAndEndContext() { String failure= new ComparisonCompactor(1, "abc", "adc").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testStartAndEndContextWithEllipses() { String failure= 1

Kent Beck, JUnit Pocket Guide, O’Reilly 2004, s. 43.

264

ROZDZIAŁ 15.

}

new ComparisonCompactor(1, "abcde", "abfde").compact(null); assertEquals("oczekiwane:<...b[c]d...> a było:<...b[f]d...>", failure);

public void testComparisonErrorStartSameComplete() { String failure= new ComparisonCompactor(2, "ab", "abc").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testComparisonErrorEndSameComplete() { String failure= new ComparisonCompactor(0, "bc", "abc").compact(null); assertEquals("oczekiwane:<[]...> a było:<[a]...>", failure); } public void testComparisonErrorEndSameCompleteContext() { String failure= new ComparisonCompactor(2, "bc", "abc").compact(null); assertEquals("oczekiwane:<[]bc> a było:<[a]bc>", failure); } public void testComparisonErrorOverlapingMatches() { String failure= new ComparisonCompactor(0, "abc", "abbc").compact(null); assertEquals("oczekiwane:<...[]...> a było:<...[b]...>", failure); } public void testComparisonErrorOverlapingMatchesContext() { String failure= new ComparisonCompactor(2, "abc", "abbc").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testComparisonErrorOverlapingMatches2() { String failure= new ComparisonCompactor(0, "abcdde", "abcde").compact(null); assertEquals("oczekiwane:<...[d]...> a było:<...[]...>", failure); } public void testComparisonErrorOverlapingMatches2Context() { String failure= new ComparisonCompactor(2, "abcdde", "abcde").compact(null); assertEquals("oczekiwane:<...cd[d]e> a było:<...cd[]e>", failure); } public void testComparisonErrorWithActualNull() { String failure= new ComparisonCompactor(0, "a", null).compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testComparisonErrorWithActualNullContext() { String failure= new ComparisonCompactor(2, "a", null).compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testComparisonErrorWithExpectedNull() { String failure= new ComparisonCompactor(0, null, "a").compact(null); assertEquals("oczekiwane: a było: ", failure); } public void testComparisonErrorWithExpectedNullContext() { String failure= new ComparisonCompactor(2, null, "a").compact(null); assertEquals("oczekiwane: a było: ", failure); }

}

public void testBug609972() { String failure= new ComparisonCompactor(10, "S&P500", "0").compact(null); assertEquals("oczekiwane:<[S&P50]0> a było:<[]0>", failure); }

STRUKTURA BIBLIOTEKI JUNIT

265

Uruchomiłem analizę pokrycia kodu ComparisionCompactor przy użyciu tych testów. Kod jest w stu procentach pokryty. Każdy wiersz kodu, każda instrukcja if i pętla for jest wykonywana w tych testach. Daje mi to duży stopień pewności, że kod działa, i wzbudza we mnie duży respekt dla umiejętności autorów. Kod ComparisionCompactor jest zamieszczony na listingu 15.2. Warto poświęcić trochę czasu na zapoznanie się z tym kodem. Chyba wszyscy zauważą, że jest ładnie podzielony, wyrazisty i ma prostą strukturę. Po zakończeniu tej analizy zbierzemy wszystkie uwagi. L I S T I N G 1 5 . 2 . ComparisonCompactor.java (Oryginalny) package junit.framework; public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "]"; private static final String DELTA_START = "["; private private private private private

int fContextLength; String fExpected; String fActual; int fPrefix; int fSuffix;

public ComparisonCompactor(int contextLength, String expected, String actual) { fContextLength = contextLength; fExpected = expected; fActual = actual; } public String compact(String message) { if (fExpected == null || fActual == null || areStringsEqual()) return Assert.format(message, fExpected, fActual); findCommonPrefix(); findCommonSuffix(); String expected = compactString(fExpected); String actual = compactString(fActual); return Assert.format(message, expected, actual); } private String compactString(String source) { String result = DELTA_START + source.substring(fPrefix, source.length() fSuffix + 1) + DELTA_END; if (fPrefix > 0) result = computeCommonPrefix() + result; if (fSuffix > 0) result = result + computeCommonSuffix(); return result; } private void findCommonPrefix() { fPrefix = 0; int end = Math.min(fExpected.length(), fActual.length()); for (; fPrefix < end; fPrefix++) { if (fExpected.charAt(fPrefix) != fActual.charAt(fPrefix))

266

ROZDZIAŁ 15.

break; } } private void findCommonSuffix() { int expectedSuffix = fExpected.length() - 1; int actualSuffix = fActual.length() - 1; for (; actualSuffix >= fPrefix && expectedSuffix >= fPrefix; actualSuffix--, expectedSuffix--) { if (fExpected.charAt(expectedSuffix) != fActual.charAt(actualSuffix)) break; } fSuffix = fExpected.length() - expectedSuffix; } private String computeCommonPrefix() { return (fPrefix > fContextLength ? ELLIPSIS : "") + fExpected.substring(Math.max(0, fPrefix - fContextLength), fPrefix); } private String computeCommonSuffix() { int end = Math.min(fExpected.length() - fSuffix + 1 + fContextLength, fExpected.length()); return fExpected.substring(fExpected.length() - fSuffix + 1, end) + (fExpected.length() - fSuffix + 1 < fExpected.length() fContextLength ? ELLIPSIS : ""); } private boolean areStringsEqual() { return fExpected.equals(fActual); } }

Można mieć pewne zastrzeżenia do tego modułu. Znajduje się tu nieco długich wyrażeń, kilka dziwnych operacji +1 i tak dalej. Jednak ogólnie jest to całkiem niezły moduł. Ostatecznie mógłby on wyglądać jak na listingu 15.3. L I S T I N G 1 5 . 3 . ComparisonCompator.java (uszkodzony) package junit.framework; public class ComparisonCompactor { private int ctxt; private String s1; private String s2; private int pfx; private int sfx; public ComparisonCompactor(int ctxt, String s1, String s2) { this.ctxt = ctxt; this.s1 = s1; this.s2 = s2; } public String compact(String msg) { if (s1 == null || s2 == null || s1.equals(s2)) return Assert.format(msg, s1, s2); pfx = 0; for (; pfx < Math.min(s1.length(), s2.length()); pfx++) {

STRUKTURA BIBLIOTEKI JUNIT

267

if (s1.charAt(pfx) != s2.charAt(pfx)) break; } int sfx1 = s1.length() - 1; int sfx2 = s2.length() - 1; for (; sfx2 >= pfx && sfx1 >= pfx; sfx2--, sfx1--) { if (s1.charAt(sfx1) != s2.charAt(sfx2)) break; } sfx = s1.length() - sfx1; String cmp1 = compactString(s1); String cmp2 = compactString(s2); return Assert.format(msg, cmp1, cmp2); } private String compactString(String s) { String result = "[" + s.substring(pfx, s.length() - sfx + 1) + "]"; if (pfx > 0) result = (pfx > ctxt ? "..." : "") + s1.substring(Math.max(0, pfx - ctxt), pfx) + result; if (sfx > 0) { int end = Math.min(s1.length() - sfx + 1 + ctxt, s1.length()); result = result + (s1.substring(s1.length() - sfx + 1, end) + (s1.length() - sfx + 1 < s1.length() - ctxt ? "..." : "")); } return result; } }

Mimo że autorzy nadali temu modułowi bardzo dobry kształt, zasada skautów2 mówi, że powinniśmy pozostawić go czystszym, niż go zastaliśmy. W jaki sposób można poprawić oryginalny kod z listingu 15.2? Pierwszą rzeczą, jakiej nie cierpię, jest prefiks f przed zmiennymi składowymi [N6]. Dzisiejsze środowiska powodują, że taki sposób kodowania zakresu jest niarowy. Wyeliminujemy więc wszystkie f. private private private private private

int contextLength; String expected; String actual; int prefix; int suffix;

Następnie mamy niehermetyzowany warunek na początku funkcji compact [G28]. public String compact(String message) { if (expected == null || actual == null || areStringsEqual()) return Assert.format(message, expected, actual); findCommonPrefix(); findCommonSuffix(); String expected = compactString(this.expected); String actual = compactString(this.actual); return Assert.format(message, expected, actual); }

2

Patrz „Zasada skautów” w rozdziale 1.

268

ROZDZIAŁ 15.

Warunek ten powinien być hermetyzowany, aby nasze intencje były jasne. Z tego powodu wyodrębnimy metodę, która je wyjaśnia. public String compact(String message) { if (shouldNotCompact()) return Assert.format(message, expected, actual);

}

findCommonPrefix(); findCommonSuffix(); String expected = compactString(this.expected); String actual = compactString(this.actual); return Assert.format(message, expected, actual);

private boolean shouldNotCompact() { return expected == null || actual == null || areStringsEqual(); }

Nie podoba mi się notacja this.expected oraz this.actual w funkcji compact. Powstała ona, gdy zmieniłem nazwę z fExpected na expected. Dlaczego w tej funkcji wykorzystane są nazwy mające takie same nazwy co zmienne składowe? Czy nie reprezentują czegoś innego [N4]? Powinniśmy użyć bardziej znaczących nazw. String compactExpected = compactString(expected); String compactActual = compactString(actual);

Wyrażenia negatywne są nieco trudniejsze do zrozumienia niż pozytywne [G29]. Postawimy więc wyrażenie if na głowie i zmienimy sens warunku. public String compact(String message) { if (canBeCompacted()) { findCommonPrefix(); findCommonSuffix(); String compactExpected = compactString(expected); String compactActual = compactString(actual); return Assert.format(message, compactExpected, compactActual); } else { return Assert.format(message, expected, actual); } } private boolean canBeCompacted() { return expected != null && actual != null && !areStringsEqual(); }

Nazwa funkcji jest dość dziwna [N7]. Choć wykonuje ona zmniejszanie ciągów, w rzeczywistości może tego nie robić, jeżeli canBeCompacted zwróci false. Tak więc nazwanie tej funkcji compact powoduje ukrycie efektu ubocznego kontroli błędów. Należy również zauważyć, że funkcja zwraca sformatowany komunikat, a nie po prostu zmniejszony ciąg. Dlatego nazwa tej funkcji powinna brzmieć formatCompactedComparison. Będzie znacznie czytelniejsza, gdy złączymy ją z argumentem funkcji: public String formatCompactedComparison(String message) {

Faktyczne zmniejszanie oczekiwanego i otrzymanego ciągu znajduje się w ciele instrukcji if. Powinniśmy wyodrębnić tę operację do osobnej metody o nazwie compactExpectedAndActual. Jednak chcemy, aby funkcja formatCompactedComparison wykonywała całe formatowanie. Funkcja compact... nie powinna robić nic poza zmniejszaniem [G30]. Podzielmy kod w następujący sposób:

STRUKTURA BIBLIOTEKI JUNIT

269

... private String compactExpected; private String compactActual; ... public String formatCompactedComparison(String message) { if (canBeCompacted()) { compactExpectedAndActual(); return Assert.format(message, compactExpected, compactActual); } else { return Assert.format(message, expected, actual); } } private void compactExpectedAndActual() { findCommonPrefix(); findCommonSuffix(); compactExpected = compactString(expected); compactActual = compactString(actual); }

Trzeba zauważyć, że wymaga to wypromowania compactExpected oraz compactActual jako zmiennych składowych. Nie lubię sposobu, w jaki w ostatnich dwóch wierszach nowej funkcji są zwracane zmienne, a w dwóch pierwszych nie. Nie jest tu używana spójna konwencja [G11]. Powinniśmy zmienić findCommonPrefix oraz findCommonSuffix, aby zwracały wartość przedrostka i przyrostka. private void compactExpectedAndActual() { prefixIndex = findCommonPrefix(); suffixIndex = findCommonSuffix(); compactExpected = compactString(expected); compactActual = compactString(actual); } private int findCommonPrefix() { int prefixIndex = 0; int end = Math.min(expected.length(), actual.length()); for (; prefixIndex < end; prefixIndex++) { if (expected.charAt(prefixIndex) != actual.charAt(prefixIndex)) break; } return prefixIndex; } private int findCommonSuffix() { int expectedSuffix = expected.length() - 1; int actualSuffix = actual.length() - 1; for (; actualSuffix >= prefixIndex && expectedSuffix >= prefixIndex; actualSuffix--, expectedSuffix--) { if (expected.charAt(expectedSuffix) != actual.charAt(actualSuffix)) break; } return expected.length() - expectedSuffix; }

Powinniśmy również zmienić nazwy zmiennych składowych na bardziej trafne [N1]; w końcu obie są indeksami. Dokładna analiza pokazuje, że findCommonSuffix ujawnia ukryte sprzężenie czasowe [G31]; zmienna zależy od wyliczenia wartości prefixIndex przez findCommonPrefix. Jeżeli te dwie funkcje zostałyby wywołane w niewłaściwej kolejności, można by się spodziewać trudnej sesji debugowania.

270

ROZDZIAŁ 15.

Tak więc, aby ujawnić to sprzężenie czasowe, funkcja findCommonSuffix będzie oczekiwała jako argumentu prefixIndex. private void compactExpectedAndActual() { prefixIndex = findCommonPrefix(); suffixIndex = findCommonSuffix(prefixIndex); compactExpected = compactString(expected); compactActual = compactString(actual); } private int findCommonSuffix(int prefixIndex) { int expectedSuffix = expected.length() - 1; int actualSuffix = actual.length() - 1; for (; actualSuffix >= prefixIndex && expectedSuffix >= prefixIndex; actualSuffix--, expectedSuffix--) { if (expected.charAt(expectedSuffix) != actual.charAt(actualSuffix)) break; } return expected.length() - expectedSuffix; }

Nie jestem zadowolony z tego kodu. Przekazywanie argumentu prefixIndex jest zbyt dowolne [G32]. Pozwala określić kolejność, ale nie wyjaśnia potrzeby takiego uporządkowania. Inny programista może wycofać wprowadzone przez nas zmiany, ponieważ nie ma żadnej wskazówki, że parametr jest naprawdę potrzebny. Przyjmijmy więc inne podejście. private void compactExpectedAndActual() { findCommonPrefixAndSuffix(); compactExpected = compactString(expected); compactActual = compactString(actual); } private void findCommonPrefixAndSuffix() { findCommonPrefix(); int expectedSuffix = expected.length() - 1; int actualSuffix = actual.length() - 1; for (; actualSuffix >= prefixIndex && expectedSuffix >= prefixIndex; actualSuffix--, expectedSuffix-) { if (expected.charAt(expectedSuffix) != actual.charAt(actualSuffix)) break; } suffixIndex = expected.length() - expectedSuffix; } private void findCommonPrefix() { prefixIndex = 0; int end = Math.min(expected.length(), actual.length()); for (; prefixIndex < end; prefixIndex++) if (expected.charAt(prefixIndex) != actual.charAt(prefixIndex)) break; }

Umieściliśmy findCommonPrefix oraz findCommonSuffix z powrotem tam, gdzie były wcześniej, zmieniając nazwę findCommonSuffix na findCommonPrefixAndSuffix i wywołując findCommonPrefix przed wykonaniem jakichkolwiek innych operacji. Uwypukla to czasową naturę sprzężenia tych dwóch funkcji w bardziej dramatyczny sposób niż w poprzednim rozwiązaniu. Wskazuje również, jak nieudana jest funkcja findCommonPrefixAndSuffix. Zajmijmy się jej wyczyszczeniem.

STRUKTURA BIBLIOTEKI JUNIT

271

private void findCommonPrefixAndSuffix() { findCommonPrefix(); int suffixLength = 1; for (; !suffixOverlapsPrefix(suffixLength); suffixLength++) { if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength)) break; } suffixIndex = suffixLength; } private char charFromEnd(String s, int i) { return s.charAt(s.length()-i);} private boolean suffixOverlapsPrefix(int suffixLength) { return actual.length() - suffixLength < prefixLength || expected.length() - suffixLength < prefixLength; }

Teraz jest znacznie lepiej. Ujawnione zostało, że suffixIndex jest w rzeczywistości długością przyrostka, czyli nie jest dobrze nazwana. To samo dotyczy prefixIndex, czyli w tym przypadku index i length są synonimami. Kod zyska na spójności, gdy będziemy korzystać z length. Jednak problem polega na tym, że suffixIndex nie zaczyna się od zera — zaczyna się od 1, czyli nie jest to prawdziwa długość. Przyczyna się to również do tego, że w computeCommonSuffix są użyte te wszystkie +1 [G33]. Poprawmy więc to. Wynik jest zamieszczony na listingu 15.4. L I S T I N G 1 5 . 4 . ComparisonCompactor.java (tymczasowy) public class ComparisonCompactor { ... private int suffixLength; ... private void findCommonPrefixAndSuffix() { findCommonPrefix(); suffixLength = 0; for (; !suffixOverlapsPrefix(suffixLength); suffixLength++) { if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength)) break; } } private char charFromEnd(String s, int i) { return s.charAt(s.length() - i - 1); } private boolean suffixOverlapsPrefix(int suffixLength) { return actual.length() - suffixLength <= prefixLength || expected.length() - suffixLength <= prefixLength; } ... private String compactString(String source) { String result = DELTA_START + source.substring(prefixLength, source.length() - suffixLength) + DELTA_END;

272

ROZDZIAŁ 15.

if (prefixLength > 0) result = computeCommonPrefix() + result; if (suffixLength > 0) result = result + computeCommonSuffix(); return result; } ... private String computeCommonSuffix() { int end = Math.min(expected.length() - suffixLength + contextLength, expected.length() ); return expected.substring(expected.length() - suffixLength, end) + (expected.length() - suffixLength < expected.length() - contextLength ? ELLIPSIS : ""); }

Zamieniliśmy +1 w computeCommonSuffix na -1 w charFromEnd, gdzie jest to całkiem sensowne, oraz dwa operatory <= w suffixOverlapsPrefix, gdzie również jest to sensowne. Pozwoliło to nam zmienić nazwę suffixIndex na suffixLength, co znacznie poprawiło czytelność kodu. Istnieje tu jednak problem. Po wyeliminowaniu +1 pozostał w compactString następujący wiersz: if (suffixLength > 0)

Spójrzmy na listing 15.4. Ponieważ suffixLength ma teraz wartość o jeden mniejszą niż wcześniej, powinniśmy zmienić operator > na >=. Jednak nie miało to sensu. Teraz ma! Jeżeli wcześniej nie miało to sensu, był to prawdopodobnie błąd. Cóż, właściwie nie był to błąd. Dokładna analiza pokazuje, że instrukcja if zapobiega teraz dołączaniu przyrostków o zerowej długości. Przed wprowadzeniem przez nas zmian instrukcja if nie działała, ponieważ zmienna suffixIndex nigdy nie przyjmowała wartości mniejszej od jeden! Dotyczy to obu instrukcji if w compactString! Wygląda na to, że można je wyeliminować. Zakomentujemy je więc i uruchomimy testy. Zostały wykonane prawidłowo! Możemy więc zmodyfikować compactString, eliminując niarowe instrukcje if, co znacznie upraszcza tę funkcję [G9]. private String compactString(String source) { return computeCommonPrefix() + DELTA_START + source.substring(prefixLength, source.length() - suffixLength) + DELTA_END + computeCommonSuffix(); }

Teraz jest znacznie lepiej! Widzimy, że funkcja compactString po prostu łączy ze sobą fragmenty tekstu. Z pewnością możemy pokazać to jeszcze jaśniej, wykonać jeszcze wiele małych usprawnień. Jednak zamiast pokazywać pozostałe zmiany, zamieścimy ostateczny wynik na listingu 15.5.

STRUKTURA BIBLIOTEKI JUNIT

273

L I S T I N G 1 5 . 5 . ComparisonCompactor.java (ostateczny) package junit.framework; public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "]"; private static final String DELTA_START = "["; private private private private private

int contextLength; String expected; String actual; int prefixLength; int suffixLength;

public ComparisonCompactor( int contextLength, String expected, String actual ) { this.contextLength = contextLength; this.expected = expected; this.actual = actual; } public String formatCompactedComparison(String message) { String compactExpected = expected; String compactActual = actual; if (shouldBeCompacted()) { findCommonPrefixAndSuffix(); compactExpected = compact(expected); compactActual = compact(actual); } return Assert.format(message, compactExpected, compactActual); } private boolean shouldBeCompacted() { return !shouldNotBeCompacted(); } private boolean shouldNotBeCompacted() { return expected == null || actual == null || expected.equals(actual); } private void findCommonPrefixAndSuffix() { findCommonPrefix(); suffixLength = 0; for (; !suffixOverlapsPrefix(); suffixLength++) { if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength) ) break; } } private char charFromEnd(String s, int i) { return s.charAt(s.length() - i - 1); } private boolean suffixOverlapsPrefix() { return actual.length() - suffixLength <= prefixLength || expected.length() - suffixLength <= prefixLength; }

274

ROZDZIAŁ 15.

private void findCommonPrefix() { prefixLength = 0; int end = Math.min(expected.length(), actual.length()); for (; prefixLength < end; prefixLength++) if (expected.charAt(prefixLength) != actual.charAt(prefixLength)) break; } private String compact(String s) { return new StringBuilder() .append(startingEllipsis()) .append(startingContext()) .append(DELTA_START) .append(delta(s)) .append(DELTA_END) .append(endingContext()) .append(endingEllipsis()) .toString(); } private String startingEllipsis() { return prefixLength > contextLength ? ELLIPSIS : ""; } private String startingContext() { int contextStart = Math.max(0, prefixLength - contextLength); int contextEnd = prefixLength; return expected.substring(contextStart, contextEnd); } private String delta(String s) { int deltaStart = prefixLength; int deltaEnd = s.length() - suffixLength; return s.substring(deltaStart, deltaEnd); } private String endingContext() { int contextStart = expected.length() - suffixLength; int contextEnd = Math.min(contextStart + contextLength, expected.length()); return expected.substring(contextStart, contextEnd); } private String endingEllipsis() { return (suffixLength > contextLength ? ELLIPSIS : ""); } }

Kod ten jest całkiem ładny. Moduł ma oddzieloną grupę funkcji analitycznych i inną grupę funkcji syntetycznych. Są one posortowane topologicznie, dzięki czemu definicja każdej z funkcji znajduje się zaraz po jej użyciu. Wszystkie funkcje analityczne znajdują się na początku, a funkcje syntetyczne na końcu. Dokładniejsza analiza kodu pokazuje, że cofnąłem kilka decyzji, jakie podjąłem we wcześniejszej części tego rozdziału. Na przykład wbudowałem kilka wyodrębnionych metod z powrotem do formatCompactedComparison i zmieniłem sens wyrażenia shouldNotBeCompacted. Jest to typowe. Często jedna przebudowa prowadzi do anulowania wcześniejszej. Przebudowa jest procesem iteracyjnym pełnym prób i błędów — procesem, który wynika z naszego dążenia do profesjonalizmu.

STRUKTURA BIBLIOTEKI JUNIT

275

Zakończenie Wypełniliśmy regułę skauta. Pozostawiliśmy moduł czyściejszy, niż go dostaliśmy. Nie można powiedzieć, że wcześniej nie był czysty. Jego autorzy świetnie się spisali. Jednak nie ma modułu, którego nie można poprawić, a każdy z nas jest odpowiedzialny za pozostawienie kodu w lepszym stanie, niż był wcześniej.

276

ROZDZIAŁ 15.

ROZDZIAŁ 16.

Przebudowa klasy SerialDate

http://www.jfree.org/jcommon/index.php, znajdziemy tam bibliotekę J JCommon. Głęboko w tej bibliotece znajdziemy pakiet o nazwie . Z kolei w paEŻELI OTWORZYMY STRONĘ

org.jfree.date

kiecie znajduje się klasa o nazwie SerialDate. W niniejszym rozdziale przeanalizujemy tę klasę. Autorem klasy SerialDate jest David Gilbert. Jasne jest, że David to doświadczony i kompetentny programista. Jak możemy zauważyć, podczas tworzenia tego kodu wykazał się dyscypliną i profesjonalizmem. W przypadku wszystkich zastosowań jest to „dobry kod”. A ja zamierzam rozebrać go na części. Nie jest to z mojej strony żadna złośliwość. Nie uważam również, że jestem znacznie lepszym programistą niż David, więc mam prawo przeprowadzić sąd nad jego kodem. Gdyby ktoś przeanalizował mój kod, jestem pewny, że znalazłby wiele fragmentów, do których miałby uwagi.

277

Nie, nie jest to akt złośliwości ani arogancji. Moim zamiarem jest tylko profesjonalna recenzja. Jest to coś, co każdy z nas powinien wykonywać bez problemów. Jest to również coś, z czego powinniśmy być zadowoleni, gdy ktoś to robi dla nas. Tylko przez taką krytykę możemy się czegoś nauczyć. Lekarze to robią. Piloci to robią. Prawnicy to robią. Również my, programiści, powinniśmy się nauczyć recenzować dzieła innych. Jeszcze jedno słowo na temat Davida Gilberta. David to więcej niż tylko dobry programista. Miał odwagę i dobrą wolę, aby za darmo zaoferować swój kod społeczności. Udostępnił go dla wszystkich, umożliwiając jego użycie i publiczne badanie. Jest to świetnie zrobiony kod! Klasa SerialDate (listing B.1 w dodatku B) reprezentuje datę w języku Java. Po co nam kolejna klasa reprezentująca datę, skoro Java posiada już między innymi klasy java.util.Date oraz java.util.Calendar? Autor napisał tę klasę w odpowiedzi na problemy, z jakimi często się spotykaliśmy. Otwierający komentarz Javadoc (wiersz 67.) jasno to wyjaśnia. Możemy mieć wątpliwości na temat jego intencji, ale ja kiedyś musiałem zmagać się z tym problemem i z radością powitałem klasę, która operuje na datach zamiast na czasie.

Na początek uruchamiamy W klasie SerialDateTests (listing B.2 w dodatku B) znajduje się kilka testów jednostkowych. Wszystkie te testy są wykonywane prawidłowo. Niestety, szybki przegląd testów pokazuje, że nie testują wszystkiego [T1]. Na przykład wyszukanie zastosowań dla metody MonthCodeToQuarter (wiersz 334.) wykazuje, że nie jest używana [F4]. Zatem testy jednostkowe nie testują jej. Skorzystałem zatem z programu Clover, aby sprawdzić, co jest pokryte przez testy jednostkowe, a co nie. Clover wykazał, że testy jednostkowe wykonują tylko 91 ze 185 instrukcji wykonywalnych w klasie SerialDate (~50 procent) [T2]. Mapa pokrycia wyglądała jak dziurawy koc, z wielkimi połaciami niewykonywanego kodu rozsianymi po całej klasie. Musiałem dokładnie zrozumieć, jak przebudować tę klasę. Nie mogłem tego robić bez znacznie większego pokrycia kodu testami. Napisałem więc własny zestaw zupełnie niezależnych testów jednostkowych (listing B.4 w dodatku B). Przeglądając te testy, można zauważyć, że wiele z nich jest zakomentowanych. Testy te nie wykonują się prawidłowo. Reprezentują one te funkcje, które według mnie powinna posiadać klasa SerialDate. Dlatego w czasie przebudowy SerialDate będziemy dążyć do uruchomienia również tych testów. Nawet pomimo zakomentowania części testów Clover raportuje, że nowe testy jednostkowe wykonują 170 ze 180 (92 procent) instrukcji wykonywalnych. Jest to całkiem niezły wynik i uważam, że jestem w stanie uzyskać wyższy. Kilka pierwszych zakomentowanych testów (wiersze od 23. do 63.) było z mojej strony nieco przesadzonych. Program nie był zaprojektowany, aby przeszedł te testy, ale działanie takie wydawało mi się oczywiste [G2]. Nie jestem pewien, dlaczego metoda testWeekdayCodeToString była napisana

278

ROZDZIAŁ 16.

jako pierwsza, ale ponieważ już jest, wydaje się oczywiste, że powinna rozpoznawać wielkość liter. Napisanie tych testów było bardzo łatwe [T3]. Spowodowanie, aby się wykonywały, było równie proste — po prostu zmieniłem wiersze 259. i 263., aby wykorzystywana była metoda equalsIgnoreCase. Pozostawiłem zakomentowane testy w wierszach 32. i 45., ponieważ nie było dla mnie jasne, czy skróty „tues” oraz „thurs” powinny być obsługiwane. Testy z wierszy 153. i 154. nie były wykonywane prawidłowo. Jasne jest, że powinny [G2]. Możemy łatwo to poprawić, razem z testami z wierszy od 163. do 213., przez wprowadzenie następujących zmian do funkcji stringToMonthCode: 457 458 459 460 461 462 463 464 465 466 467 468

if ((result < 1) || (result > 12)) { result = -1; for (int i = 0; i < monthNames.length; i++) { if (s.equalsIgnoreCase(shortMonthNames[i])) { result = i + 1; break; } if (s.equalsIgnoreCase(monthNames[i])) { result = i + 1; break; } } }

Zakomentowany test z wiersza 318. ujawnia błąd w metodzie getFollowingDayOfWeek (wiersz 672.). 25 grudnia 2004 był sobotą. Następną sobotą był 1 stycznia 2005. Jednak po uruchomieniu testów okazuje się, że getFollowingDayOfWeek zwraca 25 grudnia jako sobotę następującą po 25 grudnia. Oczywiście jest to błąd [G3], [T1]. Problem znajduje się w wierszu 685. Jest to typowy błąd warunku granicznego [T1]. Powinien on wyglądać następująco: 685

if (baseDOW >= targetWeekday) {

Warto zauważyć, że funkcja ta była celem wcześniejszej poprawki. Historia zmian wykazuje (wiersz 43.), że te „błędy” były poprawione w getPreviousDayOfWeek, getFollowingDayOfWeek oraz getNearestDayOfWeek [T6]. Test jednostkowy testGetNearestDayOfWeek (wiersz 329.), który testuje metodę getNearest DayOfWeek (wiersz 705.), nie był tak długi i dokładny, jak jest obecnie. Dodałem do niego wiele przypadków testowych, ponieważ nie wszystkie moje początkowe przypadki testowe wykonywały się prawidłowo [T6]. Można zauważyć wzorzec awarii przez sprawdzenie, które przypadki testowe są zakomentowane. Wzorzec ten wiele nam mówi [T7]. Pokazuje, że algorytm nie działa prawidłowo, jeżeli najbliższy dzień jest w przyszłości. Jasne jest, że jest to jakiś rodzaj błędu w warunku granicznym [T5]. Równie interesujący jest wzór pokrycia testami raportowany przez program Clover [T8]. Wiersz 719. nigdy nie jest wykonywany! Oznacza to, że instrukcja if w wierszu 718. zawsze ma wartość false. Patrząc na kod, można stwierdzić, że musi mieć ona wartość true. Zmienna adjust jest zawsze ujemna, więc nie może być większa lub równa 4. A zatem algorytm ten jest nieprawidłowy.

PRZEBUDOWA KLASY SERIALDATE

279

Prawidłowy algorytm jest przedstawiony poniżej: int delta = targetDOW - base.getDayOfWeek(); int positiveDelta = delta + 7; int adjust = positiveDelta % 7; if (adjust > 3) adjust -= 7; return SerialDate.addDays(adjust, base);

Testy z wierszy 417. oraz 429. mogą być wykonywane prawidłowo przez zgłoszenie wyjątku IllegalArgumentException, zamiast zwracać komunikat błędu z weekInMonthToString oraz relativeToString. Po wprowadzeniu tych zmian wszystkie testy jednostkowe są wykonywane prawidłowo i uważam, że SerialDate teraz działa. Czas więc, by była napisana „właściwie”.

Teraz poprawiamy Mam zamiar przejść od początku do końca klasy SerialDate, ulepszając kolejne konstrukcje. Choć nie jest to pokazane, po każdej wprowadzonej zmianie uruchamiałem wszystkie testy jednostkowe JCommon, razem z moimi ulepszonymi testami jednostkowymi SerialDate. Pozostałe testy upewniały mnie, że każda pokazana tu zmiana działa z pozostałym kodem JCommon. Zaczynając od wiersza 1., widzimy blok komentarzy z informacjami o licencji, autorach i historii zmian. Zgadzam się, że określone problemy prawne powinny zostać rozwiązane, więc informacje o prawach autorskich i licencjach powinny zostać. Z drugiej strony, historia zmian jest pozostałością z lat sześćdziesiątych ubiegłego stulecia. Mamy teraz narzędzia kontroli wersji, które robią to za nas. Historia ta powinna zostać usunięta [C1]. Lista importów zaczynająca się od wiersza 61. powinna zostać skrócona przez użycie java.text.* oraz java.util.* [J1]. Formatowanie HTML w Javadoc przyprawia mnie o ból głowy (wiersz 67.). Pliki źródłowe z więcej niż jednym językiem są dla mnie problemem. Ten komentarz korzysta z czterech języków: Java, angielskiego, Javadoc oraz HTML [G1]. Przy tak dużej liczbie zastosowanych języków trudno zachować prostotę. Na przykład ładne pozycjonowanie w wierszach 71. i 72. jest tracone po wygenerowaniu Javadoc, a poza tym kto chce widzieć w kodzie źródłowym znaczniki

i
• . Lepszą strategią jest objęcie całego komentarza znacznikami <pre>, aby formatowanie naturalne dla kodu źródłowego zostało zachowane w Javadoc1. W wierszu 86. znajduje się deklaracja klasy. Dlaczego klasa ta jest nazwana SerialDate? Jakie jest znaczenie wartości słowa „serial”? Czy pochodzi ono od Serializable? Raczej mało prawdopodobne.
  
  1
  
  Jeszcze lepszym rozwiązaniem byłoby, gdyby Javadoc prezentował wszystkie komentarze w postaci wstępnie sformatowanej — te same komentarze wyglądały identycznie w kodzie i dokumentacji.
  
  280
  
  ROZDZIAŁ 16.
  
  Nie chcę trzymać dalej Czytelników w niepewności. Wiem (lub co najmniej uważam, że wiem), dlaczego zostało użyte słowo „serial”. Powodem jest użycie stałych SERIAL_LOWER_BOUND i SERIAL_UPPER_BOUND z wierszy 98. i 101. Jeszcze lepszą wskazówką jest komentarz zaczynający się w wierszu 830. Klasa ta jest nazwana SerialDate, ponieważ jest zaimplementowana z użyciem „numeru seryjnego”, który jest liczbą dni od 30 grudnia 1899. Są z tym związane dwa problemy. Po pierwsze, nazwa „numer seryjny” nie jest tak naprawdę prawidłowa. Może to być wątpliwe, ponieważ reprezentacja ta jest bardziej względnym przesunięciem niż numerem seryjnym. Nazwa „numer seryjny” ma więcej wspólnego ze znacznikami identyfikującymi produkty niż z datami. Dlatego nie uważam, aby nazwa ta była odpowiednio opisowa [N1]. Właściwszym terminem może być „ordinal” (kolejność). Drugi problem jest ważniejszy. Nazwa SerialDate zakłada implementację. Klasa ta jest klasą abstrakcyjną. Nie ma potrzeby, aby zakładała cokolwiek na temat jej implementacji. W rzeczywistości istnieją powody, aby ukryć implementację! Uważam więc, że nazwa ta znajduje się na niewłaściwym poziomie abstrakcji [N2]. Według mnie klasa ta powinna nazywać się po prostu Date. Niestety, w bibliotece Java znajduje się zbyt wiele klas nazwanych Date, więc nie jest to najlepsza nazwa. Ponieważ klasa ta operuje na dniach, a nie na czasie, rozważałem nazwanie jej Day, ale ta nazwa jest równie intensywnie używana w innych miejscach. W końcu wybrałem DayDate jako najlepszy kompromis. Od teraz w rozdziale będę korzystał z nazwy DayDate. Czytelnik winien pamiętać, że listingi, na jakie będzie patrzył, nadal korzystają z nazwy SerialDate. Rozumiem, dlaczego DayDate dziedziczy po Comparable i Serializable. Dlaczego jednak dziedziczy po MonthConstants? Klasa MonthConstants (listing B.3 w dodatku B) jest po prostu zbiorem statycznych stałych final, które definiują nazwy miesięcy. Dziedziczenie po klasach ze stałymi jest starą sztuczką używaną przez programistów Java, aby uniknąć używania wyrażeń takich jak MonthConstants.January, ale jest to zły pomysł [J2]. MonthConstants powinien być typem wyliczeniowym. public abstract class DayDate implements Comparable, Serializable { public static enum Month { JANUARY(1), FEBRUARY(2), MARCH(3), APRIL(4), MAY(5), JUNE(6), JULY(7), AUGUST(8), SEPTEMBER(9), OCTOBER(10), NOVEMBER(11), DECEMBER(12); Month(int index) { this.index = index; }
  
  PRZEBUDOWA KLASY SERIALDATE
  
  281
  
  public static Month make(int monthIndex) { for (Month m : Month.values()) { if (m.index == monthIndex) return m; } throw new IllegalArgumentException("Niewłaściwy indeks miesiąca " + monthIndex); } public final int index; }
  
  Zmiana MonthConstants na enum wymusza niewiele zmian w klasie DayDate i klasach jej używających. Wprowadzenie wszystkich tych zmian zajęło mi godzinę. Jednak każda funkcja, która wcześniej oczekiwała int z miesiącem, obecnie oczekuje enumeratora Month. Dzięki temu można usunąć metodę isValidMonthCode (wiersz 326.) i wszystkie sprawdzenia kodu miesiąca, takie jak te używane w monthCodeToQuarter (wiersz 356.) [G5]. Następnie w wierszu 91. mamy serialVersionUID. Zmienna ta jest używana do sterowania serializacją. Jeżeli ją zmienimy, to dowolny obiekt DayDate zapisany w starszej wersji oprogramowania nie będzie czytelny w nowszej i spowoduje zgłoszenie wyjątku InvalidClassException. Jeżeli nie zadeklarujemy zmiennej serialVersionUID, kompilator automatycznie ją dla nas wygeneruje i będzie ona miała inną wartość po każdej zmianie w module. Wiem, że we wszystkich dokumentach zalecana jest ręczna kontrola nad tą zmienną, ale wydaje mi się, że automatyczne sterowanie serializacją jest znacznie bezpieczniejsze [G4]. W końcu raczej będę debugował InvalidClass Exception, niż podejmę dziwne działanie, jakie będzie wynikiem braku zmiany wartości serial VersionUID. Dlatego usunę tę zmienną — przynajmniej na jakiś czas2. Uważam, że komentarz z wiersza 93. jest niarowy. Niarowe komentarze są po prostu dezinformującymi miejscami gromadzącymi kłamstwa [C2]. Zamierzam więc usunąć go. Komentarze z wierszy 97. i 100. traktują o numerach seryjnych, o czym wspominałem wcześniej [C1]. Zmienne, jakie opisują, są najwcześniejszą i najpóźniejszą możliwą datą, jaką można opisać za pomocą DayDate. Może to być nieco jaśniejsze [N1]. public static final int EARLIEST_DATE_ORDINAL = 2; // 1900.01.01 public static final int LATEST_DATE_ORDINAL = 2958465; // 9999.12.31
  
  Nie jest dla mnie jasne, dlaczego EARLIEST_DATE_ORDINAL ma wartość 2 zamiast 0. W wierszu 829. znajduje się sugestia, że ma to coś wspólnego ze sposobem reprezentacji dat w programie Microsoft Excel. Znacznie dokładniej jest to przedstawione w klasie SpreadsheetDate dziedziczącej po DayDate (listing B.5 w dodatku B). Komentarz z wiersza 71. dobrze opisuje problem. Problem, jaki mamy tutaj, wydaje się związany z implementacją SpreadsheetDate i nie ma nic wspólnego z DayDate. Wywnioskowałem z tego, że EARLIEST_DATE_ORDINAL oraz LATEST_DATE_ORDINAL nie należą do DayDate i powinny zostać przeniesione do SpreadsheetDate [G6]. 2
  
  Kilku recenzentów tego rozdziału protestowało przeciwko tej decyzji. Przekonywali oni, że w bibliotece open source lepiej zakładać ręczną kontrolę nad identyfikatorem serializacji, aby pomniejsze zmiany w oprogramowaniu nie powodowały unieważnienia starych serializowanych dat. Jest to zrozumiały powód. Jednak awarie, niezależnie od tego, jak mogą być niewygodne, mają jasną przyczynę. Z drugiej strony, jeżeli autor klasy zapomni zaktualizować identyfikator, to powód awarii nie jest zdefiniowany i może być dobrze ukryty. Uważam, że morałem z tej historii jest to, że nie powinniśmy oczekiwać deserializacji pomiędzy różnymi wersjami.
  
  282
  
  ROZDZIAŁ 16.
  
  Faktycznie, przeszukanie kodu wykazuje, że zmienne te są używane wyłącznie w SpreadsheetDate. Nic w DayDate ani w innych klasach biblioteki JCommon nie korzysta z tych zmiennych. Dlatego przeniosłem je do SpreadsheetDate. Następne zmienne, MINIMUM_YEAR_ED oraz MAXIMUM_YEAR_ED (wiersz 104. oraz 107.), spowodowały pewien dylemat. Wydaje się jasne, że jeżeli klasa DayDate jest klasą abstrakcyjną, która nie zapewnia implementacji, to nie powinna informować nas o roku minimalnym i maksymalnym. Kolejny raz miałem zamiar przenieść te zmienne do SpreadsheetDate [G6]. Jednak wyszukanie użytkowników tych zmiennych wykazało, że inna klasa z nich korzysta: Relative DayOfWeekRule (listing B.6 w dodatku B). Są one zastosowane w wierszu 177. i 178. w funkcji getDate, gdzie są wykorzystywane do sprawdzenia, czy argument getDate ma prawidłowy rok. Dylemat jest związany z tym, że użytkownik klasy abstrakcyjnej potrzebuje informacji o jej implementacji. Do dostarczenia tych informacji bez zanieczyszczania potrzebujemy klasy DayDate. Zwykle powinniśmy uzyskać informacje o implementacji z obiektu klasy pochodnej. Jednak do funkcji getDate nie jest przekazywany obiekt DayDate. Zwraca ona jednak taki obiekt, co oznacza, że musi być gdzieś utworzony. Podpowiedzią są wiersze od 187. do 205. Obiekt DayDate jest tworzony przez jedną z trzech funkcji, getPreviousDayOfWeek, getNearestDayOfWeek lub getFollowingDayOfWeek. Wracając do listingu DayDate, możemy zauważyć, że te funkcje (wiersze od 638. do 724.) zwracają datę utworzoną przez addDays (wiersz 571.), a ta wywołuje createInstance (wiersz 808.), która z kolei tworzy obiekt SpreadsheetDate! [G7]. Zwykle złym pomysłem jest, gdy klasy bazowe wiedzą o swoich klasach pochodnych. Aby to poprawić, powinniśmy użyć wzorca fabryki abstrakcyjnej3 i utworzyć DayDateFactory. Fabryka ta utworzy potrzebne nam instancje DayDate i dodatkowo odpowie na pytania o implementację, takie jak data minimalna i maksymalna. public abstract class DayDateFactory { private static DayDateFactory factory = new SpreadsheetDateFactory(); public static void setInstance(DayDateFactory factory) { DayDateFactory.factory = factory; } protected protected protected protected protected protected
  
  abstract abstract abstract abstract abstract abstract
  
  DayDate _makeDate(int ordinal); DayDate _makeDate(int day, DayDate.Month month, int year); DayDate _makeDate(int day, int month, int year); DayDate _makeDate(java.util.Date date); int _getMinimumYear(); int _getMaximumYear();
  
  public static DayDate makeDate(int ordinal) { return factory._makeDate(ordinal); } public static DayDate makeDate(int day, DayDate.Month month, int year) { return factory._makeDate(day, month, year); }
  
  3
  
  [GOF].
  
  PRZEBUDOWA KLASY SERIALDATE
  
  283
  
  public static DayDate makeDate(int day, int month, int year) { return factory._makeDate(day, month, year); } public static DayDate makeDate(java.util.Date date) { return factory._makeDate(date); } public static int getMinimumYear() { return factory._getMinimumYear(); } public static int getMaximumYear() { return factory._getMaximumYear(); } }
  
  Ta klasa fabryki zastępuje metody createInstance za pomocą metod makeDate, co nieco poprawia nazewnictwo [N1]. Domyślnie wykorzystywana jest klasa SpreadsheetDateFactory, ale może to być zmienione w dowolnym momencie przez użycie innej fabryki. Metody statyczne, które delegują do metod abstrakcyjnych, korzystają z połączenia wzorców: singleton 4, dekorator5 i fabryka abstrakcyjna (moim zdaniem, wzorców bardzo użytecznych). Kod SpreadsheetDateFactory wygląda następująco: public class SpreadsheetDateFactory extends DayDateFactory { public DayDate _makeDate(int ordinal) { return new SpreadsheetDate(ordinal); } public DayDate _makeDate(int day, DayDate.Month month, int year) { return new SpreadsheetDate(day, month, year); } public DayDate _makeDate(int day, int month, int year) { return new SpreadsheetDate(day, month, year); } public DayDate _makeDate(Date date) { final GregorianCalendar calendar = new GregorianCalendar(); calendar.setTime(date); return new SpreadsheetDate( calendar.get(Calendar.DATE), DayDate.Month.make(calendar.get(Calendar.MONTH) + 1), calendar.get(Calendar.YEAR)); } protected int _getMinimumYear() { return SpreadsheetDate.MINIMUM_YEAR_ED; } protected int _getMaximumYear() { return SpreadsheetDate.MAXIMUM_YEAR_ED; } }
  
  4
  
  Ibid.
  
  5
  
  Ibid.
  
  284
  
  ROZDZIAŁ 16.
  
  Jak można zauważyć, przeniosłem już zmienne MINIMUM_YEAR_ED oraz MAXIMUM_YEAR_ ED do SpreadsheetDate, do której to klasy one faktycznie należą [G6]. Następnym problemem w DayDate są stałe dni rozpoczynające się w wierszu 109. Powinny być one osobnym typem wyliczeniowym [J3]. Przedstawiałem już ten wzorzec, więc nie będę się tutaj powtarzał. Można go zobaczyć w końcowym listingu. Następnie mamy serię zmiennych zaczynających się od LAST_DAY_OF_MONTH w wierszu 140. Moim pierwszym zastrzeżeniem było to, że opisujące je komentarze są niarowe [C3]. Ich nazwy są wystarczające. Dlatego usunę te komentarze. Wydaje się, że nie ma powodu, aby ta tabela nie była prywatna [G8], ponieważ dostępna jest funkcja statyczna lastDayOfMonth, która dostarcza tych samych danych. Następna tabela, AGGREGATE_DAYS_TO_END_OF_MONTH, jest nieco tajemnicza, ponieważ nie jest używana w bibliotece JCommon [G9]. Dlatego ją usunąłem. To samo dotyczy LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_MONTH. Następna tabela, AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH, jest używana wyłącznie w SpreadsheetDate (wiersz 434. oraz 473.). Powstaje pytanie, czy nie powinna zostać przeniesiona do SpreadsheetDate. Argument za nieprzenoszeniem jej jest taki, że tabela ta nie jest specyficzna dla żadnej określonej implementacji [G6]. Z drugiej strony, nie istnieje inna implementacja poza SpreadsheetDate, więc tabela powinna zostać przeniesiona możliwie blisko miejsca użycia [G10]. Najlepszym dla mnie argumentem jest konieczność zachowania spójności [G11], więc powinniśmy oznaczyć tę tabelę jako prywatną i udostępnić ją za pomocą funkcji, na przykład julianDateOf LastDayOfMonth. Wydaje się, że nikt nie potrzebuje tej funkcji. Co więcej, tabela może być łatwo przeniesiona do DayDate, jeżeli nowa implementacja tej klasy będzie jej potrzebowała. Dlatego ją przeniosłem. To samo dotyczy LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_MONTH. Następnie mamy trzy zestawy stałych, które mogą być zmienione na typy wyliczeniowe (wiersze od 162. do 205.). Pierwszy z nich pozwala na wybranie tygodnia w miesiącu. Zamieniłem go na typ wyliczeniowy o nazwie WeekInMonth. public enum WeekInMonth { FIRST(1), SECOND(2), THIRD(3), FOURTH(4), LAST(0); public final int index; WeekInMonth(int index) { this.index = index; } }
  
  Drugi zestaw stałych (wiersze 177. – 187.) jest nieco brzydszy. Stałe INCLUDE_NONE, INCLUDE_FIRST, INCLUDE_SECOND oraz INCLUDE_BOTH są wykorzystywane do opisywania, czy zdefiniowane daty końcowe zakresu powinny być dołączone do tego zakresu. Matematycznie rzecz ujmując, opisują
  
  PRZEBUDOWA KLASY SERIALDATE
  
  285
  
  terminy „otwarty okres”, „półotwarty okres” oraz „zamknięty okres”. Uważam, że jaśniejsze będzie użycie nomenklatury matematycznej [N3], więc zmieniłem je na typ wyliczeniowy o nazwie DateInterval ze stałymi CLOSED, CLOSED_LEFT, CLOSED_RIGHT oraz OPEN. Trzeci zbiór stałych (wiersze 189. – 205.) opisuje, czy wyszukiwanie określonego dnia tygodnia powinno dać w wyniku ostatnie, następne lub najbliższe wystąpienie. Wybór tej nazwy jest co najmniej trudny. W końcu zdecydowałem się na WeekdayRange ze stałymi LAST, NEXT oraz NEAREST. Niekoniecznie można zgadzać się z wybranymi przeze mnie nazwami. Mają one dla mnie sens, ale niekoniecznie mogą mieć sens dla innych. Jednak są one teraz w takiej postaci, którą można bardzo łatwo zmieniać [J3]. Nigdzie nie są przekazywane w postaci liczb — są przekazywane jako symbole. Można użyć funkcji IDE „zmień nazwę” do zmiany nazwy lub korzystać z nich bez obawy, że w innym miejscu kodu opuściliśmy -1 lub 2 albo że któraś z deklaracji argumentu int została źle opisana. Pole opisowe z wiersza 208. nie jest już nigdzie używane. Usunąłem je więc razem z jego akcesorem i mutatorem. Dodatkowo usunąłem zdegenerowany konstruktor domyślny z wiersza 213. [G12]. Kompilator wygeneruje go za nas. Możemy pominąć metodę isValidWeekdayCode (wiersze 216. – 238.), ponieważ usunęliśmy ją podczas tworzenia typu wyliczeniowego Day. Dotarliśmy więc do metody stringToWeekdayCode (wiersze 242. – 270.). Komentarze Javadoc, które nie dodają informacji do sygnatury metody, są jedynie wypełniaczem [C3], [G12]. Jedyną wartością tego komentarza Javadoc jest opis zwracanej wartości -1. Jednak ponieważ skorzystaliśmy z typu wyliczeniowego Day, komentarz ten jest teraz nieprawidłowy [C2]. Obecnie metoda zgłasza wyjątek IllegalArgumentException. Usunąłem więc Javadoc. Usunąłem również słowa kluczowe final z deklaracji argumentów i zmiennych. Można powiedzieć, że nie dodają one żadnej rzeczywistej wartości, a jedynie zaciemniają kod [G12]. Eliminacja słów kluczowych final kłóci się z pewnymi konwencjami. Na przykład Robert Simmons6 gorąco zachęca nas do „korzystania z final w całym kodzie”. Nie zgadzam się z tym. Uważam, że istnieje trochę dobrych zastosowań final, takich jak niektóre stałe final, ale w innych przypadkach to słowo kluczowe niewiele daje poza zaśmiecaniem kodu. Być może uważam tak, ponieważ błędy, przed jakimi zabezpiecza słowo kluczowe final, mogą być wcześniej przechwycone przez pisane przeze mnie testy jednostkowe. Nie podobają mi się powtórzone instrukcje if [G5] wewnątrz pętli for (wiersze 259. oraz 263.), więc połączyłem je za pomocą operatora || w jedną instrukcję if. Wykorzystałem również typ wyliczeniowy Day do sterowania pętlą i wprowadziłem kilka innych kosmetycznych zmian.
  
  6
  
  [Simmons04], s. 73.
  
  286
  
  ROZDZIAŁ 16.
  
  Zauważyłem również, że metoda ta nie należy tak naprawdę do DayDate. Jest to funkcja analizująca wartość Day. Dlatego przeniosłem ją do typu wyliczeniowego Day. Jednak spowodowało to, że typ Day stał się dosyć duży. Ponieważ zgodnie z koncepcją Day nie zależy od DayDate, przeniosłem typ wyliczeniowy Day poza klasę DayDate, do osobnego pliku źródłowego [G13]. Przeniosłem do niego również następną funkcję, weekdayCodeToString (wiersze 272. – 286.), i nazwałem ją toString. public enum Day { MONDAY(Calendar.MONDAY), TUESDAY(Calendar.TUESDAY), WEDNESDAY(Calendar.WEDNESDAY),s THURSDAY(Calendar.THURSDAY), FRIDAY(Calendar.FRIDAY), SATURDAY(Calendar.SATURDAY), SUNDAY(Calendar.SUNDAY); public final int index; private static DateFormatSymbols dateSymbols = new DateFormatSymbols(); Day(int day) { index = day; } public static Day make(int index) throws IllegalArgumentException { for (Day d : Day.values()) if (d.index == index) return d; throw new IllegalArgumentException( String.format("Niedozwolony indeks dnia: %d.", index)); } public static Day parse(String s) throws IllegalArgumentException { String[] shortWeekdayNames = dateSymbols.getShortWeekdays(); String[] weekDayNames = dateSymbols.getWeekdays();
  
  }
  
  }
  
  s = s.trim(); for (Day day : Day.values()) { if (s.equalsIgnoreCase(shortWeekdayNames[day.index]) || s.equalsIgnoreCase(weekDayNames[day.index])) { return day; } } throw new IllegalArgumentException( String.format("%s nie jest prawidłową nazwą dnia", s));
  
  public String toString() { return dateSymbols.getWeekdays()[index]; }
  
  Następnie mamy dwie funkcje getMonths (wiersze 288. – 316.). Pierwsza wywołuje drugą. Druga nie jest wywoływana nigdzie poza pierwszą. Dlatego połączyłem te funkcje, znacznie je upraszczając [G9], [G12], [F4]. Na koniec zmieniłem nazwę na bardziej sugestywną [N1]. public static String[] getMonthNames() { return dateFormatSymbols.getMonths(); }
  
  PRZEBUDOWA KLASY SERIALDATE
  
  287
  
  Funkcja isValidMonthCode (wiersze 326. – 346.) przestała być potrzebna przez zastosowanie typu wyliczeniowego Month, więc ją usunąłem [G9]. Metoda monthCodeToQuarter (wiersze 356. – 375.) wygląda na przypadek „zazdrości o funkcje”7 (ang. Feature Envy) [G14] i prawdopodobnie należy do typu wyliczeniowego Month jako metoda quarter. Dlatego ją zastąpiłem. public int quarter() { return 1 + (index-1)/3; }
  
  Spowodowało to, że typ wyliczeniowy Month stał się tak duży, iż powinien stać się osobną klasą. Przeniosłem go więc poza DayDate, zachowując spójność z typem wyliczeniowym Day [G11], [G13]. Następne dwie metody noszą nazwę monthCodeToString (wiersze 377. – 426.). Również w tym przypadku mamy wzorzec wywołania jednej metody z drugiej, z dodatkowo przekazanym znacznikiem. Zwykle przekazywanie znacznika jako argumentu funkcji jest złym pomysłem, szczególnie gdy znacznik wybiera format danych wyjściowych [G15]. Zmieniłem nazwę tej funkcji, zmieniłem strukturę i uprościłem ją, a następnie przeniosłem do typu wyliczeniowego Month [N1], [N3], [C3], [G14]. public String toString() { return dateFormatSymbols.getMonths()[index - 1]; } public String toShortString() { return dateFormatSymbols.getShortMonths()[index - 1]; }
  
  Kolejną metodą jest stringToMonthCode (wiersze 428. – 472.). Zmieniłem nazwę tej funkcji i uprościłem ją, a następnie przeniosłem do typu wyliczeniowego Month [N1], [N3], [C3], [G14], [G12]. public static Month parse(String s) { s = s.trim(); for (Month m : Month.values()) if (m.matches(s)) return m; try { return make(Integer.parseInt(s)); } catch (NumberFormatException e) {} throw new IllegalArgumentException("Niewłaściwy miesiąc " + s); } private boolean matches(String s) { return s.equalsIgnoreCase(toString()) || s.equalsIgnoreCase(toShortString()); }
  
  7
  
  [Refactoring].
  
  288
  
  ROZDZIAŁ 16.
  
  Metoda isLeapYear (wiersze 495. – 513.) powinna być bardziej ekspresyjna [G16]. public static boolean isLeapYear(int year) { boolean fourth = year % 4 == 0; boolean hundredth = year % 100 == 0; boolean fourHundredth = year % 400 == 0; return fourth && (!hundredth || fourHundredth); }
  
  Następna funkcja, leapYearCount (wiersze 519. – 536.), nie należy do DayDate. Nic jej nie wywołuje poza dwoma metodami z SpreadsheetDate. Dlatego przeniosłem ją dalej. Funkcja lastDayOfMonth (wiersze 538. – 560.) korzysta z tablicy LAST_DAY_OF_MONTH. Tablica należy naprawdę do typu wyliczeniowego Month [G17], więc ją tam przeniosłem. Dodatkowo uprościłem ją i zmieniłem na bardziej ekspresyjną [G16]. public static int lastDayOfMonth(Month month, int year) { if (month == Month.FEBRUARY && isLeapYear(year)) return month.lastDay() + 1; else return month.lastDay(); }
  
  Kolejne funkcje są bardziej interesujące. Następną funkcją jest addDays (wiersze 562. – 567.). Po pierwsze, ponieważ ta funkcja działa na zmiennych DayDate, nie powinna być statyczna [G18]. Dlatego zmieniłem ją na metodę instancyjną. Po drugie, wywołuje ona funkcję toSerial. Funkcja ta powinna zostać nazwana toOrdinal [N1]. Dodatkowo metoda ta może być uproszczona. public DayDate addDays(int days) { return DayDateFactory.makeDate(toOrdinal() + days); }
  
  To samo dotyczy addMonths (wiersze 578. – 602.). Powinna to być metoda instancyjna [G18]. Algorytm jest dość skomplikowany, więc użyłem objaśniających zmiennych tymczasowych8 [G19], aby był bardziej przejrzysty. Dodatkowo zmieniłem metodę getYYY na getYear [N1]. public DayDate addMonths(int months) { int thisMonthAsOrdinal = 12 * getYear() + getMonth().index - 1; int resultMonthAsOrdinal = thisMonthAsOrdinal + months; int resultYear = resultMonthAsOrdinal / 12; Month resultMonth = Month.make(resultMonthAsOrdinal % 12 + 1); int lastDayOfResultMonth = lastDayOfMonth(resultMonth, resultYear); int resultDay = Math.min(getDayOfMonth(), lastDayOfResultMonth); return DayDateFactory.makeDate(resultDay, resultMonth, resultYear); }
  
  W funkcji addYears (wiersze 604. – 626.) nie ma żadnych nowych niespodzianek. public DayDate plusYears(int years) { int resultYear = getYear() + years; int lastDayOfMonthInResultYear = lastDayOfMonth(getMonth(), resultYear); int resultDay = Math.min(getDayOfMonth(), lastDayOfMonthInResultYear); return DayDateFactory.makeDate(resultDay, getMonth(), resultYear); }
  
  8
  
  [Beck97].
  
  PRZEBUDOWA KLASY SERIALDATE
  
  289
  
  Cichutki głosik w mojej głowie namawiał mnie na zmianę tych metod ze statycznych na instancyjne. Czy wyrażenie date.addDays(5) jasno pokazuje, że obiekt date nie zmienia się i zwracany jest nowy obiekt DayDate? Czy też błędnie przyjmujemy, że do obiektu date zostanie dodanych pięć dni? Można uważać, że nie jest to duży problem, ale poniższy fragment kodu pokazuje, że może to być bardzo mylące [G20]. DayDate date = DateFactory.makeDate(5, Month.DECEMBER, 1952); date.addDays(7); // Przesuwamy datę o tydzień.
  
  Ktoś, kto czyta ten kod, najprawdopodobniej przyjmie, że addDays zmienia obiekt date. Musimy wybrać nazwę, która rozwieje tę niejasność [N4]. Zmieniłem więc nazwy na plusDays oraz plusMonths. Wydaje mi się, że przeznaczenie tej metody jest dobrze oddawane przez DayDate date = oldDate.plusDays(5);
  
  natomiast poniższe wywołanie nie da się przeczytać tak płynnie, aby czytelnik przyjął, że zmieniany jest obiekt date: date.plusDays(5);
  
  Algorytmy stają się coraz bardziej interesujące. Metoda getPreviousDayOfWeek (wiersze 628. – 660.) działa, ale jest skomplikowana. Po przeanalizowaniu, co naprawdę jest tu wykonywane [G21], byłem w stanie uprościć ją i użyć objaśniających zmiennych tymczasowych [G19], aby ją zapisać jaśniej. Zmieniłem ją również z metody statycznej na instancyjną [G18] i usunąłem powtórzoną metodę instancyjną [G5] (wiersze 997. – 1008.). public DayDate getPreviousDayOfWeek(Day targetDayOfWeek) { int offsetToTarget = targetDayOfWeek.index - getDayOfWeek().index; if (offsetToTarget >= 0) offsetToTarget -= 7; return plusDays(offsetToTarget); }
  
  Dokładnie taką samą analizę zastosowałem w getFollowingDayOfWeek (wiersze 662. – 693.), uzyskując analogiczne wyniki. public DayDate getFollowingDayOfWeek(Day targetDayOfWeek) { int offsetToTarget = targetDayOfWeek.index - getDayOfWeek().index; if (offsetToTarget <= 0) offsetToTarget += 7; return plusDays(offsetToTarget); }
  
  Następną funkcją jest getNearestDayOfWeek (wiersze 695. – 726.), którą poprawiliśmy już wcześniej. Jednak wprowadzone zmiany nie są spójne z bieżącym wzorcem zastosowanym w ostatnich dwóch funkcjach [G11]. Aby uzyskać spójność, skorzystałem z kilku objaśniających zmiennych tymczasowych [G19] do wyjaśnienia algorytmu. public DayDate getNearestDayOfWeek(final Day targetDay) { int offsetToThisWeeksTarget = targetDay.index - getDayOfWeek().index; int offsetToFutureTarget = (offsetToThisWeeksTarget + 7) % 7; int offsetToPreviousTarget = offsetToFutureTarget - 7;
  
  }
  
  290
  
  if (offsetToFutureTarget > 3) return plusDays(offsetToPreviousTarget); else return plusDays(offsetToFutureTarget);
  
  ROZDZIAŁ 16.
  
  Metoda getEndOfCurrentMonth (wiersze 728. – 740.) jest dziwna, ponieważ jest to zmienna instancyjna, która „zazdrości” [G14] własnej klasie przez oczekiwanie argumentu DayDate. Zmieniłem ją na prawdziwą metodę instancyjną i rozjaśniłem kilka nazw. public DayDate getEndOfMonth() { Month month = getMonth(); int year = getYear(); int lastDay = lastDayOfMonth(month, year); return DayDateFactory.makeDate(lastDay, month, year); }
  
  Przebudowa metody weekInMonthToString (wiersze 742. – 761.) okazała się jednak bardzo interesująca. Przy użyciu narzędzi środowiska IDE na początek przeniosłem metodę do typu wyliczeniowego WeekInMonth, który został utworzony nieco wcześniej. Następnie zmieniłem nazwę tej metody na toString. Potem zmieniłem ją z metody statycznej na instancyjną. Testy nadal były wykonywane prawidłowo (czy wiesz, do czego zmierzam?). Następnie zupełnie ją usunąłem! Pięć asercji przestało działać (wiersze 411. – 415., listing B.4 w dodatku B). Zmieniłem te wiersze tak, aby wykorzystywane były nazwy stałych typu wyliczeniowego (FIRST, SECOND, …). Wszystkie testy były wykonywane prawidłowo. Czy możesz powiedzieć, dlaczego? Czy widzisz, dlaczego każdy z tych kroków był potrzebny? Narzędzie przebudowy kontroluje, czy wszystkie poprzednie wywołania weekInMonthToString obecnie są zamienione na toString ze stałych typu wyliczeniowego weekInMonth, ponieważ wszystkie stałe wyliczeniowe implementują metodę toString, która po prostu zwraca ich nazwę. Niestety, było to zbyt proste. Niezależnie od tego, jak wspaniały był łańcuch przebudowy, ostatecznie zorientowałem się, że jedynymi użytkownikami tej funkcji były zmodyfikowane przeze mnie testy, więc je usunąłem. Oszukasz mnie raz — wstydź się. Gdy oszukasz mnie po raz drugi, ja powinienem się wstydzić. Gdy zorientowałem się, że nic innego poza testami nie wywołuje metody relativeToString (wiersze 765. – 781.), po prostu usunąłem funkcję i jej testy. W końcu dotarliśmy do metod abstrakcyjnych tej klasy abstrakcyjnej. Pierwsza jest najbardziej właściwa: toSerial (wiersze 838. – 844.). Na początku tego rozdziału zmieniłem jej nazwę na toOrdinal. Patrząc na jej kontekst, zdecydowałem się na zmianę jej nazwy na getOrdinalDay. Następną metodą abstrakcyjną jest toDate (wiersze 838. – 844.). Konwertuje ona DayDate na java.util.Date . Dlaczego ta metoda jest abstrakcyjna? Jeżeli spojrzymy na implementację w SpreadsheetDate (wiersze 198. – 207., listing B.5 w dodatku B), okaże się, że nie zależy ona od niczego w implementacji tej klasy [G6]. Dlatego przesunąłem ją w górę. Metody getYYYY, getMonth oraz getDayOfMonth tworzą ładną abstrakcję. Jednak metoda gatDayOfWeek jest kolejną, która powinna być wyjęta z SpreadSheetDate, ponieważ nie zależy od niczego innego, jak tylko od elementów znajdujących się w DayDate [G6]. A może nie?
  
  PRZEBUDOWA KLASY SERIALDATE
  
  291
  
  Jeżeli przyjrzymy się jej dokładnie (wiersz 247., listing B.5 w dodatku B), zauważymy, że algorytm niejawnie zależy od położenia dni w kolejności (inaczej mówiąc, który dzień tygodnia ma indeks 0). Tak więc, mimo że ta funkcja nie ma fizycznych zależności, które nie mogą być przeniesione do DayDate, posiada zależności logiczne. Tego typu zależności logiczne budzą moje wątpliwości [G22]. Jeżeli coś zależy logicznie od implementacji, to powinno również zależeć fizycznie. Ponadto wydaje mi się, że sam algorytm może być ogólny, a tylko niewielka jego część powinna być zależna od implementacji [G6]. Dlatego utworzyłem metodę abstrakcyjną w DayDate, o nazwie getDayOfWeekForOrdinalZero, i do SpreadsheetDate dodałem implementację zwracającą Day.SATURDAY. Następnie przeniosłem metodę getDayOfWeek do DayDate i zmieniłem ją, aby wywoływała getOrdinalDay oraz getDayOfWeekForOrdinalZero. public Day getDayOfWeek() { Day startingDay = getDayOfWeekForOrdinalZero(); int startingOffset = startingDay.index - Day.SUNDAY.index; return Day.make((getOrdinalDay() + startingOffset) % 7 + 1); }
  
  Proponuję przyjrzeć się uważniej komentarzowi znajdującemu się w wierszach od 895. do 899. Czy takie powtórzenie jest naprawdę potrzebne? Jak zwykle, usunąłem ten komentarz wraz z innymi. Następną metodą jest compare (wiersze 902. – 913.). Po raz kolejny metoda ta jest na niewłaściwym poziomie abstrakcji [G6], więc przeniosłem jej implementację do DayDate. Dodatkowo nazwa nie jest wystarczająco komunikatywna [N1]. Metoda faktycznie zwraca różnicę w dniach w stosunku do argumentu. Dlatego zmieniłem jej nazwę na daysSince. Zauważyłem też, że nie ma dla tej metody testów, więc je dopisałem. Sześć kolejnych funkcji (wiersze od 915. do 980.) to funkcje abstrakcyjne, które powinny być implementowane w DayDate. Dlatego wyciągnąłem je z SpreadsheetDate. Ostatnia funkcja, isInRange (wiersze 982. – 995.), również wymaga wydobycia i przebudowy. Instrukcja switch jest niezbyt elegancka [G23] i może być zamieniona przez przeniesienie przypadków do typu wyliczeniowego DateInterval. public enum DateInterval { OPEN { public boolean isIn(int d, int left, int right) { return d > left && d < right; } }, CLOSED_LEFT { public boolean isIn(int d, int left, int right) { return d >= left && d < right; } }, CLOSED_RIGHT { public boolean isIn(int d, int left, int right) { return d > left && d <= right; } }, CLOSED {
  
  292
  
  ROZDZIAŁ 16.
  
  public boolean isIn(int d, int left, int right) { return d >= left && d <= right; }
  
  }
  
  }; public abstract boolean isIn(int d, int left, int right);
  
  public boolean isInRange(DayDate d1, DayDate d2, DateInterval interval) { int left = Math.min(d1.getOrdinalDay(), d2.getOrdinalDay()); int right = Math.max(d1.getOrdinalDay(), d2.getOrdinalDay()); return interval.isIn(getOrdinalDay(), left, right); }
  
  W ten sposób dotarliśmy do końca klasy DayDate. Kolejnym krokiem będzie ponowne przejrzenie całej klasy i sprawdzenie, czy przepływ kodu jest właściwy. Otwierający komentarz jest od dawna niewłaściwy, więc skróciłem go i poprawiłem [C2]. Następnie przeniosłem pozostałe typy wyliczeniowe do osobnych plików [G12]. Potem przeniosłem zmienną statyczną (dateFormatSymbols) oraz trzy metody statyczne (getMonthNames, isLeapYear, lastDayOfMonth) do nowej klasy o nazwie DateUtil [G6]. Przeniosłem metody abstrakcyjne w górę, tam gdzie powinny być [G24]. Zmieniłem Month.make na Month.fromInt [N1] i wykonałem to samo w przypadku pozostałych typów wyliczeniowych. Dodatkowo we wszystkich typach wyliczeniowych utworzyłem akcesor toInt() i pole index zmieniłem na prywatne. Znalazłem również kilka interesujących powtórzeń [G5] w plusYears oraz plusMonths, które mogłem wyeliminować przez wyodrębnienie nowej metody o nazwie correctLastDayOfMonth, co spowodowało, że wszystkie trzy metody są znacznie bardziej czytelne. Usunąłem również magiczną liczbę 1 [G25], zastępując ją wywołaniami, odpowiednio: Month.JANU ARY.toInt() lub Day.SUNDAY.toInt(). Poświęciłem również trochę czasu klasie SpreadsheetDate, poprawiając algorytm. Końcowy wynik znajduje się na listingach od B.7 do B.16 w dodatku B. Interesujące jest, że pokrycie kodu w DayDate zmniejszyło się do 84,9 procent. Stało się tak nie z powodu mniejszej liczby testowanych funkcji — po prostu klasa na tyle się zmniejszyła, że tych kilka niepokrytych wierszy ma większą wagę. DayDate ma obecnie pokrytych testami 45 z 53 instrukcji wykonywalnych. Niepokryte wiersze są tak proste, że nie warto ich testować.
  
  Zakończenie Kolejny raz zadziałaliśmy zgodnie z zasadą skautów. Zwróciliśmy kod nieco czyściejszy, niż go pobraliśmy. Zajęło to trochę czasu, ale się opłaciło. Pokrycie kodu testami zwiększyło się, zostało poprawionych kilka błędów, a kod został skrócony i jest bardziej zrozumiały. Mamy nadzieję, że następna osoba, która zajrzy do tego kodu, uzna, iż jest łatwiejszy w użyciu niż wcześniej. Mamy również nadzieję, że osoba ta usprawni kod w większym stopniu niż my.
  
  PRZEBUDOWA KLASY SERIALDATE
  
  293
  
  Bibliografia [GOF]: Gamma i inni, Elements of Reusable Object Oriented Software, Addison-Wesley 1996. [Simmons04]: Robert Simmons Jr., Hardcore Java, O’Reilly 2004. [Refactoring]: Martin Fowler i inni, Refactoring: Improving the Design of Existing Code, AddisonWesley 1999. [Beck97]: Kent Beck, Smalltalk Best Practice Patterns, Prentice Hall 1997.
  
  294
  
  ROZDZIAŁ 16.
  
  ROZDZIAŁ 17.
  
  Zapachy kodu i heurystyki
  
  Martin Fowler zidentyfikował wiele różnych „zapachów W kodu”. Na znajdującej się dalej liście znajduje się wiele zapachów zidentyfikowanych przez Martina SWOJEJ WSPANIAŁEJ KSIĄŻCE
  
  REFACTORING1
  
  i jeszcze więcej określonych przeze mnie. Dodatkowo dołączyłem inne perełki i heurystyki, którymi chciałbym się podzielić.
  
  1
  
  [Refactoring].
  
  295
  
  Listę tę napisałem, gdy przeglądałem kilka różnych programów i przebudowywałem je. Wprowadzając zmianę, zadawałem sobie pytanie, dlaczego ją wprowadzam, a następnie zapisywałem powód. Wynikiem jest dosyć długa lista elementów, które brzydko mi pachną, gdy czytam kod źródłowy. Lista ta może być czytana od początku do końca, jak również używana jako skorowidz. W dodatku C znajduje się lista odwołań każdej heurystyki, zawierająca wyszczególnienie miejsc w tekście, w których została użyta.
  
  Komentarze C1. Niewłaściwe informacje Niewłaściwe jest, aby komentarze przechowywały informacje, które lepiej przechowywać w innych systemach, takich jak system kontroli wersji, system śledzenia błędów lub inny system przechowywania danych. Na przykład historia zmian jedynie zaciemnia pliki źródłowe wieloma wierszami historycznego i mało interesującego tekstu. Zwykle metadane, takie jak autorzy, data ostatniej modyfikacji, numer SPR itd., nie powinny występować w komentarzach. Komentarze powinny być zarezerwowane dla informacji technicznych o kodzie i projekcie.
  
  C2. Przestarzałe komentarze Komentarz, który stał się nieistotny i nieprawidłowy, jest przestarzały. Komentarze bardzo szybko się starzeją. Najlepiej nie pisać komentarzy, które mogą utracić aktualność. Jeżeli znajdziemy przestarzały komentarz, najlepiej jak najszybciej go zaktualizować lub usunąć. Przestarzałe komentarze mają tendencję do utraty łączności z opisywanym kodem. Stają się one pływającymi wyspami nieistotności i błędnymi kierunkowskazami w kodzie.
  
  C3. Niarowe komentarze Komentarz jest niarowy, jeżeli opisuje coś, co wystarczająco dobrze samo się opisuje. Na przykład: i++; // Zwiększenie i
  
  Innym przykładem jest Javadoc niezawierający więcej informacji (a nawet mniej) niż sygnatura funkcji: /** * @param sellRequest * @return * @throws ManagedComponentException */ public SellResponse beginSellItem(SellRequest sellRequest) throws ManagedComponentException
  
  Komentarze powinny informować o tym, o czym nie może powiedzieć sam kod.
  
  296
  
  ROZDZIAŁ 17.
  
  C4. Źle napisane komentarze Komentarz, który wart jest napisania, trzeba napisać dobrze. Jeżeli decydujemy się na napisanie komentarza, musimy poświęcić trochę czasu na upewnienie się, że jest to najlepszy komentarz, jaki mogliśmy napisać. Należy uważnie dobierać słowa, przestrzegać zasad odmiany i interpunkcji. Nie pisać chaotycznie! Nie pisać o oczywistościach. Pisać zwięźle.
  
  C5. Zakomentowany kod Do szaleństwa doprowadzają mnie połacie zakomentowanego kodu. Kto będzie wiedział, jak stary jest ten kod? Kto będzie wiedział, czy jest on znaczący, czy nie? Dodatkowo nikt go nie skasuje, ponieważ każdy zakłada, że ktoś inny go potrzebuje lub ma względem niego jakieś plany. Komentarz taki tkwi w kodzie przez dłuższy czas, psując się i z każdym dniem tracąc na znaczeniu. Wywołuje funkcje, które już nie istnieją. Używa zmiennych, których nazwy zostały zmienione. Korzysta z konwencji, które już od dawna nie obowiązują. Zanieczyszcza zawierający go moduł i przeszkadza ludziom, którzy go czytają. Zakomentowany kod jest potworny. Gdy zobaczysz zakomentowany kod, usuń go! Nie obawiaj się, system kontroli wersji nadal go pamięta. Jeżeli ktokolwiek będzie go potrzebował, będzie mógł pobrać wcześniejszą wersję. Nie toleruj zachowywania zakomentowanego kodu.
  
  Środowisko E1. Budowanie wymaga więcej niż jednego kroku Budowanie (kompilacja i konsolidacja) projektu powinno być jedną prostą operacją. Niedopuszczalne jest pobieranie wielu elementów z systemu kontroli wersji. Nie powinniśmy potrzebować sekwencji zaawansowanych poleceń lub skryptów zależnych od kontekstu przeznaczonych do zbudowania poszczególnych elementów. Nie powinniśmy szukać dodatkowych plików JAR, XML i innych wymaganych przez system artefaktów. Powinniśmy mieć możliwość pobrania systemu za pomocą jednego prostego polecenia, a następnie wykonania innego prostego polecenia w celu jego zbudowania. svn get mySystem cd mySystem ant all
  
  E2. Testy wymagają więcej niż jednego kroku Powinniśmy być w stanie uruchomić wszystkie testy jednostkowe za pomocą jednego polecenia. Najlepszym przypadkiem jest uruchomienie wszystkich testów kliknięciem jednego przycisku w IDE. W najgorszym przypadku powinniśmy to osiągnąć, wywołując jedno proste polecenie powłoki. Możliwość wykonania wszystkich testów jest tak ważna i podstawowa, że powinna być szybka, łatwa i oczywista.
  
  ZAPACHY KODU I HEURYSTYKI
  
  297
  
  Funkcje F1. Niar argumentów Funkcje powinny mieć małą liczbę argumentów. Najlepszym przypadkiem jest... brak argumentów, następnie mogą być: jeden, dwa lub trzy argumenty. Większa liczba argumentów stanowi potencjalne źródło problemów (patrz „Argumenty funkcji” w rozdziale 3.).
  
  F2. Argumenty wyjściowe Argumenty wyjściowe są mało intuicyjne. Czytelnik oczekuje, że argumenty będą wejściem, a nie wyjściem. Jeżeli funkcja musi zmieniać stan czegokolwiek, powinna zmieniać stan własnego obiektu (patrz „Argumenty wyjściowe” w rozdziale 3.).
  
  F3. Argumenty znacznikowe Argumenty logiczne deklarują, że funkcja wykonuje więcej niż jedną operację. Są one mylące i powinny być eliminowane (patrz „Argumenty znacznikowe” w rozdziale 3.).
  
  F4. Martwe funkcje Metody, które nie są nigdy wywoływane, powinny być usuwane. Przechowywanie martwego kodu jest rozrzutnością. Nie trzeba się obawiać usuwania funkcji — system kontroli wersji nadal ją pamięta.
  
  Ogólne G1. Wiele języków w jednym pliku źródłowym Stosowane obecnie środowiska programowania umożliwiają umieszczanie wielu różnych języków w jednym pliku źródłowym. Na przykład plik źródłowy języka Java może zawierać fragmenty języków: XML, HTML, YAML, JavaDoc, polskiego, JavaScript i tak dalej. W przypadku plików JSP oprócz języka HTML można znaleźć kod Java, znaczniki biblioteki, komentarze w języku naturalnym, Javadoc, XML, JavaScript itd. Jest to co najmniej mylące. W idealnym przypadku jeden plik źródłowy powinien zawierać jeden i tylko jeden język. Realistycznie rzecz biorąc, konieczne będzie użycie więcej niż jednego. Jednak powinniśmy podjąć próbę ograniczenia liczby i zakresu dodatkowych języków w plikach źródłowych.
  
  298
  
  ROZDZIAŁ 17.
  
  G2. Oczywiste działanie jest nieimplementowane Zgodnie z „zasadą najmniejszego zaskoczenia2” każda funkcja lub klasa powinna być implementowana w taki sposób, aby inny programista mógł się tego spodziewać. Przyjrzyjmy się funkcji przekształcającej nazwę dnia na typ enum reprezentujący ten dzień: Day day = DayDate.StringToDay(String dayName);
  
  Możemy oczekiwać, że ciąg Monday zostanie zamieniony na Day.MONDAY. Możemy również oczekiwać, że przekształcane będą często stosowane skróty, a funkcja będzie ignorowała wielkość liter. Gdy takie oczywiste działania nie są implementowane, czytelnicy i użytkownicy kodu nie mogą polegać na swojej intuicji i nazwach funkcji. Tracą wówczas zaufanie do autora i muszą wrócić do czytania szczegółów kodu.
  
  G3. Niewłaściwe działanie w warunkach granicznych Wydaje się oczywiste, że kod powinien działać prawidłowo. Niestety, rzadko zdajemy sobie sprawę, jak skomplikowane jest prawidłowe działanie. Programiści często piszą funkcje, które według nich działają; ufają oni swojej intuicji, zamiast udowodnić, że kod działa we wszystkich sytuacjach skrajnych. Niczym nie można zastąpić dokładnej analizy. Każdy warunek graniczny, każdy problem i wyjątek reprezentuje coś, co może zepsuć elegancki i intuicyjny algorytm. Nie polegaj na swojej intuicji. Należy wyszukać wszystkie warunki graniczne i napisać dla nich testy.
  
  G4. Zdjęte zabezpieczenia Do wybuchu w Czarnobylu doszło dlatego, że dyrektor elektrowni wyłączał kolejne mechanizmy zabezpieczające. Zabezpieczenia te utrudniały przeprowadzanie eksperymentu. Eksperyment i tak się nie udał, a świat zobaczył pierwszą dużą cywilną katastrofę nuklearną. Zdejmowanie zabezpieczeń jest ryzykowne. Przejmowanie ręcznej kontroli nad wartością serialVersionUID może być niezbędne, ale zawsze jest ryzykowne. Wyłączanie określonych ostrzeżeń kompilatora (lub wszystkich ostrzeżeń!) może pomóc nam w prawidłowym skompilowaniu, ale niesie ryzyko nieskończonej sesji debugowania. Wyłączenie niewykonywanych testów i obiecanie sobie, że zajmiemy się nimi później, jest równie złe, jak postrzeganie kart kredytowych jako niewyczerpanego źródła darmowych pieniędzy.
  
  2
  
  Lub „zasadą najmniejszego zdziwienia”: http://en.wikipedia.org/wiki/Principle_of_least_astonishment.
  
  ZAPACHY KODU I HEURYSTYKI
  
  299
  
  G5. Powtórzenia Jest to jedna z najważniejszych zasad z tej książki i powinniśmy ją traktować bardzo poważnie. Niemal każdy autor piszący o projektowaniu oprogramowania wspomina o tej zasadzie. Dave Thomas oraz Andy Hunt nazwali ją zasadą DRY3 (ang. Don’t Repeat Yourself), czyli „nie powtarzaj się”. Kent Beck uznał ją za jedną z podstawowych zasad programowania ekstremalnego i nazwał ją „once, and only once”, czyli „raz i tylko raz”. Ron Jeffries uznał ją za drugą w hierarchii ważności, zaraz za wykonywaniem wszystkich testów. Za każdym razem, gdy widzimy powtórzenie w kodzie, reprezentuje ono utraconą możliwość abstrakcji. Powtórzenie takie może prawdopodobnie stać się funkcją albo zupełnie osobną klasą. Przez zamianę powtórzeń na takie abstrakcje zwiększamy słownik projektowanego przez nas języka. Inni programiści mogą skorzystać z tworzonych przez nas abstrakcji. Kodowanie staje się szybsze i bardziej odporne na błędy, ponieważ podwyższamy poziom abstrakcji. Najbardziej oczywistą formą powtórzenia jest występowanie fragmentów identycznego kodu, co wygląda, jakby któryś z programistów oszalał i wielokrotnie wklejał ten sam kod. Powinny być one zastąpione prostymi metodami. Bardziej subtelną formą jest łańcuch instrukcji switch-case lub if-else, który występuje wielokrotnie w różnych modułach i zawsze używany jest ten sam zbiór warunków. Powinny być one zastąpione polimorfizmem. Jeszcze bardziej subtelnymi powtórzeniami są moduły, które mają podobne algorytmy, ale nie mają podobnego kodu. Jest to również powtórzenie, które powinno być wyeliminowane przez użycie wzorców szablonu metody4 lub strategii5. Faktycznie, większość wzorców projektowych, jakie zostały zdefiniowane w ostatnich piętnastu latach, to dobrze znane sposoby na eliminowanie powtórzeń. Również postacie normalne Codda są strategią eliminowania powtórzeń ze schematu bazy danych. Samo programowanie obiektowe jest strategią organizacji modułów i eliminowania powtórzeń. Nie dziwi zatem fakt, że to samo dotyczy programowania strukturalnego. Uważam, że zasada została ustanowiona. Znajdź i wyeliminuj wszystkie powtórzenia.
  
  G6. Kod na nieodpowiednim poziomie abstrakcji Ważne jest, aby tworzyć abstrakcje, które oddzielają ogólne koncepcje na wyższym poziomie od szczegółów na niższym poziomie. Czasami robimy to przez tworzenie klas abstrakcyjnych, które przechowują koncepcje wyższego poziomu, a klasy dziedziczące po nich zawierają koncepcje niższych poziomów. Gdy stosujemy taki podział, musimy upewnić się, że jest kompletny. Chcemy, 3
  
  [PRAG].
  
  4
  
  [GOF].
  
  5
  
  [GOF].
  
  300
  
  ROZDZIAŁ 17.
  
  aby wszystkie koncepcje niższych poziomów znajdowały się w klasach pochodnych, a wszystkie koncepcje wyższego poziomu były w klasie bazowej. Na przykład stałe, zmienne lub funkcje użytkowe, które odnoszą się tylko do szczegółowej implementacji, nie powinny znajdować się w klasie bazowej. Klasa bazowa nie powinna nic o nich wiedzieć. Zasada ta dotyczy również plików źródłowych, komponentów i modułów. Dobry projekt oprogramowania wymaga, abyśmy rozdzielali koncepcje na różne poziomy i umieszczali je w różnych kontenerach. Czasami kontenery te są klasami bazowymi lub pochodnymi, a czasami są plikami źródłowymi, modułami lub komponentami. Niezależnie od zastosowanego przypadku, rozdzielenie powinno być pełne. Nie powinniśmy mieszać ze sobą koncepcji z niższych i wyższych poziomów. Weźmy pod uwagę następujący kod: public interface Stack { Object pop() throws EmptyException; void push(Object o) throws FullException; double percentFull(); class EmptyException extends Exception {} class FullException extends Exception {} }
  
  Funkcja percentFull znajduje się na niewłaściwym poziomie abstrakcji. Choć istnieje wiele implementacji Stack, w których koncepcja wypełnienia jest rozsądna, to jednak istnieją inne implementacje, które po prostu nie powinny wiedzieć, jak bardzo są wypełnione. Dlatego funkcja ta powinna być umieszczona w interfejsie dziedziczącym, na przykład BoundedStack. Ktoś może uważać, że taka implementacja powinna zwracać zero, jeżeli stos jest bez ograniczeń. Problem polega jednak na tym, że żaden stos nie jest naprawdę nieograniczony. Nie można naprawdę zapobiec wyjątkom OutOfMemoryException przez następujące sprawdzenia: stack.percentFull() < 50.0.
  
  Implementacja funkcji, która zwraca 0, będzie po prostu wprowadzała w błąd. Nie można wprowadzać w błąd lub maskować źle umieszczonej abstrakcji. Izolacja abstrakcji jest jednym z najtrudniejszych zadań programistów i w przypadku, gdy zostanie przeprowadzona źle, nie ma szybkiego sposobu poprawienia kodu.
  
  G7. Klasy bazowe zależne od swoich klas pochodnych Najczęstszym powodem podziału koncepcji na klasę bazową i pochodne jest to, że klasa bazowa wyższego poziomu może być niezależna od klas pochodnych niższego poziomu. Dlatego, gdy widzimy klasę bazową korzystającą z nazw swoich pochodnych, oczekujemy problemu. Klasy bazowe nie powinny nic wiedzieć o swoich potomkach. Istnieją oczywiście wyjątki od tej zasady. Czasami liczba klas pochodnych jest ściśle ustalona i klasa bazowa posiada kod wybierający pomiędzy tymi klasami. Widzieliśmy takie rozwiązanie w wielu implementacjach automatów skończonych. Jednak w takim przypadku klasy pochodne i klasa bazowa
  
  ZAPACHY KODU I HEURYSTYKI
  
  301
  
  są ściśle połączone i zawsze udostępniane razem, w tym samym pliku jar. W ogólnym przypadku chcemy mieć możliwość udostępniania klas bazowych i pochodnych w różnych plikach jar. Udostępnianie klas pochodnych w różnych plikach jar i zapewnienie, że bazowe pliki jar nic nie wiedzą o zawartości plików jar z klasami pochodnymi, pozwala nam na instalowanie systemów w indywidualnych i niezależnych komponentach. Gdy taki komponent zostanie zmodyfikowany, może być ponownie zainstalowany, bez konieczności instalowania komponentów bazowych. Oznacza to, że wpływ zmian jest znacznie obniżony, a utrzymanie działających systemów jest znacznie prostsze.
  
  G8. Za dużo informacji Dobrze zdefiniowane moduły mają bardzo małe interfejsy, które umożliwiają wykonanie wielu operacji. Źle zdefiniowane moduły mają szerokie i głębokie interfejsy, które wymuszają na nas tworzenie wielu różnych konstrukcji do wykonania prostych operacji. Dobrze zdefiniowane interfejsy nie posiadają wielu funkcji, od których zależą, więc sprzężenie jest niskie. Źle zdefiniowane interfejsy mają wiele funkcji, które należy wywołać, więc sprzężenie jest wysokie. Profesjonalni twórcy oprogramowania ograniczają liczbę elementów udostępnianych w interfejsach ich klas i modułów. Im mniej metod ma klasa, tym lepiej. Im mniej zmiennych jest wykorzystywanych w funkcji, tym lepiej. Im mniej zmiennych instancyjnych ma klasa, tym lepiej. Ukrywajmy nasze dane. Ukrywajmy funkcje narzędziowe. Ukrywajmy stałe i dane tymczasowe. Nie twórzmy klas z wieloma metodami i wieloma zmiennymi instancyjnymi. Nie twórzmy wielu zmiennych i funkcji zabezpieczonych dla naszych klas bazowych. Skoncentrujmy się na zachowaniu małych i ścisłych interfejsów. Eliminujmy sprzężenia przez ograniczanie informacji.
  
  G9. Martwy kod Martwy kod to taki, który nie jest wykonywany. Można znaleźć go w treści instrukcji if, które kontrolują nigdy niespełniane warunki. Można znaleźć go w blokach catch, dla których nigdy nie zostanie wywołane odpowiednie throw. Można go znaleźć w niewielkich metodach narzędziowych, które nie są nigdy wywoływane, lub w warunkach switch-case, które nigdy nie zostają spełnione. Problem z martwym kodem jest taki, że szybko zaczyna wydzielać zapach. Im jest starszy, tym ten zapach staje się silniejszy i kwaśniejszy. Dzieje się tak, ponieważ martwy kod nie jest w pełni aktualizowany w czasie zmian projektu. Nadal kompiluje się, ale nie jest zgodny z najnowszymi konwencjami i zasadami. Był on pisany w czasie, gdy system był inny. Gdy znajdziemy martwy kod, możemy zrobić tylko jedną właściwą rzecz. Zapewnijmy mu godny pochówek, usuwając go z systemu.
  
  302
  
  ROZDZIAŁ 17.
  
  G10. Separacja pionowa Zmienne i funkcje powinny być definiowane blisko miejsca, gdzie są użyte. Zmienne lokalne powinny być deklarowane bezpośrednio ponad pierwszym użyciem i powinny mieć mały zakres pionowy. Nie chcemy zmiennych lokalnych deklarowanych setki wierszy od ich zastosowania. Funkcje prywatne powinny być definiowane poniżej pierwszego zastosowania. Funkcje prywatne należą do zakresu całej klasy, ale i tak chcemy ograniczyć odległość w pionie pomiędzy wywołaniem a definicją. Znalezienie funkcji prywatnej powinno sprowadzać się do przewinięcia kodu w dół od pierwszego użycia.
  
  G11. Niespójność Jeżeli wykonujemy coś w określony sposób, wszystkie podobne zadania powinniśmy wykonywać w taki sam sposób. Odnosi się to do zasady najmniejszego zaskoczenia. Należy rozważnie wybierać konwencje i po ich wybraniu konsekwentnie je stosować. Jeżeli w określonej funkcji korzystamy ze zmiennej o nazwie response, zawierającej HttpServlet Response, to tej samej nazwy zmiennej powinniśmy używać we wszystkich innych funkcjach korzystających z obiektu HttpServletResponse. Jeżeli nazwiemy metodę processVerificationRequest, to powinniśmy użyć podobnej nazwy, takiej jak processDeletionRequest, dla metod przetwarzających inne rodzaje żądań. Tego typu prosta spójność, jeżeli jest konsekwentnie stosowana, może spowodować, że kod będzie znacznie łatwiejszy do czytania i modyfikacji.
  
  G12. Zaciemnianie Jakie jest zastosowanie domyślnego konstruktora bez implementacji? Służy on jedynie do zaciemniania kodu fragmentami niemającymi znaczenia. Zmienne, które nie są używane, nigdy niewywoływane funkcje, komentarze, które nie dodają żadnej informacji i tym podobne elementy zaciemniają kod i powinny zostać usunięte. Pliki źródłowe winny być uporządkowane, dobrze zorganizowane.
  
  G13. Sztuczne sprzężenia Elementy, które nie są od siebie zależne, nie powinny być sztucznie łączone. Na przykład ogólny typ enum nie powinien znajdować się w bardziej specjalizowanej klasie, ponieważ wymusza to na całej aplikacji korzystanie ze zbyt szczegółowych klas. To samo dotyczy funkcji statycznej ogólnego przeznaczenia zadeklarowanej w specjalizowanej klasie. Sztuczne sprzężenie to takie, które występuje pomiędzy dwoma niepowiązanymi bezpośrednio modułami. Jest to wynik umieszczenia zmiennej, stałej lub funkcji w tymczasowo wygodnej, choć niewłaściwej lokalizacji. Jest to wynik lenistwa i niedbalstwa.
  
  ZAPACHY KODU I HEURYSTYKI
  
  303
  
  Należy poświęcić trochę czasu na określenie, w którym miejscu powinny być zadeklarowane nasze funkcje, stałe i zmienne. Nie należy ich po prostu wrzucać w najwygodniejsze w danej chwili miejsce i pozostawiać ich tam.
  
  G14. Zazdrość o funkcje Jest to jeden z zapachów kodu6 Martina Fowlera. Klasa (lub metoda) powinna być zainteresowana zmiennymi i funkcjami należącymi do tej klasy, a nie zmiennymi i metodami innych klas. Gdy metoda korzysta z akcesorów i mutatorów innego obiektu do manipulowania danymi wewnątrz tego obiektu, to zazdrości zakresu klasy tego obiektu. Żałuje, że nie znajduje się wewnątrz innej klasy, by mieć bezpośredni dostęp do zmiennych, którymi manipuluje. Na przykład: public class HourlyPayCalculator { public Money calculateWeeklyPay(HourlyEmployee e) { int tenthRate = e.getTenthRate().getPennies(); int tenthsWorked = e.getTenthsWorked(); int straightTime = Math.min(400, tenthsWorked); int overTime = Math.max(0, tenthsWorked - straightTime); int straightPay = straightTime * tenthRate; int overtimePay = (int)Math.round(overTime*tenthRate*1.5); return new Money(straightPay + overtimePay); } }
  
  Metoda calculateWeeklyPay sięga do obiektu HourlyEmployee w celu uzyskania danych, na których operuje. Metoda calculateWeeklyPay zazdrości zakresu HourlyEmployee. „Żałuje” ona, że nie jest wewnątrz HourlyEmployee. Eliminujemy z kodu zazdrość o funkcje, ponieważ powoduje to ujawnienie jednej klasie wewnętrznej budowy innej klasy. Czasami jednak zazdrość o funkcje jest złem koniecznym. Weźmy pod uwagę następujący kod: public class HourlyEmployeeReport { private HourlyEmployee employee ; public HourlyEmployeeReport(HourlyEmployee e) { this.employee = e; }
  
  }
  
  String reportHours() { return String.format( "Nazwisko: %s\tGodziny:%d.%1d\n", employee.getName(), employee.getTenthsWorked()/10, employee.getTenthsWorked()%10); }
  
  Oczywiście, metoda reportHours zazdrości klasie HourlyEmployee. Z drugiej strony, nie chcemy, aby klasa HourlyEmployee znała szczegóły formatowania raportu. Przeniesienie tego ciągu formatującego do klasy HourlyEmployee złamałoby kilka zasad projektowania obiektowego7. Spowodowałoby sprzężenie HourlyEmployee z formatem raportu, wystawiając ją na zmiany w formacie. 6
  
  [Refactoring].
  
  7
  
  Dokładnie — zasadę pojedynczej odpowiedzialności, zasadę otwarty-zamknięty oraz zasadę wspólnego zamknięcia. Patrz [PPP].
  
  304
  
  ROZDZIAŁ 17.
  
  G15. Argumenty wybierające Trudno o coś bardziej wstrętnego, jak wiszący argument false na końcu wywołania funkcji. Co on oznacza? Co się stanie, jeżeli zmienimy go na true? Nie tylko trudno zapamiętać przeznaczenie argumentu wybierającego, ale również każdy argument wybierający łączy kilka funkcji w jednej. Argumenty wybierające są sposobem na uniknięcie podziału dużej funkcji na kilka mniejszych, wynikającym z lenistwa. Przeanalizujmy taki przykład: public int calculateWeeklyPay(boolean overtime) { int tenthRate = getTenthRate(); int tenthsWorked = getTenthsWorked(); int straightTime = Math.min(400, tenthsWorked); int overTime = Math.max(0, tenthsWorked - straightTime); int straightPay = straightTime * tenthRate; double overtimeRate = overtime ? 1.5 : 1.0 * tenthRate; int overtimePay = (int)Math.round(overTime*overtimeRate); return straightPay + overtimePay; }
  
  Można wywołać tę funkcję z wartością true, jeżeli nadgodziny są płatne ze współczynnikiem 1,5, lub false, jeżeli są płacone w zwykły sposób. Niewłaściwe jest, że musimy pamiętać, co oznacza wywołanie calculateWeeklyPay(false), gdy się na takie natkniemy. Jednak prawdziwym wstydem jest to, że autor nie korzysta z możliwości napisania następującego kodu: public int straightPay() { return getTenthsWorked() * getTenthRate(); } public int overTimePay() { int overTimeTenths = Math.max(0, getTenthsWorked() - 400); int overTimePay = overTimeBonus(overTimeTenths); return straightPay() + overTimePay; } private int overTimeBonus(int overTimeTenths) { double bonus = 0.5 * getTenthRate() * overTimeTenths; return (int) Math.round(bonus); }
  
  Oczywiście, argument wybierający nie musi być typu boolean. Może być to typ wyliczeniowy, całkowity lub inny, który może być użyty do wyboru zachowania funkcji. Zwykle lepiej mieć więcej funkcji, niż przekazywać pewien kod do funkcji w celu wybrania zachowania.
  
  G16. Zaciemnianie intencji Kod powinien być wyrazisty i zrozumiały. Rozwlekłe wyrażenia, notacja węgierska i magiczne liczby zaciemniają intencje autora. Mamy tu na przykład funkcję overTimePay: public int m_otCalc() { return iThsWkd * iThsRte + (int) Math.round(0.5 * iThsRte * Math.max(0, iThsWkd - 400) ); }
  
  Wygląda ona na małą i zwięzłą, ale jest kompletnie enigmatyczna. Warto poświęcić trochę czasu na ujawnienie czytelnikom zamierzeń naszego kodu. ZAPACHY KODU I HEURYSTYKI
  
  305
  
  G17. Źle rozmieszczona odpowiedzialność Jedną z najważniejszych decyzji twórcy oprogramowania jest rozmieszczenie kodu. Gdzie na przykład powinna znaleźć się stała PI? Czy powinna być w klasie Math? Być może należy do klasy Trigonometry? A może do klasy Circle? Ma tu zastosowanie zasada najmniejszego zaskoczenia. Kod powinien być umieszczony tam, gdzie spodziewa się go czytelnik. Stała PI powinna znaleźć się tam, gdzie są zadeklarowane funkcje trygonometryczne. Stała OVERTIME_RATE powinna znajdować się w klasie HourlyPay Calculator. Czasami chcemy zastosować „sprytne” rozwiązanie określonych funkcji. Umieszczamy funkcję tam, gdzie jest nam wygodnie, nie biorąc pod uwagę oczekiwań czytelnika. Możemy na przykład potrzebować raportu z sumą godzin przepracowanych przez pracownika. Możemy zsumować te godziny w kodzie drukującym raport albo spróbować tworzyć sumę w kodzie akceptującym karty czasu pracy. Decyzję tę będzie nam łatwiej podjąć, gdy spojrzymy na nazwy funkcji. Załóżmy, że nasz moduł raportowy posiada funkcję o nazwie getTotalHours. Załóżmy również, że moduł akceptacji kart czasu pracy posiada funkcję saveTimeCard. Która nazwa tych dwóch funkcji informuje nas, że jest w niej obliczana sumaryczna liczba godzin? Odpowiedź powinna być oczywista. Czasami względy wydajnościowe powodują, że suma jest obliczana w czasie akceptacji kart pracy, a nie w czasie drukowania raportu. Jest to do przyjęcia pod warunkiem, że nazwy funkcji będą to odzwierciedlać. W takim przypadku w module kart czasu pracy powinna znajdować się funkcja computeRunningTotalOfHours.
  
  G18. Niewłaściwe metody statyczne Przykładem dobrej metody statycznej jest Math.max(double a, double b). Nie działa ona na jednym obiekcie, a w rzeczywistości niewłaściwe byłoby korzystanie z new Math().max(a, b) czy też a.max(b). Wszystkie dane wykorzystywane przez max pochodzą z argumentów, a nie z „zawierającego” ją obiektu. Co więcej, niemal nie ma szansy, abyśmy potrzebowali polimorficznej metody Math.max. Czasami jednak piszemy metody statyczne, które nie powinny być statyczne. Oto przykład: HourlyPayCalculator.calculatePay(employee, overtimeRate).
  
  Wydaje się, że jest to sensowna funkcja statyczna. Nie operuje ona na żadnym określonym obiekcie i pobiera wszystkie dane z argumentów. Jednak istnieje prawdopodobieństwo, że będziemy potrzebować, aby funkcja ta była polimorficzna. Możemy chcieć zaimplementować kilka różnych algorytmów obliczania płacy godzinowej, na przykład OvertimeHourlyPayCalculator, czasami StraightTimeHourlyPayCalculator. Dlatego w tym przypadku funkcja nie powinna być statyczna. Powinna być niestatyczną metodą składową klasy Employee.
  
  306
  
  ROZDZIAŁ 17.
  
  Powinniśmy preferować korzystanie z metod niestatycznych zamiast statycznych. Jeżeli mamy wątpliwości, nie tworzymy funkcji statycznej. Jeżeli faktycznie chcemy, aby funkcja była statyczna, musimy się upewnić, że nie powinna ona działać polimorficznie.
  
  G19. Użycie opisowych zmiennych Kent Beck pisał o tym w swojej wspaniałej książce Smalltalk Best Practice Patterns8 oraz później, w równie dobrej pracy Implementation Patterns9. Jednym z najefektywniejszych sposobów zapewnienia czytelności programu jest podzielenie obliczeń na kroki pośrednie, których wyniki są przechowywane w zmiennych o znaczących nazwach. Przykładem może być fragment kodu z FitNesse: Matcher match = headerPattern.matcher(line); if(match.find()) { String key = match.group(1); String value = match.group(2); headers.put(key.toLowerCase(), value); }
  
  Dzięki użyciu zmiennych opisowych od razu wiadomo, że pierwsza znaleziona grupa jest kluczem, a druga wartością. Trudno zrobić to lepiej. Im więcej zmiennych opisowych, tym lepiej. Trudno uwierzyć, jak szybko nieczytelny moduł staje się przejrzysty, gdy tylko podzielimy obliczenia na dobrze nazwane wartości pośrednie.
  
  G20. Nazwy funkcji powinny informować o tym, co realizują Spójrzmy na ten wiersz kodu: Date newDate = date.add(5);
  
  Czy możemy oczekiwać, że spowoduje to dodanie pięciu dni do daty? Czy też tygodni lub godzin? Czy obiekt date jest zmieniany, czy tylko funkcja zwraca nowy obiekt Date bez zmiany starego? Nie jesteśmy w stanie stwierdzić na podstawie wywołania, co robi funkcja. Jeżeli funkcja dodaje pięć dni do daty i zmienia ją, to powinna być nazwana addDaysTo lub increaseByDays. Jeżeli jednak funkcja zwraca nową datę późniejszą o pięć dni i nie zmienia bazowego obiektu daty, powinna być nazwana daysLater lub daysSince. Jeżeli musimy spojrzeć do implementacji (lub dokumentacji) funkcji w celu sprawdzenia, co ona robi, to powinniśmy znaleźć jej lepszą nazwę lub zmienić działanie tak, aby mogło być realizowane przez funkcje o lepszych nazwach.
  
  8
  
  [Beck97], s. 108.
  
  9
  
  [Beck07].
  
  ZAPACHY KODU I HEURYSTYKI
  
  307
  
  G21. Zrozumienie algorytmu Dzięki temu, że ludzie nie poświęcają czasu na zrozumienie algorytmu, powstało wiele śmiesznego kodu. Próbują oni uzyskać jakiekolwiek wyniki przez dodawanie odpowiedniej liczby instrukcji if oraz znaczników, zamiast zatrzymać się i sprawdzić, co naprawdę powinni zrobić. Programowanie często jest eksploracją. Uważamy, że znamy odpowiedni algorytm czynności, ale następnie męczymy się z nim, ugniatając go i szturchając, do momentu, aż będzie on „działał”. Skąd jednak wiemy, że „działa”? Ponieważ realizuje wszystkie testy, o których pomyśleliśmy. Nie ma nic złego w takim podejściu. W rzeczywistości często jest to jedyny sposób na otrzymanie potrzebnej funkcji. Jednak nie można pozostawiać cudzysłowów wokół „działa”. Zanim uznamy, że funkcja jest zakończona, upewnijmy się, że rozumiemy, jak ona działa. Nie wystarczy, że przechodzi wszystkie testy. Musimy wiedzieć10, że rozwiązanie jest prawidłowe. Najczęściej najlepszym sposobem na uzyskanie tej wiedzy i zrozumienie algorytmu jest przebudowa funkcji do postaci tak jasnej i ekspresywnej, że jest oczywiste, jak ona działa.
  
  G22. Zamiana zależności logicznych na fizyczne Jeżeli jeden moduł zależy od drugiego, to ta zależność powinna być fizyczna, a nie tylko logiczna. Moduł zależny nie powinien wykonywać założeń (inaczej mówiąc, zależności logicznych) na temat modułu, od którego zależy. Zamiast tego należy jawnie odpytać ten moduł o informacje, na których nam zależy. Załóżmy, że piszemy funkcję generującą tekstowy raport godzin przepracowanych przez pracowników. Klasa o nazwie HourlyReporter zbiera wszystkie dane, a następnie przekazuje je do Hourly ReportFormatter w celu ich wyświetlenia (patrz listing 17.1). L I S T I N G 1 7 . 1 . HourlyReporter.java public class HourlyReporter { private HourlyReportFormatter formatter; private List page; private final int PAGE_SIZE = 55; public HourlyReporter(HourlyReportFormatter formatter) { this.formatter = formatter; page = new ArrayList (); } public void generateReport(List employees) { for (HourlyEmployee e : employees) { addLineItemToPage(e); if (page.size() == PAGE_SIZE)
  
  10
  
  Istnieje różnica pomiędzy znajomością działania kodu a pewnością, że algorytm realizuje wymagane działanie. Brak pewności co do algorytmu zdarza się, i często jest po prostu faktem. Brak pewności co do działania własnego kodu jest po prostu lenistwem.
  
  308
  
  ROZDZIAŁ 17.
  
  printAndClearItemList(); } if (page.size() > 0) printAndClearItemList(); } private void printAndClearItemList() { formatter.format(page); page.clear(); } private void addLineItemToPage(HourlyEmployee e) { LineItem item = new LineItem(); item.name = e.getName(); item.hours = e.getTenthsWorked() / 10; item.tenths = e.getTenthsWorked() % 10; page.add(item); } public class LineItem { public String name; public int hours; public int tenths; } }
  
  Kod ten zawiera zależności logiczne, które nie zostały fizycznie ujawnione. Czy możesz je znaleźć? Jest to stała PAGE_SIZE. Dlaczego klasa HourlyReporter zna wielkość strony? Wielkość ta powinna być odpowiedzialnością klasy HourlyReportFormatter. Fakt deklaracji stałej PAGE_SIZE w HourlyReporter jest źle rozmieszczoną odpowiedzialnością [G17], co powoduje, że HourlyReporter zakłada, iż wie, jaka powinna być wielkość strony. Takie założenie jest zależnością logiczną. Klasa HourlyReporter zależy od tego, że HourlyReportFormatter może obsługiwać strony o długości 55 wierszy. Jeżeli pewna implementacja HourlyReportFormatter nie będzie obsługiwała takiej wielkości, wystąpi błąd. Można ujawnić tę zależność przez utworzenie w klasie HourlyReportFormatter nowej metody o nazwie getMaxPageSize(). Klasa HourlyReporter powinna wywołać tę funkcję, zamiast korzystać ze stałej PAGE_SIZE.
  
  G23. Zastosowanie polimorfizmu zamiast instrukcji if-else lub switch-case Wydaje się to dziwną sugestią po przedstawieniu zagadnienia w rozdziale 6. W końcu uznałem tam, że instrukcje switch są lepsze w tych częściach systemu, w których dodawanie nowych funkcji jest bardziej prawdopodobne niż dodawanie nowych typów. Po pierwsze, większość programistów używa instrukcji switch, ponieważ jest to rozwiązanie oczywiste, a nie dlatego, że jest to rozwiązanie właściwe w danej sytuacji. Poruszamy ten temat, aby przypomnieć, że przed zastosowaniem instrukcji switch należy rozważyć użycie polimorfizmu.
  
  ZAPACHY KODU I HEURYSTYKI
  
  309
  
  Po drugie, przypadki, w których funkcje są bardziej ulotne od typów, są względnie rzadkie. Dlatego każda instrukcja switch powinna być dla nas podejrzana. Osobiście korzystam z następującej zasady „jeden switch”: W danej deklaracji typu może znaleźć się najwyżej jedna instrukcja switch. W takim przypadku instrukcja switch powinna tworzyć obiekty polimorficzne, które zastępują instrukcje switch w pozostałych częściach systemu.
  
  G24. Wykorzystanie standardowych konwencji Każdy zespół powinien korzystać ze standardów kodowania bazujących na wspólnych normach przemysłowych. Standard kodowania powinien definiować takie zagadnienia, jak miejsce deklaracji zmiennych instancyjnych, sposób nazewnictwa klas, metod i zmiennych, miejsce umieszczenia klamer i tak dalej. Zespół nie powinien potrzebować dokumentu opisującego te konwencje, ponieważ przykłady są zawarte w kodzie. Każdy członek zespołu powinien stosować się do tych konwencji. Oznacza to, że każdy członek zespołu powinien być na tyle dojrzały, aby zgodzić się, że nie ma znaczenia, gdzie umieszcza się klamry, dopóki wszyscy zgadzają się na jedno miejsce. Jeżeli ktoś chciałby znać używane przeze mnie konwencje, może je zobaczyć w przebudowanym kodzie zamieszczonym w listingach od B.7 do B.14 w dodatku B.
  
  G25. Zamiana magicznych liczb na stałe nazwane Jest to prawdopodobnie jedna z najstarszych zasad programowania. Pamiętam ją już z podręczników Cobola, Fortrana i PL/1 z lat sześćdziesiątych ubiegłego wieku. Zwykle złym pomysłem jest korzystanie z surowych liczb w kodzie. Powinniśmy je ukrywać w dobrze nazwanych stałych. Na przykład liczba 86 400 powinna być ukryta w stałej SECONDS_PER_DAY. Jeżeli wyświetlamy 55 wierszy na stronę, to liczba 55 powinna być ukryta w stałej LINES_PER_PAGE. Niektóre stałe są tak proste do rozpoznania, że nie zawsze wymagają stałej nazwanej, o ile są połączone z bardzo dobrze opisującym się kodem. Na przykład: double milesWalked = feetWalked/5280.0; int dailyPay = hourlyRate * 8; double circumference = radius * Math.PI * 2;
  
  Czy faktycznie w powyższych przykładach potrzebujemy stałych FEET_PER_MILE, WORK_HOURS_PER_DAY oraz TWO? Oczywiście, ostatni przypadek jest absurdalny. Istnieją jednak wyrażenia, w których stałe są po prostu lepsze niż surowe liczby. Można mieć wątpliwości co do stałej WORK_HOURS_PER_DAY, ponieważ prawo i konwencje mogą się zmieniać. Z drugiej strony, wyrażenie to czyta się tak dobrze z cyfrą, że byłbym ostrożny przed dodawaniem do niego 17 znaków. W przypadku FEET_PER_MILE liczba 5280 jest tak dobrze znana i unikatowa, że czytelnik rozpozna ją, nawet gdyby znajdowała się sama na stronie, bez żadnego kontekstu.
  
  310
  
  ROZDZIAŁ 17.
  
  Stałe, takie jak 3,141592653589793, są również bardzo dobrze znane i łatwo rozpoznawalne. Jednak szansa popełnienia błędu jest zbyt duża, aby pozostawić ją w surowej postaci. Za każdym razem, gdy ktoś zobaczy 3,1415927535890793, będzie wiedział, że jest to pi, i nie będzie jej sprawdzał (czy zauważyłeś błąd w jednej cyfrze?). Nie chcemy również, aby używane były wartości 3,14, 3,14159, 3,142 i tak dalej. Dlatego dobrze, że mamy już zdefiniowaną stałą Math.PI. Termin „magiczna liczba” nie odnosi się wyłącznie do liczb. Odnosi się do dowolnej wartości, która nie jest rozpoznawalna na pierwszy rzut oka. Na przykład: assertEquals(7777, Employee.find("John Doe").employeeNumber());
  
  W tej asercji mamy dwie magiczne liczby. Pierwszą jest 7777, ponieważ jej znaczenie nie jest oczywiste. Drugą magiczną liczbą jest "John Doe", ponieważ i w tym przypadku intencje nie są jasne. Wygląda to tak, jakby "John Doe" był nazwą pracownika numer 7777 w testowej bazie danych, utworzonej przez nasz zespół. Każdy w zespole wie, że po podłączeniu do tej bazy będzie miał dostęp do danych kilku pracowników mających znane wartości i atrybuty. Okazuje się więc, że "John Doe" reprezentuje jedynego pracownika opłacanego na godziny w tej testowej bazie danych. Dlatego test ten powinien wyglądać następująco: assertEquals( HOURLY_EMPLOYEE_ID, Employee.find(HOURLY_EMPLOYEE_NAME).employeeNumber());
  
  G26. Precyzja Oczekiwanie, że pierwsze dopasowanie będzie jedynym wynikiem zapytania, jest co najmniej naiwne. Użycie liczb zmiennoprzecinkowych do reprezentowania walut jest niemal przestępstwem. Unikanie blokad i zarządzania transakcjami, gdyż nie uważamy, że równoległa aktualizacja jest prawdopodobna, jest lenistwem. Deklarowanie zmiennej jako ArrayList, gdy wystarczy List, jest niernym ograniczeniem. Domyślne oznaczanie wszystkich zmiennych jako protected jest niewystarczającym ograniczeniem. Podejmując decyzje dotyczące kodu, należy to robić precyzyjnie. Trzeba wiedzieć, dlaczego są one podjęte i jak obsłużyć wszystkie wyjątki. Nie należy być leniwym, jeżeli chodzi o precyzję decyzji. Jeżeli zdecydujemy, że funkcja może zwracać null, należy upewnić się, że wartość null jest kontrolowana. Jeżeli zadajemy zapytanie dotyczące elementu, który powinien być jedyny w bazie danych, nasz kod powinien sprawdzić, czy nie ma innych. Jeżeli potrzebujemy obsługi walut, należy użyć liczb całkowitych11 i prawidłowo obsługiwać zaokrąglanie. Jeżeli istnieje możliwość równoległej aktualizacji, należy zaimplementować mechanizm blokowania. Niejednoznaczności w kodzie są wynikiem niezgodności lub lenistwa. Bez względu na ich przyczynę, powinny zostać wyeliminowane.
  
  11
  
  Lub lepiej — zastosować klasę Money wykorzystującą liczby całkowite.
  
  ZAPACHY KODU I HEURYSTYKI
  
  311
  
  G27. Struktura przed konwencją Decyzje projektowe należy wymuszać przez zastosowanie struktury przed konwencją. Konwencje nazewnictwa są dobre, ale są gorsze od struktur wymuszających zgodność. Na przykład instrukcje switch-case z ładnie nazwanymi wyliczeniami są gorsze od klas bazowych z metodami abstrakcyjnymi. Nikt nie jest zmuszany do implementowania instrukcji switch-case zawsze w taki sam sposób, natomiast klasy bazowe mogą wymusić, aby klasy konkretne miały zaimplementowane wszystkie metody abstrakcyjne.
  
  G28. Hermetyzacja warunków Wyrażenia logiczne są wystarczająco trudne do zrozumienia, bez konieczności oglądania kontekstu instrukcji if lub while. Warto wyodrębniać funkcję, która wyjaśnia przeznaczenie warunku. Na przykład: if (shouldBeDeleted(timer))
  
  jest lepsze niż if (timer.hasExpired() && !timer.isRecurrent())
  
  G29. Unikanie warunków negatywnych Warunki negatywne są nieco trudniejsze do zrozumienia niż pozytywne. Dlatego, jeżeli jest to możliwe, wyrażenia powinny być formułowane jako warunki pozytywne. Na przykład: if (buffer.shouldCompact())
  
  jest lepsze niż if (!buffer.shouldNotCompact())
  
  G30. Funkcje powinny wykonywać jedną operację Często kuszące jest tworzenie funkcji, które mają wiele sekcji wykonujących serię działań. Funkcje tego rodzaju realizują więcej niż jedną operację i powinny zostać zamienione na mniejsze, z których każda wykonuje jedną operację. Na przykład: public void pay() { for (Employee e : employees) { if (e.isPayday()) { Money pay = e.calculatePay(); e.deliverPay(pay); } } }
  
  312
  
  ROZDZIAŁ 17.
  
  Ten fragment kodu wykonuje trzy operacje. Przegląda dane pracowników, sprawdza, czy kolejnemu pracownikowi należy zapłacić, a następnie realizuje wypłatę. Lepiej zapisać go tak: public void pay() { for (Employee e : employees) payIfNecessary(e); } private void payIfNecessary(Employee e) { if (e.isPayday()) calculateAndDeliverPay(e); } private void calculateAndDeliverPay(Employee e) { Money pay = e.calculatePay(); e.deliverPay(pay); }
  
  Teraz każda z tych funkcji wykonuje jedną operację (patrz „Wykonuj jedną czynność” w rozdziale 3.).
  
  G31. Ukryte sprzężenia czasowe Sprzężenia czasowe są często potrzebne, ale nie powinny ukrywać zależności. Należy tak uporządkować argumenty funkcji, aby kolejność ich wywoływania była oczywista. Weźmy pod uwagę następujący kod: public class MoogDiver { Gradient gradient; List<Spline> splines; public void dive(String reason) { saturateGradient(); reticulateSplines(); diveForMoog(reason); } ... }
  
  Kolejność tych trzech funkcji jest ważna. Należy nasycić gradient przed retykulacją splajnów i tylko po tej operacji można wykonać ostatnią funkcję. Niestety, kod ten nie wymusza tego sprzężenia czasowego. Inny programista może wywołać reticulateSplines przed saturateGradient, doprowadzając do wyjątku UnsaturatedGradientException. Lepszym rozwiązaniem jest następująca konstrukcja: public class MoogDiver { Gradient gradient; List<Spline> splines; public void dive(String reason) { Gradient gradient = saturateGradient(); List<Spline> splines = reticulateSplines(gradient); diveForMoog(splines, reason); } ... }
  
  ZAPACHY KODU I HEURYSTYKI
  
  313
  
  Ujawnia to sprzężenie czasowe przez utworzenie zestawu kubełków. Każda funkcja wytwarza wynik potrzebny następnej funkcji, więc nie ma sensownego sposobu na wywołanie ich w nieprawidłowej kolejności. Można narzekać, że zwiększa to złożoność funkcji, i trzeba się z tym zgodzić. Jednak dodatkowa złożoność składniowa ujawnia prawdziwe sprzężenie czasowe w tej sytuacji. Należy zwrócić uwagę, że pozostawiłem zmienne instancyjne. Zakładam, że będą one potrzebne metodom prywatnym w tej klasie. Nawet pomimo tego chcemy, aby sprzężenia czasowe były ujawnione.
  
  G32. Unikanie dowolnych działań Struktura kodu nie powinna być przypadkowa. Jeżeli struktura wygląda na dowolną, inne osoby czują się zobowiązane do jej zmiany. Jeżeli struktura jest spójna w całym systemie, inne osoby będą jej używać w celu zachowania konwencji. Na przykład ostatnio łączyłem zmiany w FitNesse i odkryłem, że jeden z programistów dodał taki kod: public class AliasLinkWidget extends ParentWidget { public static class VariableExpandingWidgetRoot { ... ... }
  
  Problemem jest to, że VariableExpandingWidgetRoot nie musi być w zakresie AliasLinkWidget. Co więcej, inne niezwiązane klasy korzystały z AliasLinkWidget.VariableExpandingWidgetRoot. Klasy te nie musiały nic wiedzieć na temat AliasLinkWidget. Prawdopodobnie programista wrzucił VariableExpandingWidgetRoot do AliasWidget dla wygody albo myślał, że faktycznie będzie potrzebował operacji wewnątrz AliasWidget. Niezależnie od powodu, wynik wygląda na dosyć dowolny. Klasy publiczne, które nie są narzędziami innej klasy, nie powinny być zagłębione w innej klasie. Zgodnie z konwencją, należy zadeklarować je jako publiczne na poziomie pakietu.
  
  G33. Hermetyzacja warunków granicznych Warunki graniczne są trudne do obsługi. Należy umieścić ich przetwarzanie w jednym miejscu. Nie należy dopuszczać, aby rozlały się po całym kodzie. Nie chcemy stada +1 i -1 wyglądających zza każdego rogu. Przykładem może być fragment kodu z FIT: if(level + 1 < tags.length) { parts = new Parse(body, tags, level + 1, offset + endTag); body = null; }
  
  Można zauważyć, że level+1 występuje dwa razy. Jest to warunek graniczny, który powinien być hermetyzowany wewnątrz zmiennej o nazwie podobnej do nextLevel.
  
  314
  
  ROZDZIAŁ 17.
  
  int nextLevel = level + 1; if(nextLevel < tags.length) { parts = new Parse(body, tags, nextLevel, offset + endTag); body = null; }
  
  G34. Funkcje powinny zagłębiać się na jeden poziom abstrakcji Instrukcje wewnątrz funkcji powinny być pisane na tym samym poziomie abstrakcji, który powinien być o jeden poziom niższy od operacji opisanych w nazwie funkcji. Może być to najtrudniejsza do interpretacji i stosowania z wszystkich opisanych tu heurystyk. Choć zagadnienie jest dosyć proste, ludzie są po prostu zbyt dobrzy w płynnym mieszaniu poziomów abstrakcji. Jako przykład weźmy następujący kod z FitNesse: public String render() throws Exception { StringBuffer html = new StringBuffer("

  ---

  0) html.append(" size=\"").append(size + 1).append("\""); html.append(">"); return html.toString(); }
  
  Krótka analiza pozwala stwierdzić, co się tu dzieje. Funkcja ta tworzy znacznik HTML rysujący poziomą linię na stronie. Wysokość tej linii jest zdefiniowana w zmiennej size. Teraz spójrzmy na niego jeszcze raz. Metoda ta miesza ze sobą co najmniej dwa poziomy abstrakcji. Pierwszym jest informacja, że linia pozioma posiada wielkość. Drugim jest sama składnia znacznika HR. Kod ten pochodzi z modułu HruleWidget z FitNesse. Moduł ten wykrywa wiersz z czterema lub więcej minusami i konwertuje je na odpowiedni znacznik HR. Im więcej minusów, tym większy rozmiar. Poniżej zamieszczony jest kod po przebudowie. Należy zauważyć, że zmieniłem nazwę pola size, aby odzwierciedlała jego prawdziwe przeznaczenie. Przechowuje ono liczbę dodatkowych minusów. public String render() throws Exception { HtmlTag hr = new HtmlTag("hr"); if (extraDashes > 0) hr.addAttribute("size", hrSize(extraDashes)); return hr.html(); } private String hrSize(int height) { int hrSize = height + 1; return String.format("%d", hrSize); }
  
  Zmiana ta pozwoliła na eleganckie rozdzielenie dwóch poziomów abstrakcji. Funkcja render tworzy dla nas znacznik HR, bez konieczności znajomości składni HTML tego znacznika. Moduł HtmlTag zajmuje się wszystkimi problemami składniowymi.
  
  ZAPACHY KODU I HEURYSTYKI
  
  315
  
  Wprowadzając tę zmianę, znalazłem subtelny błąd. Oryginalny kod nie umieszczał zamykającego ukośnika znacznika HR, tak jak definiuje to standard XHTML (inaczej mówiąc, generował

  ---

  zamiast

  ---

  ). Moduł HtmlTag został już dawno tak zmieniony, aby był zgodny z XHTML-em. Rozdzielenie poziomów abstrakcji jest jednym z najważniejszych zadań przebudowy, przy tym najtrudniejszym do wykonania. Jako przykład weźmy poniższy kod. Była to moja pierwsza próba rozdzielenia poziomów abstrakcji w metodzie HruleWidget.render. public String render() throws Exception { HtmlTag hr = new HtmlTag("hr"); if (size > 0) { hr.addAttribute("size", ""+(size+1)); } return hr.html(); }
  
  Moim celem było zapewnienie odpowiedniej separacji i umożliwienie wykonywania testów. Łatwo zrealizowałem te cele, ale wynikiem była funkcja, która nadal mieszała poziomy abstrakcji. W tym przypadku wymieszanymi poziomami były: tworzenie znacznika HR oraz interpretacja i formatowanie zmiennej size. W tym przypadku okazało się, że gdy podzielimy funkcję wzdłuż poziomów abstrakcji, często wykrywamy następne, ukryte przez poprzednią strukturę.
  
  G35. Przechowywanie danych konfigurowalnych na wysokim poziomie Jeżeli mamy stałe, takie jak wartości domyślne lub konfiguracyjne, które są oczekiwane na wysokim poziomie abstrakcji, to nie należy ukrywać ich w funkcjach niskiego poziomu. Należy ujawnić je jako argumenty, z użyciem których funkcje niskiego poziomu są wywoływane z funkcji wysokiego poziomu. Weźmy pod uwagę następujący kod z FitNesse: public static void main(String[] args) throws Exception { Arguments arguments = parseCommandLine(args); ... } public class Arguments { public static final String DEFAULT_PATH = "."; public static final String DEFAULT_ROOT = "FitNesseRoot"; public static final int DEFAULT_PORT = 80; public static final int DEFAULT_VERSION_DAYS = 14; ... }
  
  Argumenty wiersza poleceń są analizowane w pierwszym wykonywalnym wierszu FitNesse. Wartości domyślne tych argumentów są specyfikowane w klasie Arguments. Nie musimy zaglądać do niskich poziomów systemu za pomocą takich instrukcji: if (arguments.port == 0) // Używamy domyślnie 80.
  
  316
  
  ROZDZIAŁ 17.
  
  Stałe konfiguracji znajdują się na bardzo wysokim poziomie i łatwo je zmienić. Są one przekazywane w dół, do pozostałych części aplikacji. Niższe poziomy aplikacji nie zawierają wartości tych stałych.
  
  G36. Unikanie nawigacji przechodnich Zazwyczaj nie chcemy, aby jeden moduł znał swoich współpracowników. Mówiąc dokładniej, jeżeli A współdziała z B, a B współpracuje z C, to nie chcemy, aby moduły korzystające z A wiedziały coś o C (na przykład nie chcemy instrukcji a.getB().getC().doSomething();). Jest to czasami nazywane prawem Demeter. Pragmatyczni programiści nazywają to „pisaniem wstydliwego kodu”12. W obu przypadkach sprowadza się to do upewnienia się, że moduły znają tylko swoich bezpośrednich współpracowników i nie znają mapy nawigacji w całym systemie. Jeżeli wiele modułów korzysta z instrukcji takich jak a.getB().getC(), to trudno zmienić projekt i architekturę i wstawić Q pomiędzy B a C. Konieczne będzie wyszukanie wszystkich wystąpień a.getB().getC() i ich zamiana na a.getB().getQ().getC(). W ten sposób architektura staje się sztywna. Zbyt wiele modułów wie zbyt dużo o architekturze. Zamiast tego oczekujemy, że pośredni współpracownicy będą oferowali wszystkie potrzebne usługi. Nie powinniśmy przeglądać grafu obiektów w systemie, polując na metodę do wywołania. Zamiast tego powinniśmy być w stanie skorzystać z: myCollaborator.doSomething().
  
  Java J1. Unikanie długich list importu przez użycie znaków wieloznacznych Jeżeli używamy dwóch lub więcej klas z pakietu, to warto zaimportować go w całości przez użycie: import package.*;
  
  Długie listy importu są nużące dla czytelnika. Nie chcemy zaśmiecać początku modułu ponad 80 wierszami importów. Chcemy raczej, aby importy były zwięzłymi instrukcjami opisującymi pakiety, z którymi współpracujemy. Specyficzne importy są trwałymi zależnościami, natomiast importy ze znakami wieloznacznymi — nie. Jeżeli zaimportujemy specyficzną klasę, to musi ona istnieć. Jeżeli jednak zaimportujemy pakiet z użyciem znaków wieloznacznych, nie musi istnieć żadna określona klasa. Instrukcja importu po prostu dodaje pakiet do ścieżki przeszukiwania, używanej przy polowaniu na nazwy. Dlatego za pomocą importu nie są tworzone konkretne zależności, dzięki czemu moduły są mniej sprzężone. 12
  
  [PRAG], s. 138.
  
  ZAPACHY KODU I HEURYSTYKI
  
  317
  
  Istnieją przypadki, w których długie listy importów mogą być przydatne. Na przykład, jeżeli korzystamy z zastanego kodu i musimy dowiedzieć się, których klas potrzebujemy w celu zbudowania imitacji i zrębów, możemy przeglądać listę specyficznych importów, szukając nazw kwalifikowanych wszystkich tych klas, a następnie zastąpić je zrębami. Jednak takie zastosowanie specyficznych importów jest bardzo rzadkie. Dodatkowo większość nowoczesnych środowisk IDE pozwala na zamianę importów ze znakami wieloznacznymi na listę specyficznych importów po wykonaniu jednego polecenia. Dlatego nawet w zastanym kodzie lepiej korzystać z importów wieloznacznych. Importy wieloznaczne mogą czasami powodować konflikty nazw i niejednoznaczności. Dwie klasy o tej samej nazwie, ale znajdujące się w różnych pakietach, będą wymagały specyficznego importu lub co najmniej kwalifikowania w czasie użycia. Może to być niuans, ale jest tak rzadki, że najczęściej importowanie z użyciem znaków wieloznacznych jest lepsze od specyficznych importów.
  
  J2. Nie dziedziczymy stałych Widziałem to kilka razy i zawsze wywołuje to grymas na mojej twarzy. Programista umieszcza stałe w interfejsie, a następnie uzyskuje dostęp do tych stałych przez dziedziczenie interfejsu. Przyjrzyjmy się następującemu przykładowi kodu: public class HourlyEmployee extends Employee { private int tenthsWorked; private double hourlyRate; public Money calculatePay() { int straightTime = Math.min(tenthsWorked, TENTHS_PER_WEEK); int overTime = tenthsWorked - straightTime; return new Money( hourlyRate * (tenthsWorked + OVERTIME_RATE * overTime) ); } ... }
  
  Skąd pochodzą stałe TENTHS_PER_WEEK oraz OVERTIME_RATE? Mogą pochodzić z klasy Employee, więc rzućmy na nią okiem: public abstract class Employee implements PayrollConstants { public abstract boolean isPayday(); public abstract Money calculatePay(); public abstract void deliverPay(Money pay); }
  
  Nie, nie ma ich tu. No to gdzie są? Spójrzmy dokładniej na klasę Employee. Implementuje ona PayrollConstants. public interface PayrollConstants { public static final int TENTHS_PER_WEEK = 400; public static final double OVERTIME_RATE = 1.5; }
  
  Jest to fatalna praktyka! Stałe są ukryte na szczycie hierarchii dziedziczenia. Okropność! Nie należy używać dziedziczenia jako sposobu oszukania zasad zakresu zdefiniowanych w języku. Zamiast tego należy korzystać z importu statycznego.
  
  318
  
  ROZDZIAŁ 17.
  
  import static PayrollConstants.*; public class HourlyEmployee extends Employee { private int tenthsWorked; private double hourlyRate; public Money calculatePay() { int straightTime = Math.min(tenthsWorked, TENTHS_PER_WEEK); int overTime = tenthsWorked - straightTime; return new Money( hourlyRate * (tenthsWorked + OVERTIME_RATE * overTime) ); } ... }
  
  J3. Stałe kontra typy wyliczeniowe Teraz, gdy do języka zostało dodane słowo kluczowe enum (Java 5), warto z niego korzystać! Nie należy trzymać się starych sztuczek public static final int. Znaczenie wartości int może zostać utracone. Znaczenie typu wyliczeniowego nie może, ponieważ należy do nazwanego wyliczenia. Co więcej, warto uważnie przestudiować składnię enum. Mogą one posiadać metody i pola. Powoduje to, że stają się bardzo potężnym narzędziem i pozwalają na uzyskanie znacznie większej ekspresywności i elastyczności niż liczby int. Przeanalizujmy odmianę wcześniejszego kodu obliczania płac: public class HourlyEmployee extends Employee { private int tenthsWorked; HourlyPayGrade grade; public Money calculatePay() { int straightTime = Math.min(tenthsWorked, TENTHS_PER_WEEK); int overTime = tenthsWorked - straightTime; return new Money( grade.rate() * (tenthsWorked + OVERTIME_RATE * overTime) ); } ... } public enum HourlyPayGrade { APPRENTICE { public double rate() { return 1.0; } }, LEUTENANT_JOURNEYMAN { public double rate() { return 1.2; } }, JOURNEYMAN { public double rate() { return 1.5; } }, MASTER { public double rate() {
  
  ZAPACHY KODU I HEURYSTYKI
  
  319
  
  return 2.0; } }; public abstract double rate(); }
  
  Nazwy N1. Wybór opisowych nazw Nie należy zbyt szybko wybierać nazwy. Należy upewnić się, że jest opisowa. Trzeba pamiętać, że znaczenie ma tendencję do dryfowania wraz z rozwojem oprogramowania, więc częste sprawdzanie dokładności nazw jest wskazane. To nie jest tylko rekomendacja „dobrego samopoczucia”. W 90 procentach nazwy w kodzie decydują o jego czytelności. Nazwy są zbyt ważne, aby je traktować beztrosko. Weźmy pod uwagę poniższy kod. Co on robi? Jeżeli pokażę go z użytymi odpowiednimi nazwami, będzie dla nas zupełnie sensowny, ale w tej postaci jest zlepkiem symboli i magicznych liczb. public int x() { int q = 0; int z = 0; for (int kk = 0; kk < 10; kk++) { if (l[z] == 10) { q += 10 + (l[z + 1] + l[z + 2]); z += 1; } else if (l[z] + l[z + 1] == 10) { q += 10 + l[z + 2]; z += 2; } else { q += l[z] + l[z + 1]; z += 2; } } return q; }
  
  Poniżej mamy ten sam kod zapisany we właściwy sposób. Ten fragment jest w rzeczywistości mniej kompletny niż pokazany powyżej. Niemal natychmiast można wywnioskować, co on ma robić, i z dużym prawdopodobieństwem moglibyśmy od razu napisać brakujące funkcje, bazując tylko na wywnioskowanym znaczeniu. Magiczne liczby przestały być magiczne, a struktura algorytmu jest zachęcająco opisowa. public int score() { int score = 0; int frame = 0; for (int frameNumber = 0; frameNumber < 10; frameNumber++) { if (isStrike(frame)) { score += 10 + nextTwoBallsForStrike(frame); frame += 1;
  
  320
  
  ROZDZIAŁ 17.
  
  } else if (isSpare(frame)) { score += 10 + nextBallForSpare(frame); frame += 2; } else { score += twoBallsInFrame(frame); frame += 2; } } return score; }
  
  Siłą dobrze dobranych nazw jest uzupełnianie struktury kodu przy użyciu opisów. Pozwala to na przystosowanie oczekiwań czytelnika do tego, co realizują inne funkcje w module. Czy możemy wywnioskować implementację isStrike(), spoglądając na powyższy kod? Gdy będziemy czytać metodę isStrike, będzie robiła „mniej więcej to, czego oczekiwaliśmy”13. private boolean isStrike(int frame) { return rolls[frame] == 10; }
  
  N2. Wybór nazw na odpowiednich poziomach abstrakcji Nie należy wybierać nazw informujących o implementacji, ale raczej nazwy odzwierciedlające poziom abstrakcji, na którym operuje klasa lub funkcja. Jest to trudne do realizacji. Przypomnijmy, że ludzie są zbyt dobrzy w mieszaniu poziomów abstrakcji. Za każdym razem, gdy przejrzysz swój kod, najprawdopodobniej znajdziesz kilka zmiennych, których nazwy są na zbyt niskim poziomie. Po znalezieniu takich nazw warto wykorzystać okazję i zmienić je. Proces tworzenia czytelnego kodu wymaga chęci do stałej poprawy. Weźmy jako przykład poniższy interfejs Modem: public interface Modem { boolean dial(String phoneNumber); boolean disconnect(); boolean send(char c); char recv(); String getConnectedPhoneNumber(); }
  
  Na pierwszy rzut oka wygląda świetnie. Wszystkie funkcje wydają się odpowiednie. Faktycznie, dla wielu zastosowań są takie. Weźmy pod uwagę aplikację, w której modemy nie są łączone z użyciem wybierania. Zamiast tego są połączone na stałe (tak jak modemy kablowe używane obecnie do dostarczania internetu w wielu domach). Być może niektóre są łączone przez wysyłanie numeru portu do przełącznika, z użyciem połączenia USB. Jasne jest, że notacja numerów telefonów znajduje się na niewłaściwym poziomie abstrakcji. Lepszą strategią nazewniczą dla tego scenariusza może być: public interface Modem { boolean connect(String connectionLocator); boolean disconnect(); boolean send(char c); char recv(); String getConnectedLocator(); } 13
  
  Patrz cytat wypowiedzi Warda Cunninghama z rozdziału 1.
  
  ZAPACHY KODU I HEURYSTYKI
  
  321
  
  Teraz nazwy nie zawierają żadnych odwołań do numerów telefonicznych. Numery telefoniczne mogą być nadal używane, można też zastosować inną strategię połączenia.
  
  N3. Korzystanie ze standardowej nomenklatury tam, gdzie jest to możliwe Nazwy są łatwiejsze do zrozumienia, jeżeli bazują na istniejących konwencjach lub zastosowaniach. Na przykład, jeżeli korzystamy z wzorca Dekorator, to powinniśmy użyć słowa Decorator w nazwach klas dekorujących. Nazwą klasy dekorującej Modem i zapewniającej automatyczne rozłączanie na końcu sesji może być AutoHangupModemDecorator. Wzorce są po prostu jednym z rodzajów standardów. W języku Java funkcje konwertujące obiekty na postać znakową są często nazywane toString. Lepiej zachować zgodność z tego typu konwencjami, niż wymyślać własne. Zespoły często wymyślają własne standardy nazewnictwa dla określonych projektów. Eric Evans nazywa to wszechobecnym językiem projektu14. W naszym kodzie powinniśmy intensywnie używać terminów z tego języka. Mówiąc krótko, im więcej używamy nazw przeładowanych znaczeniami odnoszącymi się do naszego projektu, tym łatwiej będzie czytelnikowi zrozumieć, do czego służy dany kod.
  
  N4. Jednoznaczne nazwy Należy wybierać nazwy, które nie pozostawiają niejednoznaczności co do działania funkcji lub zmiennej. Spójrzmy na fragment kodu z FitNesse: private String doRename() throws Exception { if(refactorReferences) renameReferences(); renamePage(); pathToRename.removeNameFromEnd(); pathToRename.addNameToEnd(newName); return PathParser.render(pathToRename); }
  
  Nazwa tej funkcji nie mówi nam, co funkcja realizuje, poza ogólnym i niejasnym pojęciem. Odczucie to jest jeszcze powiększane przez fakt, że wewnątrz funkcji doRename znajduje się wywołanie funkcji renamePage! Co te nazwy mówią nam o różnicach pomiędzy tymi dwoma funkcjami? Nic. Lepszą nazwą dla tej funkcji byłaby renamePageAndOptionallyAllReferences. Może się ona wydawać długa (bo taka faktycznie jest), ale funkcja jest wywoływana z jednego miejsca w module, więc wartość informacyjna tej nazwy przewyższa problemy wynikające z jej długości.
  
  14
  
  [DDD].
  
  322
  
  ROZDZIAŁ 17.
  
  N5. Użycie długich nazw dla długich zakresów Długość nazwy powinna być związana z długością zakresu. Można używać bardzo krótkich nazw dla niewielkich zakresów, ale dla dużych zakresów powinny być używane długie nazwy. Nazwy zmiennych takie jak i oraz j są świetne, o ile ich zakres ma długość najwyżej pięciu wierszy. Oto fragment kodu starej gry w kręgle: private void rollMany(int n, int pins) { for (int i=0; i
  Jest to zupełnie jasne i jeżeli zmienna i zostałaby zastąpiona nieco irytującą, jak rollCount, kod byłby trudniejszy do zrozumienia. Z drugiej strony, zmienne i funkcje o krótkich nazwach tracą swoje znaczenie na dłuższych dystansach. Dlatego im szerszy zakres nazwy, tym powinna być ona dłuższa i precyzyjniejsza.
  
  N6. Unikanie kodowania W nazwach nie powinny być kodowane informacje o typie i zakresie. Przedrostki, takie jak m_ czy f, są w dzisiejszych środowiskach bezużyteczne. Również kodowanie projektu lub (i) podsystemu, takiego jak vis_ (dla systemu przetwarzania wizualnego), jest rozpraszające i niarowe. Stosowane obecnie środowiska zapewniają wszystkie te informacje bez konieczności dołączania ich do nazw. Należy zachować nazwy wolne od skażenia notacją węgierską.
  
  N7. Nazwy powinny opisywać efekty uboczne Nazwy powinny opisywać wszystko, co wykonuje dana funkcja, zmienna lub klasa. Nie należy ukrywać efektów ubocznych w nazwie. Nie należy używać prostego słowa do opisania funkcji, która wykonuje więcej niż tylko tę prostą akcję. Przykładem może być następujący kod z TestNG: public ObjectOutputStream getOos() throws IOException { if (m_oos == null) { m_oos = new ObjectOutputStream(m_socket.getOutputStream()); } return m_oos; }
  
  Funkcja ta realizuje więcej niż tylko pobieranie „oos”; ona tworzy „oos”, jeżeli nie był wcześniej utworzony. Dlatego lepszą nazwą może być createOrReturnOos.
  
  ZAPACHY KODU I HEURYSTYKI
  
  323
  
  Testy T1. Niewystarczające testy Ile testów powinno znajdować się w zestawie testowym? Niestety, wielu programistów stosuje miarę „to powinno wystarczyć”. Zestaw testów powinien sprawdzać wszystko, co może zawieść. Testy są niewystarczające dopóty, dopóki będą istnieć warunki nieskontrolowane przez testy lub niesprawdzone obliczenia.
  
  T2. Użycie narzędzi kontroli pokrycia W naszej strategii testowania konieczne jest wykorzystanie narzędzi raportujących pokrycie kodu. Ułatwiają one znalezienie modułów, klas i funkcji, które są niewystarczająco testowane. Większość środowisk IDE posiada wizualną prezentację pokrycia, oznaczając wiersze pokryte testami kolorem zielonym, a niepokryte kolorem czerwonym. Pozwala to szybko i łatwo znaleźć instrukcje if oraz catch, których treść nie jest sprawdzana.
  
  T3. Nie pomijaj prostych testów Są one bardzo proste do napisania, a ich wartość dokumentalna jest wyższa niż koszt produkcji.
  
  T4. Ignorowany test jest wskazaniem niejednoznaczności Czasami jesteśmy niepewni szczegółów działania, ponieważ wymagania są niejasne. Możemy wyrazić nasze pytanie na temat wymagania w postaci zakomentowanego testu lub testu oznaczonego za pomocą @Ignore. Metoda, jaką wybierzemy, zależy od tego, czy niejednoznaczność dotyczy czegoś, co się kompiluje, czy nie.
  
  T5. Warunki graniczne Szczególną uwagę należy poświęcić warunkom granicznym. Często prawidłowo realizujemy środkową część algorytmu, ale mamy błędy w warunkach granicznych.
  
  T6. Dokładne testowanie pobliskich błędów Błędy mają tendencję do łączenia się. Gdy znajdziemy błąd w funkcji, mądrze jest wykonać dokładne testy funkcji. Prawdopodobnie okaże się, że ten błąd nie był jedynym.
  
  T7. Wzorce błędów wiele ujawniają Czasami możemy zdiagnozować problem przez znalezienie wzorca błędów przypadków testowych. Jest to kolejny argument przemawiający za tworzeniem możliwie kompletnych przypadków testowych. Kompletne przypadki testowe, które są uporządkowane w sensowny sposób, pozwalają ujawniać takie wzorce.
  
  324
  
  ROZDZIAŁ 17.
  
  Może być to przypadek, gdy nie wszystkie testy są wykonywane z danymi wejściowymi dłuższymi niż pięć znaków. Innym przykładem może być złe wykonywanie wszystkich testów, w których drugi argument jest liczbą ujemną. Czasami tylko zobaczenie wzorów kolorów czerwonego i zielonego na raporcie testów wystarczy nam do znalezienia rozwiązania. Interesujące przykłady można znaleźć w rozdziale 16. przy okazji przedstawiania przykładu klasy SerialDate.
  
  T8. Wzorce pokrycia testami wiele ujawniają Spojrzenie na kod, który jest lub nie jest wykonywany przez testy, daje wskazówki odnośnie do przyczyny błędu testowania.
  
  T9. Testy powinny być szybkie Powolne testy nie będą wykonywane. Gdy zacznie nam brakować czasu, powolne testy będą usuwane z zestawu. Dlatego należy robić wszystko, aby testy były szybkie.
  
  Zakończenie Trudno stwierdzić, czy ta lista zapachów i heurystyk jest kompletna. W rzeczywistości nie jestem pewien, czy taka lista kiedykolwiek będzie kompletna. Jednak kompletność nie powinna być tu celem, ponieważ lista ta pozwala na ocenę systemu. W rzeczywistości ocena systemu powinna być celem i tematem tej książki. Czysty kod nie jest tworzony przez zamieszczoną tu listę zasad. Nikt nie stanie się świetnym programistą przez nauczenie się listy heurystyk. Profesjonalizm i umiejętności biorą się z dyscypliny ich stosowania.
  
  Bibliografia [Refactoring]: Martin Fowler i inni, Refactoring: Improving the Design of Existing Code, AddisonWesley 1999. [PRAG]: Andrew Hunt, Dave Thomas, The Pragmatic Programmer, Addison-Wesley 2000. [GOF]: Gamma i inni, Elements of Reusable Object Oriented Software, Addison-Wesley 1996. [Beck97]: Kent Beck, Smalltalk Best Practice Patterns, Prentice Hall 1997. [Beck07]: Kent Beck, Implementation Patterns, Addison-Wesley 2008. [PPP]: Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices, Prentice Hall 2002. [DDD]: Eric Evans, Domain Driven Design, Addison-Wesley 2003.
  
  ZAPACHY KODU I HEURYSTYKI
  
  325
  
  326
  
  ROZDZIAŁ 17.
  
  DODATEK A
  
  Współbieżność II Brett L. Schuchert
  
  rozdział 13., „Współbieżność”. Został on napisany w postaci serii niezależD nych tematów, które mogą być czytane w dowolnej kolejności. Aby umożliwić taki sposób czytaODATEK TEN UZUPEŁNIA
  
  nia, występuje tu kilka powtórzeń między punktami.
  
  Przykład klient-serwer Wyobraźmy sobie prostą aplikację klient-serwer. Serwer nasłuchuje na gnieździe, oczekując na podłączenie się klienta. Klient podłącza się i wysyła żądanie.
  
  Serwer Poniżej przedstawiona jest uproszczona wersja aplikacji serwera. Pełny kod źródłowy zaczyna się w dalszej części dodatku, w punkcie „Klient-serwer bez wątków”. ServerSocket serverSocket = new ServerSocket(8009); while (keepProcessing) { try { Socket socket = serverSocket.accept(); process(socket); } catch (Exception e) { handle(e); } }
  
  327
  
  Ta prosta aplikacja oczekuje na połączenia, przetwarza przychodzące komunikaty i znów oczekuje na przyjście następnego żądania klienta. Poniżej mamy kod klienta podłączającego się do tego serwera: private void connectSendReceive(int i) { try { Socket socket = new Socket("localhost", PORT); MessageUtils.sendMessage(socket, Integer.toString(i)); MessageUtils.getMessage(socket); socket.close(); } catch (Exception e) { e.printStackTrace(); } }
  
  Jak szybko działa para klient-serwer? W jaki sposób możemy formalnie opisać jej wydajność? Mamy tu test, który zakłada, że wydajność jest „akceptowalna”: @Test(timeout = 10000) public void shouldRunInUnder10Seconds() throws Exception { Thread[] threads = createThreads(); startAllThreadsw(threads); waitForAllThreadsToFinish(threads); }
  
  Konfiguracja nie jest tu zamieszczona, aby uprościć nasz test (patrz listing A4. ClientTest.java). Test ten zakłada, że powinien zakończyć się w czasie 10 000 milisekund. Jest to klasyczny przykład kontroli przepustowości systemu. System ten powinien zakończyć serię żądań klientów w czasie dziesięciu sekund. Jeżeli serwer będzie w stanie przetworzyć poszczególne żądania klienta na czas, test się powiedzie. Co się stanie, jeżeli test się nie uda? Poza utworzeniem pętli odpytywania zdarzeń nie da się zrobić zbyt wiele z jednym wątkiem w celu przyspieszenia działania tego kodu. Czy zastosowanie wielu wątków rozwiąże problem? Być może, ale musimy wcześniej wiedzieć, gdzie jest marnowany czas. Istnieją dwie możliwości: 
  
  Wejście-wyjście — korzystanie z gniazd, podłączanie się do bazy danych, oczekiwanie na przełączenie pamięci wirtualnej i tak dalej.
  
  
  
  Procesor — obliczenia numeryczne, przetwarzanie wyrażeń regularnych, zbieranie nieużytków i tak dalej.
  
  Zwykle systemy mają kilka takich wąskich gardeł, ale w przypadku danej operacji najczęściej dominuje jedno. Jeżeli kod jest związany z procesorem, to lepszy sprzęt przetwarzający może poprawić wydajność i testy się powiodą. Jednak mamy dostępną tylko określoną liczbę cykli U, więc dodanie wątków do problemu związanego z procesorem nie przyspieszy działania programu. Jeżeli jednak proces jest ograniczany przez wejście-wyjście, to współbieżność może poprawić efektywność. Gdy jedna część systemu oczekuje na operację wejścia-wyjścia, inna część może wykorzystać ten czas oczekiwania do przetworzenia czegoś innego, bardziej efektywnie korzystając z dostępnych zasobów procesora.
  
  328
  
  DODATEK A
  
  Dodajemy wątki Załóżmy teraz, że test wydajnościowy się nie powiódł. Jak możemy poprawić przepustowość, aby zaliczyć ten test? Jeżeli metoda serwera process jest ograniczana przez wejście-wyjście, to możemy w serwerze zastosować wątki (wystarczy zmienić processMessage): void process(final Socket socket) { if (socket == null) return; Runnable clientHandler = new Runnable() { public void run() { try { String message = MessageUtils.getMessage(socket); MessageUtils.sendMessage(socket, "Processed: " + message); closeIgnoringException(socket); } catch (Exception e) { e.printStackTrace(); } } }; Thread clientConnection = new Thread(clientHandler); clientConnection.start(); }
  
  Załóżmy, że zmiana ta spowodowała, iż test zostanie wykonany1; kod jest kompletny, zgadza się?
  
  Uwagi na temat serwera Zaktualizowany serwer wykonuje test w nieco ponad sekundę. Niestety, rozwiązanie to jest trochę naiwne i wprowadza kilka nowych problemów. Ile wątków może utworzyć nasz serwer? W kodzie nie ma ograniczeń, więc możemy bez trudu dojść do ograniczenia nakładanego przez maszynę wirtualną środowiska Java (JVM). Dla wielu prostych systemów może to wystarczyć. Co jednak, jeżeli system jest przeznaczony do obsługi wielu użytkowników w sieci publicznej? Jeżeli zbyt wielu użytkowników podłączy się w tym samym czasie, system może się zatrzymać. Jednak pozostawmy na moment problem działania. Przedstawione rozwiązanie ma problemy z czystością i strukturą. Ile odpowiedzialności ma kod serwera? Oto one:
  
  1
  
  
  
  zarządzanie podłączaniem do gniazd,
  
  
  
  obsługa klientów,
  
  
  
  zasady wątków,
  
  
  
  zasady wyłączenia serwera.
  
  Można to sprawdzić samemu, testując obie wersje kodu. Warto zapoznać się z kodem niekorzystającym z wątków, z punktu „Klient-serwer bez wątków”, a także z kodem korzystającym z wątków, z punktu „Klient-serwer z wątkami”.
  
  WSPÓŁBIEŻNOŚĆ II
  
  329
  
  Niestety, wszystkie te odpowiedzialności są umieszczone w funkcji process. Dodatkowo kod przekracza wiele różnych poziomów abstrakcji. Dlatego funkcja przetwarzania wymaga podzielenia, pomimo że jest tak mała. Istnieje kilka potencjalnych powodów zmiany serwera, więc łamie to zasadę pojedynczej odpowiedzialności. Aby zachować czystość systemów współbieżnych, zarządzanie wątkami powinno być umieszczone w niewielu odpowiednio kontrolowanych miejscach. Co więcej, każdy kod zarządzający wątkami powinien nie robić nic poza zarządzaniem wątkami. Dlaczego? Wystarczy powiedzieć, że śledzenie problemów ze współbieżnością jest wystarczająco trudne bez konieczności jednoczesnego rozwiązywania problemów niezwiązanych z nią. Jeżeli utworzymy osobną klasę dla każdej wymienionej wcześniej odpowiedzialności, w tym dla odpowiedzialności zarządzania wątkami, to gdy zmienimy strategię zarządzania wątkami, będzie ona miała wpływ na mniejszą część kodu i nie będzie przeszkadzać w innych odpowiedzialnościach. Dodatkowo pozwala to łatwiej testować wszystkie inne odpowiedzialności, bez obawy o wielowątkowość. Poniżej przedstawiona jest zmieniona wersja kodu, która działa właśnie w taki sposób: public void run() { while (keepProcessing) { try { ClientConnection clientConnection = connectionManager.awaitClient(); ClientRequestProcessor requestProcessor = new ClientRequestProcessor(clientConnection); clientScheduler.schedule(requestProcessor); } catch (Exception e) { e.printStackTrace(); } } connectionManager.shutdown(); }
  
  Teraz wszystkie elementy związane z wątkami znajdują się w jednym miejscu, clientScheduler. Jeżeli wystąpią problemy ze współbieżnością, mamy jedno miejsce do sprawdzenia: public interface ClientScheduler { void schedule(ClientRequestProcessor requestProcessor); }
  
  Bieżące zasady są łatwe do zaimplementowania: public class ThreadPerRequestScheduler implements ClientScheduler { public void schedule(final ClientRequestProcessor requestProcessor) { Runnable runnable = new Runnable() { public void run() { requestProcessor.process(); } }; Thread thread = new Thread(runnable); thread.start(); } }
  
  Wyizolowanie wszystkich elementów zarządzania wątkami do jednego miejsca pozwala na znacznie łatwiejsze zmienianie sposobu sterowania wątkami. Na przykład przejście na bibliotekę Java 5 Executor wymaga napisania nowej klasy i jej podłączenia (listing A1).
  
  330
  
  DODATEK A
  
  L I S T I N G A 1 . ExecutorClientScheduler.java import java.util.concurrent.Executor; import java.util.concurrent.Executors; public class ExecutorClientScheduler implements ClientScheduler { Executor executor; public ExecutorClientScheduler(int availableThreads) { executor = Executors.newFixedThreadPool(availableThreads); } public void schedule(final ClientRequestProcessor requestProcessor) { Runnable runnable = new Runnable() { public void run() { requestProcessor.process(); } }; executor.execute(runnable); } }
  
  Zakończenie Wprowadzanie współbieżności w tym określonym przykładzie demonstruje sposób poprawiania przepustowości systemu oraz jeden sposób kontrolowania przepustowości za pomocą testów. Umieszczenie całego kodu współbieżności w małej liczbie klas jest przykładem zastosowania zasady pojedynczej odpowiedzialności. W przypadku programowania współbieżnego staje się to szczególnie istotne z powodu jego złożoności.
  
  Możliwe ścieżki wykonania Przyjrzyjmy się jednowierszowej metodzie incrementValue napisanej w języku Java, niezawierającej pętli ani instrukcji warunkowych. public class IdGenerator { int lastIdUsed; public int incrementValue() { return ++lastIdUsed; } }
  
  Zignorujmy przepełnienie liczby całkowitej i załóżmy, że tylko jeden wątek ma dostęp do jednego obiektu IdGenerator. W takim przypadku mamy jedną ścieżkę wykonania i jeden gwarantowany wynik: 
  
  Zwracana wartość jest równa wartości lastIdUsed, która jest o jeden większa niż przed wywołaniem tej metody.
  
  Co się stanie, jeżeli użyjemy dwóch wątków i pozostawimy metodę niezmienioną? Jakie są możliwe wyniki, jeżeli każdy wątek jeden raz wywoła incrementValue? Ile mamy możliwych ścieżek wykonania? Na początek wyniki (zakładamy, że lastIdUsed zaczyna od wartości 93):
  
  WSPÓŁBIEŻNOŚĆ II
  
  331
  
  
  
  Wątek 1. otrzymuje wartość 94, wątek 2. otrzymuje wartość 95, lastUsedId jest równe 95.
  
  
  
  Wątek 1. otrzymuje wartość 95, wątek 2. otrzymuje wartość 94, lastUsedId jest równe 95.
  
  
  
  Wątek 1. otrzymuje wartość 94, wątek 2. otrzymuje wartość 94, lastUsedId jest równe 94.
  
  Ostatni wynik, choć zaskakujący, jest możliwy. Aby sprawdzić, w jaki sposób są możliwe te różne wyniki, musimy poznać liczbę możliwych ścieżek wykonania i sposób ich realizacji przez maszynę wirtualną Java.
  
  Liczba ścieżek Aby obliczyć liczbę możliwych ścieżek wykonania, zaczniemy od wygenerowanego kodu bajtowego. Jeden wiersz kodu Java (return ++lastIdUsed;) staje się ośmioma instrukcjami kodu bajtowego. Możliwe jest, że dwa wątki przeplatają wykonanie tych ośmiu instrukcji, w sposób podobny do tasowania kart przez krupiera2. Nawet jeżeli w każdej ręce będzie miał osiem kart, to wynikowa liczba przetasowań jest znaczna. Dla tego prostego przypadku sekwencji N instrukcji, bez pętli i warunków oraz T wątków, całkowita liczba możliwych ścieżek wykonania jest równa:
  
  ( NT )! N !T Wyliczanie możliwych uporządkowań Metoda pochodzi z e-maila wujka Boba do Bretta: Przy N krokach i T wątkach mamy razem T×N kroków. Przed każdym krokiem wykonywane jest przełączenie kontekstu, które pozwala na wybranie spośród T wątków. Każda ścieżka może być reprezentowana jako ciąg cyfr określających przełączenia kontekstu. Jeżeli mamy kroki A i B oraz wątki 1. i 2., sześcioma możliwymi ścieżkami będą 1122, 1212, 1221, 2112, 2121 oraz 2211. Zapisując to w kontekście kroków, uzyskujemy: A1B1A2B2, A1A2B1B2, A1A2B2B1, A2A1B1B2, A2A1B2B1 oraz A2B2A1B1. Dla trzech wątków mamy następujące sekwencje: 112233, 112323, 113223, 113232, 112233, 121233, 121323, 121332, 123132, 123123, … . Ciągi te mają jedną ważną cechę — zawsze musi znajdować się N wystąpień każdego T. Dlatego ciąg 111111 jest nieprawidłowy, ponieważ ma sześć wystąpień 1 i zero wystąpień 2 i 3. Oczekujemy permutacji N jedynek, N dwójek, … oraz N wystąpień T. Jest to naprawdę permutacja N × T elementów po N × T jednocześnie, czyli (N × T)!, ale z usuniętymi powtórzeniami. Musimy tylko policzyć powtórzenia i odjąć je od (N × T )!
  
  2
  
  Jest to niewielkie uproszczenie. Jednak na potrzeby tej dyskusji możemy użyć takiego uproszczonego modelu.
  
  332
  
  DODATEK A
  
  Mając dwa kroki i dwa wątki, ile znajdziemy powtórzeń? Każdy czterocyfrowy ciąg ma dwie 1 i dwie 2. Każda z tych par może być zamieniona bez zmiany sensu ciągu. Można zamienić jedynki lub dwójki. Mamy więc cztery równorzędne postacie dla każdego ciągu, co oznacza, że mamy tu trzy powtórzenia. Trzy z czterech opcji to powtórzenia albo, inaczej mówiąc, jedna z czterech permutacji nie jest powtórzeniem. 4!×0,25 = 6. Wnioskowanie to wydaje się prawidłowe. Ile mamy powtórzeń? W przypadku, gdy N = 2 i T = 2, mogę zamienić jedynki, dwójki lub obie. W przypadku, gdy N = 2, a T = 3, możemy zamienić jedynki, dwójki, trójki, jedynki i dwójki, jedynki i trójki lub dwójki i trójki. Zamiana jest po prostu permutacją N. Załóżmy, że mamy P permutacji N. Liczba różnych sposobów uporządkowania tych permutacji wynosi P××T. Dlatego liczba możliwych postaci równorzędnych wynosi N!××T. Więc liczba ścieżek wynosi (T×N)!/(N!××T). W naszym przypadku, T = 2 i N = 2, otrzymamy 6 (24/4). Dla N = 2 oraz T = 3 otrzymamy 720/8 = 90. Dla N = 3 oraz T = 3 otrzymamy 9!/3^3 = 1680. Dla naszego prostego kodu Java zawierającego jeden wiersz, który daje osiem wierszy kodu bajtowego, oraz dwóch wątków całkowita liczba możliwych ścieżek wykonania wynosi 12 870. Jeżeli zmienna lastIdUsed byłaby typu long, to każdy odczyt i zapis obejmowałby dwie operacje zamiast jednej, więc liczba możliwych uporządkowań wyniosłaby 2 704 156. Co się stanie, jeżeli do tej metody wprowadzimy jedną zmianę? public synchronized void incrementValue() { ++lastIdUsed; }
  
  Liczba możliwych ścieżek wykonania byłaby równa 2 dla dwóch wątków i N! w ogólnym przypadku.
  
  Kopiemy głębiej Co to za zaskakujący wynik, jeżeli dwa wątki mogą wywołać jednocześnie tę samą metodę (przed dodaniem synchronized) i otrzymamy ten sam wynik numeryczny? Jak to możliwe? Na początek podstawy. Co jest operacją atomową? Możemy ją zdefiniować jako operację, której nie można przerwać. Na przykład w poniższym kodzie wiersz 5., gdzie jest przypisywana wartość 0 do lastId, jest atomowy, ponieważ zgodnie z modelem pamięci Java przypisanie wartości 32-bitowej jest nieprzerywalne. 01: public class Example { 02: int lastId; 03:
  
  WSPÓŁBIEŻNOŚĆ II
  
  333
  
  04: 05: 06: 07: 08: 09: 10: 11:}
  
  public void resetId() { value = 0; } public int getNextId() { ++value; }
  
  Co się stanie, jeżeli zmienimy typ lastId na long? Czy wiersz 5. jest nadal atomowy? Nie, zgodnie ze specyfikacją JVM. Może być on atomowy na określonym procesorze, ale zgodnie ze specyfikacją JVM przypisanie dowolnej wartości 64-bitowej wymaga dwóch przypisań 32-bitowych. Oznacza to, że pomiędzy pierwszym przypisaniem 32-bitowym a drugim przypisaniem 32-bitowym inny wątek może się wślizgnąć i zmienić jedną z wartości. Co można powiedzieć o operatorze inkrementacji z wiersza 9.? Operator ten może być przerwany, więc nie jest atomowy. Aby to zrozumieć, przejrzyjmy kod bajtowy obu tych metod. Zanim będziemy mogli kontynuować, przytoczymy ważne definicje: 
  
  Ramka — każde wywołanie metody wymaga ramki. Ramka zawiera adres powrotu, wszystkie parametry przekazane do metody oraz zmienne lokalne zdefiniowane w metodzie. Jest to standardowa technika używana do definiowania stosu wywołań, który jest wykorzystywany przez nowoczesne języki do podstawowego wywołania metod i funkcji oraz umożliwienia wywoływania rekurencyjnego.
  
  
  
  Zmienna lokalna — dowolna zmienna zdefiniowana w zakresie metody. Wszystkie niestatyczne metody mają co najmniej jedną zmienną, this, która reprezentuje bieżący obiekt — obiekt, który otrzymał ostatni komunikat (w bieżącym wątku), jaki spowodował wywołanie metody.
  
  
  
  Stos operandów — wiele z instrukcji w maszynie wirtualnej Java posiada parametry. Parametry te są odkładane na stos operandów. Stos jest strukturą danych typu „ostatni wszedł, pierwszy wyszedł” (LIFO).
  
  Poniżej zamieszczony jest kod bajtowy wygenerowany dla resetId().
  
  334
  
  Mnemonika
  
  Opis
  
  Końcowy stos operandów
  
  ALOAD 0
  
  Załadowanie zerowej zmiennej na stos operandów. Co jest zerową zmienną? Jest to this, bieżący obiekt. Gdy zostaje wywołana metoda, odbiorca komunikatu, obiekt Example, jest umieszczany w tablicy zmiennych lokalnych ramki utworzonej dla wywołania metody. Jest to zawsze pierwsza zmienna umieszczana dla każdej metody instancyjnej.
  
  this
  
  ICONST_0
  
  Umieszczenie wartości stałej 0 na stosie operandów.
  
  this, 0
  
  PUTFIELD lastId
  
  Zapamiętanie wartości ze szczytu stosu (czyli 0) w polu obiektu, do którego odwołuje się referencja obiektu ze szczytu stosu, czyli this.
  
  
  
  DODATEK A
  
  Gwarantowane jest, że te trzy instrukcje są atomowe, ponieważ pomimo możliwości przerwania wątku po każdej z nich, informacja dla instrukcji PUTFIELD (stała 0 ze szczytu stosu oraz odwołanie do this poniżej szczytu, jak również wartość pola) nie może być zmieniona przez żaden wątek. Dlatego, gdy nastąpi przypisanie, gwarantowane jest, że w polu zostanie zapisana wartość 0. Operacja jest atomowa. Wszystkie operandy działają na informacjach lokalnych dla metody, więc nie ma interferencji między wieloma wątkami. Jeżeli te trzy instrukcje są wykonywane przez dziesięć wątków, może wystąpić 4,38679733629e+24 uporządkowań. Jednak jest tylko jeden możliwy wynik, więc różne uporządkowania są bez znaczenia. W tym przypadku ten sam wynik jest gwarantowany również dla wartości long. Dlaczego? Wszystkie dziesięć wątków przypisuje stałą wartość. Nawet jeżeli przeplatają się, ostateczny wynik będzie taki sam. W przypadku operacji ++ w metodzie getNextId zaczynają się problemy. Załóżmy, że na początku działania tej metody lastId zawiera wartość 42. Poniżej pokazany jest kod bajtowy dla tej nowej metody. Mnemonika
  
  Opis
  
  Końcowy stos operandów
  
  ALOAD 0
  
  Ładuje this na stos operandów.
  
  this
  
  DUP
  
  Kopiuje szczyt stosu. Na stosie operandów mamy teraz dwie kopie this.
  
  this, this
  
  GETFIELD lastId
  
  Pobiera wartość pola lastId z obiektu wskazywanego przez referencję na szczycie stosu (this) i zapisuje wartość z powrotem na stosie.
  
  this, 42
  
  ICONST_1
  
  Umieszcza stałą całkowitą 1 na stosie.
  
  this, 42, 1
  
  IADD
  
  Dodaje dwie wartości całkowite na stosie operandów i zapisuje wynik z powrotem na stosie operandów.
  
  this, 43
  
  DUP_X1
  
  Powiela wartość 43 i umieszcza ją przed this.
  
  43, this, 43
  
  PUTFIELD value
  
  Zapisuje wartość ze szczytu stosu operandów, 43, do pola bieżącego obiektu, reprezentowanego przez drugą od szczytu wartość stosu operandów, czyli this.
  
  43
  
  IRETURN
  
  Zwraca wartość ze szczytu stosu (tylko tę).
  
  
  
  Wyobraźmy sobie przypadek, gdy pierwszy wątek kończy pierwsze trzy instrukcje, aż do GETFIELD włącznie, i jest przerywany. Drugi wątek przejmuje sterowanie i wykonuje całą metodę, zwiększając lastId o jeden; otrzymamy wartość 43. Następnie pierwszy wątek wznawia pracę tam, gdzie został przerwany, a na jego stosie operandów nadal znajduje się 42, ponieważ w czasie wykonywania GETFIELD taka była właśnie wartość lastId. Znów dodawana jest wartość jeden i ponownie zapisywany jest wynik 43. Wartość 43 jest zwracana również z pierwszego wątku. W wyniku tego jedna inkrementacja jest utracona, ponieważ pierwszy wątek został przerwany przez drugi. Oznaczenie metody getNextId() jako synchronized rozwiązuje problem.
  
  WSPÓŁBIEŻNOŚĆ II
  
  335
  
  Zakończenie Szczegółowa znajomość kodu bajtowego nie jest niezbędna do zrozumienia tego, jak wątki mogą się na siebie nakładać. Jeżeli zrozumiemy przedstawiony tu przykład, powinniśmy wiedzieć o możliwości nakładania się dwóch wątków, co jest wystarczającą wiedzą. Ten prosty przykład miał za zadanie pokazać potrzebę zrozumienia modelu pamięci na tyle, aby wiedzieć, co jest bezpieczne, a co nie. Często spotykaną pomyłką jest założenie, że operator ++ (zarówno pre-, jak i postinkrementujący) jest atomowy. To nieprawda. Oznacza to, że powinniśmy wiedzieć: 
  
  gdzie znajdują się współużytkowane obiekty i wartości,
  
  
  
  który kod może spowodować problemy z równoległym odczytem i zapisem,
  
  
  
  jak chronić się przed wystąpieniem problemów ze współbieżnością.
  
  Poznaj używaną bibliotekę Biblioteka Executor Jak jest pokazane na listingu A1, ExecutorClientScheduler.java, biblioteka Executor, wprowadzona w Java 5, pozwala na złożone operacje wykorzystujące pule wątków. Klasa ta znajduje się w pakiecie java.util.concurrent. Jeżeli tworzymy wątki i nie korzystamy z pul wątków lub korzystamy z własnych, powinniśmy rozważyć wykorzystanie klasy Executor. Pozwala to na tworzenie czystszego, łatwiejszego do analizy i mniejszego kodu. Biblioteka Executor zarządza pulą wątków, zmienia ją automatycznie i w razie potrzeby odtwarza wątki. Obsługuje ona obiekty future, często stosowaną konstrukcję programowania współbieżnego. Biblioteka Executor operuje na klasach implementujących Runnable i dodatkowo na klasach implementujących interfejs Callable. Interfejs Callable jest podobny do Runnable, ale pozwala na zwrócenie wyniku, co jest często potrzebne w rozwiązaniach wielowątkowych. Obiekt future jest wygodny, jeżeli w naszym kodzie istnieje potrzeba wykonania wielu niezależnych operacji i oczekiwania na ich zakończenie. public String processRequest(String message) throws Exception { Callable<String> makeExternalCall = new Callable<String>() { public String call() throws Exception { String result = "";
  
  // Wykonanie zewnętrznego żądania. return result; } }; Future<String> result = executorService.submit(makeExternalCall); String partialResult = doSomeLocalProcessing(); return result.get() + partialResult; }
  
  336
  
  DODATEK A
  
  W tym przykładzie metoda uruchamia wykonywanie obiektu makeExternalCall. Następnie metoda kontynuuje przetwarzanie. W ostatnim wierszu wywołanie result.get() powoduje zablokowanie działania do zakończenia future.
  
  Rozwiązania nieblokujące Maszyna wirtualna Java 5 wykorzystuje projekty nowoczesnych procesorów, które obsługują niezawodne aktualizacje nieblokujące. Jako przykład weźmy klasę korzystającą z synchronizacji (a więc i blokowania) do zapewnienia bezpiecznej dla wątków aktualizacji wartości: public class ObjectWithValue { private int value; public void synchronized incrementValue() { ++value; } public int getValue() { return value; } }
  
  Java 5 posiada zestaw nowych klas pozwalających na obsłużenie takich sytuacji — przykładami mogą być AtomicBoolean, AtomicInteger czy AtomicReference, ale dostępnych jest jeszcze kilka innych. Możemy zmienić powyższy kod tak, aby korzystał z rozwiązania nieblokującego: public class ObjectWithValue { private AtomicInteger value = new AtomicInteger(0); public void incrementValue() { value.incrementAndGet(); } public int getValue() { return value.get(); } }
  
  Mimo że wykorzystany jest obiekt zamiast wartości prostej i wysyłany jest komunikat increment AndGet() zamiast ++, wydajność działania tej klasy niemal zawsze przewyższa wcześniejszą wersję. W niektórych przypadkach kod ten jest tylko nieznacznie szybszy, ale przypadki, gdy rozwiązanie to jest wolniejsze, praktycznie nie istnieją. Jak to możliwe? Nowoczesne procesory udostępniają operację zwykle nazywaną Compare and Swap (CAS). Operacja ta jest analogiczna do blokowania optymistycznego w bazie danych, natomiast wersja synchronizowana jest analogiczna do blokowania pesymistycznego. Słowo kluczowe synchronized zawsze nakłada blokadę, nawet jeżeli drugi wątek nie próbuje zaktualizować tej samej blokady. Mimo że wydajność koniecznych blokad z każdą wersją się poprawia, nadal są one kosztowne. Wersja nieblokująca wychodzi z założenia, że wiele wątków zwykle nie modyfikuje tej samej wartości na tyle często, aby powstały problemy. Zamiast tego efektywnie wykrywa moment wystąpienia takiej sytuacji i powtarza operację do prawidłowego zakończenia aktualizacji. Takie wykrywanie jest niemal zawsze mniej kosztowne niż nakładanie blokady, nawet w przypadku średniego i wysokiego obciążenia.
  
  WSPÓŁBIEŻNOŚĆ II
  
  337
  
  W jaki sposób realizuje to maszyna wirtualna? Operacja CAS jest atomowa. Logicznie rzecz biorąc, operacja CAS wygląda mniej więcej tak: int variableBeingSet; void simulateNonBlockingSet(int newValue) { int currentValue; do { currentValue = variableBeingSet } while(currentValue != compareAndSwap(currentValue, newValue)); } int synchronized compareAndSwap(int currentValue, int newValue) { if(variableBeingSet == currentValue) { variableBeingSet = newValue; return currentValue; } return variableBeingSet; }
  
  Gdy metoda próbuje zaktualizować współużytkowaną zmienną, operacja CAS sprawdza, czy zmienna ta nadal posiada znaną wartość. Jeżeli tak, zmienna jest modyfikowana. Jeżeli nie, zmienna nie jest ustawiana, ponieważ inny wątek wszedł nam w drogę. Metoda wykonująca operację (przy użyciu CAS) zauważa, że zmiana nie została wykonana, i ponawia próbę.
  
  Bezpieczne klasy nieobsługujące wątków Niektóre klasy z natury nie są bezpieczne dla wątków. Kilka przykładów takich klas przedstawiono poniżej:  SimpleDateFormat, 
  
  połączenia z bazami danych,
  
  
  
  kontenery w java.util,
  
  
  
  serwlety.
  
  Niektóre klasy kolekcji posiadają pojedyncze metody bezpieczne dla wątków. Jednak każda operacja wymagająca wywołania więcej niż jednej metody nie jest bezpieczna. Na przykład, gdy nie chcemy zamieniać elementu z HashTable, jeżeli już się tam znajduje, możemy napisać następujący kod: if(!hashTable.containsKey(someKey)) { hashTable.put(someKey, new SomeValue()); }
  
  Każda z tych metod jest bezpieczna dla wątków. Jednak inny wątek może dodać wartość pomiędzy wywołaniami containsKey oraz put. Istnieje kilka możliwości rozwiązania tego problemu: 
  
  Wcześniejsze zablokowanie HashTable i upewnienie się, że wszyscy użytkownicy zrobili to samo — blokowanie z poziomu klienta: synchronized(map) { if(!map.conainsKey(key)) map.put(key,value); }
  
  338
  
  DODATEK A
  
  
  
  Opakowanie HashTable we własny obiekt i użycie innego API — blokowanie z poziomu serwera wykorzystujące wzorzec adapter: public class WrappedHashtable { private Map map = new Hashtable (); public synchronized void putIfAbsent(K key, V value) { if (map.containsKey(key)) map.put(key, value); } }
  
  
  
  Zastosowanie kolekcji bezpiecznych dla wątków: ConcurrentHashMap map = new ConcurrentHashMap (); map.putIfAbsent(key, value);
  
  Kolekcje z pakietu java.util.concurrent posiadają metody, takie jak putIfAbsent(), pozwalające obsłużyć takie operacje.
  
  Zależności między metodami mogą uszkodzić kod współbieżny Poniżej przedstawiony jest prosty przykład wprowadzenia zależności między modułami: public class IntegerIterator implements Iterator private Integer nextValue = 0; public synchronized boolean hasNext() { return nextValue < 100000; } public synchronized Integer next() { if (nextValue == 100000) throw new IteratorPastEndException(); return nextValue++; } public synchronized Integer getNextValue() { return nextValue; } }
  
  Poniżej mamy kod wykorzystujący tę klasę IntegerIterator: IntegerIterator iterator = new IntegerIterator(); while(iterator.hasNext()) { int nextValue = iterator.next();
  
  // Wykonanie operacji na nextValue. }
  
  Jeżeli kod ten jest wykonywany przez jeden wątek, nie będzie żadnych problemów. Co się stanie, jeżeli dwa wątki będą współużytkowały jeden obiekt IntegerIterator przy takim założeniu, że każdy wątek przetwarza pobrane wartości, ale każdy z elementów na liście będzie przetwarzany tylko raz? W większości przypadków nie stanie się nic złego; wątki będą w zgodzie współużytkowały listę, przetwarzały elementy uzyskane za pomocą iteratora i kończyły pracę, gdy iterator nie będzie
  
  WSPÓŁBIEŻNOŚĆ II
  
  339
  
  miał kolejnych elementów. Jednak istnieje niewielka szansa, że na końcu iteracji dwa wątki będą interferowały ze sobą i mogą spowodować, że jeden wątek wyjdzie poza iterator i zgłosi wyjątek. Problem ten jest następujący: wątek 1. wywołuje hasNext(), która zwraca true. Wątek 1. zostaje wywłaszczony, a wątek 2. wykonuje to samo wywołanie, nadal otrzymując true. Wątek 2. wywołuje metodę next(), która zwraca oczekiwaną wartość, ale efektem ubocznym jej działania jest zmiana wartości zwracanej przez hasNext() na false. Wątek 1. wznawia pracę i zakłada, że hasNext() nadal ma wartość true, więc wywołuje next(). Mimo że poszczególne metody są synchronizowane, klient używa dwóch metod. Jest to rzeczywisty problem i takie przykłady często zdarzają się we współbieżnym kodzie. W tej sytuacji problem jest szczególnie subtelny, ponieważ jedynym miejscem, w którym może zdarzyć się błąd, jest ostatni krok iteratora. Jeżeli wątki tam właśnie się spotkają, to jeden z nich wychodzi poza iterator. Tego rodzaju błędy zdarzają się najczęściej już po produkcyjnym wdrożeniu systemu i są bardzo trudne do wyśledzenia. Mamy wtedy trzy możliwości: 
  
  tolerować awarię,
  
  
  
  rozwiązać problem przez zmianę klienta — blokowanie na kliencie,
  
  
  
  rozwiązać problem przez zmianę serwera, co dodatkowo wymaga zmian w kliencie — blokowanie na serwerze.
  
  Tolerowanie awarii Czasami można tak zorganizować pracę, aby takie awarie nie powodowały problemów. Na przykład klient może przechwycić wyjątek i wyczyścić obiekt. Oczywiście, jest to kiepskie rozwiązanie. Jest podobne do wyczyszczenia wycieków pamięci przez przeładowanie systemu o północy.
  
  Blokowanie na kliencie Aby IntegerIterator mógł działać prawidłowo dla wielu wątków, można zmienić tego klienta (i wszystkie inne) w następujący sposób: IntegerIterator iterator = new IntegerIterator(); while (true) { int nextValue; synchronized (iterator) { if (!iterator.hasNext()) break; nextValue = iterator.next(); } doSometingWith(nextValue); }
  
  Każdy klient wprowadza blokadę przez użycie słowa kluczowego synchronized. Takie powtórzenie narusza zasadę DRY, ale może być niezbędne, jeżeli kod korzysta z zewnętrznych narzędzi, które nie są bezpieczne dla wątków. 340
  
  DODATEK A
  
  Strategia ta jest ryzykowna, ponieważ wszyscy programiści korzystający z serwera muszą pamiętać o nałożeniu blokady przed jego użyciem i odblokowaniu po zakończeniu. Wiele (naprawdę wiele!) lat temu pracowałem nad systemem, w którym została zastosowana strategia blokowania zasobów na kliencie. Zasób był używany w setkach różnych miejsc w kodzie. Jeden biedny programista zapomniał o zablokowaniu zasobu w jednym z tych miejsc. System był wieloterminalowym systemem ze współużytkowaniem czasu, obsługującym księgowość dla związku kierowców ciężarówek Local 705. Komputer znajdował się w pokoju z podniesioną podłogą i klimatyzacją, 80 kilometrów na północ od siedziby Local 705. W siedzibie zainstalowanych było kilkanaście stanowisk wprowadzania danych, na których urzędnicy wprowadzali dokumenty do systemu. Terminale były podłączone do komputera z użyciem dedykowanej linii telefonicznej i półdupleksowych modemów o prędkości 600 b/s (to było bardzo, bardzo dawno). Mniej więcej raz dziennie jeden z terminali „zawieszał się”. Nie można było określić żadnych prawidłowości — blokada nie wykazywała żadnych preferencji co do terminala ani określonego czasu. Wyglądało to tak, jakby ktoś rzucał kostkami, wybierając czas i terminal do zablokowania. Czasami blokowało się kilka terminali. W niektórych dniach nie było żadnych zawieszeń. Na początku jedynym rozwiązaniem było przeładowanie. Jednak operacja ta była trudna do skoordynowania. Musieliśmy zadzwonić do centrali i poczekać na zakończenie pracy na wszystkich terminalach. Wtedy mogliśmy wyłączyć system i ponownie go uruchomić. Jeżeli ktoś robił coś ważnego, co trwało godzinę lub dwie, zablokowany terminal musiał pozostać bezużyteczny. Po kilku tygodniach debugowania odkryliśmy, że przyczyną był licznik bufora cyklicznego, który tracił synchronizację ze wskaźnikiem. Bufor ten kontrolował wyjście na terminal. Wartość wskaźnika wskazywała, że bufor był pusty, ale licznik wskazywał, że był pełny. Ponieważ był pusty, nie było nic do wyświetlania, ale ponieważ był jednocześnie pełny, nic nie można było dodać do bufora wyświetlania na ekranie. Wiedzieliśmy więc, dlaczego terminal się blokował, ale nie wiedzieliśmy, dlaczego bufor cykliczny rozsynchronizowywał się. Dodaliśmy więc modyfikację pozwalającą obejść problem. Możliwe było odczytywanie stanu przełączników na u kontrolnym komputera (to było bardzo, bardzo, bardzo dawno). Napisaliśmy małą funkcję przechwytującą, która w momencie przełączenia jednego z przełączników wyszukiwała bufory cykliczne, które były jednocześnie pełne i puste. Jeżeli go znalazła, ustawiała bufor na pusty. Voila! Zablokowany terminal ponownie zaczynał wyświetlać dane. Nie musieliśmy więc restartować systemu po zablokowaniu terminala. Wystarczył telefon od klienta, a ktoś podchodził do komputera i naciskał przycisk. Czasami jednak Local 705 pracował w weekendy, a my nie. Dodaliśmy więc funkcję do harmonogramu, która sprawdzała wszystkie bufory cykliczne co minutę i jeżeli któryś był jednocześnie pełny i pusty, resetowała go. Dzięki temu terminale odblokowywały się, zanim ktoś z Local podszedł do telefonu. Po kilku kolejnych tygodniach przeglądania strona po stronie monolitycznego kodu asemblera znaleźliśmy przyczynę. Wykonaliśmy obliczenia i wyliczyliśmy, że częstotliwość blokowania była spójna z jednym niechronionym użyciem bufora cyklicznego. Musieliśmy więc tylko znaleźć jedno
  
  WSPÓŁBIEŻNOŚĆ II
  
  341
  
  nieprawidłowe użycie. Niestety, było to bardzo dawno temu i nie mieliśmy narzędzi wyszukujących ani wzajemnych odwołań, ani też innych automatycznych podpowiedzi. Musieliśmy po prostu ślęczeć nad listingami. Tej chłodnej zimy 1971 roku w Chicago nauczyłem się czegoś ważnego. Blokowanie na kliencie jest do niczego.
  
  Blokowanie na serwerze Powtórzenia mogą być usunięte przez wprowadzenie do klasy IntegerIterator następujących zmian: public class IntegerIteratorServerLocked { private Integer nextValue = 0; public synchronized Integer getNextOrNull() { if (nextValue < 100000) return nextValue++; else return null; } }
  
  Musi zmienić się również kod klienta: while (true) { Integer nextValue = iterator.getNextOrNull(); if (next == null) break;
  
  // Wykonanie operacji na nextValue. }
  
  W tym przypadku tak zmieniamy API naszej klasy, aby obsługiwało wielowątkowość3. Klient musi skontrolować wartość null, zamiast korzystać z hasNext(). Powinniśmy korzystać z blokowania na serwerze z następujących powodów:
  
  3
  
  
  
  Zmniejsza powtarzanie kodu — blokowanie na kliencie wymusza prawidłowe blokowanie na każdym kliencie. Przeniesienie kodu blokującego na serwer pozwala, aby klienty korzystały z obiektów bez konieczności pisania dodatkowego kodu blokującego.
  
  
  
  Pozwala osiągnąć lepszą wydajność — w przypadku instalacji jednowątkowej pozwala na zamianę serwera bezpiecznego dla wątków na serwer bez obsługi wątków, dzięki czemu można pozbyć się wszystkich narzutów.
  
  
  
  Zmniejsza możliwość wystąpienia błędu — niemożliwe jest spowodowanie awarii przez jednego programistę, który zapomniał o zastosowaniu prawidłowej blokady.
  
  
  
  Wymusza jedną zasadę — zasady są w jednym miejscu, na serwerze, a nie w wielu miejscach, na każdym kliencie.
  
  W rzeczywistości interfejs Iterator jest z natury niebezpieczny dla wątków. Nigdy nie był projektowany do pracy na wielu wątkach, więc nie powinno to być niespodzianką.
  
  342
  
  DODATEK A
  
  
  
  Zmniejsza zasięg współużytkowanych zmiennych — klient nie jest ich świadom, jak również sposobu, w jaki są blokowane. Wszystko jest ukryte w serwerze. Jeżeli wystąpi błąd, liczba miejsc do sprawdzenia jest mniejsza.
  
  Co możemy zrobić, jeżeli nie mamy wpływu na kod serwera? 
  
  Skorzystać z wzorca adaptera do zmiany API i dodania blokowania. public class ThreadSafeIntegerIterator { private IntegerIterator iterator = new IntegerIterator(); public synchronized Integer getNextOrNull() { if(iterator.hasNext()) return iterator.next(); return null; } }
  
  
  
  Jeszcze lepszym rozwiązaniem jest użycie kolekcji z rozszerzonym interfejsem, bezpiecznym dla wątków.
  
  Zwiększanie przepustowości Załóżmy, że musimy skorzystać z sieci i odczytać zawartość zbioru stron z listy adresów URL. Gdy strona jest odczytywana, analizujemy ją i zbieramy pewne statystyki. Po przeczytaniu wszystkich stron wyświetlamy raport podsumowujący. Poniższa klasa zwraca zawartość strony o podanym adresie URL. public class PageReader {
  
  //... public String getPageFor(String url) { HttpMethod method = new GetMethod(url); try { httpClient.executeMethod(method); String response = method.getResponseBodyAsString(); return response; } catch (Exception e) { handle(e); } finally { method.releaseConnection(); } } }
  
  Następna klasa jest iteratorem, który udostępnia zawartość stron na podstawie iteratora adresów URL: public class PageIterator { private PageReader reader; private URLIterator urls; public PageIterator(PageReader reader, URLIterator urls) { this.urls = urls; this.reader = reader; } public synchronized String getNextPageOrNull() {
  
  WSPÓŁBIEŻNOŚĆ II
  
  343
  
  if (urls.hasNext()) getPageFor(urls.next()); else return null; } public String getPageFor(String url) { return reader.getPageFor(url); } }
  
  Obiekt PageIterator może być współużytkowany przez rożne wątki, z których każdy korzysta z własnego obiektu PageReader do odczytywania i analizowania stron uzyskanych z iteratora. Należy zauważyć, że bloki synchronized są bardzo małe. Zawierają wyłącznie sekcje krytyczne głęboko wewnątrz PageIterator. Zawsze lepiej synchronizować możliwe małe fragmenty, niż obejmować synchronizacją wszystko, co jest możliwe.
  
  Obliczenie przepustowości jednowątkowej Wykonajmy teraz proste obliczenia. Na nasze potrzeby załóżmy następujące wielkości: 
  
  Czas wejścia-wyjścia potrzebny do pobrania strony (średnio): 1 sekunda.
  
  
  
  Czas przetwarzania całej strony (średnio): 0,5 sekundy.
  
  
  
  Operacje wejścia-wyjścia wymagają 0 procent czasu procesora, natomiast przetwarzanie 100 procent.
  
  Dla N stron przetwarzanych przez jeden wątek całkowity czas wykonania wynosi 1,5 sekundy × N. Na rysunku A1 przedstawione jest przetwarzanie 13 stron, czyli około 19,5 sekundy.
  
  R Y S U N E K A 1 . Jeden wątek
  
  Obliczenie przepustowości wielowątkowej Jeżeli możliwe jest pobieranie stron w dowolnej kolejności i ich niezależne przetwarzanie, to możliwe jest użycie wielu wątków do zwiększenia przepustowości. Co się stanie, gdy użyjemy trzech wątków? Ile stron przetworzymy w tym samym czasie? Jak jest pokazane na rysunku A2, rozwiązanie wielowątkowe pozwala na to, aby przetwarzanie stron związane z procesorem przeplatało się z odczytem stron związanym z operacją wejścia-wyjścia. W idealnym przypadku oznacza to, że procesor będzie w pełni wykorzystany. Każde jednosekundowe pobranie będzie przeplatało się z analizą dwóch stron. Dlatego możemy przetwarzać dwie strony na sekundę, czyli trzy razy więcej niż przepustowość rozwiązania jednowątkowego.
  
  344
  
  DODATEK A
  
  R Y S U N E K A 2 . Trzy wątki współbieżne
  
  Zakleszczenie Wyobraźmy sobie aplikację WWW z dwoma pulami zasobów o skończonym rozmiarze: 
  
  Pula połączeń do bazy danych dla pracy lokalnej przy przetwarzaniu danych.
  
  
  
  Pula połączeń MQ do repozytorium nadrzędnego.
  
  Załóżmy, że w aplikacji mamy dwie operacje — utworzenie i aktualizację: 
  
  Utworzenie — uzyskanie połączenia z głównym repozytorium i bazą danych. Wymiana danych z usługą głównego repozytorium i zapisanie danych w lokalnej bazie danych.
  
  
  
  Aktualizacja — uzyskanie połączenia z bazą danych, a następnie z głównym repozytorium. Odczytanie danych z lokalnej bazy danych i wysłanie ich do głównego repozytorium.
  
  Co się stanie, jeżeli liczba użytkowników będzie przekraczała wielkość pul? Załóżmy, że każda pula ma wielkość równą 10. 
  
  Dziesięciu użytkowników próbuje użyć opcji utworzenia, więc wszystkie (dziesięć) połączenia do bazy danych są zajęte, a każdy wątek jest przerywany po uzyskaniu dostępu do bazy danych, ale przed uzyskaniem połączenia z głównym repozytorium.
  
  
  
  Dziesięciu użytkowników próbuje użyć opcji aktualizacji, więc wszystkie połączenia z głównym repozytorium są zajęte, a każdy wątek jest przerywany po uzyskaniu dostępu do głównego repozytorium, ale przed uzyskaniem połączenia z bazą danych.
  
  
  
  Teraz wszystkie wątki „tworzące” muszą poczekać na uzyskanie połączenia z repozytorium, a jednocześnie dziesięć wątków „aktualizujących” musi poczekać na uzyskanie połączenia z bazą danych.
  
  
  
  Zakleszczenie. System nigdy nie ruszy dalej. WSPÓŁBIEŻNOŚĆ II
  
  345
  
  Może się to wydawać mało prawdopodobną sytuacją, ale kto chciałby mieć system, który każdego tygodnia zupełnie przestaje odpowiadać? Kto chce debugować system, mając objawy tak trudne do powtórzenia? Jeżeli tego rodzaju problemy zdarzają się po wdrożeniu, to ich rozwiązanie ciągnie się tygodniami. Typowym „rozwiązaniem” jest dodanie instrukcji debugujących, które pomagają określić przyczyny problemu. Oczywiście instrukcje debugujące zmieniają kod na tyle, że zakleszczenia pojawiają się w innej sytuacji i znów trzeba czekać miesiące na ich wystąpienie4. Aby naprawdę rozwiązać problem zakleszczenia, musimy zrozumieć jego przyczynę. Istnieją cztery warunki wymagane do wystąpienia zakleszczenia: 
  
  wzajemne wykluczanie,
  
  
  
  blokowanie i oczekiwanie,
  
  
  
  brak wywłaszczania,
  
  
  
  cykliczne oczekiwanie.
  
  Wzajemne wykluczanie Wzajemne wykluczanie występuje, gdy wiele wątków musi użyć tych samych zasobów, a te zasoby: 
  
  nie mogą być używane przez wiele wątków jednocześnie,
  
  
  
  są ograniczone.
  
  Często spotykanym przykładem takich zasobów są połączenia z bazą danych, otwarte do zapisu pliki, blokady rekordów lub semafory.
  
  Blokowanie i oczekiwanie Gdy wątek uzyska zasób, nie zwalnia go do momentu uzyskania pozostałych zasobów wymaganych do zakończenia zadania.
  
  Brak wywłaszczania Jeden wątek nie może zabrać zasobów innemu wątkowi. Gdy wątek zablokuje zasób, drugi wątek może skorzystać z niego dopiero po jego zwolnieniu przez wątek blokujący.
  
  Cykliczne oczekiwanie Jest to nazywane również śmiertelnym objęciem. Wyobraźmy sobie dwa wątki, T1 i T2, oraz dwa zasoby, R1 i R2. T1 posiada R1, a T2 posiada R2. T1 wymaga również R2, a T2 wymaga również R1. Daje to w wyniku sytuację, której schemat jest przedstawiony na rysunku A3. 4
  
  Na przykład ktoś dodaje rejestrowanie diagnostyczne i problem „znika”. Kod debugujący „naprawia” problem, więc jest pozostawiany w systemie.
  
  346
  
  DODATEK A
  
  RYSUNEK A3.
  
  Wszystkie cztery warunki muszą być spełnione, aby doszło do zakleszczenia.
  
  Zapobieganie wzajemnemu wykluczaniu Jedną ze strategii unikania zakleszczenia jest zapobieganie warunkom wzajemnego wykluczania. Można to zrobić przez: 
  
  wykorzystywanie zasobów pozwalających na jednoczesne używanie, na przykład Atomic Integer;
  
  
  
  zwiększenie liczby zasobów, aby była równa lub przekraczała liczbę rywalizujących wątków;
  
  
  
  sprawdzanie, czy wszystkie zasoby są wolne przed zablokowaniem któregokolwiek.
  
  Niestety, większość zasobów jest ograniczona i nie pozwalają one na jednoczesne wykorzystywanie. Dodatkowo często drugi zasób jest określany na podstawie wyników działania na pierwszym. Jednak nie należy się zrażać, pozostały jeszcze trzy warunki.
  
  Zapobieganie blokowaniu i oczekiwaniu Można również wyeliminować zakleszczenia, jeżeli nie będziemy oczekiwać na zwolnienie blokady. Należy sprawdzić każdy zasób przed jego zablokowaniem, zwolnić wszystkie zasoby i zacząć od nowa, jeżeli jeden z nich jest zajęty. Rozwiązanie to wprowadza jednak kilka potencjalnych problemów: 
  
  Zagłodzenie — jeden wątek nie jest w stanie uzyskać potrzebnych zasobów (na przykład jest to unikatowa kombinacja zasobów, która rzadko jest dostępna).
  
  
  
  Uwięzienie — kilka wątków może wpaść w dynamiczne zakleszczenie, gdy wszystkie zajmują jeden zasób, a następnie zwalniają go, i tak w nieskończoność. Jest to szczególnie prawdopodobne dla uproszczonych algorytmów harmonogramowania U (w urządzeniach wbudowanych lub prostych własnoręcznie napisanych algorytmach równoważenia wątków).
  
  Obie te sytuacje mogą obniżać przepustowość. Wynikiem pierwszej jest niskie użycie procesora, natomiast drugiej — bezużytecznie wysokie użycie procesora.
  
  WSPÓŁBIEŻNOŚĆ II
  
  347
  
  Mimo że strategia ta wygląda na mało efektywną, jest lepsza niż nic. Posiada swoje zalety i może być niemal zawsze zastosowana, gdy wszystko inne zawiedzie.
  
  Umożliwienie wywłaszczania Inną strategią zapobiegania zakleszczeniom jest umożliwienie wątkom zabierania zasobów innym wątkom. Jest to zwykle realizowane przez prosty mechanizm żądań. Gdy wątek wykryje, że zasób jest zajęty, prosi właściciela o jego zwolnienie. Jeżeli właściciel również oczekuje na inny zasób, zwalnia wszystkie i zaczyna od nowa. Jest to podobne do poprzedniego podejścia, ale pozwala, aby wątek oczekiwał na zasób. Zmniejsza to liczbę restartów. Trzeba jednak pamiętać, że zarządzanie tymi żądaniami może być kłopotliwe.
  
  Zapobieganie oczekiwaniu cyklicznemu Jest to najczęściej stosowane podejście do zapobiegania zakleszczeniom. W przypadku większości systemów nie wymaga niczego poza uzgodnieniem przez wszystkie strony prostej konwencji. W wcześniej przedstawionym przykładzie z wątkiem 1., wymagającym zasobów 1. i 2., oraz wątkiem 2., wymagającym zasobów 2. i 1., zwykłe wymuszenie na wątkach 1. i 2. blokowania zasobów w tej samej kolejności spowoduje, że oczekiwanie cykliczne będzie niemożliwe. Co więcej, jeżeli wszystkie wątki będą stosowały globalne uporządkowanie zasobów i wszystkie będą przydzielać zasoby w tej kolejności, zakleszczenia będą niemożliwe. Jak w przypadku pozostałych strategii, może to powodować problemy: 
  
  Kolejność pobierania może nie być zgodna z kolejnością używania; zasób zajęty na początku może nie być używany aż do końca procesu. Może to powodować dłuższe zajęcie zasobów, niż są potrzebne.
  
  
  
  Czasami nie można wywnioskować kolejności przydzielania zasobów. Jeżeli identyfikator kolejnego zasobu pochodzi z operacji wykonanej na pierwszym, to kolejność może nie być właściwa.
  
  Istnieje wiele sposobów unikania zakleszczeń. Niektóre prowadzą do zagłodzenia, natomiast inne do silnego obciążenia procesora i zwiększenia czasów odpowiedzi. NMDO5! Izolowanie części rozwiązania odpowiedzialnych za wątki pozwalające na dostrajanie i eksperymentowanie jest efektywnym sposobem uzyskania wiedzy pozwalającej na wybranie najlepszej strategii.
  
  5
  
  Nie ma darmowych obiadów.
  
  348
  
  DODATEK A
  
  Testowanie kodu wielowątkowego Jak napisać test pokazujący, że poniższy kod zawiera błąd? 01: public class ClassWithThreadingProblem { 02: int nextId; 03: 04: public int takeNextId() { 05: return nextId++; 06: } 07: }
  
  Poniżej zamieszczony jest opis testu, który udowadnia, że w kodzie jest błąd: 
  
  Zapamiętaj bieżącą wartość nextId.
  
  
  
  Utwórz dwa wątki, które jednocześnie wywołują takeNextId().
  
  
  
  Sprawdź, czy nextId ma wartość o dwa większą niż na początku.
  
  
  
  Uruchamiaj test do momentu, gdy nextId będzie zwiększone o jeden zamiast dwa.
  
  Test taki jest zamieszczony na listingu A2. L I S T I N G A 2 . ClassWithThreadingProblemTest.java 01: 02: 03: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33:
  
  package example; import static org.junit.Assert.fail; import org.junit.Test; public class ClassWithThreadingProblemTest { @Test public void twoThreadsShouldFailEventually() throws Exception { final ClassWithThreadingProblem classWithThreadingProblem = new ClassWithThreadingProblem(); Runnable runnable = new Runnable() { public void run() { classWithThreadingProblem.takeNextId(); } }; for (int i = 0; i < 50000; ++i) { int startingId = classWithThreadingProblem.lastId; int expectedResult = 2 + startingId; Thread t1 = new Thread(runnable); Thread t2 = new Thread(runnable); t1.start(); t2.start(); t1.(); t2.(); int endingId = classWithThreadingProblem.lastId; if (endingId != expectedResult) return; }
  
  WSPÓŁBIEŻNOŚĆ II
  
  349
  
  34: 35: 36: 37: }
  
  fail("Powinien pokazać problem z wątkami, ale się to nie udało."); }
  
  Wiersz
  
  Opis
  
  10
  
  Utworzenie obiektu ClassWithThreadingProblem. Musieliśmy tu użyć słowa kluczowego final, ponieważ używamy go poniżej wewnętrznej klasy anonimowej.
  
  12 – 16
  
  Utworzenie anonimowej klasy wewnętrznej, która korzysta z jednego obiektu ClassWithThreadingProblem.
  
  18
  
  Uruchomienie tego kodu „odpowiednią” liczbę razy w celu pokazania, że kod zawiedzie, ale nie tak dużo, aby test „wykonywał się zbyt długo”. Jest to kwestia wyważenia; nie chcemy oczekiwać zbyt długo na pokazanie awarii. Ustalenie tej liczby jest trudne — choć później pokażemy, że można znacznie ją zmniejszyć.
  
  19
  
  Zapamiętanie wartości początkowej. Test ten próbuje udowodnić, że kod w ClassWith ThreadingProblem jest nieprawidłowy. Jeżeli ten test zostanie wykonany, udowodnimy, że kod zawiera błąd. Jeżeli test zawiedzie, nie będzie w stanie pokazać błędu w kodzie.
  
  20
  
  Oczekujemy, że końcowa wartość będzie o dwa większa niż bieżąca wartość.
  
  22 – 23
  
  Utworzenie dwóch wątków, oba są utworzone w wierszach 12. – 16. Daje to nam potencjalnie dwa wątki próbujące użyć jednego obiektu ClassWithThreadingProblem, wpływające wzajemnie na siebie.
  
  24 – 25
  
  Upewnienie się, że dwa wątki są gotowe do uruchomienia.
  
  26 – 27
  
  Oczekiwanie na zakończenie obu wątków przed sprawdzeniem wyników.
  
  29
  
  Zapamiętanie aktualnej wartości końcowej.
  
  31 – 32
  
  Czy wartość endingId różni się od oczekiwanej? Jeżeli tak, kończymy test — udowodniliśmy, że kod zawiera błąd. Jeżeli nie, próbujemy jeszcze raz.
  
  35
  
  Jeżeli doszliśmy do tego miejsca, nie jesteśmy w stanie udowodnić w „rozsądnym” czasie, że kod produkcyjny zawiera błąd; nasz test zawiódł. Albo kod nie zawiera błędu, albo nie wykonaliśmy wystarczająco dużo iteracji, aby wystąpiła sytuacja błędna.
  
  Test ten konfiguruje warunki wystąpienia problemu równoległej aktualizacji. Jednak problem występuje tak rzadko, że w większości przypadków test go nie wykryje. W rzeczywistości, aby wykryć błąd, musimy ustawić liczbę iteracji na ponad milion. Nawet wtedy w dziesięciu uruchomieniach pętli wykonującej 1 000 000 iteracji problem występuje tylko raz. Oznacza to, że aby uzyskać właściwe wyniki, powinniśmy ustawić liczbę iteracji na ponad sto milionów. Na jak długie czekanie jesteśmy przygotowani? Nawet jeżeli ustawimy test na niezawodne wykrywanie błędu na jednym komputerze, prawdopodobnie będziemy musieli zrobić to ponownie, aby wykryć błąd na innym komputerze, innym systemie operacyjnym lub wersji JVM. Pamiętajmy, że jest to prosty problem. Jeżeli nie możemy łatwo zademonstrować błędu w tym przypadku, to jak wykryć naprawdę skomplikowane problemy? Jakie podejście możemy przyjąć, aby zademonstrować taki prosty błąd? Co ważniejsze, jak pisać testy, które demonstrują błędy w bardziej złożonym kodzie? W jaki sposób wykryć błędy w kodzie, gdy nie wiemy, gdzie trzeba ich szukać?
  
  350
  
  DODATEK A
  
  Poniżej przedstawiono kilka pomysłów. 
  
  Testowanie Monte Carlo. Testy należy pisać elastycznie, aby mogły być dostrajane. Następnie należy je wykonywać w pętli — na przykład na serwerze testowym — losowo zmieniając wartości dostrajające. Jeżeli kiedykolwiek test się nie powiedzie, to w kodzie jest błąd. Należy zapewnić, że testy te zostaną napisane możliwie wcześnie, aby serwer testowy zaczął je wykonywać możliwie szybko. Przy okazji należy pamiętać o precyzyjnym zarejestrowaniu sytuacji, w której test się nie powiódł.
  
  
  
  Testy należy przeprowadzać na każdej platformie docelowej. Wielokrotnie. Ciągle. Im dłużej testy działają bezbłędnie, tym bardziej prawdopodobne jest, że kod produkcyjny jest prawidłowy lub testy nie są w stanie ujawnić problemu.
  
  
  
  Testy powinny być uruchamiane na komputerze o różnym obciążeniu. Jeżeli możemy zasymulować obciążenie zbliżone do występującego w środowisku produkcyjnym, powinniśmy to zrobić.
  
  Jednak nawet jeżeli wykonamy wszystkie te operacje, nadal nie mamy zbyt dużej szansy na znalezienie problemów wielowątkowości w naszym kodzie. W większości przypadków występują one w małych sekcjach i zdarzają się raz na miliard wykonań. Takie problemy są przekleństwem złożonych systemów.
  
  Narzędzia wspierające testowanie kodu korzystającego z wątków W firmie IBM zostało wyprodukowane narzędzie o nazwie ConTest6. Pozwala ono na instrumentację klas w taki sposób, aby kod niebezpieczny dla wątków z większym prawdopodobieństwem wygenerował błąd. Nie mamy żadnych bezpośrednich związków z firmą IBM ani zespołem produkującym ConTest. Nasi koledzy nam go pokazali. Już po kilku minutach używania tego programu zauważyliśmy ogromną poprawę możliwości znalezienia błędów wielowątkowości. Sposób wykorzystania programu ConTest jest następujący: 
  
  Napisanie testów i kodu produkcyjnego. Testy powinny być tak zaprojektowane, aby symulować wielu użytkowników przy różnym obciążeniu, tak jak wspomnieliśmy to wcześniej.
  
  
  
  Instrumentacja kodu testów i kodu produkcyjnego za pomocą ConTest.
  
  
  
  Uruchomienie testów.
  
  Gdy przetworzyliśmy nasz kod za pomocą programu ConTest, współczynnik trafień wzrósł z około jednej awarii na dziesięć milionów iteracji do około jednej awarii na trzydzieści iteracji. Po instrumentacji wartości licznika pętli dla kilku kolejnych wykonań wynosiły: 13, 23, 0, 54, 16, 6
  
  http://www.haifa.ibm.com/projects/verification/contest/index.html
  
  WSPÓŁBIEŻNOŚĆ II
  
  351
  
  14, 6, 69, 107, 49, 2. Jasno widać, że klasy po instrumentacji znacznie wcześniej i bardziej niezawodnie pozwalały wykryć błędy.
  
  Zakończenie Rozdział ten był krótką przejażdżką przez ogromne i zdradzieckie terytorium programowania współbieżnego. Co najwyżej zarysowaliśmy kilka zagadnień. Naszym celem było skupienie się na dyscyplinie zachowania czystości kodu, ale jeżeli zamierzamy pisać systemy współbieżne, powinniśmy nauczyć się znacznie więcej. Na początek polecamy świetną książkę Dougha Lea Concurrent Programming in Java: Design Principles and Patterns7. W tym rozdziale zajęliśmy się współbieżną aktualizacją oraz dyscypliną czystej synchronizacji i blokowania. Wspominaliśmy o sposobie poprawiania przepustowości systemów związanych z wejściemwyjściem za pomocą wątków oraz pokazaliśmy techniki osiągania takiej poprawy. Mówiliśmy o zakleszczeniach i sposobach ich unikania. Na koniec przedstawiliśmy strategie ujawniania problemów z wielowątkowością przez instrumentację kodu.
  
  Samouczek. Pełny kod przykładów Klient-serwer bez wątków L I S T I N G A 3 . Server.java package com.objectmentor.clientserver.nonthreaded; import import import import
  
  java.io.IOException; java.net.ServerSocket; java.net.Socket; java.net.SocketException;
  
  import common.MessageUtils; public class Server implements Runnable { ServerSocket serverSocket; volatile boolean keepProcessing = true; public Server(int port, int millisecondsTimeout) throws IOException { serverSocket = new ServerSocket(port); serverSocket.setSoTimeout(millisecondsTimeout); } public void run() { System.out.printf("Serwer uruchamia się\n"); while (keepProcessing) { try { System.out.printf("przyjmowanie klienta\n"); Socket socket = serverSocket.accept(); System.out.printf("klient przyjęty\n"); process(socket);
  
  7
  
  Patrz [Lea99], s. 191.
  
  352
  
  DODATEK A
  
  } catch (Exception e) { handle(e); } } } private void handle(Exception e) { if (!(e instanceof SocketException)) { e.printStackTrace(); } } public void stopProcessing() { keepProcessing = false; closeIgnoringException(serverSocket); } void process(Socket socket) { if (socket == null) return; try { System.out.printf("Serwer: pobieranie komunikatu\n"); String message = MessageUtils.getMessage(socket); System.out.printf("Serwer: komunikat pobrany: %s\n", message); Thread.sleep(1000); System.out.printf("Serwer: wysyłanie odpowiedzi: %s\n", message); MessageUtils.sendMessage(socket, "Przetworzone: " + message); System.out.printf("Serwer: wysłane\n"); closeIgnoringException(socket); } catch (Exception e) { e.printStackTrace(); } } private void closeIgnoringException(Socket socket) { if (socket != null) try { socket.close(); } catch (IOException ignore) { } } private void closeIgnoringException(ServerSocket serverSocket) { if (serverSocket != null) try { serverSocket.close(); } catch (IOException ignore) { } } }
  
  L I S T I N G A 4 . ClientTest.java package com.objectmentor.clientserver.nonthreaded; import import import import
  
  java.io.IOException; java.net.ServerSocket; java.net.Socket; java.net.SocketException;
  
  import common.MessageUtils; public class Server implements Runnable {
  
  WSPÓŁBIEŻNOŚĆ II
  
  353
  
  ServerSocket serverSocket; volatile boolean keepProcessing = true; public Server(int port, int millisecondsTimeout) throws IOException { serverSocket = new ServerSocket(port); serverSocket.setSoTimeout(millisecondsTimeout); } public void run() { System.out.printf("Serwer uruchamia się\n"); while (keepProcessing) { try { System.out.printf("przyjmowanie klienta\n"); Socket socket = serverSocket.accept(); System.out.printf("klient przyjęty\n"); process(socket); } catch (Exception e) { handle(e); } } } private void handle(Exception e) { if (!(e instanceof SocketException)) { e.printStackTrace(); } } public void stopProcessing() { keepProcessing = false; closeIgnoringException(serverSocket); } void process(Socket socket) { if (socket == null) return; try { System.out.printf("Serwer: pobieranie komunikatu\n"); String message = MessageUtils.getMessage(socket); System.out.printf("Serwer: komunikat pobrany: %s\n", message); Thread.sleep(1000); System.out.printf("Serwer: wysyłanie odpowiedzi: %s\n", message); MessageUtils.sendMessage(socket, "Przetworzone: " + message); System.out.printf("Serwer: wysłane\n"); closeIgnoringException(socket); } catch (Exception e) { e.printStackTrace(); } } private void closeIgnoringException(Socket socket) { if (socket != null) try { socket.close(); } catch (IOException ignore) { } } private void closeIgnoringException(ServerSocket serverSocket) { if (serverSocket != null) try { serverSocket.close(); } catch (IOException ignore) {
  
  354
  
  DODATEK A
  
  } } }
  
  L I S T I N G A 5 . MessageUtils.java package common; import import import import import import
  
  java.io.IOException; java.io.InputStream; java.io.ObjectInputStream; java.io.ObjectOutputStream; java.io.OutputStream; java.net.Socket;
  
  public class MessageUtils { public static void sendMessage(Socket socket, String message) throws IOException { OutputStream stream = socket.getOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(stream); oos.writeUTF(message); oos.flush(); } public static String getMessage(Socket socket) throws IOException { InputStream stream = socket.getInputStream(); ObjectInputStream ois = new ObjectInputStream(stream); return ois.readUTF(); } }
  
  Klient-serwer z użyciem wątków Aby serwer mógł korzystać z wątków, wystarczy zmienić sposób przetwarzania komunikatu (nowe wiersze są — dla ułatwienia — wyróżnione): void process(final Socket socket) { if (socket == null) return; Runnable clientHandler = new Runnable() { public void run() { try { System.out.printf("Serwer: pobieranie komunikatu\n"); String message = MessageUtils.getMessage(socket); System.out.printf("Serwer: komunikat pobrany: %s\n", message); Thread.sleep(1000); System.out.printf("Serwer: wysyłanie odpowiedzi: %s\n", message); MessageUtils.sendMessage(socket, "Przetworzone: " + message); System.out.printf("Serwer: wysłane\n"); closeIgnoringException(socket); } catch (Exception e) { e.printStackTrace(); } } }; Thread clientConnection = new Thread(clientHandler); clientConnection.start(); }
  
  WSPÓŁBIEŻNOŚĆ II
  
  355
  
  356
  
  DODATEK A
  
  DODATEK B
  
  org.jfree.date.SerialDate L I S T I N G B 1 . SerialDate.Java 1 /* ================================================================= 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ================================================================ 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 6 * 7 * Project Info: http://www.jfree.org/jcommon/index.html 8 * 9 * This library is free software; you can redistribute it and/or modify it 10 * under the of the GNU Lesser General Public License as published by 11 * the Free Software Foundation; either version 2.1 of the License, or 12 * (at your option) any later version. 13 * 14 * This library is distributed in the hope that it will be useful, but 15 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 16 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 17 * License for more details. 18 * 19 * You should have received a copy of the GNU Lesser General Public 20 * License along with this library; if not, write to the Free Software 21 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 22 * USA. 23 * 24 * [Java is a trademark or ed trademark of Sun Microsystems, Inc. 25 * in the United States and other countries.] 26 * 27 * --------------28 * SerialDate.java 29 * --------------30 * (C) Copyright 2001-2005, by Object Refinery Limited. 31 * 32 * Original Author: David Gilbert (for Object Refinery Limited); 33 * Contributor(s): -; 34 * 35 * $Id: SerialDate.java,v 1.7 2005/11/03 09:25:17 mungady Exp $ 36 * 37 * Changes (from 11-Oct-2001) 38 * -------------------------39 * 11-Oct-2001 : Re-organised the class and moved it to new package 40 * com.jrefinery.date (DG);
  
  357
  
  41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
  
  358
  
  * 05-Nov-2001 : Added a getDescription() method, and eliminated NotableDate * class (DG); * 12-Nov-2001 : IBD requires setDescription() method, now that NotableDate * class is gone (DG); Changed getPreviousDayOfWeek(), * getFollowingDayOfWeek() and getNearestDayOfWeek() to correct * bugs (DG); * 05-Dec-2001 : Fixed bug in SpreadsheetDate class (DG); * 29-May-2002 : Moved the month constants into a separate interface * (MonthConstants) (DG); * 27-Aug-2002 : Fixed bug in addMonths() method, thanks to N???levka Petr (DG); * 03-Oct-2002 : Fixed errors reported by Checkstyle (DG); * 13-Mar-2003 : Implemented Serializable (DG); * 29-May-2003 : Fixed bug in addMonths method (DG); * 04-Sep-2003 : Implemented Comparable. Updated the isInRange javadocs (DG); * 05-Jan-2005 : Fixed bug in addYears() method (1096282) (DG); * */ package org.jfree.date; import import import import import
  
  java.io.Serializable; java.text.DateFormatSymbols; java.text.SimpleDateFormat; java.util.Calendar; java.util.GregorianCalendar;
  
  /** * An abstract class that defines our requirements for manipulating dates, * without tying down a particular implementation. *

  * Requirement 1 : match at least what Excel does for dates; * Requirement 2 : class is immutable; *

  * Why not just use java.util.Date? We will, when it makes sense. At times, * java.util.Date can be *too* precise - it represents an instant in time, * accurate to 1/1000th of a second (with the date itself depending on the * time-zone). Sometimes we just want to represent a particular day (e.g. 21 * January 2015) without concerning ourselves about the time of day, or the * time-zone, or anything else. That's what we've defined SerialDate for. *

  * You can call getInstance() to get a concrete subclass of SerialDate, * without worrying about the exact implementation. * * @author David Gilbert */ public abstract class SerialDate implements Comparable, Serializable, MonthConstants {
  
  /** For serialization. */ private static final long serialVersionUID = -293716040467423637L;
  
  /** Date format symbols. */ public static final DateFormatSymbols DATE_FORMAT_SYMBOLS = new SimpleDateFormat().getDateFormatSymbols();
  
  /** The serial number for 1 January 1900. */ public static final int SERIAL_LOWER_BOUND = 2;
  
  /** The serial number for 31 December 9999. */ public static final int SERIAL_UPPER_BOUND = 2958465;
  
  DODATEK B
  
  102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163
  
  /** The lowest year value ed by this date format. */ public static final int MINIMUM_YEAR_ED = 1900;
  
  /** The highest year value ed by this date format. */ public static final int MAXIMUM_YEAR_ED = 9999;
  
  /** Useful constant for Monday. Equivalent to java.util.Calendar.MONDAY. */ public static final int MONDAY = Calendar.MONDAY;
  
  /** * Useful constant for Tuesday. Equivalent to java.util.Calendar.TUESDAY. */ public static final int TUESDAY = Calendar.TUESDAY;
  
  /** * Useful constant for Wednesday. Equivalent to * java.util.Calendar.WEDNESDAY. */ public static final int WEDNESDAY = Calendar.WEDNESDAY;
  
  /** * Useful constant for Thrusday. Equivalent to java.util.Calendar.THURSDAY. */ public static final int THURSDAY = Calendar.THURSDAY;
  
  /** Useful constant for Friday. Equivalent to java.util.Calendar.FRIDAY. */ public static final int FRIDAY = Calendar.FRIDAY;
  
  /** * Useful constant for Saturday. Equivalent to java.util.Calendar.SATURDAY. */ public static final int SATURDAY = Calendar.SATURDAY;
  
  /** Useful constant for Sunday. Equivalent to java.util.Calendar.SUNDAY. */ public static final int SUNDAY = Calendar.SUNDAY;
  
  /** The number of days in each month in non leap years. */ static final int[] LAST_DAY_OF_MONTH = {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
  
  /** The number of days in a (non-leap) year up to the end of each month. */ static final int[] AGGREGATE_DAYS_TO_END_OF_MONTH = {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365};
  
  /** The number of days in a year up to the end of the preceding month. */ static final int[] AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH = {0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365};
  
  /** The number of days in a leap year up to the end of each month. */ static final int[] LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_MONTH = {0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366};
  
  /** * The number of days in a leap year up to the end of the preceding month. */ static final int[] LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH = {0, 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366};
  
  /** A useful constant for referring to the first week in a month. */ public static final int FIRST_WEEK_IN_MONTH = 1;
  
  ORG.JFREE.DATE.SERIALDATE
  
  359
  
  164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
  
  360
  
  /** A useful constant for referring to the second week in a month. */ public static final int SECOND_WEEK_IN_MONTH = 2;
  
  /** A useful constant for referring to the third week in a month. */ public static final int THIRD_WEEK_IN_MONTH = 3;
  
  /** A useful constant for referring to the fourth week in a month. */ public static final int FOURTH_WEEK_IN_MONTH = 4;
  
  /** A useful constant for referring to the last week in a month. */ public static final int LAST_WEEK_IN_MONTH = 0;
  
  /** Useful range constant. */ public static final int INCLUDE_NONE = 0;
  
  /** Useful range constant. */ public static final int INCLUDE_FIRST = 1;
  
  /** Useful range constant. */ public static final int INCLUDE_SECOND = 2;
  
  /** Useful range constant. */ public static final int INCLUDE_BOTH = 3;
  
  /** * Useful constant for specifying a day of the week relative to a fixed * date. */ public static final int PRECEDING = -1;
  
  /** * Useful constant for specifying a day of the week relative to a fixed * date. */ public static final int NEAREST = 0;
  
  /** * Useful constant for specifying a day of the week relative to a fixed * date. */ public static final int FOLLOWING = 1;
  
  /** A description for the date. */ private String description;
  
  /** * Default constructor. */ protected SerialDate() { }
  
  /** * Returns true if the supplied integer code represents a * valid day-of-the-week, and false otherwise. * * @param code the code being checked for validity. * * @return true if the supplied integer code represents a * valid day-of-the-week, and false otherwise. */ public static boolean isValidWeekdayCode(final int code) {
  
  DODATEK B
  
  226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288
  
  switch(code) { case SUNDAY: case MONDAY: case TUESDAY: case WEDNESDAY: case THURSDAY: case FRIDAY: case SATURDAY: return true; default: return false; } }
  
  /** * Converts the supplied string to a day of the week. * * @param s a string representing the day of the week. * * @return -1 if the string is not convertable, the day of * the week otherwise. */ public static int stringToWeekdayCode(String s) { final String[] shortWeekdayNames = DATE_FORMAT_SYMBOLS.getShortWeekdays(); final String[] weekDayNames = DATE_FORMAT_SYMBOLS.getWeekdays(); int result = -1; s = s.trim(); for (int i = 0; i < weekDayNames.length; i++) { if (s.equals(shortWeekdayNames[i])) { result = i; break; } if (s.equals(weekDayNames[i])) { result = i; break; } } return result; }
  
  /** * Returns a string representing the supplied day-of-the-week. *

  * Need to find a better approach. * * @param weekday the day of the week. * * @return a string representing the supplied day-of-the-week. */ public static String weekdayCodeToString(final int weekday) { final String[] weekdays = DATE_FORMAT_SYMBOLS.getWeekdays(); return weekdays[weekday]; }
  
  /**
  
  ORG.JFREE.DATE.SERIALDATE
  
  361
  
  289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350
  
  362
  
  * Returns an array of month names. * * @return an array of month names. */ public static String[] getMonths() { return getMonths(false); }
  
  /** * Returns an array of month names. * * @param shortened a flag indicating that shortened month names should * be returned. * * @return an array of month names. */ public static String[] getMonths(final boolean shortened) { if (shortened) { return DATE_FORMAT_SYMBOLS.getShortMonths(); } else { return DATE_FORMAT_SYMBOLS.getMonths(); } }
  
  /** * Returns true if the supplied integer code represents a valid month. * * @param code the code being checked for validity. * * @return true if the supplied integer code represents a * valid month. */ public static boolean isValidMonthCode(final int code) { switch(code) { case JANUARY: case FEBRUARY: case MARCH: case APRIL: case MAY: case JUNE: case JULY: case AUGUST: case SEPTEMBER: case OCTOBER: case NOVEMBER: case DECEMBER: return true; default: return false; } }
  
  /** * Returns the quarter for the specified month. *
  
  DODATEK B
  
  351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412
  
  * @param code the month code (1-12). * * @return the quarter that the month belongs to. * @throws java.lang.IllegalArgumentException */ public static int monthCodeToQuarter(final int code) { switch(code) { case JANUARY: case FEBRUARY: case MARCH: return 1; case APRIL: case MAY: case JUNE: return 2; case JULY: case AUGUST: case SEPTEMBER: return 3; case OCTOBER: case NOVEMBER: case DECEMBER: return 4; default: throw new IllegalArgumentException( "SerialDate.monthCodeToQuarter: invalid month code."); } }
  
  /** * Returns a string representing the supplied month. *

  * The string returned is the long form of the month name taken from the * default locale. * * @param month the month. * * @return a string representing the supplied month. */ public static String monthCodeToString(final int month) { return monthCodeToString(month, false); }
  
  /** * Returns a string representing the supplied month. *

  * The string returned is the long or short form of the month name taken * from the default locale. * * @param month the month. * @param shortened if true return the abbreviation of the * month. * * @return a string representing the supplied month. * @throws java.lang.IllegalArgumentException */ public static String monthCodeToString(final int month, final boolean shortened) {
  
  // check arguments... if (!isValidMonthCode(month)) { throw new IllegalArgumentException( "SerialDate.monthCodeToString: month outside valid range.");
  
  ORG.JFREE.DATE.SERIALDATE
  
  363
  
  413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475
  
  364
  
  } final String[] months; if (shortened) { months = DATE_FORMAT_SYMBOLS.getShortMonths(); } else { months = DATE_FORMAT_SYMBOLS.getMonths(); } return months[month - 1]; }
  
  /** * Converts a string to a month code. *

  * This method will return one of the constants JANUARY, FEBRUARY, …, * DECEMBER that corresponds to the string. If the string is not * recognised, this method returns -1. * * @param s the string to parse. * * @return -1 if the string is not parseable, the month of the * year otherwise. */ public static int stringToMonthCode(String s) { final String[] shortMonthNames = DATE_FORMAT_SYMBOLS.getShortMonths(); final String[] monthNames = DATE_FORMAT_SYMBOLS.getMonths(); int result = -1; s = s.trim();
  
  // first try parsing the string as an integer (1-12)… try { result = Integer.parseInt(s); } catch (NumberFormatException e) {
  
  // suppress }
  
  // now search through the month names… if ((result < 1) || (result > 12)) { for (int i = 0; i < monthNames.length; i++) { if (s.equals(shortMonthNames[i])) { result = i + 1; break; } if (s.equals(monthNames[i])) { result = i + 1; break; } } } return result; }
  
  /** * Returns true if the supplied integer code represents a valid
  
  DODATEK B
  
  476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537
  
  * week-in-the-month, and false otherwise. * * @param code the code being checked for validity. * @return true if the supplied integer code represents a * valid week-in-the-month. */ public static boolean isValidWeekInMonthCode(final int code) { switch(code) { case FIRST_WEEK_IN_MONTH: case SECOND_WEEK_IN_MONTH: case THIRD_WEEK_IN_MONTH: case FOURTH_WEEK_IN_MONTH: case LAST_WEEK_IN_MONTH: return true; default: return false; } }
  
  /** * Determines whether or not the specified year is a leap year. * * @param yyyy the year (in the range 1900 to 9999). * * @return true if the specified year is a leap year. */ public static boolean isLeapYear(final int yyyy) { if ((yyyy % 4) != 0) { return false; } else if ((yyyy % 400) == 0) { return true; } else if ((yyyy % 100) == 0) { return false; } else { return true; } }
  
  /** * Returns the number of leap years from 1900 to the specified year * INCLUSIVE. *

  * Note that 1900 is not a leap year. * * @param yyyy the year (in the range 1900 to 9999). * * @return the number of leap years from 1900 to the specified year. */ public static int leapYearCount(final int yyyy) { final int leap4 = (yyyy - 1896) / 4; final int leap100 = (yyyy - 1800) / 100; final int leap400 = (yyyy - 1600) / 400; return leap4 - leap100 + leap400; }
  
  ORG.JFREE.DATE.SERIALDATE
  
  365
  
  538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599
  
  366
  
  /** * Returns the number of the last day of the month, taking into * leap years. * * @param month the month. * @param yyyy the year (in the range 1900 to 9999). * * @return the number of the last day of the month. */ public static int lastDayOfMonth(final int month, final int yyyy) { final int result = LAST_DAY_OF_MONTH[month]; if (month != FEBRUARY) { return result; } else if (isLeapYear(yyyy)) { return result + 1; } else { return result; } }
  
  /** * Creates a new date by adding the specified number of days to the base * date. * * @param days the number of days to add (can be negative). * @param base the base date. * * @return a new date. */ public static SerialDate addDays(final int days, final SerialDate base) { final int serialDayNumber = base.toSerial() + days; return SerialDate.createInstance(serialDayNumber); }
  
  /** * Creates a new date by adding the specified number of months to the base * date. *

  * If the base date is close to the end of the month, the day on the result * may be adjusted slightly: 31 May + 1 month = 30 June. * * @param months the number of months to add (can be negative). * @param base the base date. * * @return a new date. */ public static SerialDate addMonths(final int months, final SerialDate base) { final int yy = (12 * base.getYYYY() + base.getMonth() + months - 1) / 12; final int mm = (12 * base.getYYYY() + base.getMonth() + months - 1) % 12 + 1; final int dd = Math.min( base.getDayOfMonth(), SerialDate.lastDayOfMonth(mm, yy) );
  
  DODATEK B
  
  600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661
  
  return SerialDate.createInstance(dd, mm, yy); }
  
  /** * Creates a new date by adding the specified number of years to the base * date. * * @param years the number of years to add (can be negative). * @param base the base date. * * @return A new date. */ public static SerialDate addYears(final int years, final SerialDate base) { final int baseY = base.getYYYY(); final int baseM = base.getMonth(); final int baseD = base.getDayOfMonth(); final int targetY = baseY + years; final int targetD = Math.min( baseD, SerialDate.lastDayOfMonth(baseM, targetY) ); return SerialDate.createInstance(targetD, baseM, targetY); }
  
  /** * Returns the latest date that falls on the specified day-of-the-week and * is BEFORE the base date. * * @param targetWeekday a code for the target day-of-the-week. * @param base the base date. * * @return the latest date that falls on the specified day-of-the-week and * is BEFORE the base date. */ public static SerialDate getPreviousDayOfWeek(final int targetWeekday, final SerialDate base) {
  
  // check arguments… if (!SerialDate.isValidWeekdayCode(targetWeekday)) { throw new IllegalArgumentException( "Invalid day-of-the-week code." ); }
  
  // find the date… final int adjust; final int baseDOW = base.getDayOfWeek(); if (baseDOW > targetWeekday) { adjust = Math.min(0, targetWeekday - baseDOW); } else { adjust = -7 + Math.max(0, targetWeekday - baseDOW); } return SerialDate.addDays(adjust, base); }
  
  ORG.JFREE.DATE.SERIALDATE
  
  367
  
  662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723
  
  368
  
  /** * Returns the earliest date that falls on the specified day-of-the-week * and is AFTER the base date. * * @param targetWeekday a code for the target day-of-the-week. * @param base the base date. * * @return the earliest date that falls on the specified day-of-the-week * and is AFTER the base date. */ public static SerialDate getFollowingDayOfWeek(final int targetWeekday, final SerialDate base) {
  
  // check arguments… if (!SerialDate.isValidWeekdayCode(targetWeekday)) { throw new IllegalArgumentException( "Invalid day-of-the-week code." ); }
  
  // find the date… final int adjust; final int baseDOW = base.getDayOfWeek(); if (baseDOW > targetWeekday) { adjust = 7 + Math.min(0, targetWeekday - baseDOW); } else { adjust = Math.max(0, targetWeekday - baseDOW); } return SerialDate.addDays(adjust, base); }
  
  /** * Returns the date that falls on the specified day-of-the-week and is * CLOSEST to the base date. * * @param targetDOW a code for the target day-of-the-week. * @param base the base date. * * @return the date that falls on the specified day-of-the-week and is * CLOSEST to the base date. */ public static SerialDate getNearestDayOfWeek(final int targetDOW, final SerialDate base) {
  
  // check arguments… if (!SerialDate.isValidWeekdayCode(targetDOW)) { throw new IllegalArgumentException( "Invalid day-of-the-week code." ); }
  
  // find the date… final int baseDOW = base.getDayOfWeek(); int adjust = -Math.abs(targetDOW - baseDOW); if (adjust >= 4) { adjust = 7 - adjust; } if (adjust <= -4) { adjust = 7 + adjust; }
  
  DODATEK B
  
  724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785
  
  return SerialDate.addDays(adjust, base); }
  
  /** * Rolls the date forward to the last day of the month. * * @param base the base date. * * @return a new serial date. */ public SerialDate getEndOfCurrentMonth(final SerialDate base) { final int last = SerialDate.lastDayOfMonth( base.getMonth(), base.getYYYY() ); return SerialDate.createInstance(last, base.getMonth(), base.getYYYY()); }
  
  /** * Returns a string corresponding to the week-in-the-month code. *

  * Need to find a better approach. * * @param count an integer code representing the week-in-the-month. * * @return a string corresponding to the week-in-the-month code. */ public static String weekInMonthToString(final int count) { switch (count) { case SerialDate.FIRST_WEEK_IN_MONTH : return "First"; case SerialDate.SECOND_WEEK_IN_MONTH : return "Second"; case SerialDate.THIRD_WEEK_IN_MONTH : return "Third"; case SerialDate.FOURTH_WEEK_IN_MONTH : return "Fourth"; case SerialDate.LAST_WEEK_IN_MONTH : return "Last"; default : return "SerialDate.weekInMonthToString(): invalid code."; } }
  
  /** * Returns a string representing the supplied 'relative'. *

  * Need to find a better approach. * * @param relative a constant representing the 'relative'. * * @return a string representing the supplied 'relative'. */ public static String relativeToString(final int relative) { switch (relative) { case SerialDate.PRECEDING case SerialDate.NEAREST : case SerialDate.FOLLOWING default : return "ERROR : }
  
  : return "Preceding"; return "Nearest"; : return "Following"; Relative To String";
  
  }
  
  /**
  
  ORG.JFREE.DATE.SERIALDATE
  
  369
  
  786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846
  
  370
  
  * Factory method that returns an instance of some concrete subclass of * {@link SerialDate}. * * @param day the day (1-31). * @param month the month (1-12). * @param yyyy the year (in the range 1900 to 9999). * * @return An instance of {@link SerialDate}. */ public static SerialDate createInstance(final int day, final int month, final int yyyy) { return new SpreadsheetDate(day, month, yyyy); }
  
  /** * Factory method that returns an instance of some concrete subclass of * {@link SerialDate}. * * @param serial the serial number for the day (1 January 1900 = 2). * * @return a instance of SerialDate. */ public static SerialDate createInstance(final int serial) { return new SpreadsheetDate(serial); }
  
  /** * Factory method that returns an instance of a subclass of SerialDate. * * @param date A Java date object. * * @return a instance of SerialDate. */ public static SerialDate createInstance(final java.util.Date date) { final GregorianCalendar calendar = new GregorianCalendar(); calendar.setTime(date); return new SpreadsheetDate(calendar.get(Calendar.DATE), calendar.get(Calendar.MONTH) + 1, calendar.get(Calendar.YEAR)); }
  
  /** * Returns the serial number for the date, where 1 January 1900 = 2 (this * corresponds, almost, to the numbering system used in Microsoft Excel for * Windows and Lotus 1-2-3). * * @return the serial number for the date. */ public abstract int toSerial();
  
  /** * Returns a java.util.Date. Since java.util.Date has more precision than * SerialDate, we need to define a convention for the 'time of day'. * * @return this as java.util.Date. */ public abstract java.util.Date toDate();
  
  /**
  
  DODATEK B
  
  847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907
  
  * Returns a description of the date. * * @return a description of the date. */ public String getDescription() { return this.description; }
  
  /** * Sets the description for the date. * * @param description the new description for the date. */ public void setDescription(final String description) { this.description = description; }
  
  /** * Converts the date to a string. * * @return a string representation of the date. */ public String toString() { return getDayOfMonth() + "-" + SerialDate.monthCodeToString(getMonth()) + "-" + getYYYY(); }
  
  /** * Returns the year (assume a valid range of 1900 to 9999). * * @return the year. */ public abstract int getYYYY();
  
  /** * Returns the month (January = 1, February = 2, March = 3). * * @return the month of the year. */ public abstract int getMonth();
  
  /** * Returns the day of the month. * * @return the day of the month. */ public abstract int getDayOfMonth();
  
  /** * Returns the day of the week. * * @return the day of the week. */ public abstract int getDayOfWeek();
  
  /** * Returns the difference (in days) between this date and the specified * 'other' date. *

  * The result is positive if this date is after the 'other' date and * negative if it is before the 'other' date.
  
  ORG.JFREE.DATE.SERIALDATE
  
  371
  
  908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968
  
  372
  
  * * @param other the date being compared to. * * @return the difference between this and the other date. */ public abstract int compare(SerialDate other);
  
  /** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date as * the specified SerialDate. */ public abstract boolean isOn(SerialDate other);
  
  /** * Returns true if this SerialDate represents an earlier date compared to * the specified SerialDate. * * @param other The date being compared to. * * @return true if this SerialDate represents an earlier date * compared to the specified SerialDate. */ public abstract boolean isBefore(SerialDate other);
  
  /** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date * as the specified SerialDate. */ public abstract boolean isOnOrBefore(SerialDate other);

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date * as the specified SerialDate. */ public abstract boolean isAfter(SerialDate other);

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date * as the specified SerialDate. */ public abstract boolean isOnOrAfter(SerialDate other);

DODATEK B

969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029

/** * Returns true if this {@link SerialDate} is within the * specified range (INCLUSIVE). The date order of d1 and d2 is not * important. * * @param d1 a boundary date for the range. * @param d2 the other boundary date for the range. * * @return A boolean. */ public abstract boolean isInRange(SerialDate d1, SerialDate d2);

/** * Returns true if this {@link SerialDate} is within the * specified range (caller specifies whether or not the end-points are * included). The date order of d1 and d2 is not important. * * @param d1 a boundary date for the range. * @param d2 the other boundary date for the range. * @param include a code that controls whether or not the start and end * dates are included in the range. * * @return A boolean. */ public abstract boolean isInRange(SerialDate d1, SerialDate d2, int include);

/** * Returns the latest date that falls on the specified day-of-the-week and * is BEFORE this date. * * @param targetDOW a code for the target day-of-the-week. * * @return the latest date that falls on the specified day-of-the-week and * is BEFORE this date. */ public SerialDate getPreviousDayOfWeek(final int targetDOW) { return getPreviousDayOfWeek(targetDOW, this); }

/** * Returns the earliest date that falls on the specified day-of-the-week * and is AFTER this date. * * @param targetDOW a code for the target day-of-the-week. * * @return the earliest date that falls on the specified day-of-the-week * and is AFTER this date. */ public SerialDate getFollowingDayOfWeek(final int targetDOW) { return getFollowingDayOfWeek(targetDOW, this); }

/** * Returns the nearest date that falls on the specified day-of-the-week. * * @param targetDOW a code for the target day-of-the-week. * * @return the nearest date that falls on the specified day-of-the-week. */

ORG.JFREE.DATE.SERIALDATE

373

1030 1031 1032 1033 1034 }

public SerialDate getNearestDayOfWeek(final int targetDOW) { return getNearestDayOfWeek(targetDOW, this); }

L I S T I N G B 2 . SerialDateTest.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

374

/* ================================================================== * JCommon : a free general purpose class library for the Java(tm) platform * ================================================================= * * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. * * Project Info: http://www.jfree.org/jcommon/index.html * * This library is free software; you can redistribute it and/or modify it * under the of the GNU Lesser General Public License as published by * the Free Software Foundation; either version 2.1 of the License, or * (at your option) any later version. * * This library is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public * License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, * USA. * * [Java is a trademark or ed trademark of Sun Microsystems, Inc. * in the United States and other countries.] * * -------------------* SerialDateTests.java * -------------------* (C) Copyright 2001-2005, by Object Refinery Limited. * * Original Author: David Gilbert (for Object Refinery Limited); * Contributor(s): -; * * $Id: SerialDateTests.java,v 1.5 2005/10/18 13:15:28 mungady Exp $ * * Changes * ------* 15-Nov-2001 : Version 1 (DG); * 25-Jun-2002 : Removed unnecessary import (DG); * 24-Oct-2002 : Fixed errors reported by Checkstyle (DG); * 13-Mar-2003 : Added serialization test (DG); * 05-Jan-2005 : Added test for bug report 1096282 (DG); * */ package org.jfree.date.junit; import import import import import

java.io.ByteArrayInputStream; java.io.ByteArrayOutputStream; java.io.ObjectInput; java.io.ObjectInputStream; java.io.ObjectOutput;

DODATEK B

54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115

import java.io.ObjectOutputStream; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; import org.jfree.date.MonthConstants; import org.jfree.date.SerialDate;

/** * Some JUnit tests for the {@link SerialDate} class. */ public class SerialDateTests extends TestCase {

/** Date representing November 9. */ private SerialDate nov9Y2001;

/** * Creates a new test case. * * @param name the name. */ public SerialDateTests(final String name) { super(name); }

/** * Returns a test suite for the JUnit test runner. * * @return The test suite. */ public static Test suite() { return new TestSuite(SerialDateTests.class); }

/** * Problem set up. */ protected void setUp() { this.nov9Y2001 = SerialDate.createInstance(9, MonthConstants.NOVEMBER, 2001); }

/** * 9 Nov 2001 plus two months should be 9 Jan 2002. */ public void testAddMonthsTo9Nov2001() { final SerialDate jan9Y2002 = SerialDate.addMonths(2, this.nov9Y2001); final SerialDate answer = SerialDate.createInstance(9, 1, 2002); assertEquals(answer, jan9Y2002); }

/** * A test case for a reported bug, now fixed. */ public void testAddMonthsTo5Oct2003() { final SerialDate d1 = SerialDate.createInstance(5, MonthConstants.OCTOBER, 2003); final SerialDate d2 = SerialDate.addMonths(2, d1); assertEquals(d2, SerialDate.createInstance(5, MonthConstants.DECEMBER, 2003)); }

/** * A test case for a reported bug, now fixed.

ORG.JFREE.DATE.SERIALDATE

375

116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175

376

*/ public void testAddMonthsTo1Jan2003() { final SerialDate d1 = SerialDate.createInstance(1, MonthConstants.JANUARY, 2003); final SerialDate d2 = SerialDate.addMonths(0, d1); assertEquals(d2, d1); }

/** * Monday preceding Friday 9 November 2001 should be 5 November. */ public void testMondayPrecedingFriday9Nov2001() { SerialDate mondayBefore = SerialDate.getPreviousDayOfWeek( SerialDate.MONDAY, this.nov9Y2001 ); assertEquals(5, mondayBefore.getDayOfMonth()); }

/** * Monday following Friday 9 November 2001 should be 12 November. */ public void testMondayFollowingFriday9Nov2001() { SerialDate mondayAfter = SerialDate.getFollowingDayOfWeek( SerialDate.MONDAY, this.nov9Y2001 ); assertEquals(12, mondayAfter.getDayOfMonth()); }

/** * Monday nearest Friday 9 November 2001 should be 12 November. */ public void testMondayNearestFriday9Nov2001() { SerialDate mondayNearest = SerialDate.getNearestDayOfWeek( SerialDate.MONDAY, this.nov9Y2001 ); assertEquals(12, mondayNearest.getDayOfMonth()); }

/** * The Monday nearest to 22nd January 1970 falls on the 19th. */ public void testMondayNearest22Jan1970() { SerialDate jan22Y1970 = SerialDate.createInstance(22, MonthConstants.JANUARY, 1970); SerialDate mondayNearest = SerialDate.getNearestDayOfWeek(SerialDate.MONDAY, jan22Y1970); assertEquals(19, mondayNearest.getDayOfMonth()); }

/** * Problem that the conversion of days to strings returns the right result. Actually, this * result depends on the Locale so this test needs to be modified. */ public void testWeekdayCodeToString() { final String test = SerialDate.weekdayCodeToString(SerialDate.SATURDAY); assertEquals("Saturday", test); }

/** * Test the conversion of a string to a weekday. Note that this test will fail if the * default locale doesn't use English weekday names...devise a better test!

DODATEK B

176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237

*/ public void testStringToWeekday() { int weekday = SerialDate.stringToWeekdayCode("Wednesday"); assertEquals(SerialDate.WEDNESDAY, weekday); weekday = SerialDate.stringToWeekdayCode(" Wednesday "); assertEquals(SerialDate.WEDNESDAY, weekday); weekday = SerialDate.stringToWeekdayCode("Wed"); assertEquals(SerialDate.WEDNESDAY, weekday); }

/** * Test the conversion of a string to a month. Note that this test will fail if the default * locale doesn't use English month names...devise a better test! */ public void testStringToMonthCode() { int m = SerialDate.stringToMonthCode("January"); assertEquals(MonthConstants.JANUARY, m); m = SerialDate.stringToMonthCode(" January "); assertEquals(MonthConstants.JANUARY, m); m = SerialDate.stringToMonthCode("Jan"); assertEquals(MonthConstants.JANUARY, m); }

/** * Tests the conversion of a month code to a string. */ public void testMonthCodeToStringCode() { final String test = SerialDate.monthCodeToString(MonthConstants.DECEMBER); assertEquals("December", test); }

/** * 1900 is not a leap year. */ public void testIsNotLeapYear1900() { assertTrue(!SerialDate.isLeapYear(1900)); }

/** * 2000 is a leap year. */ public void testIsLeapYear2000() { assertTrue(SerialDate.isLeapYear(2000)); }

/** * The number of leap years from 1900 up-to-and-including 1899 is 0. */ public void testLeapYearCount1899() { assertEquals(SerialDate.leapYearCount(1899), 0); }

ORG.JFREE.DATE.SERIALDATE

377

238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298

378

/** * The number of leap years from 1900 up-to-and-including 1903 is 0. */ public void testLeapYearCount1903() { assertEquals(SerialDate.leapYearCount(1903), 0); }

/** * The number of leap years from 1900 up-to-and-including 1904 is 1. */ public void testLeapYearCount1904() { assertEquals(SerialDate.leapYearCount(1904), 1); }

/** * The number of leap years from 1900 up-to-and-including 1999 is 24. */ public void testLeapYearCount1999() { assertEquals(SerialDate.leapYearCount(1999), 24); }

/** * The number of leap years from 1900 up-to-and-including 2000 is 25. */ public void testLeapYearCount2000() { assertEquals(SerialDate.leapYearCount(2000), 25); }

/** * Serialize an instance, restore it, and check for equality. */ public void testSerialization() { SerialDate d1 = SerialDate.createInstance(15, 4, 2000); SerialDate d2 = null; try { ByteArrayOutputStream buffer = new ByteArrayOutputStream(); ObjectOutput out = new ObjectOutputStream(buffer); out.writeObject(d1); out.close(); ObjectInput in = new ObjectInputStream(new ByteArrayInputStream (buffer.toByteArray())); d2 = (SerialDate) in.readObject(); in.close(); } catch (Exception e) { System.out.println(e.toString()); } assertEquals(d1, d2); }

/** * A test for bug report 1096282 (now fixed). */ public void test1096282() { SerialDate d = SerialDate.createInstance(29, 2, 2004); d = SerialDate.addYears(1, d); SerialDate expected = SerialDate.createInstance(28, 2, 2005); assertTrue(d.isOn(expected));

DODATEK B

299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 }

}

/** * Miscellaneous tests for the addMonths() method. */ public void testAddMonths() { SerialDate d1 = SerialDate.createInstance(31, 5, 2004); SerialDate d2 = SerialDate.addMonths(1, d1); assertEquals(30, d2.getDayOfMonth()); assertEquals(6, d2.getMonth()); assertEquals(2004, d2.getYYYY()); SerialDate d3 = SerialDate.addMonths(2, d1); assertEquals(31, d3.getDayOfMonth()); assertEquals(7, d3.getMonth()); assertEquals(2004, d3.getYYYY()); SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1)); assertEquals(30, d4.getDayOfMonth()); assertEquals(7, d4.getMonth()); assertEquals(2004, d4.getYYYY()); }

L I S T I N G B 3 . MonthConstants.java 1 /* ================================================================== 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ================================================================== 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 6 * 7 * Project Info: http://www.jfree.org/jcommon/index.html 8 * 9 * This library is free software; you can redistribute it and/or modify it 10 * under the of the GNU Lesser General Public License as published by 11 * the Free Software Foundation; either version 2.1 of the License, or 12 * (at your option) any later version. 13 * 14 * This library is distributed in the hope that it will be useful, but 15 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 16 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 17 * License for more details. 18 * 19 * You should have received a copy of the GNU Lesser General Public 20 * License along with this library; if not, write to the Free Software 21 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 22 * USA. 23 * 24 * [Java is a trademark or ed trademark of Sun Microsystems, Inc. 25 * in the United States and other countries.] 26 * 27 * ------------------28 * MonthConstants.java 29 * ------------------30 * (C) Copyright 2002, 2003, by Object Refinery Limited. 31 * 32 * Original Author: David Gilbert (for Object Refinery Limited); 33 * Contributor(s): -;

ORG.JFREE.DATE.SERIALDATE

379

34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

380

* * $Id: MonthConstants.java,v 1.3 2005/10/18 13:15:08 mungady Exp $ * * Changes * ------* 29-May-2002 : Version 1 (code moved from SerialDate class) (DG); * */ package org.jfree.date;

/** * Useful constants for months. Note that these are NOT equivalent to the * constants defined by java.util.Calendar (where JANUARY=0 and DECEMBER=11). *

  * Used by the SerialDate and RegularTimePeriod classes. * * @author David Gilbert */ public interface MonthConstants {

/** Constant for January. */ public static final int JANUARY = 1;

/** Constant for February. */ public static final int FEBRUARY = 2;

/** Constant for March. */ public static final int MARCH = 3;

/** Constant for April. */ public static final int APRIL = 4;

/** Constant for May. */ public static final int MAY = 5;

/** Constant for June. */ public static final int JUNE = 6;

/** Constant for July. */ public static final int JULY = 7;

/** Constant for August. */ public static final int AUGUST = 8;

/** Constant for September. */ public static final int SEPTEMBER = 9;

/** Constant for October. */ public static final int OCTOBER = 10;

/** Constant for November. */ public static final int NOVEMBER = 11;

/** Constant for December. */ public static final int DECEMBER = 12; }

DODATEK B

L I S T I N G B 4 . BobsSerialDateTest.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

package org.jfree.date.junit; import junit.framework.TestCase; import org.jfree.date.*; import static org.jfree.date.SerialDate.*; import java.util.*; public class BobsSerialDateTest extends TestCase { public void testIsValidWeekdayCode() throws Exception { for (int day = 1; day <= 7; day++) assertTrue(isValidWeekdayCode(day)); assertFalse(isValidWeekdayCode(0)); assertFalse(isValidWeekdayCode(8)); } public void testStringToWeekdayCode() throws Exception { assertEquals(-1, stringToWeekdayCode("Hello")); assertEquals(MONDAY, stringToWeekdayCode("Monday")); assertEquals(MONDAY, stringToWeekdayCode("Mon"));

//todo assertEquals(MONDAY,stringToWeekdayCode("monday")); // assertEquals(MONDAY,stringToWeekdayCode("MONDAY")); // assertEquals(MONDAY, stringToWeekdayCode("mon")); assertEquals(TUESDAY, stringToWeekdayCode("Tuesday")); assertEquals(TUESDAY, stringToWeekdayCode("Tue"));

// assertEquals(TUESDAY,stringToWeekdayCode("tuesday")); // assertEquals(TUESDAY,stringToWeekdayCode("TUESDAY")); // assertEquals(TUESDAY, stringToWeekdayCode("tue")); // assertEquals(TUESDAY, stringToWeekdayCode("tues")); assertEquals(WEDNESDAY, stringToWeekdayCode("Wednesday")); assertEquals(WEDNESDAY, stringToWeekdayCode("Wed"));

// assertEquals(WEDNESDAY,stringToWeekdayCode("wednesday")); // assertEquals(WEDNESDAY,stringToWeekdayCode("WEDNESDAY")); // assertEquals(WEDNESDAY, stringToWeekdayCode("wed")); assertEquals(THURSDAY, stringToWeekdayCode("Thursday")); assertEquals(THURSDAY, stringToWeekdayCode("Thu"));

// assertEquals(THURSDAY,stringToWeekdayCode("thursday")); // assertEquals(THURSDAY,stringToWeekdayCode("THURSDAY")); // assertEquals(THURSDAY, stringToWeekdayCode("thu")); // assertEquals(THURSDAY, stringToWeekdayCode("thurs")); assertEquals(FRIDAY, stringToWeekdayCode("Friday")); assertEquals(FRIDAY, stringToWeekdayCode("Fri"));

// assertEquals(FRIDAY,stringToWeekdayCode("friday")); // assertEquals(FRIDAY,stringToWeekdayCode("FRIDAY")); // assertEquals(FRIDAY, stringToWeekdayCode("fri")); assertEquals(SATURDAY, stringToWeekdayCode("Saturday")); assertEquals(SATURDAY, stringToWeekdayCode("Sat"));

// assertEquals(SATURDAY,stringToWeekdayCode("saturday")); // assertEquals(SATURDAY,stringToWeekdayCode("SATURDAY")); // assertEquals(SATURDAY, stringToWeekdayCode("sat")); assertEquals(SUNDAY, stringToWeekdayCode("Sunday")); assertEquals(SUNDAY, stringToWeekdayCode("Sun"));

// assertEquals(SUNDAY,stringToWeekdayCode("sunday"));

ORG.JFREE.DATE.SERIALDATE

381

62 // assertEquals(SUNDAY,stringToWeekdayCode("SUNDAY")); 63 // assertEquals(SUNDAY, stringToWeekdayCode("sun")); 64 } 65 66 public void testWeekdayCodeToString() throws Exception { 67 assertEquals("Sunday", weekdayCodeToString(SUNDAY)); 68 assertEquals("Monday", weekdayCodeToString(MONDAY)); 69 assertEquals("Tuesday", weekdayCodeToString(TUESDAY)); 70 assertEquals("Wednesday", weekdayCodeToString(WEDNESDAY)); 71 assertEquals("Thursday", weekdayCodeToString(THURSDAY)); 72 assertEquals("Friday", weekdayCodeToString(FRIDAY)); 73 assertEquals("Saturday", weekdayCodeToString(SATURDAY)); 74 } 75 76 public void testIsValidMonthCode() throws Exception { 77 for (int i = 1; i <= 12; i++) 78 assertTrue(isValidMonthCode(i)); 79 assertFalse(isValidMonthCode(0)); 80 assertFalse(isValidMonthCode(13)); 81 } 82 83 public void testMonthToQuarter() throws Exception { 84 assertEquals(1, monthCodeToQuarter(JANUARY)); 85 assertEquals(1, monthCodeToQuarter(FEBRUARY)); 86 assertEquals(1, monthCodeToQuarter(MARCH)); 87 assertEquals(2, monthCodeToQuarter(APRIL)); 88 assertEquals(2, monthCodeToQuarter(MAY)); 89 assertEquals(2, monthCodeToQuarter(JUNE)); 90 assertEquals(3, monthCodeToQuarter(JULY)); 91 assertEquals(3, monthCodeToQuarter(AUGUST)); 92 assertEquals(3, monthCodeToQuarter(SEPTEMBER)); 93 assertEquals(4, monthCodeToQuarter(OCTOBER)); 94 assertEquals(4, monthCodeToQuarter(NOVEMBER)); 95 assertEquals(4, monthCodeToQuarter(DECEMBER)); 96 97 try { 98 monthCodeToQuarter(-1); 99 fail("Nieprawidłowy kod miesiąca powinien wygenerować wyjątek"); 100 } catch (IllegalArgumentException e) { 101 } 102 } 103 104 public void testMonthCodeToString() throws Exception { 105 assertEquals("January", monthCodeToString(JANUARY)); 106 assertEquals("February", monthCodeToString(FEBRUARY)); 107 assertEquals("March", monthCodeToString(MARCH)); 108 assertEquals("April", monthCodeToString(APRIL)); 109 assertEquals("May", monthCodeToString(MAY)); 110 assertEquals("June", monthCodeToString(JUNE)); 111 assertEquals("July", monthCodeToString(JULY)); 112 assertEquals("August", monthCodeToString(AUGUST)); 113 assertEquals("September", monthCodeToString(SEPTEMBER)); 114 assertEquals("October", monthCodeToString(OCTOBER)); 115 assertEquals("November", monthCodeToString(NOVEMBER)); 116 assertEquals("December", monthCodeToString(DECEMBER)); 117 118 assertEquals("Jan", monthCodeToString(JANUARY, true)); 119 assertEquals("Feb", monthCodeToString(FEBRUARY, true)); 120 assertEquals("Mar", monthCodeToString(MARCH, true)); 121 assertEquals("Apr", monthCodeToString(APRIL, true)); 122 assertEquals("May", monthCodeToString(MAY, true)); 123 assertEquals("Jun", monthCodeToString(JUNE, true)); 124 assertEquals("Jul", monthCodeToString(JULY, true)); 125 assertEquals("Aug", monthCodeToString(AUGUST, true));

382

DODATEK B

126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

assertEquals("Sep", assertEquals("Oct", assertEquals("Nov", assertEquals("Dec",

monthCodeToString(SEPTEMBER, true)); monthCodeToString(OCTOBER, true)); monthCodeToString(NOVEMBER, true)); monthCodeToString(DECEMBER, true));

try { monthCodeToString(-1); fail("Nieprawidłowy kod miesiąca powinien wygenerować wyjątek"); } catch (IllegalArgumentException e) { } } public void testStringToMonthCode() throws Exception { assertEquals(JANUARY,stringToMonthCode("1")); assertEquals(FEBRUARY,stringToMonthCode("2")); assertEquals(MARCH,stringToMonthCode("3")); assertEquals(APRIL,stringToMonthCode("4")); assertEquals(MAY,stringToMonthCode("5")); assertEquals(JUNE,stringToMonthCode("6")); assertEquals(JULY,stringToMonthCode("7")); assertEquals(AUGUST,stringToMonthCode("8")); assertEquals(SEPTEMBER,stringToMonthCode("9")); assertEquals(OCTOBER,stringToMonthCode("10")); assertEquals(NOVEMBER, stringToMonthCode("11")); assertEquals(DECEMBER,stringToMonthCode("12"));

//todo assertEquals(-1, stringToMonthCode("0")); // assertEquals(-1, stringToMonthCode("13")); assertEquals(-1,stringToMonthCode("Cześć")); for (int m = 1; m <= 12; m++) { assertEquals(m, stringToMonthCode(monthCodeToString(m, false))); assertEquals(m, stringToMonthCode(monthCodeToString(m, true))); }

// assertEquals(1,stringToMonthCode("jan")); // assertEquals(2,stringToMonthCode("feb")); // assertEquals(3,stringToMonthCode("mar")); // assertEquals(4,stringToMonthCode("apr")); // assertEquals(5,stringToMonthCode("may")); // assertEquals(6,stringToMonthCode("jun")); // assertEquals(7,stringToMonthCode("jul")); // assertEquals(8,stringToMonthCode("aug")); // assertEquals(9,stringToMonthCode("sep")); // assertEquals(10,stringToMonthCode("oct")); // assertEquals(11,stringToMonthCode("nov")); // assertEquals(12,stringToMonthCode("dec")); // assertEquals(1,stringToMonthCode("JAN")); // assertEquals(2,stringToMonthCode("FEB")); // assertEquals(3,stringToMonthCode("MAR")); // assertEquals(4,stringToMonthCode("APR")); // assertEquals(5,stringToMonthCode("MAY")); // assertEquals(6,stringToMonthCode("JUN")); // assertEquals(7,stringToMonthCode("JUL")); // assertEquals(8,stringToMonthCode("AUG")); // assertEquals(9,stringToMonthCode("SEP")); // assertEquals(10,stringToMonthCode("OCT")); // assertEquals(11,stringToMonthCode("NOV")); // assertEquals(12,stringToMonthCode("DEC"));

ORG.JFREE.DATE.SERIALDATE

383

188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249

384

// assertEquals(1,stringToMonthCode("january")); // assertEquals(2,stringToMonthCode("february")); // assertEquals(3,stringToMonthCode("march")); // assertEquals(4,stringToMonthCode("april")); // assertEquals(5,stringToMonthCode("may")); // assertEquals(6,stringToMonthCode("june")); // assertEquals(7,stringToMonthCode("july")); // assertEquals(8,stringToMonthCode("august")); // assertEquals(9,stringToMonthCode("september")); // assertEquals(10,stringToMonthCode("october")); // assertEquals(11,stringToMonthCode("november")); // assertEquals(12,stringToMonthCode("december")); // assertEquals(1,stringToMonthCode("JANUARY")); // assertEquals(2,stringToMonthCode("FEBRUARY")); // assertEquals(3,stringToMonthCode("MAR")); // assertEquals(4,stringToMonthCode("APRIL")); // assertEquals(5,stringToMonthCode("MAY")); // assertEquals(6,stringToMonthCode("JUNE")); // assertEquals(7,stringToMonthCode("JULY")); // assertEquals(8,stringToMonthCode("AUGUST")); // assertEquals(9,stringToMonthCode("SEPTEMBER")); // assertEquals(10,stringToMonthCode("OCTOBER")); // assertEquals(11,stringToMonthCode("NOVEMBER")); // assertEquals(12,stringToMonthCode("DECEMBER")); } public void testIsValidWeekInMonthCode() throws Exception { for (int w = 0; w <= 4; w++) { assertTrue(isValidWeekInMonthCode(w)); } assertFalse(isValidWeekInMonthCode(5)); } public void testIsLeapYear() throws Exception { assertFalse(isLeapYear(1900)); assertFalse(isLeapYear(1901)); assertFalse(isLeapYear(1902)); assertFalse(isLeapYear(1903)); assertTrue(isLeapYear(1904)); assertTrue(isLeapYear(1908)); assertFalse(isLeapYear(1955)); assertTrue(isLeapYear(1964)); assertTrue(isLeapYear(1980)); assertTrue(isLeapYear(2000)); assertFalse(isLeapYear(2001)); assertFalse(isLeapYear(2100)); } public void testLeapYearCount() throws Exception { assertEquals(0, leapYearCount(1900)); assertEquals(0, leapYearCount(1901)); assertEquals(0, leapYearCount(1902)); assertEquals(0, leapYearCount(1903)); assertEquals(1, leapYearCount(1904)); assertEquals(1, leapYearCount(1905)); assertEquals(1, leapYearCount(1906)); assertEquals(1, leapYearCount(1907)); assertEquals(2, leapYearCount(1908)); assertEquals(24, leapYearCount(1999)); assertEquals(25, leapYearCount(2001));

DODATEK B

250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308

assertEquals(49, leapYearCount(2101)); assertEquals(73, leapYearCount(2201)); assertEquals(97, leapYearCount(2301)); assertEquals(122, leapYearCount(2401)); } public void testLastDayOfMonth() throws Exception { assertEquals(31, lastDayOfMonth(JANUARY, 1901)); assertEquals(28, lastDayOfMonth(FEBRUARY, 1901)); assertEquals(31, lastDayOfMonth(MARCH, 1901)); assertEquals(30, lastDayOfMonth(APRIL, 1901)); assertEquals(31, lastDayOfMonth(MAY, 1901)); assertEquals(30, lastDayOfMonth(JUNE, 1901)); assertEquals(31, lastDayOfMonth(JULY, 1901)); assertEquals(31, lastDayOfMonth(AUGUST, 1901)); assertEquals(30, lastDayOfMonth(SEPTEMBER, 1901)); assertEquals(31, lastDayOfMonth(OCTOBER, 1901)); assertEquals(30, lastDayOfMonth(NOVEMBER, 1901)); assertEquals(31, lastDayOfMonth(DECEMBER, 1901)); assertEquals(29, lastDayOfMonth(FEBRUARY, 1904)); } public void testAddDays() throws Exception { SerialDate newYears = d(1, JANUARY, 1900); assertEquals(d(2, JANUARY, 1900), addDays(1, newYears)); assertEquals(d(1, FEBRUARY, 1900), addDays(31, newYears)); assertEquals(d(1, JANUARY, 1901), addDays(365, newYears)); assertEquals(d(31, DECEMBER, 1904), addDays(5 * 365, newYears)); } private static SpreadsheetDate d(int day, int month, int year) {return new SpreadsheetDate(day, month, year);} public void testAddMonths() throws Exception { assertEquals(d(1, FEBRUARY, 1900), addMonths(1, d(1, JANUARY, 1900))); assertEquals(d(28, FEBRUARY, 1900), addMonths(1, d(31, JANUARY, 1900))); assertEquals(d(28, FEBRUARY, 1900), addMonths(1, d(30, JANUARY, 1900))); assertEquals(d(28, FEBRUARY, 1900), addMonths(1, d(29, JANUARY, 1900))); assertEquals(d(28, FEBRUARY, 1900), addMonths(1, d(28, JANUARY, 1900))); assertEquals(d(27, FEBRUARY, 1900), addMonths(1, d(27, JANUARY, 1900))); assertEquals(d(30, JUNE, 1900), addMonths(5, d(31, JANUARY, 1900))); assertEquals(d(30, JUNE, 1901), addMonths(17, d(31, JANUARY, 1900))); assertEquals(d(29, FEBRUARY, 1904), addMonths(49, d(31, JANUARY, 1900))); } public void testAddYears() throws Exception { assertEquals(d(1, JANUARY, 1901), addYears(1, d(1, JANUARY, 1900))); assertEquals(d(28, FEBRUARY, 1905), addYears(1, d(29, FEBRUARY, 1904))); assertEquals(d(28, FEBRUARY, 1905), addYears(1, d(28, FEBRUARY, 1904))); assertEquals(d(28, FEBRUARY, 1904), addYears(1, d(28, FEBRUARY, 1903))); } public void testGetPreviousDayOfWeek() throws Exception { assertEquals(d(24, FEBRUARY, 2006), getPreviousDayOfWeek(FRIDAY, d(1, MARCH, 2006))); assertEquals(d(22, FEBRUARY, 2006), getPreviousDayOfWeek(WEDNESDAY, d(1, MARCH, 2006))); assertEquals(d(29, FEBRUARY, 2004), getPreviousDayOfWeek(SUNDAY, d(3, MARCH, 2004))); assertEquals(d(29, DECEMBER, 2004), getPreviousDayOfWeek(WEDNESDAY, d(5, JANUARY, 2005)));

ORG.JFREE.DATE.SERIALDATE

385

309 310 try { 311 getPreviousDayOfWeek(-1, d(1, JANUARY, 2006)); 312 fail("Nieprawidłowy kod tygodnia powinien wygenerować wyjątek"); 313 } catch (IllegalArgumentException e) { 314 } 315 } 316 317 public void testGetFollowingDayOfWeek() throws Exception { 318 // assertEquals(d(1, JANUARY, 2005),getFollowingDayOfWeek(SATURDAY, d(25, DECEMBER, 2004))); 319 assertEquals(d(1, JANUARY, 2005), getFollowingDayOfWeek(SATURDAY, d(26, DECEMBER, 2004))); 320 assertEquals(d(3, MARCH, 2004), getFollowingDayOfWeek(WEDNESDAY, d(28, FEBRUARY, 2004))); 321 322 try { 323 getFollowingDayOfWeek(-1, d(1, JANUARY, 2006)); 324 fail("Nieprawidłowy kod tygodnia powinien wygenerować wyjątek"); 325 } catch (IllegalArgumentException e) { 326 } 327 } 328 329 public void testGetNearestDayOfWeek() throws Exception { 330 assertEquals(d(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(16, APRIL, 2006))); 331 assertEquals(d(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(17, APRIL, 2006))); 332 assertEquals(d(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(18, APRIL, 2006))); 333 assertEquals(d(16, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(19, APRIL, 2006))); 334 assertEquals(d(23, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(20, APRIL, 2006))); 335 assertEquals(d(23, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(21, APRIL, 2006))); 336 assertEquals(d(23, APRIL, 2006), getNearestDayOfWeek(SUNDAY, d(22, APRIL, 2006))); 337 338 //todo assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(16, APRIL, 2006))); 339 assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(17, APRIL, 2006))); 340 assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(18, APRIL, 2006))); 341 assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(19, APRIL, 2006))); 342 assertEquals(d(17, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(20, APRIL, 2006))); 343 assertEquals(d(24, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(21, APRIL, 2006))); 344 assertEquals(d(24, APRIL, 2006), getNearestDayOfWeek(MONDAY, d(22, APRIL, 2006))); 345 346 // assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(16, APRIL, 2006))); 347 // assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(17, APRIL, 2006))); 348 assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(18, APRIL, 2006))); 349 assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(19, APRIL, 2006))); 350 assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(20, APRIL, 2006))); 351 assertEquals(d(18, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(21, APRIL, 2006))); 352 assertEquals(d(25, APRIL, 2006), getNearestDayOfWeek(TUESDAY, d(22, APRIL, 2006))); 353 354 // assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(16, APRIL, 2006))); 355 // assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(17, APRIL, 2006))); 356 // assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(18, APRIL, 2006))); 357 assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(19, APRIL, 2006))); 358 assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(20, APRIL, 2006))); 359 assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(21, APRIL, 2006))); 360 assertEquals(d(19, APRIL, 2006), getNearestDayOfWeek(WEDNESDAY, d(22, APRIL, 2006))); 361 362 // assertEquals(d(13, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(16, APRIL, 2006))); 363 // assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(17, APRIL, 2006))); 364 // assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(18, APRIL, 2006))); 365 // assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(19, APRIL, 2006))); 366 assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(20, APRIL, 2006))); 367 assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(21, APRIL, 2006))); 368 assertEquals(d(20, APRIL, 2006), getNearestDayOfWeek(THURSDAY, d(22, APRIL, 2006))); 369

386

DODATEK B

370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432

// assertEquals(d(14, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(16, APRIL, 2006))); // assertEquals(d(14, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(17, APRIL, 2006))); // assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(18, APRIL, 2006))); // assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(19, APRIL, 2006))); // assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(20, APRIL, 2006))); assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(21, APRIL, 2006))); assertEquals(d(21, APRIL, 2006), getNearestDayOfWeek(FRIDAY, d(22, APRIL, 2006)));

// assertEquals(d(15, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(16, APRIL, 2006))); // assertEquals(d(15, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(17, APRIL, 2006))); // assertEquals(d(15, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(18, APRIL, 2006))); // assertEquals(d(22, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(19, APRIL, 2006))); // assertEquals(d(22, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(20, APRIL, 2006))); // assertEquals(d(22, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(21, APRIL, 2006))); assertEquals(d(22, APRIL, 2006), getNearestDayOfWeek(SATURDAY, d(22, APRIL, 2006))); try { getNearestDayOfWeek(-1, d(1, JANUARY, 2006)); fail("Nieprawidłowy kod tygodnia powinien wygenerować wyjątek"); } catch (IllegalArgumentException e) { } } public void testEndOfCurrentMonth() throws Exception { SerialDate d = SerialDate.createInstance(2); assertEquals(d(31, JANUARY, 2006), d.getEndOfCurrentMonth(d(1, JANUARY, 2006))); assertEquals(d(28, FEBRUARY, 2006), d.getEndOfCurrentMonth(d(1, FEBRUARY, 2006))); assertEquals(d(31, MARCH, 2006), d.getEndOfCurrentMonth(d(1, MARCH, 2006))); assertEquals(d(30, APRIL, 2006), d.getEndOfCurrentMonth(d(1, APRIL, 2006))); assertEquals(d(31, MAY, 2006), d.getEndOfCurrentMonth(d(1, MAY, 2006))); assertEquals(d(30, JUNE, 2006), d.getEndOfCurrentMonth(d(1, JUNE, 2006))); assertEquals(d(31, JULY, 2006), d.getEndOfCurrentMonth(d(1, JULY, 2006))); assertEquals(d(31, AUGUST, 2006), d.getEndOfCurrentMonth(d(1, AUGUST, 2006))); assertEquals(d(30, SEPTEMBER, 2006), d.getEndOfCurrentMonth(d(1, SEPTEMBER, 2006))); assertEquals(d(31, OCTOBER, 2006), d.getEndOfCurrentMonth(d(1, OCTOBER, 2006))); assertEquals(d(30, NOVEMBER, 2006), d.getEndOfCurrentMonth(d(1, NOVEMBER, 2006))); assertEquals(d(31, DECEMBER, 2006), d.getEndOfCurrentMonth(d(1, DECEMBER, 2006))); assertEquals(d(29, FEBRUARY, 2008), d.getEndOfCurrentMonth(d(1, FEBRUARY, 2008))); } public void testWeekInMonthToString() throws Exception { assertEquals("First",weekInMonthToString(FIRST_WEEK_IN_MONTH)); assertEquals("Second",weekInMonthToString(SECOND_WEEK_IN_MONTH)); assertEquals("Third",weekInMonthToString(THIRD_WEEK_IN_MONTH)); assertEquals("Fourth",weekInMonthToString(FOURTH_WEEK_IN_MONTH)); assertEquals("Last",weekInMonthToString(LAST_WEEK_IN_MONTH));

//todo try { // weekInMonthToString(-1); // fail("Nieprawidłowy kod tygodnia powinien wygenerować wyjątek"); // } catch (IllegalArgumentException e) { // } } public void testRelativeToString() throws Exception { assertEquals("Preceding",relativeToString(PRECEDING)); assertEquals("Nearest",relativeToString(NEAREST)); assertEquals("Following",relativeToString(FOLLOWING));

//todo try { // relativeToString(-1000); // fail("Nieprawidłowy kod względny powinien wygenerować wyjątek"); // } catch (IllegalArgumentException e) {

ORG.JFREE.DATE.SERIALDATE

387

433 // } 434 } 435 436 public void testCreateInstanceFromDDMMYYY() throws Exception { 437 SerialDate date = createInstance(1, JANUARY, 1900); 438 assertEquals(1,date.getDayOfMonth()); 439 assertEquals(JANUARY,date.getMonth()); 440 assertEquals(1900,date.getYYYY()); 441 assertEquals(2,date.toSerial()); 442 } 443 444 public void testCreateInstanceFromSerial() throws Exception { 445 assertEquals(d(1, JANUARY, 1900),createInstance(2)); 446 assertEquals(d(1, JANUARY, 1901), createInstance(367)); 447 } 448 449 public void testCreateInstanceFromJavaDate() throws Exception { 450 assertEquals(d(1, JANUARY, 1900),createInstance(new GregorianCalendar (1900,0,1).getTime())); 451 assertEquals(d(1, JANUARY, 2006),createInstance(new GregorianCalendar (2006,0,1).getTime())); 452 } 453 454 public static void main(String[] args) { 455 junit.textui.TestRunner.run(BobsSerialDateTest.class); 456 } 457 }

L I S T I N G B 5 . SpreadsheetDate.java 1 /* ================================================================== 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ================================================================= 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 6 * 7 * Project Info: http://www.jfree.org/jcommon/index.html 8 * 9 * This library is free software; you can redistribute it and/or modify it 10 * under the of the GNU Lesser General Public License as published by 11 * the Free Software Foundation; either version 2.1 of the License, or 12 * (at your option) any later version. 13 * 14 * This library is distributed in the hope that it will be useful, but 15 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 16 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 17 * License for more details. 18 * 19 * You should have received a copy of the GNU Lesser General Public 20 * License along with this library; if not, write to the Free Software 21 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 22 * USA. 23 * 24 * [Java is a trademark or ed trademark of Sun Microsystems, Inc. 25 * in the United States and other countries.] 26 * 27 * -------------------28 * SpreadsheetDate.java 29 * -------------------30 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 31 * 32 * Original Author: David Gilbert (for Object Refinery Limited);

388

DODATEK B

33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93

* Contributor(s): -; * * $Id: SpreadsheetDate.java,v 1.8 2005/11/03 09:25:39 mungady Exp $ * * Changes * ------* 11-Oct-2001 : Version 1 (DG); * 05-Nov-2001 : Added getDescription() and setDescription() methods (DG); * 12-Nov-2001 : Changed name from ExcelDate.java to SpreadsheetDate.java (DG); * Fixed a bug in calculating day, month and year from serial * number (DG); * 24-Jan-2002 : Fixed a bug in calculating the serial number from the day, * month and year. Thanks to Trevor Hills for the report (DG); * 29-May-2002 : Added equals(Object) method (SourceForge ID 558850) (DG); * 03-Oct-2002 : Fixed errors reported by Checkstyle (DG); * 13-Mar-2003 : Implemented Serializable (DG); * 04-Sep-2003 : Completed isInRange() methods (DG); * 05-Sep-2003 : Implemented Comparable (DG); * 21-Oct-2003 : Added hashCode() method (DG); * */ package org.jfree.date; import java.util.Calendar; import java.util.Date;

/** * Represents a date using an integer, in a similar fashion to the * implementation in Microsoft Excel. The range of dates ed is * 1-Jan-1900 to 31-Dec-9999. *

  * Be aware that there is a deliberate bug in Excel that recognises the year * 1900 as a leap year when in fact it is not a leap year. You can find more * information on the Microsoft website in article Q181370: *

  * http://.microsoft.com//kb/articles/Q181/3/70.asp *

  * Excel uses the convention that 1-Jan-1900 = 1. This class uses the * convention 1-Jan-1900 = 2. * The result is that the day number in this class will be different to the * Excel figure for January and February 1900...but then Excel adds in an extra * day (29-Feb-1900 which does not actually exist!) and from that point forward * the day numbers will match. * * @author David Gilbert */ public class SpreadsheetDate extends SerialDate {

/** For serialization. */ private static final long serialVersionUID = -2039586705374454461L;

/** * The day number (1-Jan-1900 = 2, 2-Jan-1900 = 3, ..., 31-Dec-9999 = * 2958465). */ private int serial;

/** The day of the month (1 to 28, 29, 30 or 31 depending on the month). */ private int day;

ORG.JFREE.DATE.SERIALDATE

389

94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156

390

/** The month of the year (1 to 12). */ private int month;

/** The year (1900 to 9999). */ private int year;

/** An optional description for the date. */ private String description;

/** * Creates a new date instance. * * @param day the day (in the range 1 to 28/29/30/31). * @param month the month (in the range 1 to 12). * @param year the year (in the range 1900 to 9999). */ public SpreadsheetDate(final int day, final int month, final int year) { if ((year >= 1900) && (year <= 9999)) { this.year = year; } else { throw new IllegalArgumentException( "The 'year' argument must be in range 1900 to 9999." ); } if ((month >= MonthConstants.JANUARY) && (month <= MonthConstants.DECEMBER)) { this.month = month; } else { throw new IllegalArgumentException( "The 'month' argument must be in the range 1 to 12." ); } if ((day >= 1) && (day <= SerialDate.lastDayOfMonth(month, year))) { this.day = day; } else { throw new IllegalArgumentException("Invalid 'day' argument."); }

// the serial number needs to be synchronised with the day-month-year… this.serial = calcSerial(day, month, year); this.description = null; }

/** * Standard constructor - creates a new date object representing the * specified day number (which should be in the range 2 to 2958465. * * @param serial the serial number for the day (range: 2 to 2958465). */ public SpreadsheetDate(final int serial) { if ((serial >= SERIAL_LOWER_BOUND) && (serial <= SERIAL_UPPER_BOUND)) { this.serial = serial; } else {

DODATEK B

157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218

throw new IllegalArgumentException( "SpreadsheetDate: Serial must be in range 2 to 2958465."); }

// the day-month-year needs to be synchronised with the serial number… calcDayMonthYear(); }

/** * Returns the description that is attached to the date. It is not * required that a date have a description, but for some applications it * is useful. * * @return The description that is attached to the date. */ public String getDescription() { return this.description; }

/** * Sets the description for the date. * * @param description the description for this date (null * permitted). */ public void setDescription(final String description) { this.description = description; }

/** * Returns the serial number for the date, where 1 January 1900 = 2 * (this corresponds, almost, to the numbering system used in Microsoft * Excel for Windows and Lotus 1-2-3). * * @return The serial number of this date. */ public int toSerial() { return this.serial; }

/** * Returns a java.util.Date equivalent to this date. * * @return The date. */ public Date toDate() { final Calendar calendar = Calendar.getInstance(); calendar.set(getYYYY(), getMonth() - 1, getDayOfMonth(), 0, 0, 0); return calendar.getTime(); }

/** * Returns the year (assume a valid range of 1900 to 9999). * * @return The year. */ public int getYYYY() { return this.year; }

/**

ORG.JFREE.DATE.SERIALDATE

391

219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280

392

* Returns the month (January = 1, February = 2, March = 3). * * @return The month of the year. */ public int getMonth() { return this.month; }

/** * Returns the day of the month. * * @return The day of the month. */ public int getDayOfMonth() { return this.day; }

/** * Returns a code representing the day of the week. *

  * The codes are defined in the {@link SerialDate} class as: * SUNDAY, MONDAY, TUESDAY, * WEDNESDAY, THURSDAY, FRIDAY, and * SATURDAY. * * @return A code representing the day of the week. */ public int getDayOfWeek() { return (this.serial + 6) % 7 + 1; }

/** * Tests the equality of this date with an arbitrary object. *

  * This method will return true ONLY if the object is an instance of the * {@link SerialDate} base class, and it represents the same day as this * {@link SpreadsheetDate}. * * @param object the object to compare (null permitted). * * @return A boolean. */ public boolean equals(final Object object) { if (object instanceof SerialDate) { final SerialDate s = (SerialDate) object; return (s.toSerial() == this.toSerial()); } else { return false; } }

/** * Returns a hash code for this object instance. * * @return A hash code. */ public int hashCode() { return toSerial(); }

DODATEK B

281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341

/** * Returns the difference (in days) between this date and the specified * 'other' date. * * @param other the date being compared to. * * @return The difference (in days) between this date and the specified * 'other' date. */ public int compare(final SerialDate other) { return this.serial - other.toSerial(); }

/** * Implements the method required by the Comparable interface. * * @param other the other object (usually another SerialDate). * * @return A negative integer, zero, or a positive integer as this object * is less than, equal to, or greater than the specified object. */ public int compareTo(final Object other) { return compare((SerialDate) other); }

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date as * the specified SerialDate. */ public boolean isOn(final SerialDate other) { return (this.serial == other.toSerial()); }

/** * Returns true if this SerialDate represents an earlier date compared to * the specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents an earlier date * compared to the specified SerialDate. */ public boolean isBefore(final SerialDate other) { return (this.serial < other.toSerial()); }

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date * as the specified SerialDate. */

ORG.JFREE.DATE.SERIALDATE

393

342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402

394

public boolean isOnOrBefore(final SerialDate other) { return (this.serial <= other.toSerial()); }

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date * as the specified SerialDate. */ public boolean isAfter(final SerialDate other) { return (this.serial > other.toSerial()); }

/** * Returns true if this SerialDate represents the same date as the * specified SerialDate. * * @param other the date being compared to. * * @return true if this SerialDate represents the same date as * the specified SerialDate. */ public boolean isOnOrAfter(final SerialDate other) { return (this.serial >= other.toSerial()); }

/** * Returns true if this {@link SerialDate} is within the * specified range (INCLUSIVE). The date order of d1 and d2 is not * important. * * @param d1 a boundary date for the range. * @param d2 the other boundary date for the range. * * @return A boolean. */ public boolean isInRange(final SerialDate d1, final SerialDate d2) { return isInRange(d1, d2, SerialDate.INCLUDE_BOTH); }

/** * Returns true if this SerialDate is within the specified range (caller * specifies whether or not the end-points are included). The order of d1 * and d2 is not important. * * @param d1 one boundary date for the range. * @param d2 a second boundary date for the range. * @param include a code that controls whether or not the start and end * dates are included in the range. * * @return true if this SerialDate is within the specified * range. */ public boolean isInRange(final SerialDate d1, final SerialDate d2, final int include) { final int s1 = d1.toSerial(); final int s2 = d2.toSerial();

DODATEK B

403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465

final int start = Math.min(s1, s2); final int end = Math.max(s1, s2); final int s = toSerial(); if (include == SerialDate.INCLUDE_BOTH) { return (s >= start && s <= end); } else if (include == SerialDate.INCLUDE_FIRST) { return (s >= start && s < end); } else if (include == SerialDate.INCLUDE_SECOND) { return (s > start && s <= end); } else { return (s > start && s < end); } }

/** * Calculate the serial number from the day, month and year. *

  * 1-Jan-1900 = 2. * * @param d the day. * @param m the month. * @param y the year. * * @return the serial number from the day, month and year. */ private int calcSerial(final int d, final int m, final int y) { final int yy = ((y - 1900) * 365) + SerialDate.leapYearCount(y - 1); int mm = SerialDate.AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH[m]; if (m > MonthConstants.FEBRUARY) { if (SerialDate.isLeapYear(y)) { mm = mm + 1; } } final int dd = d; return yy + mm + dd + 1; }

/** * Calculate the day, month and year from the serial number. */ private void calcDayMonthYear() {

// get the year from the serial date final int days = this.serial - SERIAL_LOWER_BOUND;

// overestimated because we ignored leap days final int overestimatedYYYY = 1900 + (days / 365); final int leaps = SerialDate.leapYearCount(overestimatedYYYY); final int nonleapdays = days - leaps;

// underestimated because we overestimated years int underestimatedYYYY = 1900 + (nonleapdays / 365); if (underestimatedYYYY == overestimatedYYYY) { this.year = underestimatedYYYY; } else { int ss1 = calcSerial(1, 1, underestimatedYYYY); while (ss1 <= this.serial) { underestimatedYYYY = underestimatedYYYY + 1; ss1 = calcSerial(1, 1, underestimatedYYYY);

ORG.JFREE.DATE.SERIALDATE

395

466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 }

} this.year = underestimatedYYYY - 1; } final int ss2 = calcSerial(1, 1, this.year); int[] daysToEndOfPrecedingMonth = AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH; if (isLeapYear(this.year)) { daysToEndOfPrecedingMonth = LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH; }

// get the month from the serial date int mm = 1; int sss = ss2 + daysToEndOfPrecedingMonth[mm] - 1; while (sss < this.serial) { mm = mm + 1; sss = ss2 + daysToEndOfPrecedingMonth[mm] - 1; } this.month = mm - 1;

// what's left is d(+1); this.day = this.serial - ss2 - daysToEndOfPrecedingMonth[this.month] + 1; }

L I S T I N G B 6 . RelativeDayOfWeekRule.java 1 /* ================================================================== 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ================================================================= 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 6 * 7 * Project Info: http://www.jfree.org/jcommon/index.html 8 * 9 * This library is free software; you can redistribute it and/or modify it 10 * under the of the GNU Lesser General Public License as published by 11 * the Free Software Foundation; either version 2.1 of the License, or 12 * (at your option) any later version. 13 * 14 * This library is distributed in the hope that it will be useful, but 15 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 16 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 17 * License for more details. 18 * 19 * You should have received a copy of the GNU Lesser General Public 20 * License along with this library; if not, write to the Free Software 21 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 22 * USA. 23 * 24 * [Java is a trademark or ed trademark of Sun Microsystems, Inc. 25 * in the United States and other countries.] 26 * 27 * -------------------------28 * RelativeDayOfWeekRule.java 29 * --------------------------

396

DODATEK B

30 * (C) Copyright 2000-2003, by Object Refinery Limited and Contributors. 31 * 32 * Original Author: David Gilbert (for Object Refinery Limited); 33 * Contributor(s): -; 34 * 35 * $Id: RelativeDayOfWeekRule.java,v 1.5 2005/11/03 09:24:45 mungady Exp $ 36 * 37 * Changes (from 26-Oct-2001) 38 * -------------------------39 * 26-Oct-2001 : Changed package to com.jrefinery.date.*; 40 * 03-Oct-2002 : Fixed errors reported by Checkstyle (DG); 41 * 42 */ 43 44 package org.jfree.date; 45 46 /** 47 * An annual date rule that returns a date for each year based on (a) a 48 * reference rule; (b) a day of the week; and (c) a selection parameter 49 * (SerialDate.PRECEDING, SerialDate.NEAREST, SerialDate.FOLLOWING). 50 *

  51 * For example, Good Friday can be specified as 'the Friday PRECEDING Easter 52 * Sunday'. 53 * 54 * @author David Gilbert 55 */ 56 public class RelativeDayOfWeekRule extends AnnualDateRule { 57 58 /** A reference to the annual date rule on which this rule is based. */ 59 private AnnualDateRule subrule; 60 61 /** 62 * The day of the week (SerialDate.MONDAY, SerialDate.TUESDAY, and so on). 63 */ 64 private int dayOfWeek; 65 66 /** Specifies which day of the week (PRECEDING, NEAREST or FOLLOWING). */ 67 private int relative; 68 69 /** 70 * Default constructor - builds a rule for the Monday following 1 January. 71 */ 72 public RelativeDayOfWeekRule() { 73 this(new DayAndMonthRule(), SerialDate.MONDAY, SerialDate.FOLLOWING); 74 } 75 76 /** 77 * Standard constructor - builds rule based on the supplied sub-rule. 78 * 79 * @param subrule the rule that determines the reference date. 80 * @param dayOfWeek the day-of-the-week relative to the reference date. 81 * @param relative indicates *which* day-of-the-week (preceding, nearest 82 * or following). 83 */ 84 public RelativeDayOfWeekRule(final AnnualDateRule subrule, 85 final int dayOfWeek, final int relative) { 86 this.subrule = subrule; 87 this.dayOfWeek = dayOfWeek; 88 this.relative = relative; 89 } 90

ORG.JFREE.DATE.SERIALDATE

397

91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151

398

/** * Returns the sub-rule (also called the reference rule). * * @return The annual date rule that determines the reference date for this * rule. */ public AnnualDateRule getSubrule() { return this.subrule; }

/** * Sets the sub-rule. * * @param subrule the annual date rule that determines the reference date * for this rule. */ public void setSubrule(final AnnualDateRule subrule) { this.subrule = subrule; }

/** * Returns the day-of-the-week for this rule. * * @return the day-of-the-week for this rule. */ public int getDayOfWeek() { return this.dayOfWeek; }

/** * Sets the day-of-the-week for this rule. * * @param dayOfWeek the day-of-the-week (SerialDate.MONDAY, * SerialDate.TUESDAY, and so on). */ public void setDayOfWeek(final int dayOfWeek) { this.dayOfWeek = dayOfWeek; }

/** * Returns the 'relative' attribute, that determines *which* * day-of-the-week we are interested in (SerialDate.PRECEDING, * SerialDate.NEAREST or SerialDate.FOLLOWING). * * @return The 'relative' attribute. */ public int getRelative() { return this.relative; }

/** * Sets the 'relative' attribute (SerialDate.PRECEDING, SerialDate.NEAREST, * SerialDate.FOLLOWING). * * @param relative determines *which* day-of-the-week is selected by this * rule. */ public void setRelative(final int relative) { this.relative = relative; }

DODATEK B

152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 }

/** * Creates a clone of this rule. * * @return a clone of this rule. * * @throws CloneNotedException this should never happen. */ public Object clone() throws CloneNotedException { final RelativeDayOfWeekRule duplicate = (RelativeDayOfWeekRule) super.clone(); duplicate.subrule = (AnnualDateRule) duplicate.getSubrule().clone(); return duplicate; }

/** * Returns the date generated by this rule, for the specified year. * * @param year the year (1900 <= year <= 9999). * * @return The date generated by the rule for the given year (possibly * null). */ public SerialDate getDate(final int year) {

// check argument… if ((year < SerialDate.MINIMUM_YEAR_ED) || (year > SerialDate.MAXIMUM_YEAR_ED)) { throw new IllegalArgumentException( "RelativeDayOfWeekRule.getDate(): year outside valid range."); }

// calculate the date… SerialDate result = null; final SerialDate base = this.subrule.getDate(year); if (base != null) { switch (this.relative) { case(SerialDate.PRECEDING): result = SerialDate.getPreviousDayOfWeek(this.dayOfWeek, base); break; case(SerialDate.NEAREST): result = SerialDate.getNearestDayOfWeek(this.dayOfWeek, base); break; case(SerialDate.FOLLOWING): result = SerialDate.getFollowingDayOfWeek(this.dayOfWeek, base); break; default: break; } } return result; }

ORG.JFREE.DATE.SERIALDATE

399

L I S T I N G B 7 . DayDate.java (ostateczny) 1 /* ===================================================================== 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ====================================================================== 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. ... 36 */ 37 package org.jfree.date; 38 39 import java.io.Serializable; 40 import java.util.*; 41 42 /** 43 * Klasa abstrakcyjna, która reprezentuje niezmienne daty z dokładnością 44 * do jednego dnia. Implementacja odwzorowuje każdy dzień na liczbę integer 45 * reprezentującą kolejny dzień od pewnego dnia początkowego. 46 * 47 * Dlaczego nie skorzystać po prostu z java.util.Date? Robimy to, gdy ma to sens. 48 * Czasami java.util.Date może być *zbyt* dokładna - reprezentuje czas 49 * z dokładnością do 1/1000 sekundy (a sama data jest zależna od strefy czasowej). 50 * Czasami chcemy reprezentować określony dzień (np. 21 stycznia 2015) 51 * bez zajmowania się czasem w tym dniu, strefą czasową 52 * czy też innymi parametrami. Do tego właśnie wykorzystujemy DayDate. 53 * 54 * Do utworzenia obiektu będziemy używać DayDateFactory.makeDate. 55 * 56 * @author David Gilbert 57 * @author Robert C. Martin znacznie przebudował kod. 58 */ 59 60 public abstract class DayDate implements Comparable, Serializable { 61 public abstract int getOrdinalDay(); 62 public abstract int getYear(); 63 public abstract Month getMonth(); 64 public abstract int getDayOfMonth(); 65 66 protected abstract Day getDayOfWeekForOrdinalZero(); 67 68 public DayDate plusDays(int days) { 69 return DayDateFactory.makeDate(getOrdinalDay() + days); 70 } 71 72 public DayDate plusMonths(int months) { 73 int thisMonthAsOrdinal = getMonth().toInt() - Month.JANUARY.toInt(); 74 int thisMonthAndYearAsOrdinal = 12 * getYear() + thisMonthAsOrdinal; 75 int resultMonthAndYearAsOrdinal = thisMonthAndYearAsOrdinal + months; 76 int resultYear = resultMonthAndYearAsOrdinal / 12; 77 int resultMonthAsOrdinal = resultMonthAndYearAsOrdinal % 12 + Month.JANUARY.toInt(); 78 Month resultMonth = Month.fromInt(resultMonthAsOrdinal); 79 int resultDay = correctLastDayOfMonth(getDayOfMonth(), resultMonth, resultYear); 80 return DayDateFactory.makeDate(resultDay, resultMonth, resultYear); 81 } 82 83 public DayDate plusYears(int years) { 84 int resultYear = getYear() + years; 85 int resultDay = correctLastDayOfMonth(getDayOfMonth(), getMonth(), resultYear); 86 return DayDateFactory.makeDate(resultDay, getMonth(), resultYear); 87 } 88 89 private int correctLastDayOfMonth(int day, Month month, int year) {

400

DODATEK B

90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153

int lastDayOfMonth = DateUtil.lastDayOfMonth(month, year); if (day > lastDayOfMonth) day = lastDayOfMonth; return day; } public DayDate getPreviousDayOfWeek(Day targetDayOfWeek) { int offsetToTarget = targetDayOfWeek.toInt() - getDayOfWeek().toInt(); if (offsetToTarget >= 0) offsetToTarget -= 7; return plusDays(offsetToTarget); } public DayDate getFollowingDayOfWeek(Day targetDayOfWeek) { int offsetToTarget = targetDayOfWeek.toInt() - getDayOfWeek().toInt(); if (offsetToTarget <= 0) offsetToTarget += 7; return plusDays(offsetToTarget); } public DayDate getNearestDayOfWeek(Day targetDayOfWeek) { int offsetToThisWeeksTarget = targetDayOfWeek.toInt() - getDayOfWeek().toInt(); int offsetToFutureTarget = (offsetToThisWeeksTarget + 7) % 7; int offsetToPreviousTarget = offsetToFutureTarget - 7; if (offsetToFutureTarget > 3) return plusDays(offsetToPreviousTarget); else return plusDays(offsetToFutureTarget); } public DayDate getEndOfMonth() { Month month = getMonth(); int year = getYear(); int lastDay = DateUtil.lastDayOfMonth(month, year); return DayDateFactory.makeDate(lastDay, month, year); } public Date toDate() { final Calendar calendar = Calendar.getInstance(); int ordinalMonth = getMonth().toInt() - Month.JANUARY.toInt(); calendar.set(getYear(), ordinalMonth, getDayOfMonth(), 0, 0, 0); return calendar.getTime(); } public String toString() { return String.format("%02d-%s-%d", getDayOfMonth(), getMonth(), getYear()); } public Day getDayOfWeek() { Day startingDay = getDayOfWeekForOrdinalZero(); int startingOffset = startingDay.toInt() - Day.SUNDAY.toInt(); int ordinalOfDayOfWeek = (getOrdinalDay() + startingOffset) % 7; return Day.fromInt(ordinalOfDayOfWeek + Day.SUNDAY.toInt()); } public int daysSince(DayDate date) { return getOrdinalDay() - date.getOrdinalDay(); } public boolean isOn(DayDate other) { return getOrdinalDay() == other.getOrdinalDay(); }

ORG.JFREE.DATE.SERIALDATE

401

154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 }

public boolean isBefore(DayDate other) { return getOrdinalDay() < other.getOrdinalDay(); } public boolean isOnOrBefore(DayDate other) { return getOrdinalDay() <= other.getOrdinalDay(); } public boolean isAfter(DayDate other) { return getOrdinalDay() > other.getOrdinalDay(); } public boolean isOnOrAfter(DayDate other) { return getOrdinalDay() >= other.getOrdinalDay(); } public boolean isInRange(DayDate d1, DayDate d2) { return isInRange(d1, d2, DateInterval.CLOSED); } public boolean isInRange(DayDate d1, DayDate d2, DateInterval interval) { int left = Math.min(d1.getOrdinalDay(), d2.getOrdinalDay()); int right = Math.max(d1.getOrdinalDay(), d2.getOrdinalDay()); return interval.isIn(getOrdinalDay(), left, right); }

L I S T I N G B 8 . Month.java (ostateczny) 1 package org.jfree.date; 2 3 import java.text.DateFormatSymbols; 4 5 public enum Month { 6 JANUARY(1), FEBRUARY(2), MARCH(3), 7 APRIL(4), MAY(5), JUNE(6), 8 JULY(7), AUGUST(8), SEPTEMBER(9), 9 OCTOBER(10),NOVEMBER(11),DECEMBER(12); 10 private static DateFormatSymbols dateFormatSymbols = new DateFormatSymbols(); 11 private static final int[] LAST_DAY_OF_MONTH = 12 {0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; 13 14 private int index; 15 16 Month(int index) { 17 this.index = index; 18 } 19 20 public static Month fromInt(int monthIndex) { 21 for (Month m : Month.values()) { 22 if (m.index == monthIndex) 23 return m; 24 } 25 throw new IllegalArgumentException("Niewłaściwy indeks miesiąca " + monthIndex); 26 } 27 28 public int lastDay() { 29 return LAST_DAY_OF_MONTH[index]; 30 } 31 32 public int quarter() { 33 return 1 + (index - 1) / 3; 34 }

402

DODATEK B

35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 }

public String toString() { return dateFormatSymbols.getMonths()[index - 1]; } public String toShortString() { return dateFormatSymbols.getShortMonths()[index - 1]; } public static Month parse(String s) { s = s.trim(); for (Month m : Month.values()) if (m.matches(s)) return m; try { return fromInt(Integer.parseInt(s)); } catch (NumberFormatException e) {} throw new IllegalArgumentException("Nieprawidłowy miesiąc " + s); } private boolean matches(String s) { return s.equalsIgnoreCase(toString()) || s.equalsIgnoreCase(toShortString()); } public int toInt() { return index; }

L I S T I N G B 9 . Day.java (ostateczny) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

package org.jfree.date; import java.util.Calendar; import java.text.DateFormatSymbols; public enum Day { MONDAY(Calendar.MONDAY), TUESDAY(Calendar.TUESDAY), WEDNESDAY(Calendar.WEDNESDAY), THURSDAY(Calendar.THURSDAY), FRIDAY(Calendar.FRIDAY), SATURDAY(Calendar.SATURDAY), SUNDAY(Calendar.SUNDAY); private final int index; private static DateFormatSymbols dateSymbols = new DateFormatSymbols(); Day(int day) { index = day; } public static Day fromInt(int index) throws IllegalArgumentException { for (Day d : Day.values()) if (d.index == index) return d; throw new IllegalArgumentException( String.format("Nieprawidłowy indeks dnia: %d.", index)); }

ORG.JFREE.DATE.SERIALDATE

403

30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 }

public static Day parse(String s) throws IllegalArgumentException { String[] shortWeekdayNames = dateSymbols.getShortWeekdays(); String[] weekDayNames = dateSymbols.getWeekdays(); s = s.trim(); for (Day day : Day.values()) { if (s.equalsIgnoreCase(shortWeekdayNames[day.index]) || s.equalsIgnoreCase(weekDayNames[day.index])) { return day; } } throw new IllegalArgumentException( String.format("%s nie jest prawidłową nazwą dnia tygodnia", s)); } public String toString() { return dateSymbols.getWeekdays()[index]; } public int toInt() { return index; }

L I S T I N G B 1 0 . DateInterval.java (ostateczny) 1 package org.jfree.date; 2 3 public enum DateInterval { 4 OPEN { 5 public boolean isIn(int d, int left, int right) 6 return d > left && d < right; 7 } 8 }, 9 CLOSED_LEFT { 10 public boolean isIn(int d, int left, int right) 11 return d >= left && d < right; 12 } 13 }, 14 CLOSED_RIGHT { 15 public boolean isIn(int d, int left, int right) 16 return d > left && d <= right; 17 } 18 }, 19 CLOSED { 20 public boolean isIn(int d, int left, int right) 21 return d >= left && d <= right; 22 } 23 }; 24 25 public abstract boolean isIn(int d, int left, int 26 }

{

{

{

{

L I S T I N G B 1 1 . WeekInMonth.java (ostateczny)

right);

1 package org.jfree.date; 2 3 public enum WeekInMonth { 4 FIRST(1), SECOND(2), THIRD(3), FOURTH(4), LAST(0); 5 private final int index; 6

404

DODATEK B

7 8 9 10 11 12 13 14 }

WeekInMonth(int index) { this.index = index; } public int toInt() { return index; }

L I S T I N G B 1 2 . WeekdayRange.java (ostateczny) 1 package org.jfree.date; 2 3 public enum WeekdayRange { 4 LAST, NEAREST, NEXT 5 }

L I S T I N G B 1 3 . DateUtil.java (ostateczny) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

package org.jfree.date; import java.text.DateFormatSymbols; public class DateUtil { private static DateFormatSymbols dateFormatSymbols = new DateFormatSymbols(); public static String[] getMonthNames() { return dateFormatSymbols.getMonths(); } public static boolean isLeapYear(int year) { boolean fourth = year % 4 == 0; boolean hundredth = year % 100 == 0; boolean fourHundredth = year % 400 == 0; return fourth && (!hundredth || fourHundredth); } public static int lastDayOfMonth(Month month, int year) { if (month == Month.FEBRUARY && isLeapYear(year)) return month.lastDay() + 1; else return month.lastDay(); } public static int leapYearCount(int year) { int leap4 = (year - 1896) / 4; int leap100 = (year - 1800) / 100; int leap400 = (year - 1600) / 400; return leap4 - leap100 + leap400; } }

L I S T I N G B 1 4 . DayDateFactory.java (ostateczny) 1 package org.jfree.date; 2 3 public abstract class DayDateFactory { 4 private static DayDateFactory factory = new SpreadsheetDateFactory(); 5 public static void setInstance(DayDateFactory factory) { 6 DayDateFactory.factory = factory; 7 } 8 9 protected abstract DayDate _makeDate(int ordinal);

ORG.JFREE.DATE.SERIALDATE

405

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 }

protected protected protected protected protected

abstract abstract abstract abstract abstract

DayDate _makeDate(int day, Month month, int year); DayDate _makeDate(int day, int month, int year); DayDate _makeDate(java.util.Date date); int _getMinimumYear(); int _getMaximumYear();

public static DayDate makeDate(int ordinal) { return factory._makeDate(ordinal); } public static DayDate makeDate(int day, Month month, int year) { return factory._makeDate(day, month, year); } public static DayDate makeDate(int day, int month, int year) { return factory._makeDate(day, month, year); } public static DayDate makeDate(java.util.Date date) { return factory._makeDate(date); } public static int getMinimumYear() { return factory._getMinimumYear(); } public static int getMaximumYear() { return factory._getMaximumYear(); }

L I S T I N G B 1 5 . SpreadsheetDateFactory.java (ostateczny) 1 package org.jfree.date; 2 3 import java.util.*; 4 5 public class SpreadsheetDateFactory extends DayDateFactory { 6 public DayDate _makeDate(int ordinal) { 7 return new SpreadsheetDate(ordinal); 8 } 9 10 public DayDate _makeDate(int day, Month month, int year) { 11 return new SpreadsheetDate(day, month, year); 12 } 13 14 public DayDate _makeDate(int day, int month, int year) { 15 return new SpreadsheetDate(day, month, year); 16 } 17 18 public DayDate _makeDate(Date date) { 19 final GregorianCalendar calendar = new GregorianCalendar(); 20 calendar.setTime(date); 21 return new SpreadsheetDate( 22 calendar.get(Calendar.DATE), 23 Month.fromInt(calendar.get(Calendar.MONTH) + 1), 24 calendar.get(Calendar.YEAR)); 25 } 26 27 protected int _getMinimumYear() { 28 return SpreadsheetDate.MINIMUM_YEAR_ED; 29 } 30

406

DODATEK B

31 protected int _getMaximumYear() { 32 return SpreadsheetDate.MAXIMUM_YEAR_ED; 33 } 34 }

L I S T I N G B 1 6 . SpreadsheetDate.java (ostateczny) 1 /* ====================================================================== 2 * JCommon : a free general purpose class library for the Java(tm) platform 3 * ====================================================================== 4 * 5 * (C) Copyright 2000-2005, by Object Refinery Limited and Contributors. 6 * ... 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97

* */ package org.jfree.date; import static org.jfree.date.Month.FEBRUARY; import java.util.*;

/** * Reprezentuje daty przy użyciu liczb integer, podobnie jak w * programie Microsoft Excel. Obsługiwany zakres dat: od * 1 stycznia 1900 do 31 grudnia 9999. *

  * Trzeba zwrócić uwagę, że w Excelu występuje błąd, powodujący uznanie roku * 1900 za rok przestępny, choć nim nie jest. Więcej informacji na ten temat * można znaleźć w witrynie Microsoft, w artykule Q181370: *
  * http://.microsoft.com//kb/articles/Q181/3/70.asp *
  * Excel korzysta z konwencji, w której 1 stycznia 1900 = 1. Ta klasa korzysta * z konwencji, w której 1 stycznia 1900 = 2. * W wyniku tego numer dnia w tej klasie jest inny niż w * Excelu dla stycznia i lutego 1900..., ale wtedy Excel wprowadza dodatkowy dzień * (29 lutego 1900, który faktycznie nie istniał!) i od tego momentu * numery dni zgadzają się. * * @author David Gilbert */ public class SpreadsheetDate extends DayDate { public static final int EARLIEST_DATE_ORDINAL = 2; // 1/1/1900 public static final int LATEST_DATE_ORDINAL = 2958465; // 12/31/9999 public static final int MINIMUM_YEAR_ED = 1900; public static final int MAXIMUM_YEAR_ED = 9999; static final int[] AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH = {0, 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365}; static final int[] LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH = {0, 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366}; private private private private
  
  int ordinalDay; int day; Month month; int year;
  
  public SpreadsheetDate(int day, Month month, int year) { if (year < MINIMUM_YEAR_ED || year > MAXIMUM_YEAR_ED)
  
  ORG.JFREE.DATE.SERIALDATE
  
  407
  
  98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161
  
  408
  
  throw new IllegalArgumentException( "Argument 'year' musi zawierać się w zakresie " + MINIMUM_YEAR_ED + " do " + MAXIMUM_YEAR_ED + "."); if (day < 1 || day > DateUtil.lastDayOfMonth(month, year)) throw new IllegalArgumentException("Nieprawidłowy argument 'day'."); this.year = year; this.month = month; this.day = day; ordinalDay = calcOrdinal(day, month, year); } public SpreadsheetDate(int day, int month, int year) { this(day, Month.fromInt(month), year); } public SpreadsheetDate(int serial) { if (serial < EARLIEST_DATE_ORDINAL || serial > LATEST_DATE_ORDINAL) throw new IllegalArgumentException( "SpreadsheetDate: wartość 'serial' musi być z zakresu od 2 do 2958465."); ordinalDay = serial; calcDayMonthYear(); } public int getOrdinalDay() { return ordinalDay; } public int getYear() { return year; } public Month getMonth() { return month; } public int getDayOfMonth() { return day; } protected Day getDayOfWeekForOrdinalZero() {return Day.SATURDAY;} public boolean equals(Object object) { if (!(object instanceof DayDate)) return false; DayDate date = (DayDate) object; return date.getOrdinalDay() == getOrdinalDay(); } public int hashCode() { return getOrdinalDay(); } public int compareTo(Object other) { return daysSince((DayDate) other); } private int calcOrdinal(int day, Month month, int year) { int leapDaysForYear = DateUtil.leapYearCount(year - 1); int daysUpToYear = (year - MINIMUM_YEAR_ED) * 365 + leapDaysForYear; int daysUpToMonth = AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH[month.toInt()]; if (DateUtil.isLeapYear(year) && month.toInt() > FEBRUARY.toInt())
  
  DODATEK B
  
  162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 }
  
  daysUpToMonth++; int daysInMonth = day - 1; return daysUpToYear + daysUpToMonth + daysInMonth + EARLIEST_DATE_ORDINAL; } private void calcDayMonthYear() { int days = ordinalDay - EARLIEST_DATE_ORDINAL; int overestimatedYear = MINIMUM_YEAR_ED + days / 365; int nonleapdays = days - DateUtil.leapYearCount(overestimatedYear); int underestimatedYear = MINIMUM_YEAR_ED + nonleapdays / 365; year = huntForYearContaining(ordinalDay, underestimatedYear); int firstOrdinalOfYear = firstOrdinalOfYear(year); month = huntForMonthContaining(ordinalDay, firstOrdinalOfYear); day = ordinalDay - firstOrdinalOfYear - daysBeforeThisMonth(month.toInt()); } private Month huntForMonthContaining(int anOrdinal, int firstOrdinalOfYear) { int daysIntoThisYear = anOrdinal - firstOrdinalOfYear; int aMonth = 1; while (daysBeforeThisMonth(aMonth) < daysIntoThisYear) aMonth++; return Month.fromInt(aMonth - 1); } private int daysBeforeThisMonth(int aMonth) { if (DateUtil.isLeapYear(year)) return LEAP_YEAR_AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH[aMonth] - 1; else return AGGREGATE_DAYS_TO_END_OF_PRECEDING_MONTH[aMonth] - 1; } private int huntForYearContaining(int anOrdinalDay, int startingYear) { int aYear = startingYear; while (firstOrdinalOfYear(aYear) <= anOrdinalDay) aYear++; return aYear - 1; } private int firstOrdinalOfYear(int year) { return calcOrdinal(1, Month.JANUARY, year); } public static DayDate createInstance(Date date) { GregorianCalendar calendar = new GregorianCalendar(); calendar.setTime(date); return new SpreadsheetDate(calendar.get(Calendar.DATE), Month.fromInt(calendar.get(Calendar.MONTH) + 1), calendar.get(Calendar.YEAR)); }
  
  ORG.JFREE.DATE.SERIALDATE
  
  409
  
  410
  
  DODATEK B
  
  DODATEK C
  
  Odwołania do heurystyk
  
  O
  
  DWOŁANIA DO ZAPACHÓW KODU I HEURYSTYK.
  
  Pozostałe odwołania mogą być usunięte.
  
  C1 ..................................................................................................................................................... 280, 282, 296 C2 . ............................................................................................................................................282, 286, 292, 296 C3 . ............................................................................................................................................284, 286, 288, 296 C4 ...................................................................................................................................................................... 297 C5 ...................................................................................................................................................................... 297 E1 ....................................................................................................................................................................... 297 E2 ....................................................................................................................................................................... 297 F1 ...............................................................................................................................................................242, 298 F2 ....................................................................................................................................................................... 298 F3 ....................................................................................................................................................................... 298 F4 ...................................................................................................................................................... 278, 287, 298 G ................................................................................................................................................................279, 283 G1 ..............................................................................................................................................................280, 298 G10 ............................................................................................................................................................101, 302 G11 . ..................................................................................................................................270, 285, 287, 290, 302 G12 . ..................................................................................................................................286, 287, 288, 292, 303 G13 ................................................................................................................................................... 286, 287, 303 G14 . ..........................................................................................................................................287, 288, 290, 303 G15 ............................................................................................................................................................287, 304 G16 ............................................................................................................................................................288, 305 G17 ............................................................................................................................................................288, 305 G18 ................................................................................................................................................... 288, 289, 306
  
  411
  
  G19 ................................................................................................................................................... 289, 290, 306 G2 ..............................................................................................................................................................278, 299 G20 ............................................................................................................................................................289, 307 G21 ............................................................................................................................................................289, 307 G22 ............................................................................................................................................................291, 308 G23 ............................................................................................................................................. 60, 242, 292, 309 G24 ............................................................................................................................................................292, 309 G25 ............................................................................................................................................................293, 309 G26 .................................................................................................................................................................... 310 G27 .................................................................................................................................................................... 311 G28 ............................................................................................................................................................268, 311 G29 ............................................................................................................................................................269, 311 G3 ..............................................................................................................................................................279, 299 G30 ............................................................................................................................................................269, 312 G31 ............................................................................................................................................................270, 312 G32 ............................................................................................................................................................271, 313 G33 ............................................................................................................................................................272, 314 G34 ............................................................................................................................................... 31, 57, 119, 314 G35 ............................................................................................................................................................104, 315 G36 ............................................................................................................................................................118, 316 G4 ..............................................................................................................................................................282, 299 G5 ............................................................................................................................ 144, 282, 286, 289, 292, 299 G6 . ...................................................................................................................119, 282, 284, 285, 291, 292, 300 G7 ..............................................................................................................................................................283, 301 G8 ..............................................................................................................................................................284, 302 G9 . ............................................................................................................................................273, 285, 287, 302 J1 ................................................................................................................................................................280, 316 J2 ................................................................................................................................................................281, 317 J3 ....................................................................................................................................................... 284, 285, 318 N1 . ..........................................................................................270, 281, 282, 284, 287, 288, 289, 291, 292, 319 N2 ..............................................................................................................................................................281, 320 N3 ..................................................................................................................................................... 285, 288, 321 N4 ..................................................................................................................................................... 269, 289, 321 N5 . ...............................................................................................................................................................44, 321 N6 ..............................................................................................................................................................268, 322 N7 ..............................................................................................................................................................269, 322 T1 ..................................................................................................................................................... 278, 279, 322 T2 ..............................................................................................................................................................278, 323 T3 ..............................................................................................................................................................278, 323 T4 ....................................................................................................................................................................... 323 T5 ..............................................................................................................................................................279, 323 T6 ..............................................................................................................................................................279, 323 T7 ..............................................................................................................................................................279, 323 T8 ..............................................................................................................................................................279, 323 T9 ...................................................................................................................................................................... 324
  
  412
  
  DODATEK C
  
  Epilog
  
  Agile w Denver, Elisabeth Hedrickson podała mi zieloną opaskę Wna rękę, podobną do tej,konferencji którą tak spopularyzował Lance Armstrong. Moja miała napis „Test Obsessed” ROKU
  
  2005,
  
  W CZASIE
  
  1
  
  (ogarnięty obsesją testów). Chętnie ją założyłem i nosiłem z dumą. Od momentu nauczenia się TDD od Kenta Becka, w roku 1999, faktycznie stałem się entuzjastą programowania sterowanego testami. Jednak wtedy stało się coś dziwnego. Odkryłem, że nie mogę zdjąć tej opaski. Nie dlatego, że fizycznie się zablokowała. Opaska ta ujawniała moją profesjonalną etykę. Była widocznym wskaźnikiem mojego zaangażowania w tworzenie najlepszego kodu, jaki mogłem napisać. Jej zdjęcie wydawało się zdradą tej etyki, a na to nie mogłem sobie pozwolić. Dlatego nadal jest ona na moim nadgarstku. Gdy piszę kod, widzę ją kątem oka. Jest to stałe przypomnienie celu, jaki sobie postawiłem — celem tym jest pisanie czystego kodu.
  
  1
  
  http://www.qualitytree.com
  
  413
  
  414
  
  EPILOG
  
  S KOROWI D Z
  
  A Abstract Factory, 46, 172 abstrakcja danych, 113 abstrakcje, 300 ABY, 59 ACMEPort, 128 Active Record, 120 Agile, 16, 142 akapity ABY, 59 akcesory, 47 analiza pokrycia kodu, 266 antysymetria danych i obiektów, 115 AOP, 176 API Windows C, 45 aplikacje jednowątkowe, 194 WWW, 194 architektura EJB, 176 architektura EJB2, 176 Args, 210 implementacja klasy, 210 ArgsException, 253, 260 argumenty funkcji, 62 argumenty obiektowe, 64 argumenty typu String, 228 argumenty wybierające, 305 argumenty wyjściowe, 62, 66, 298 argumenty znacznikowe, 63, 298 asercje, 149 ASM, 177, 206 AspectJ, 181 Aspect-Oriented Framework, 206 aspekty, 176 AspectJ, 181 assertEquals(), 64 atrybuty, 89 automatyczne sterowanie serializacją, 282
  
  B Basic, 45 BDUF, 182 bean, 119
  
  Beck Kent, 24, 187, 264 biblioteka JUnit, 264 Big Design Up Front, 182 bloki, 57 bloki try-catch, 68 blokowanie po stronie klienta, 201 blokowanie po stronie serwera, 201 błędy, 123 Booch Grady, 30 break, 70 brodzenie, 25 budowanie, 297
  
  C CGLIB, 177, 206 Clover, 278 ConcurrentHashMap, 199 ConTest, 207 continue, 70 CountDownLatch, 199 Cunningham Ward, 33 czasowniki, 65 czyste biblioteki Java AOP, 178 czyste granice, 139 czyste testy, 144 zasady, 151 czystość, 14, 15, 31 czystość projektu, 187 czystość testów, 143 czysty kod, 16, 23, 28, 34 czytanie kodu, 35 od góry do dołu, 58 czytelnik-pisarz, 200 czytelność, 30
  
  D dane, 115 wejściowe, 66 wyjściowe, 288 DAO, 179 DBMS, 176
  
  415
  
  definiowanie klasy wyjątków, 127 normalny przepływ, 129 deklaracje zmiennych, 102 dekorator, 179, 284 Dependency Injection, 172 dezinformacja, 42 DI, 172 Dijkstra Edserer, 70 DIP, 36, 167 długie listy importu, 317 długie nazwy, 323 długość wierszy kodu, 106 dobre komentarze, 77 dobry kod, 16, 24 Don’t Repeat Yourself, 300 dopiski, 89 dostarczenie produktu na rynek, 14 dostęp do danych, 179 DRY, 69, 300 DSL, 183 DTO, 119, 176 dyscyplina, 14 dziedziczenie stałych, 318
  
  E efekty uboczne, 65, 323 sprzężenie czasowe, 66 efektywność, 29 EJB, 176, 194 EJB1, 174 EJB2, 174, 175, 176 EJB3, 180 eliminacja niarowych instrukcji, 273 Entity Bean, 174 enum, 319 Error.java, 69 Evans Eric, 322
  
  F F.I.R.S.T., 151 fabryka abstrakcyjna, 46, 60, 172, 284 fabryki, 172, 284 Feathers Michael, 31 Feature Envy, 288 final, 286 fizyka oprogramowania, 182
  
  416
  
  SKOROWIDZ
  
  format danych wyjściowych, 288 formatowanie, 97 deklaracje zmiennych, 102 funkcje zależne, 103 gazeta, 99 gęstość pionowa, 101 koligacja koncepcyjna, 105 łamanie wcięć, 110 odległość pionowa, 101 pionowe, 98 pionowe odstępy pomiędzy segmentami kodu, 99 poziome, 106 poziome odstępy, 106 przeznaczenie, 98 puste zakresy, 110 rozmieszczenie poziome, 107 uporządkowanie pionowe, 105 wcięcia, 109 zasady zespołowe, 110 zmienne instancyjne, 102 formatowanie HTML, 280 Fortran, 45 Fowler Martin, 304 funkcje, 53, 298 argumenty, 62 argumenty obiektowe, 64 argumenty wyjściowe, 62, 66 argumenty znacznikowe, 63 bezargumentowe, 62 bloki, 57 bloki try-catch, 68 break, 70 continue, 70 czasowniki, 65 dane wejściowe, 66 długość, 56 dwuargumentowe, 63 efekty uboczne, 65 goto, 70 jednoargumentowe, 62 kody błędów, 67 listy argumentów, 65 nagłówki, 92 nazwy, 40, 61, 269, 307 Nie powtarzaj się, 69 obsługa błędów, 69 poziom abstrakcji, 58 return, 70 rozdzielanie poleceń i zapytań, 67
  
  sekcje, 58 słowa kluczowe, 65 sprzężenie czasowe, 66 switch, 59 trzyargumentowe, 64 uporządkowane składniki jednej wartości, 64 wcięcia, 57 wieloargumentowe, 62 wyjątki, 67 wykonywane czynności, 57 zależne funkcje, 103 zasada konstruowania, 56 zasady pisania, 70 zdarzenia, 63 zwracanie kodów błędów, 67 zwracanie wyniku, 62
  
  G Ga-Jol, 16 Gamm Eric, 264 gazeta, 99 gettery, 113 gęstość pionowa, 101 Gilbert David, 277 given-when-then, 150 globalna strategia konfiguracji, 171 goto, 70 granice, 133 czyste granice, 139 korzystanie z nieistniejącego kodu, 138 przeglądanie, 136 testy graniczne, 138 testy uczące, 138 uczenie się obcego kodu, 136 zastosowanie kodu innych firm, 134
  
  H hermetyzacja, 127, 154 hermetyzacja warunków, 312 warunki graniczne, 314 HTML, 90 Hunt Andy, 29, 300 hybrydowe struktury danych, 118 hybrydy, 118 hypotenuse, 41
  
  I idiom późnej inicjalizacji, 170 if, 286, 300, 309 implementacja interfejsu, 46 include, 70 informacja, 42 informacje nielokalne, 91 instrukcje switch, 59 interfejsy, 46 Inversion of Control, 172 IoC, 172
  
  J jar, 302 Java, 46, 317 JUnit, 263 klasy, 153 pośredniki, 177 współbieżność, 198 Java Swing, 156 java.util.Calendar, 278 java.util.concurrent, 198 java.util.Date, 278 java.util.Map, 134 Javadoc, 81, 280, 286 Javassist, 177 JBoss, 179 JBoss AOP, 178, 181 JCommon, 277, 280 JDBC, 179 JDK, 177 jedna asercja na test, 149 jedna koncepcja na test, 150 jedno słowo na jedno abstrakcyjne pojęcie, 48 jednoznaczne nazwy, 322 Jeffries Ron, 32 język, 298 język DSL, 184 język dziedzinowy, 183 języki testowania specyficzne dla domeny, 147 JFrame, 156 JNDI, 173 JUnit, 55, 149, 226, 263 analiza pokrycia kodu, 266 przypadki testowe, 264
  
  SKOROWIDZ
  
  417
  
  K klasy, 153 bazowe, 301 bazowe zależne od swoich klas pochodnych, 301 DIP, 167 hermetyzacja, 154 izolowanie modułów kodu przed zmianami, 166 Java, 153 liczba zmiennych instancyjnych, 158 metody prywatne, 164 nazwy, 40, 47, 156 O, 166 odpowiedzialności, 154 organizacja, 153, 157 organizacja zmian, 164 prywatne funkcje użytkowe, 154 prywatne zmienne statyczne, 153 przebudowa, 277 publiczne stałe statyczne, 153 rozmiar, 154 spójność, 158 utrzymywanie spójności, 158 zasada odwrócenia zależności, 167 zasada otwarty-zamknięty, 166 zasada pojedynczej odpowiedzialności, 156 zmiany, 164, 166 klasyfikacja wyjątków, 127 kod, 24 kod innych firm, 134 kod na nieodpowiednim poziomie abstrakcji, 300 kod testów, 144 kod za przyjemny w czytaniu, 29 kody błędów, 67 kody powrotu, 124 kolekcje bezpieczne dla wątków, 198 koligacja koncepcyjna, 105 komentarze, 75, 282, 293, 296 atrybuty, 89 bełkot, 81 czytelny kod, 77 dopiski, 89 dziennik, 85 HTML, 90 informacje nielokalne, 91 informacyjne, 78 Javadoc, 81, 92 klamry zamykające, 88
  
  418
  
  SKOROWIDZ
  
  mylące komentarze, 84 niar informacji, 91 nagłówki funkcji, 92 nieoczywiste połączenia, 91 nieudany kod, 77 objaśniające, 79 ostrzeżenia o konsekwencjach, 80 powody pisania, 77 powtarzające się komentarze, 82 prawne, 77 szum, 87 TODO, 80 wprowadzanie szumu informacyjnego, 86 wyjaśnianie zamierzeń, 78, 79 wymagane komentarze, 85 wzmocnienie wagi operacji, 81 zakomentowany kod, 89 złe komentarze, 81 znaczniki pozycji, 88 komunikaty błędów, 127 konstruowanie systemu, 170 kontekst kodu, 40 kontekst nazwy, 50 kontener, 173 kontrolowane wyjątki, 126 korzystanie z nieistniejącego kodu, 138 korzystanie ze standardów, 183 koszt utrzymania zestawu testów, 143
  
  L listy argumentów, 65 listy importu, 317 log4j, 136
  
  Ł łamanie wcięć, 110
  
  M magiczne liczby, 310 magnesy zależności, 69 main, 171 Map, 134 martwe funkcje, 298 martwy kod, 302 mechanika pisania funkcji, 71
  
  metody, 117 abstrakcyjne, 293 instancyjne, 289 nazwy, 47 statyczne, 284, 306 minimalizowanie kodu, 31 minimalne klasy, 192 minimalne metody, 192 Mock, 171 moduły, 117 main, 171 mutatory, 47
  
  N niar argumentów, 298 niar informacji, 91 niarowe instrukcje, 273 niarowe komentarze, 83, 282, 296 nagłówki funkcji, 92 narzędzia kontroli pokrycia, 324 nawigacja przechodnia, 317 nazwy, 39, 290, 320 akcesory, 47 argumenty, 43 dezinformacja, 42 długość, 45 dodatkowe słowa, 43 dziedzina problemu, 49 dziedzina rozwiązania, 49 efekty uboczne, 323 funkcje, 40, 61, 269, 307 ilustracja zamiarów, 40 implementacja interfejsu, 46 informacja, 42 interfejsy, 46 interpretacja słów, 43 jedno słowo na jedno abstrakcyjne pojęcie, 48 jednoliterowe, 44, 47 kalambury, 49 klasy, 40, 47, 156 kodowanie, 45 kontekst, 50 łatwość wyszukania, 44 metody, 47 mutatory, 47 niarowy kontekst, 51 notacja węgierska, 45 odpowiedni poziom abstrakcji, 321
  
  odwzorowanie mentalne, 47 parametry, 48 predykaty, 47 przedrostki składników, 46 refactoring, 52 standardowa nomenklatura, 322 tworzenie wyraźnych różnic, 42 unikanie dezinformacji, 41 unikanie kodowania, 323 wymawianie, 43 zmienne, 40, 47 zmienne składowe, 270 Newkirk Jim, 136 Nie powtarzaj się, 69 niejawność kodu, 40 niekontrolowane wyjątki, 126 niespójność, 303 niewłaściwe działanie w warunkach granicznych, 299 niewłaściwe informacje, 296 niewłaściwe metody statyczne, 306 niewystarczające testy, 324 notacja węgierska, 45 null, 130 NW, 45
  
  O obiekt dostępu do danych, 179 obiekty, 113, 115 obiekty Mock, 171 obiekty POJO, 178 obiekty Test Double, 171 obiekty transferu danych, 119, 176 objaśniające zmienne tymczasowe, 290 Object.priority(), 205 Object.sleep(), 205 Object.wait(), 205 Object.yield(), 205 obliczanie przeciwprostokątnej, 41 obsługa błędów, 69, 123, 254 definiowanie klas wyjątków, 127 definiowanie normalnego przepływu, 129 dostarczanie kontekstu, 127 kody powrotu, 124 komunikaty błędów, 127 niekontrolowane wyjątki, 126 null, 130 przekazywanie wartości null, 131 try-catch-finally, 125 wyjątki, 124
  
  SKOROWIDZ
  
  419
  
  O, 36, 60, 166 oczyszczanie kodu, 209 oczywiste działanie, 299 odległość pionowa, 101 odpowiedzialności, 154 odwrócenie sterowania, 172 odwzorowanie mentalne nazw, 47 opisowe nazwy, 61, 320 opisowe zmienne, 307 optymalizacja, 173 optymalizacja podejmowania decyzji, 183 organizacja, 14 organizacja klas, 153 ostrzeżenia o konsekwencjach, 80 OTO, 57
  
  P pakiet log4j, 136 pionowe odstępy pomiędzy segmentami kodu, 99 Plain-Old Java Object, 178 pliki źródłowe, 298 początkowe przypadki testowe, 279 podejmowanie decyzji, 183 POJO, 178, 182, 184, 206 polimorfizm, 309 porządek, 14 pośredniki Java, 177 powtórzenia, 189, 300 poziome odstępy, 106 późna inicjalizacja, 170, 173 PPP, 36 prawa TDD, 142 prawo Demeter, 117 precyzja, 311 predykaty, 47 priority(), 205 problem z szerokością listy, 108 problemy, 170, 176 problemy z wielowątkowością, 203 proces uruchomienia, 170 producent-konsument, 199 produkt, 14 program współbieżny, 194 programowanie, 24 piśmienne, 31 sterowane testami, 141, 226 strukturalne, 70 współbieżne, 194, 196 zorientowane aspektowo, 176
  
  420
  
  SKOROWIDZ
  
  projekt, 187 czystość, 187 minimalne klasy, 192 minimalne metody, 192 powtórzenia, 189 prosty projekt, 188 przebudowa, 188 rozwijanie, 187 system przechodzi wszystkie testy, 188 wyrazistość kodu, 191 projektowanie obiektowe, 304 prosty projekt, 188 próbowanie, 192 przebudowa klasy, 277 przebudowa projektu, 188 przechowywanie danych konfigurowalnych na wysokim poziomie, 316 przedrostki składników, 46 przekazywanie argumentów, 271 przekazywanie wartości null, 131 przestarzałe komentarze, 296 przyciąganie zależności, 69 przypadki testowe, 264, 279 przyrostowość, 226, 227 puste zakresy, 110 Python, 126
  
  R ReentrantLock, 199 refactoring, 52 reguła nożyczek, 103 return, 70 rozbite okno, 29 rozcięcie problemów, 176 rozdzielanie, 194 rozdzielanie poleceń i zapytań, 67 rozkład długości wierszy kodu, 106 rozmieszczenie kodu, 306 rozmieszczenie odpowiedzialności, 306 rozmieszczenie poziome, 107 rozwijanie projektu, 187 Ruby, 126
  
  S samodyscyplina, 14 Scrum, 16 seiketsu, 14
  
  seiri, 14, 15 seiso, 14 seiton, 14, 15 sekcje krytyczne, 197 sekcje synchronizowane, 201 Semaphore, 199 separacja pionowa, 303 separowanie problemów, 176 SerialDate, 277 serwer adaptujący, 201 serwlety, 194 settery, 113 SetupTeardownIncluder, 71 shutsuke, 14 singleton, 284 skalowanie w górę, 173 sleep(), 205 słowa kluczowe, 65 SOAP, 163 Sparkle, 56 Special Case Pattern, 130 specyfikacja, 24 specyfikacja wymagań, 24 spójność, 285 sprawdzanie pokrycia przez testy, 278 Spring, 179, 180 Spring AOP, 178, 181 Spring Framework, 173 sprzężenie czasowe, 66, 270, 313 SRP, 36, 60, 156, 157, 164, 190, 197, 260 stałe, 319 stałe nazwane, 310 stałe numeryczne, 44 standardowe konwencje, 310 standardy, 183 standaryzacja, 14 sterowanie serializacją, 282 strategia konfiguracji, 171 String, 228 String.format(), 65 Stroustrup Bjarne, 29 struktura przed konwencją, 312 struktury danych, 113, 114 ukrywanie struktury, 119 switch, 59, 292, 300, 309 synchronized, 197, 201 systemy, 169 BDUF, 182 czyste biblioteki Java AOP, 178 fabryki, 172
  
  fizyka oprogramowania, 182 język dziedzinowy, 183 konstruowanie, 170 moduł main, 171 optymalizacja podejmowania decyzji, 183 podejmowanie decyzji, 183 problemy, 176 rozcięcie problemów, 176 rozdzielanie problemów, 170 separowanie problemów, 176 skalowanie w górę, 173 standardy, 183 strategia konfiguracji, 171 testowanie architektury, 182 używanie, 170 wstrzykiwanie zależności, 172 szkoła myślenia, 34 sztuczne sprzężenia, 303 sztuka czystego kodu, 28 szum, 87
  
  Ś środowisko, 297
  
  T TDD, 126, 184, 226 prawa, 142 Template Method, 150, 190 Test Double, 171 Test Driven Development, 141 TestNG, 323 testowanie architektura systemu, 182 jednostkowe, 171 kod wątków, 202 pobliskie błędy, 324 testy, 31, 278, 324 automatyczne, 226 graniczne, 138 uczące, 136, 138 testy jednostkowe, 141, 144, 297 asercje, 149 czyste testy, 144 czystość testów, 143 F.I.R.S.T., 151 jedna asercja na test, 149 jedna koncepcja na test, 150
  
  SKOROWIDZ
  
  421
  
  testy jednostkowe języki testowania specyficzne dla domeny, 147 koszt utrzymania zestawu testów, 143 możliwości, 144 powtarzalność, 151 TDD, 142 Thomas Dave, 29, 30, 300 TODO, 80 Total Productive Maintenance, 14 Totalne Zarządzanie Produkcją, 14 TPM, 14, 15 trafna abstrakcja, 30 trwałość obiektów, 176 try, 125 try-catch, 68, 126 try-catch-finally, 125 tworzenie czysty kod, 28 produkt, 14 typy wyliczeniowe, 319
  
  U uczenie się obcego kodu, 136 ucztujący filozofowie, 200 udane oczyszczanie kodu, 209 ukryte sprzężenie czasowe, 270, 313 ukrywanie implementacji, 114 ukrywanie struktury, 119 UML, 16 unikanie dezinformacji, 41 unikanie dowolnych działań, 314 unikanie kodowania, 323 unikanie nawigacji przechodnich, 317 unikanie warunków negatywnych, 312 uporządkowanie pionowe, 105 upraszczanie funkcji, 273 utrzymywanie możliwie najwyższej czystości kodu, 28 uwięzienie, 199 uzyskiwanie czystości projektu, 187 używanie systemu, 170
  
  V void, 45
  
  422
  
  SKOROWIDZ
  
  W wading, 25 wait(), 205 wartość null, 130 warunki graniczne, 279, 299, 324 warunki negatywne, 312 wątki, 194, 198 testowanie kodu, 202 wcięcia, 57, 109 wczesne uruchamianie, 202 wczesne wyłączanie, 202 współbieżność, 193 atomowość, 196 awarie, 205 biblioteki, 198 blokowanie po stronie klienta, 201 blokowanie po stronie serwera, 201 CountDownLatch, 199 czytelnik-pisarz, 200 instrumentacja automatyczna, 206 instrumentacja ręczna, 205 Java 5, 198 kolekcje bezpieczne dla wątków, 198 kopie danych, 197 mity, 195 modele wykonania, 199 nieporozumienia, 195 ograniczanie zakresu danych, 197 problemy, 195 producent-konsument, 199 przypadkowe awarie, 203 ReentrantLock, 199 sekcje krytyczne, 197 sekcje synchronizowane, 201 Semaphore, 199 serwer adaptujący, 201 serwlety, 194 SRP, 197 stosowanie, 194 synchronizowane metody, 201 testowanie kodu wątków, 202 testy, 204 tworzenie sekcji synchronizowanych, 201 ucztujący filozofowie, 200 uwięzienie, 199 wątki, 198, 203 wczesne uruchamianie, 202
  
  wczesne wyłączanie, 202 wydajność, 195 wyzwania, 196 wzajemne wykluczanie, 199 zagłodzenie, 199 zakleszczenie, 199 zależności pomiędzy synchronizowanymi metodami, 201 zasada pojedynczej odpowiedzialności, 197 zasady obrony współbieżności, 196 zasoby związane, 199 wstrzykiwanie zależności, 172, 173, 179 wszechobecny język projektu, 322 wybór nazw, 40 wybór opisowych nazw, 320 wydajność, 26 wydzielanie modułu main, 171 wyjaśnianie zamierzeń, 78 wyjątki, 67, 124, 125, 253 dostarczanie kontekstu, 127 klasy, 127 przechwytywanie, 127 wykonywanie wielkiego projektu od podstaw, 182 wymagane komentarze, 85 wymagania użytkowników, 24 wyrazistość kodu, 191 wyszukiwanie JNDI, 173 wzajemne wykluczanie, 199 wzmocnienie wagi operacji, 81 wzorce błędów, 324 wzorce pokrycia testami, 279, 325 wzorzec awarii, 279 wzorzec fabryki abstrakcyjnej, 172 wzorzec specjalnego przypadku, 130 wzorzec szablonu metody, 150, 190
  
  X XHTML, 316
  
  Y yield(), 205
  
  zakleszczenie, 199 zakomentowany kod, 89, 297 zależności, 172 fizyczne, 308 logiczne, 292, 308 pomiędzy synchronizowanymi metodami, 201 zamiana zależności logicznych na fizyczne, 308 zarządzanie zależnościami, 172 zasada DRY, 300 zasada jedno słowo na jedno abstrakcyjne pojęcie, 48 zasada najmniejszego zaskoczenia, 299 zasada odwrócenia zależności, 36, 167 zasada otwarty-zamknięty, 36, 60, 166 zasada pojedynczej odpowiedzialności, 36, 60, 156, 171, 172, 197 zasada skautów, 36, 268 zasada SRP, 197 zasada zstępująca, 58 zasady 5S, 14 zasady formatowania, 110, 111 zasoby związane, 199 zastosowanie kodu innych firm, 134 zazdrość o funkcje, 288, 304 zdarzenia, 63 zdejmowanie zabezpieczeń, 299 zespół tygrysów, 26 zły kod, 29 zmiana nazwy, 61 zmiany, 27, 166 zmiany projektu, 26 zmienne, 102 deklaracje, 102 instancyjne, 102 nazwy, 40 prywatne, 113 tymczasowe, 289 znaczniki HTML, 90 znaczniki pozycji, 88 zrozumienie algorytmu, 308 zwracanie kodów błędów z funkcji, 67 zwracanie wartości null, 130
  
  Ź Z
  
  źle napisane komentarze, 297 źródło danych, 179
  
  zaciemnianie, 303 zaciemnianie intencji, 305 zagłodzenie, 199
  
  SKOROWIDZ
  
  423

  ---

  Related Documents 2w1qw

Kod-sekolah 4y6m63

October 2019 274

Kod-atrakcyjnosci.pdf 2f1a5p

October 2021 0

Kod Iso 6l574x

March 2023 0

Kod Senang 543m6p

December 2019 99

Kod Magnum 1y3il

October 2019 132

114 Kod 3r2d19

October 2021 0

---

More Documents from "Wesley" 46a6z

Sand Model Room Based On Gis Platform.docx 6t6z3b

October 2019 98

504uu

November 2019 263

Technical Report For Solidworks r1x6r

November 2019 119

December 2019 95

Hsc Chemistry Exam Questions- By Module And Section .pdf 6g24

November 2019 121

504uu

November 2019 155

Copyright © 2025 IDOUB.