Piątek, a zatem słuchamy Listy w Trójce. Przed nami ostatnia z zasad Jeff’a Bay’a

Nie używaj getterów/setterów/własności

Niewątpliwie jest to najbardziej obiektowa z zasad. By zrozumieć o co w niej chodzi porównajmy takie oto dwie klasy

Listing 1. klasa bardziej “obiektowa”

class Chłopiec{

	private String imię;

	private String nazwisko;

	private String wiek;

	public String getImię() {
		return imię;
	}

	public void setImię(String imię) {
		this.imię = imię;
	}

	public String getNazwisko() {
		return nazwisko;
	}

	public void setNazwisko(String nazwisko) {
		this.nazwisko = nazwisko;
	}

	public String getWiek() {
		return wiek;
	}

	public void setWiek(String wiek) {
		this.wiek = wiek;
	}

}

Listing 2. klasa mniej “obiektowa”

class Dziewczynka {

	public String imię;

	public String nazwisko;

	public String wiek;

}

Czym różnią się te dwie klasy?

Obiektowość to nie metody

Pomijając różne specyficzne elementy języka związane z współbieżną zmianą stanu obiektów tych klas to te dwa twory niczym się nie różnią. Mogę jednak założyć się, że jeżeli pokażemy je “nagie i bezbronne” to pierwsza z nich zostanie zakwalifikowana jako bardziej obiektowa. Druga będzie mniej obiektowa. Dlaczego? Jakoś tak się utarło, że o obiektowości decydują metody.
W Javie jest to szczególnie potęgowane przez specyfikację Java Beans:

Properties are always accessed via method calls on their owning object. For readable properties
there will be a getter method to read the property value. For writable properties there will be a
setter method to allow the property value to be updated.

Cóż… Ma to pewien cel i jest tu pewien pomysł, ale tylko gdy przyjrzymy się tej specyfikacji jako całości (szczególnie z obsługa zdarzeń i wzorcem obserwatora). Niestety jak to w życiu bywa, ktoś z całego dokumentu wyciągnął jeden fragment i tak oto znaleźliśmy się w życi.

Czym jest obiektowość?

Obiektowość to przede wszystkim enkapsulacja. Inaczej mówiąc obiekty nie powinny ujawniać swojego wnętrza, a jedynie udostępniać pewien interfejs, który będzie odwzorowywał operacje dokonywane przez obiekt. Oczywiście może się tak zdarzyć, że operacja polega na ustawieniu jakiejś wartości obiektu. Jednak są to specyficzne przypadki. W żadnym wypadku nie należy pozwalać na swobodną manipulację właściwościami obiektu.

Co zamiast?

Skoro nie powinniśmy mieć możliwości swobodnej manipulacji jak tworzyć i konfigurować obiekty? Z każdym z elementów zajmiemy się z osobna.

Settery

Generalnie obiekty powinny być niezmienne. Ma to wiele zalet. Najważniejszą jest możliwość swobodnego programowania współbieżnego bez obawy, że wątki wzajemnie pozmieniają sobie dane. W takim wypadku settery zostaną automatycznie wyrugowane przez mechanizmy języka wymuszające ustawienie pól w konstruktorze.
Jeżeli jednak z jakiegoś powodu nie możemy użyć pól finalnych to należy ustawić je z użyciem jakiegoś kontenera DI. Zazwyczaj mamy dostęp do tego typu bibliotek i nie ma problemów z ich wykorzystaniem.
Co jednak gdy z jakiś powodów kontener DI nie jest dostępny? W takim wypadku zostaje nam wykorzystanie wzorca fabryki wzbogaconego o użycie refleksji.

Właściwości

Unikamy sytuacji kiedy zachowanie obiektu zależy od właściwości. To właściwość powinna dostarczać odpowiedniego zachowania. Przykładowo w poprzedniej części mówiłem, że opakowane kolekcje powinny dostarczać metod “kontekstowych”. Podobnie w trzeciej części gdzie mowa była o opakowaniu typów prymitywnych wspominałem o możliwości zamknięcia w typie opakowującym pewnych prostych operacji np. walidacji czy operacji arytmetycznych.

Gettery

Najbardziej kłopotliwy element. Koniec końców zawsze musimy gdzieś pokazać uzyskaną wartość. Najprościej jest przesłonić toString. Nie zawsze się to da zrobić. O ile zadziała to w przypadku prostych obiektów to już obiekty złożone stanową duży problem. Pewnym rozwiązaniem może być użycie odpowiedniego prezentera, czyli wzorca MVP. Prezenter może dostać się do obiektu via refleksja względnie odpowiednio zinterpretować wyniki z metody toString. Wzorzec ten ma w tym przypadku wiele zalet. Jeżeli jednak chcemy zrobić coś małego to można użyć czegoś co roboczo nazywam obiektem “samopezentującym się”. W takim przypadku obiekt posiada metodę, do której można przekazać docelowe miejsce prezentacji np. strumień i tyle. Jest to rozwiązanie o tyle wygodne, że czasami chcemy ograniczyć możliwość prezentacji obiektu. W takim wypadku metoda pełni rolę swoistego “pasa cnoty” ponieważ ogranicza kanały prezentacji.

Podsumowanie

Uff… przebrnąłem. Nie było łatwo. Paweł Lipiński w komentarzu do siódmej części zwrócił uwagę, że są to przede wszystkim pewne heurystyki. W części zerowej wspomniałem, że zasady te są świetne jeżeli chcemy refaktoryzować kod. Są też doskonałym narzędziem do ćwiczenia. Zatem czy stosować zasady Jeff’a Bay’a? Moim zdaniem warto dążyć do kodu napisanego zgodnie z tymi zasadami. Ponieważ kod taki promuje przemyślane konstrukcje, pozwala na odnalezienie potencjalnie niebezpiecznych fragmentów i karkołomnych konstrukcji w architekturze oraz wymusza pisanie testów. Ja napisałem projekt zgodny z tymi zasadami mający około 1000 linii. Teraz czas byś usiadł i napisał swój projekt.

Dodaj do

Gladius Noctis, a na blogu ósma z zasad Jeff’a Bay’a

Klasa której polem jest kolekcja nie powinna mieć żadnych innych pól (opakowywanie kolekcji w klasy specyficzne dla kontekstu wykorzystania)

Nazwa trochę długa, ale nie ważne. Powróćmy na chwilę do pierwszej części tego cyklu. Na koniec przykładu z tablicami mieliśmy tam następujący kod:

Listing 1. Kod z pierwszej części

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		fillArray(array3d);

		printArray(array3d);

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillArray(int[][][] array3d) {
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static void print2dArray(int[][][] array3d, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			printRow(array3d, i, j);
			System.out.println();
		}
	}

	private static void printArray(int[][][] array3d) {
		for (int i = 0; i < array3d.length; i++) {
			print2dArray(array3d, i);
			System.out.println();
		}
	}

	private static void printRow(int[][][] array3d, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
	}

}

Przy tamtych założeniach było ok. Krawetko podał jeszcze zgrabniejszą wersję. Ja jednak zmienię tu wszystko.

Co robimy z kolekcjami?

Przede wszystkim iterujemy. Przeciskamy przez różne formy pętli w celu wykonania operacji na wszystkich elementach kolekcji. W Javie jest to dość upierdliwe. Za każdym razem należy napisać te klika linijek kodu by przepuścić daną kolekcję przez pętlę. W dodatku może okazać się, że coś skrewiliśmy albo nasz kod dostał się w niepowołane ręce, które wykonały kilka niefajnych operacji bezpośrednio na kolekcji.
W Scali jest trochę lepiej mamy metodę foreach, która opakowuje pętlę:

Listing 2. foreach w Scali

val x = 1 to 10
x foreach ($ => println($*$))

I już mamy kwadraty liczb od 1 do 10. W javie trzeba na to dwóch pętli.

Oczywiście jest tu ukryty mały "fakap" ponieważ zarówno metoda to jak i foreach maskują nam odpowiednie pętle. W przypadku to jest to jeszcze wzbogacone o lazy-init, ale to insza inszość.

Dlaczego opakowywać kolekcje?

Kod w Scali fajny jest. Dlatego warto stworzyć sobie podobne możliwości. W Javie nie jest to trudne generalnie poniższy kawałek kodu rzucił mi się kiedyś w oczy, ale skąd pochodzi ta koncepcja nie jestem wstanie powiedzieć.

Listing 3. foreach w Javie

interface Foreach {

	interface Action {
		void perform(T t);
	}

	abstract class ForeachImpl implements Foreach {

		private static class ArrayDelegate implements Foreach {

			private T[] array;

			public ArrayDelegate(T[] array) {
				this.array = array;
			}

			@Override
			public void foreach(Action action) {
				for (T t : array) {
					action.perform(t);
				}
			}
		}

		private static class Delegate extends ForeachImpl {

			public Delegate(Collection collection) {
				super(collection);
			}
		}

		public static  Foreach delegate(Collection collection) {
			return new Delegate(collection);
		}

		public static  Foreach delegate(D[] collection) {
			return new ArrayDelegate(collection);
		}

		private Collection collection;

		private ForeachImpl(Collection collection) {
			this.collection = collection;
		}

		@Override
		public void foreach(Action action) {
			for (T t : collection) {
				action.perform(t);
			}
		}
	}

	public void foreach(Action action);
}

Jest to trochę karkołomna konstrukcja w tej postaci, ale wiadomo o co chodzi. Odpowiednie zagłębienia służą tu odwaleniu roboty podobnej do tej jaką odwala scalac przy dodawaniu traita do klasy. Dla przypomnienia jeżeli trait nie zawiera implementacji to jest traktowany jak interfejs. Jeżeli zawiera implementacje to tworzone są klasy abstrakcyjne zawierające zaimplementowane metody i w klasie docelowej następuje delegacja zachowania do takiej wewnętrznej klasy. Tyle w skrócie zainteresowanych odsyłam do konsoli i polecenia javap.

Nasza klasy wystarczy, że zaimplementuje interfejs i wydeleguje obsługę metody do klasy Delegate. Już dużo mniej roboty później przy iterowaniu przez kolekcję wystarczy zaimplementować clou pętli czyli to co pomiędzy { i }. Można to też łatwo przetestować. Ba! Można implementację przerzucić na użytkownika API. Niech powie co robi z pojedynczym elementem kolekcji, a to jak będzie przechodził przez kolekcję to już nie jego sprawa. Tu dochodzimy do takiego modelu, który jest już blisko programowania funkcyjnego. Klient mówi CO i nie martwi się JAK.

Wypełniamy tablicę

Powróćmy do pierwszego kodu. W pierwszym kroku opakujmy tablicę jednowymiarową o zadanej ilości elementów w coś przyjaznego dla środowiska:

Listing 4. Opakowana tablica intów

class ArrayOfInt {

	private Integer array[];

	public ArrayOfInt(int size) {
		array = new Integer[size];
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		int next = start;
		for (int i = 0; i < array.length; i++) {
			array[i] = next;
			next += step;
		}
		return next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Integer t) {
				System.out.print(String.format("%2s ", t));

			}
		});
	}

}

Ok, na razie nic groźnego. O ile inicjację tablicy i jej wypełnienie musimy przeprowadzić iterując z palucha to już wypisanie robimy za pomocą delegowania.
Teraz czas na tablicę dwu wymiarową. W tym przypadku musimy powiedzieć ile kolumn i ile rzędów chcemy mieć. Jednak czy aby na pewno? Opakowujemy w końcu kolekcję kolekcji... zatem...

Listing 5. Opakowana dwu wymiarowa tablica intów

class Array2dInt {

	private class Next {
		int next;
	}

	private ArrayOfInt array[];

	public Array2dInt(int rows, int cols) {
		array = new ArrayOfInt[rows];
		for (int i = 0; i < array.length; i++)
			array[i] = new ArrayOfInt(cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(ArrayOfInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Whoa... inicjacja w konstruktorze nadal z palucha (tego nie przeskoczymy). Reszta przez delegaty. Tablica trójwymiarowa to już formalność.

Listing 5. Opakowana trójwymiarowa tablica intów

class Array3dInt {

	private class Next {
		int next;
	}

	private Array2dInt array[];

	public Array3dInt(int rows, int cols, int depth) {
		array = new Array2dInt[depth];
		for (int i = 0; i < array.length; i++)
			array[i] = new Array2dInt(rows, cols);
	}

	public int fill(final int start) {
		return fill(start, 1);
	}

	public int fill(final int start, final int step) {
		final Next next = new Next();
		next.next = start;
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				next.next = t.fill(next.next, step);
			}
		});

		return next.next;
	}

	public void print() {
		ForeachImpl.delegate(array).foreach(new Action() {

			@Override
			public void perform(Array2dInt t) {
				t.print();
				System.out.println("");
			}
		});
	}
}

Całość można oczywiście ładnie rozdzielić na nieanonimowe klasy wewnętrzne (albo wyrzucić do osobnych klas o ograniczonej widoczności) czy uczynić generycznym. Cały kod jest, wbrew pozorom, prostszy i łatwiejszy w testowaniu.

Podsumowanie

Bardzo istotną rzeczą w takim podejściu do kodowania jest umiejętność rozdzielenia swojej osobowości na klienta i dostawcę. W przeciwnym wypadku możemy nieźle przestraszyć się ilością kodu.

Najistotniejszą cechą jest jednak ograniczenie klientowi pola manewru w pracy z kolekcją. Mając ograniczone API i pozbawiając go możliwości dowolnego manipulowania elementami możemy się zabezpieczyć przed nieprzyjemnymi sytuacjami jak chociażby usunięcie elementu z kolekcji (boli jak używasz JPA), głębokie klonowanie kolekcji albo nieskończonego iterowania.
Dodatkowo operacje biznesowe są jasno określone przez co zmniejsza się prawdopodobieństwo "hakierowania" i tworzenia obejść we właściwym kodzie biznesowym.

Gdzie warto używać

Przede wszystkim warto opakowywać kolekcje, które wychodzą z bazy danych/DAO. W ten sposób można ograniczyć manipulowanie obiektami w ramach kodu biznesowego. Wszelkie operacje związane ze zmianą stanu bazy będą dokonywane poprzez interfejs opakowanej kolekcji. Dzięki czemu można kontrolować kto co może. W takim układzie aplikacja nie widzi DAO jako takiego. Widzi tylko interfejs dostarczający pewne dane na których można wykonać ściśle określone operacje.
Po drugie MVP. W tym przypadku kolekcja staje się pomocnikiem dla prezentera. Można dzięki temu wprowadzić np. dodatkowe filtrowanie danych tuż przed ich wyświetleniem. To pozwala na stworzenie jednego prezentera, który będzie prezentował dane w zależności od potrzeb, ale będzie jednocześnie na tyle elastyczny by móc z niego skorzystać w wielu miejscach. Przykładowo kolekcja A przed wyświetleniem wymaga wycięcia części danych, których nie bardzo można pozbyć się na etapie pobierania z bazy. Jednocześnie kolekcja B nie ma tych danych już domyślnie. Obie mają metodę show przyjmującą jako parametr prezenter. Następnie w środku wywołują tylko wybrane metody prezentera.
Po trzecie filtry. W takim przypadku zamiast pozwolić iterować po kolekcji możemy udostępnić klientowi ileś tam predefiniowanych metod, które filtrują kolekcję w określony sposób. Tu mała uwaga. Szkoda, że w Javie nie ma eleganckich domknięć i trzeba stosować haki w stylu anonimowych klas.

Dodaj do

By ogarnąć DI należy napisać jeden projekt bez użycia słowa kluczowego new w kodzie biznesowym. Można go używać w provideach. Dozwolone jest też tworzenie prymitywów i Stringów “z palca”.

Dodaj do

Z głośników benefis Marka Niedźwieckiego. Na blogu siódma zasada Jeff’a Bay’a:

Nie używaj klas o więcej niż dwóch polach

Na początek kilka wyjątków, ponieważ ta zasada jest dość ciekawa. Otóż do liczby pól w klasie nie zaliczamy serialVersionUID oraz cache dla hashCode i toString. Pierwsze z wiadomego powodu – być musi jeżeli klasa jest serializowana. Reszta być może jeżeli klasa będzie niezmienna – pola będą final i obiekty w tych polach też będą niezmienne.

Teraz do rzeczy.

Ile masz rąk?

Zazwyczaj odpowiedź brzmi dwie. Nawet jeżeli jesteś “code monkey” to nadal nie posiadasz ani chwytnych stóp ani ogona. Zatem jesteś wstanie wykorzystywać tylko dwa przedmioty na raz.

Co z klasami modelującymi dane?

Zdawać by się mogło, że zasada ta nie jest do zastosowania wobec klas, które modelują dane (jakie to klasy? W uproszczeniu te które zawierają adnotacje JPA). Szybko można jednak dojść do wniosku, że i tu mamy pole manewru. Poza klasami posiadającymi tylko jedno pole – zasada numer 3 i zasada numer 8, są jeszcze klasy, które mają za zadanie komponować klasy zawierające po jednym polu. Jeżeli taka klas będzie miała dwa pola to będzie dość.

Po co?

Ok po co to robimy. W przypadku obiektów biznesowych intencja jest jasna. Im mniej pól, tym mniej wykonywanych operacji i tym samym ściślejsza odpowiedzialność.
W przypadku obiektów DTO sprawa ma się trochę inaczej. Na pewno każdy prędzej czy później trafi na obiekt, który ma wiele(10+) pól i współpracuje z innymi obiektami o podobnym rozmiarze. Jest to często spotykany przypadek w starym kodzie. Prześledzenie w jaki sposób przekazywane są poszczególne wartości. Jak wygląda współpraca między nimi, co jak i dlaczego jest przekazywane. Znacznie prościej jest zatem zdekomponować klasę i otrzymać znacznie prostszy w ogarnięciu kod. Nie ma wtedy miejsca na zastanawianie się, które z dziesięciu pól do czego służy. Jesteśmy za to prowadzeni jak po sznurku od elementu do elementu.
Ostatnią istotną cechą tak stworzonej hierarchii obiektów jest bardzo proste sprawdzanie poprawności stanu całego zestawu. Każdy z elementów ma własny walidator, który można odpowiednio przetestować, ma własny zestaw testów, ma w końcu jasno określony cel. Dodatkowo łatwo jest też “uniezmienniczyć” obiekty wystarczy dodać kilka razy final.

Podsumowanie

Problematyczne na pierwszy rzut oka wydaje się wykorzystanie tej zasady w przypadku wykorzystywania ORM. Ostatni mój projekt poprowadzony zgodnie z tymi zasadami używa JPA2. Na początku było dziwnie. Teraz jest dobrze. Grunt to poznać zasady mapowania w JPA2. Szczególnie jak mapować klasy złożone. Szczególnym przypadkiem wykorzystania tej zasady są naturalne klucze główne, które ze swej natury organizują kod w mniejsze klasy o lepiej określonym przeznaczeniu.
To tyle. Za niedługo trzeba będzie pokazać kawałek kodu

Dodaj do

Therion – Secret of the Runes i szósta z zasad Jeff’a Bay’a

Pilnuj wszystkie encje by były małe

Na początek mały, obrazkowy przykład dlaczego warto pisać zwięzły kod.

Oto jeden prosty program. W zasadzie jego połowa. Całość ma około 1000 linii. Tu wersja czcionką 1ką. Wyobraźmy sobie sytuację, w której:

• W trakcie kompilacji produkcyjnej usuwamy informacje dla debuggera.
• Coś się spieprzyło na produkcji.
• W stacktrace nie ma informacji o linii, bo zostały one wycięte na etapie kompilacji (piękny przykład tu).

Bingo! Szkoda tylko, że twoje serce nie wytrzymało stresu i po trzydziestej kawie odmówiło współpracy.

Czym jest encja?

W sumie nie encja, bo to określenie jednoznacznie kojarzy się z ORMem, POJO i generalnie klasami. Lepszym jest blok kodu, ale zostaniemy przy encji, bo tak. Inaczej mówiąc jakaś podstawowa jednostka kodu. Na nasze potrzeby przyjmijmy, że jednostką tą jest coś co powinno zdaniem czy to kompilatora czy też checkstyle zostać zamknięte pomiędzy { i }. W szczególności są to pętle, instrukcje warunkowe, metody, klasy. Dodatkowo Jeff Bay wspomina też o pakietach.

Jak duża powinna być encja?

Odpowiedź na to pytanie brzmi tradycyjnie “to zależy”. Najprościej rzecz ujmując zależy to od konkretnego przypadku, ale można określić pewne dobre praktyki.

Zacznijmy od klasy. Najprościej jest tu odnieść się do tego co dostarcza nam IDE. Klasa powinna mieścić się na ekranie. W całości. Oczywiście zanim klasa zostanie poddana temu testowi warto zwinąć javadoci. Można też trochę oszukiwać i zmniejszyć czcionkę, ale… kod musi być czytelny. Ustaw wielkość czcionki na taką jaka jest dla ciebie wygodna do pracy, uruchom edytor w trybie pełnoekranowym (Eclipse ctrl+m). Klasa ma się mieścić na ekranie. Dlaczego tak? Ponieważ tak mała klasa jest wygodna w czytaniu. Nie tylko jednak o wygodę tu chodzi. Za dużo kodu może oznaczać, że klasa ma za dużo odpowiedzialności. Względnie realizuje zbyt ogólną funkcjonalność za pomocą niskopoziomowych rozwiązań. Przykładowo klasa modem operująca bezpośrednio na ramkach. Jak temu zaradzić? Najprościej to delegować część czynności do osobnych klas, położonych “niżej” w architekturze. Wkraczamy tu na grunt grząski ponieważ większość programistów jest przyzwyczajona do sytuacji, w której SRP zwalnia z patrzenia na kod przez pryzmat abstrakcji. Klas z obrazka na górze jest świetnym przykładem. Jedna odpowiedzialność 1000 linii kodu. To, że w ramach tej odpowiedzialności można wydzielić pewne mniejsze elementy… nieważne.

Metody są trochę prostsze do ogarnięcia. Tu można przyjąć zasadę pięciu linii – pięciu znaków ;. Jeżeli jest za dużo średników to znaczy, że robimy za dużo rzeczy naraz. Szczególnie jest to widoczne tam gdzie korzystamy ze zmiennych lokalnych. Dużo zmiennych lokalnych – dużo problemów. Zmienne lokalne są fajne, ale pod warunkiem, że ich nie używamy. Powiedzmy sobie szczerze, zmiennej lokalnej nie zastąpisz mockiem. Tym samym nie można przetestować jak zachowa się kod pod wpływem różnych wartości. Mniejszy problem jeżeli zmienna lokalna została pozyskana z parametru bądź z pola. Wtedy można to jeszcze jakoś przetestować. Gorzej jeżeli jest to zmienna pozyskana z innej zmiennej bądź za pomocą operatora new.
Rozwiązaniem jest rozbicie metody na kilka mniejszych współpracujących ze sobą.

Pętle i instrukcje warunkowe. Bardzo podobne do metod. Jeżeli są dłuższe niż 5 linijek to można założyć, że robią za dużo na raz. Często też w przypadku instrukcji warunkowych przeniesienie części kodu do osobnej metody pozwala na odnalezienie pewnej grupy metod zależnych od jednego warunku, a to jest już świetnym punktem wyjścia do wprowadzenia nowej wyspecjalizowanej w obsłudze tego konkretnego warunku klasy. Dobrą praktyką jest przeniesienie całego bloku do osobnej metody “na dzień dobry”. W przypadku pętli można też zastosować zasadę nr 8 i zamiast gołej kolekcji użyć odpowiedniego obiektu opakowującego ze zdefiniowaną metodą robiącą “coś” na elementach kolekcji.

Na koniec pakiety. Jeff Bay określił maksymalną ilość klas w pakiecie na 10. Rzecz kontrowersyjna, ale do pewnego stopnia sensowna. Tak samo jak w przypadku klas zbyt duża ilość linii może świadczyć o wykonywaniu wielu rzeczy tak w przypadku pakietów zbyt wiele klas może być wskazówką, że pakiet jest przeładowany. Co to tak naprawdę oznacza? Przywoływana przeze mnie klasa z obrazka siedzi w pakiecie wraz z około 150 innymi klasami. Każda z tych klas to osobny bean (nie do końca, ale sens jest ten sam) zatem zdawać by się mogło, że wszystko jest OK. Tyle tylko, że czasami trzeba coś zmienić. W takim przypadku rekompilacja trwa. Testy trwają. Integracja trwa. W sumie nieźle masz czas zaparzyć trzydziestą kawę. Niewielkie pakiety promują silną modularyzację w aplikacji. O ile na co dzień nie dostrzegamy tego to mając już dwie podobne aplikacje możliwość napisania kodu raz i przenoszenia go pomiędzy aplikacjami to duży plus.
Przykład z życia ELIXIR i EuroELIXIR to w praktyce identyczne aplikacje. Różnią się trochę jeśli chodzi o komunikaty przesyłane pomiędzy uczestnikami, bo wynika to z wymagań biznesowych np. Euro musi obsługiwać komunikaty w formacie XML, ale cała reszta taka jak zarządzanie oddziałami, użytkownikami, przeglądanie komunikatów, zarządzanie przebiegiem jest identyczne. Niestety COBOL i LINC nie miały możliwości pakietowania kodu. Zatem kod został zduplikowany. Po migracji duplikacja pozostała (i jest zwalczana w miarę potrzeb i wolnego czasu).
Mając kod w niewielkich pakietach potencjalna ekstrakcja interesującego nas fragmentu do osobnego projektu będzie stosunkowo prosta.

Inne metody skracania kodu

Zanim jednak zabierzemy się za skracanie kody warto przyjrzeć się kilku technikom pozwalającym na pisanie mniejszych ilości kodu od ręki.

Biblioteki

Na początek warto zastanowić się czy jakiś fragment kodu nie został już napisany. Świetnym przykładem jest wprowadzona w Javie 7 klasa Objects wywodząca się z Commons Lang i dostarczająca builderów dla metod equals czy hashCode. Podobnie ma się sprawa z np. serializacją obiektów do XML (tu polecam Simple – łatwe proste i nawet nie ma bugów). Osobnym zagadnieniem są oczywiście frameworki oraz Lombok.

Mechanizmy języka

W tym standardy. Zamiast po raz setny pisać warunek na nie nullowy parametr można użyć Bean Validation i adnotacji @NotNull (od wersji 1.1 także dla parametrów metod) albo jak nie mamy ochoty na kod beta machnięcie kilku aspektów. Szczególnie przydatnymi narzędziami są tu rozwiązania Dependency Injection w wersji czy to Springa, czy to CDI czy to Java Inject (Guice).

Własne standardy

Mój faworyt:

Listing 1. Po co ten if

public void doSth(Param param){
    if(param == null){
        throw new NullPointerException("Param is null");
    }
    param.someMethod();
}

NPE i tak by poleciał, a rzucanie wyjątku tylko by go wyrzucić mija się z celem. Szczególnie, że komunikat nic nie wnosi. W zamian warto jasno określić czy metoda akceptuje np. null. Jak nie akceptuje to zanim wstawimy warunek warto sprawdzić czy wywołanie metody już domyślnie nie wywali błędu. Zawsze jeden if mniej. Podobnie w przypadku weryfikacji. Jeżeli już rzucamy wyjątkiem to niech komunikat coś mówi. Zresztą obsługa wyjątków to osobny temat.

Podsumowanie

Jest to, nie ukrywam, bardzo trudna do wdrożenia zasada. Często można spotkać się z oporem przed rozbijaniem kodu na drobne klasy. Warto jednak pamiętać, że szczególnie większe projekty, warto rozdrabniać. Ma to na celu maksymalne uproszczenie testowania kodu i jego późniejszego utrzymania. Rozdrobnienie pozwala też na szybkie wyłapanie zduplikowanego kodu oraz błędów w projekcie. Szczególnie ta ostatnia cecha jest pożądana ponieważ pozwala na wczesne wykrywanie miejsc podatnych na błędy czy nieprzewidzianych lecz możliwych stanów aplikacji, przypadków użycia czy też innych sytuacji.

Dodaj do

Dziś smutna, 20 rocznica śmierci Freddego Mercurego. Z tej okazji z głośników Queen, a na tapecie piąta z zasad Jeff’a Bay’a

Nie skracaj nazw

Każdy kto choć trochę interesował się zagadnieniem jakości kodu wie, że najlepszy kod to kod samo-dokumentujący się. Innymi słowy jeżeli czytamy jakiś fragment, metodę czy kilka metod, to bez zagłębiania się w niższe warstwy możemy na podstawie samej nazwy, czy szerzej sygnatury, metody określić mniej więcej co ona robi.

Z drugiej strony nikt nie lubi pisać długich nazw. Jest to niewygodne. Dlatego tak ważne jest opanowanie IDE. Dzięki temu bardzo łatwo będziemy wstanie dostać się do systemu podpowiadania nazw. To znowuż zaoszczędzi nam czasu. Jeżeli jeszcze dodatkowo zdefiniujemy własne szablony kodu to pisanie staje się czystą przyjemnością.

Liberum Veto!

Jeff Bay porusza jednak znacznie ważniejszy aspekt związany z nazewnictwem zmiennych, metod oraz klas. Jest to zniechęcenie, które pojawia się gdy wielokrotnie musimy powtarzać daną nazwę.
Czyli co? Skrócić nazwę?
I tak i nie. Jeżeli jakaś nazwa przewija się w kodzie wielokrotnie może to sygnalizować kilka problemów:

• Metoda jest przeładowana.
• Zgubiliśmy klasę.
• Źle określiliśmy zakres odpowiedzialności.

Metoda jest przeładowana

Oznacza to, że metoda wykonuje kilka rzeczy w zależności od wartości argumentów. Zazwyczaj na początku mamy kilka ifów, które pełnią rolę routera kierując przepływ sterowania w oparciu o jakąś wartość.
Rozwiązaniem jest rozdzielenie metody na kilka mniejszych i jeżeli istnieje konieczność zmiana w kodzie wywołującym tak by ograniczyć ilość instrukcji warunkowych. Warto też zastanowić się nad tym, czy dana operacja powinna być wykonana NA obiekcie czy raczej powinna być wykonana PRZEZ obiekt.

Zgubiliśmy klasę

Szczególnie widoczna przypadłość wszelkich klas Utils gdzie w ramach jednej klasy utrzymujemy wiele metod robiących wiele kompletnie nie związanych ze sobą rzeczy. Jeżeli w naszym kodzie dana klasa pojawia się często w różnych kontekstach warto rozbić ją na mniejsze bardziej wyspecjalizowane. Jeżeli nie jest to możliwe to należy pamiętać o adnotacji @Deprecated i wydelegować poszczególne grupy metod do osobnych klas. Zostaniemy w ten sposób z “klasą wydmuszką”, którą będzie można stosunkowo łatwo usunąć.

Źle określiliśmy zakres odpowiedzialności

Przypadek gdzieś pomiędzy wcześniejszymi. Z jednej strony dana metoda robi jedną rzecz, ale przy okazji wykonuje kilka dodatkowych czynności zazwyczaj związanych z walidacją parametrów czy sprawdzeniem stanu obiektu. W takim wypadku warto zastanowić się nad zmianą w kodzie tak by sprawdzać dane i delegować zadanie dalej albo założyć, że dane są zawsze dobre i nie ma sensu ich sprawdzanie.
Oba rozwiązania są poprawne, a wybór konkretnego zależy w znacznej mierze od przyjętej w ramach projektu konwencji oraz tego na jakim poziomie aplikacji jesteśmy.

Podsumowanie

Przestrzeganie tej zasady jest bardzo proste i powinno być naszym nawykiem. Dzięki niej nie tylko zyskujemy czas w trakcie czytania kodu, ale też możemy sprawnie identyfikować miejsca w kodzie, które wymagają poprawek. Co do zasady takie podejście sprawdza się w obu kierunkach. Jeżeli nie potrafimy nadać krótkiej i znaczącej nazw, która nie zawiera skrótowców to nasz kod wymaga poprawki.
Jak zawsze też w przypadku zasad Jeff’a Bay’a musimy uzbroić się w dobrą znajomość IDE. Bez tego będzie bardzo ciężko.

Dodaj do

Słuchając Manowar dzielnie zagłębiamy się w czwartą z zasad Jeff’a Bay’a.

Używaj tylko jednej kropki na linię

Jeżeli przejrzymy dowolny kod pisany “na szybko” będziemy wstanie znaleźć tego typu potworki jak ten tutaj:

Listing 1. Typowy “łańcuszek” w kodzie

package pl.koziolekweb.eowp4;

public class App {

	public static void main(String[] args) {
		Person person = new Person();
		person.name ="Ilona";
		System.out.println(isFemaleName(person));
	}

	public static boolean isFemaleName(Person person) {
		return person.name.lastIndexOf("a") == person.name.length() - 1;
	}

}

class Person {

	String name;

}

Mamy tu do czynienia z typowym “łańcuszkiem” wywołań metod. Kod ten będzie działał w oparciu o wiarę programisty w to, że po drodze nic się nie stanie.
Innym często spotykanym rozwiązaniem związanym z obsługą XMLa jest taki oto potworek:

Listing 2. Następny “łańcuszek” tu obsługa XML.

Element newDocument = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument().getDocumentElement();

Dlaczego jest to złe?

Wraz z budową tego typu konstrukcji pojawiają się też błędy. Najpopularniejszym jest klasyczny NullPointerException, który występuje “gdzieś w linii numer”. W takim przypadku zaczyna się walka z debuggrem albo dupa-debug i rozpisywanie kolejnych “kropek” na pojedyncze zmienne. Tak jest zazwyczaj w drugim przedstawionym przypadku.
Ze znacznie poważniejszym problemem mamy do czynienia w pierwszym przykładzie. Pomijając już to co pisałem w poprzedniej części na temat opakowywania typów prostych i stringów to mamy tu jeszcze bonus w postaci zignorowania podstawowych zasad programowania obiektowego. W tamtym przykładzie brakuje najzwyczajniej enkapsulacji. Wprowadzenie gettera nic nie da, bo “goły” getter służy tylko poprawie samopoczucia programisty, ale nie zapewnia enkapsulacji.
Dlaczego jest to takie ważne? Ponieważ jeżeli olejemy w Javie zasady programowania obiektowego to równie dobrze można przesiąść się na COBOLa.

Jak temu zaradzić

Najprościej jest zastosować Prawo Demeter^W. Jest to jednak dość ryzykowna zabawa. Przede wszystkim jeżeli mamy kiepsko przemyślaną strukturę to łańcuszek kropek zostanie zastąpiony przez łańcuszek metod. Co ciekawe kod wykazuje tu zadziwiająca właściwość do składowania tych metod jako publiczne w ramach obiektu, w którym mieliśmy łańcuszek. Jeff Bay proponuje więc trochę lżejszą wersję tego prawa. Mówi ona, że możesz:

• Bawić się własnymi zabawkami – legalne jest “łańcuszkowanie” metod prywatnych.
• Bawić się zabawkami, które skonstruujesz – legalne jest użycie dowolnych metod z tworzonych lokalnie obiektów.
• Bawić się zabawkami, które ktoś ci dał – możesz wywoływać metody obiektów przekazanych w parametrach metody.

Zabrania się jednak zabawy “zabawkami zabawek”, czyli w praktyce jeżeli chcemy stworzyć kod taki jak w drugim przypadku to powinniśmy zamiast kilkunastu kolejnych wywołań otrzymać zabawkę – instancję Document i na niej wywołać odpowiednią metodę. Wynik tej metody przekazać niżej jako nasz podarunek dla wywoływanego obiektu.
W pierwszym przypadku należało by zupełnie inaczej rozmieścić metody. Jako, że naszą zabawką jest obiekt klasy Person to nie możemy wykorzystać metod pola name (zabawka zabawki), nie za bardzo idzie też stworzyć nową zabawkę (np. dynamicznie dodać metodę – brak dynamicznego rozszerzania klas, ale już w Groovym będzie działać). Zostaje zatem zmiana właściciela metody tak by zabawki zostały w słusznej piaskownicy.

Listing 3. Wszystkie zabawki w swoich piaskownicach

package pl.koziolekweb.eowp4;

public class App {

	public static void main(String[] args) {
		Person person = new Person();
		person.name = "Ilona";
		System.out.println(person.isFemaleName());
	}

}

class Person {

	String name;

	boolean isFemaleName() {
		return name.lastIndexOf("a") == name.length() - 1;
	}
}

W ten sposób wszystko jest na swoim miejscu. W dodatku logika też trzyma się kupy. Klasa Person potrafi powiedzieć czy jest chłopcem czy dziewczynką.

Wyjątek

W ogólności unikanie wielu kropek w linii poza wymuszeniem lepszego rozłożenia metod i ulepszeniem ogólnego designu kodu poprawia też jego czytelność. Jest to bardzo dobre jeżeli np. korzystamy z Criteria API czy też podobnych wynalazków gdzie “da się” tworzyć konstrukcje typu przekazanie jako parametru metody trzech wywołań jakiś metod. Jest jednak pewien wyjątek od tej zasady. Jest nią wykorzystanie fluent interface.

Hej, ale tam są zabawki zabawek!

No nie do końca. Założeniem tego modelu programowania jest niezwracanie void. Jeżeli jakaś metoda nie zwraca nic to powinna zwracać this. W ten sposób możemy łatwiej tworzyć czytelny kod. Przy czym czytelność będzie zależała w znacznej mierze od konfiguracji IDE Świetny przykład pokazał Jacek Olszak we wpisie o FI w EggFramework. W praktyce zabawka zwraca samą siebie (bez klonowania mi tu!).

Podsumowanie

Czwarta z zasad jest z serii tych wrednych. Z jednej strony bardzo prosta do wprowadzenia, ale jednocześnie obnaży nawet najmniejsze nieprawidłowości w projekcie klasy. Zasada ta świetnie sprawdza się jeżeli chcemy utrzymywać porządek w interfejsie klas i nie do końca wiemy gdzie umieścić daną metodę.
Szczególnie pomocna staje się ona w momencie gdy korzystamy z kontenera DI. W takim momencie bardzo łatwo jest określić czy dana operacja powinna być wykonana na danym poziomi, czy też lepszym rozwiązaniem nie będzie przeniesienie jej w głąb i udostępnienie jako pojedynczej operacji.

Dodaj do

Z głośników spokojnie tym razem. Era. Swoją drogą przypominają mi się stare dobre czasy gdy przy “Ameno” przerąbywałem się przez kolejne poziomy w Diablo: Hellfire.
Wspomnienia, wspomnieniami czas jednak zająć się trzecią z zasad Jeff’a Bay’a.

Opakowuj wszystkie prymitywy i Stringi(w klasy o specyficznej dla zastosowania nazwie)

Rozejrzyj się wokoło. Zobacz jak zbudowany jest świat. Szybko stwierdzisz, że świat składa się z obiektów, które wchodzą w interakcje. Tak mniej więcej zaczyna się jakieś 99% kursów dotyczących programowania obiektowego. Pozostałe 1% zaczyna się mniej więcej tak: php jest językiem obiektowym.
Rzecz w tym, że w realnym świecie nie występują liczby, znaki czy stringi. Służą one do opisania jakiś konkretnych przedmiotów są ich cechami i wartościują je według określonego wzorca. W Javie liczby są przedstawione jako typu proste, a autoboxing jest tylko dodatkiem pozwalającym na łatwiejszą pracę z nimi. Swoją drogą powoduje to cholernie wiele problemów jeżeli chcemy używać typów liczbowych w metodach przyjmujących Object i przez przypadek podamy z palca prymitywa. To jednak zupełnie inny temat.

Program opisuje świat

Tak jak w realnym świecie tak i w aplikacji nie powinno używać się typów prostych i stringów. W ich miejsce należy wprowadzać niewielkie klasy reprezentujące atomową jednostkę “czegoś”. Klasa taka powinna mieć znaczenie biznesowe ponieważ reprezentuje pewną małą istotę żyjącą w ramach systemu.

Na początek pewien prosty przykład.

Listing 1. Typ prymitywny i “ciekawy błąd”

package pl.koziolekweb.eowp3;

public class MoneyExample {

	public static void main(String[] args) {
		Konto konto = new Konto();
		print(konto.stan());
		konto.uznaj(10);
		print(konto.stan());
		konto.obciąż(5);
		print(konto.stan());
		konto.uznaj(-3);
		print(konto.stan());
		konto.obciąż(-5);
		print(konto.stan());
	}

	private static void print(int stan){
		System.out.println("Stan konta to " + stan);
	}
}

class Konto {

	private int stan = 0;

	public void uznaj(int wartość) {
		stan += wartość;
	}

	public void obciąż(int wartość) {
		stan -= wartość;
	}

	public int stan(){
		return stan;
	}
}

Błąd widać na pierwszy rzut oka. Prymitywne typy danych prowokują do tego typu “ekscesów”. Oczywiście można wprowadzić dodatkowy walidator i bawić się w sprawdzanie czy przekazywana wartość nie jest mniejsza od 0. Jeżeli jednak operacje na danej wartości przeprowadzamy w różnych miejscach w aplikacji warto wprowadzić klasę zamiast typu prymitywnego. Jeff Bay idzie dalej i mówi, iż skoro w świecie realnym nie istnieją typy proste jako samodzielne twory to nie należy ich używać w aplikacji.

Typy prymitywne

Oczywiście trochę inaczej należy traktować typy proste, a inaczej String. Trochę lepsze rozwiązanie:

Listing 2. Typ prymitywny i obejście

package pl.koziolekweb.eowp3;

public class MoneyExampleWithType {

	public static void main(String[] args) {
		Konto2 konto = new Konto2();
		print(konto.stan());
		konto.uznaj(new Kwota(10));
		print(konto.stan());
		konto.obciąż(new Kwota(5));
		print(konto.stan());
		konto.uznaj(new Kwota(-3));
		print(konto.stan());
		konto.obciąż(new Kwota(-5));
		print(konto.stan());
	}

	private static void print(Stan stan) {
		System.out.println("Stan konta to " + stan);
	}

}

class Konto2 {

	private Stan stan = new Stan(0);

	public void uznaj(Kwota kwota) {
		stan.uznaj(kwota);
	}

	public void obciąż(Kwota kwota) {
		stan.obciąż(kwota);
	}

	public Stan stan() {
		return stan;
	}
}

class Kwota implements Wartość {

	private final int wartość;

	public Kwota(int wartość) {
		if (wartość < 0)
			throw new IllegalArgumentException("Kwota nieprawidłowa.");
		this.wartość = wartość;
	}

	@Override
	public Integer wartość() {
		return wartość;
	}

}

class Stan {

	private int wartość = 0;

	public Stan(int i) {
		wartość = i;
	}

	public void uznaj(Kwota kwota) {
		wartość += kwota.wartość();
	}

	public void obciąż(Kwota kwota) {
		wartość -= kwota.wartość();
	}

	@Override
	public String toString() {
		return "" + wartość;
	}
}

interface Wartość {
	T wartość();
}

Przykład działa w tym przypadku całkiem nieźle, ale… no właśnie. Jest sobie interfejs Wartość, który tan naprawdę psuje nam wszystko. Z dwóch powodów. Pierwszy to ujawnia jak trzymana jest implementacja typu prostego w klasie Kwota. Drugi nadal operujemy bezpośrednio na typie prostym. Czas wyciągnąć naszą ulubioną broń, czyli dziedziczenie.

Listing 3. Typ prymitywny i dobre podejście

package pl.koziolekweb.eowp3;

public class MoneyExampleWithExtends {
	public static void main(String[] args) {
		Konto3 konto = new Konto3();
		print(konto.stan());
		konto.uznaj(new KwotaBazowa(10));
		print(konto.stan());
		konto.obciąż(new KwotaBazowa(5));
		print(konto.stan());
		konto.uznaj(new KwotaBazowa(3));
		print(konto.stan());
		konto.obciąż(new KwotaBazowa(15));
		print(konto.stan());
	}

	private static void print(StanKonta stan) {
		System.out.println("Stan konta to " + stan);
	}
}

class Konto3 {

	private StanKonta stan = new StanKonta(0);

	public void uznaj(KwotaBazowa kwota) {
		stan = stan.uznaj(kwota);
	}

	public void obciąż(KwotaBazowa kwota) {
		stan = stan.obciąż(kwota);
	}

	public StanKonta stan() {
		return stan;
	}
}

class KwotaBazowa {

	protected final int wartość;

	public KwotaBazowa(int wartość) {
		if (wartość < 0)
			throw new IllegalArgumentException("Kwota nieprawidłowa.");
		this.wartość = wartość;
	}

}

class StanKonta extends KwotaBazowa {

	private Debet debet = Debet.N;

	private enum Debet {
		T {
			int v() {
				return -1;
			}
		},
		N {
			int v() {
				return 1;
			}
		};
		abstract int v();

		public static Debet czyDebet(int i) {
			if (i < 0)
				return T;
			return N;
		}
	}

	public StanKonta(int i) {
		this(i, Debet.N);
	}

	private StanKonta(int i, Debet debet) {
		super(i);
		this.debet = debet;
	}

	public StanKonta uznaj(KwotaBazowa kwota) {
		int nowaWartość = debet.v() * wartość + kwota.wartość;
		return new StanKonta(Math.abs(nowaWartość), Debet.czyDebet(nowaWartość));
	}

	public StanKonta obciąż(KwotaBazowa kwota) {
		int nowaWartość = debet.v() * wartość - kwota.wartość;
		return new StanKonta(Math.abs(nowaWartość), Debet.czyDebet(nowaWartość));
	}

	@Override
	public String toString() {
		return "" + debet.v() * wartość;
	}
}

Oczywiście ten kod wymaga jednej rzeczy. Testów (oraz synchronizacji, ale to inna inszość). Tych nie prezentuję, bo są nudne, ale trzeba je napisać. OK, ale co się stało? Przede wszystkim StanKonta reprezentuje kwotę (klasa nazywa się KwotaBazowa, bo siedzi w jednym pakiecie z poprzednimi przykładami i się kompilator burzy). Rozszerzyliśmy jednak zachowanie tej klasy w ten sposób, że poza zawsze dodatnią kwotą ma jeszcze flagę Debet. Flaga ta mogła być typu Boolean, ale... nie można by było wtedy uzyskać efektu wartości oraz metody czyDebet - Boolean jest final. To rozwiązanie ma pewne wady. Przede wszystkim rozwlekło kod. Wymaga też testów, ale... pierwotne rozwiązanie nadal wymaga testów w dodatku jest znacznie bardziej podatne na błędy (spróbujcie wrzucić do stanu konta np. zrzutowany char). Z drugiej strony uzyskaliśmy kod odporny na durne błędy. Łatwy w testowaniu. Jeżeli dodatkowo odpowiednio go popaczkujemy to będzie przenośny pomiędzy projektami.

Typ String

Podobnie jak typy proste typ String nie występuje w naturze z jednym wyjątkiem:

getStringFromObject

i tego wyjątku się trzymajmy.

Generalnie typ znakowy jest używany dość często jako nośnik informacji. Począwszy od dupereli typu imię i nazwisko, poprzez hasła, loginy, kończąc na adresach URL czy adresach usług. Przesłanianie tego typu ma jednak dwie zalety.

Po pierwsze pozwala na wprowadzenie dodatkowych walidacji na etapie tworzenia obiektu. Tym samym mamy kontrolę nad tym co tworzymy i nie posypie się np. MalformedURLException czy nie otrzymamy pustego napisu.
Po drugie znacznie łatwiej jest zarządzać kodem mając konkretny typ, a nie enigmatyczny String. Przykłady wymyślcie sobie sami.

Inne typy proste

Że co? Czy w Javie są jeszcze jakieś inne typy proste poza prymitywami(plus ich obiektowe wersje) oraz String? To zależy jak na to spojrzymy. Jeff Bay mówi o typach prostych, ale ja osobiści zalecam dodanie do listy typów prostych takich, które pochodzą z różnych narzędzi. Przykładowo jeżeli tworzymy XMLa i mamy schemę to warto poza walidacją ze schemą rozszerzyć klasy typu Node by uzyskać efekt wstępnej walidacji np. by nie wstawić nieprawidłowej nazw elementu.
Podobnie ma się rzecz z usługami sieciowymi. Tu wartą rozszerzenia jest klasa QName, szczególnie jeżeli wywołujemy usługi w sieci z ograniczonym dostępem. Można wtedy wprowadzić dodatkową walidację by sprawdzać już na wstępie czy dana usługa jest osiągalna. Pozwoli to na kontrolowane wyłapanie baboli.

Podsumowanie

Zasada ta jest dość trudna w zastosowaniu. Wymaga umiejętnego użycia zarówno interfejsów jak i dziedziczenia. Tworząc taki kod warto zadawać sobie pytanie "Czy A to B?". Pozwoli to na uproszczenie kodu i wczesne wyłapanie pewnych abstrakcji. Rozwiązanie tego typu pociąga za sobą pewne niedogodności. Przede wszystkim uzyskujemy prawdziwą enkapsulację. Innymi słowy łatwo wyeliminować tu gettery/settery, co pociąga za sobą spore problemy natury prezentacyjnej. Ten problem poruszę jednak w ostatniej części. Na razie można używać getterów

Dodaj do

Drugą część cyklu Ekstremalna obiektowość w praktyce czas zacząć. W głośnikach leci sobie Hammerfall, a my zajmiemy się drugą zasadą Jeff’a Bay’a.

Nie używaj słowa kluczowego else

Przecież to nic trudnego powiecie. Zatem na początek mały przykład kodu, w którym waszym zadaniem będzie zastosowanie tej zasady:

Listing 1. Jak by tu usunąć else

public AbstractServiceStub(Object object) {
		if (service == null) {
			super.service = new Service();
		} else {
			super.service = service;
		}
		((Service) super.service).setTypeMappingVersion("1.1");
	}

To jest kod wygenerowany przez AXIS. Trzeba z niego usunąć słówko kluczowe else. Proste, prawda?

W tym przypadku wystarczy użyć Extract Method w celu wyciągnięcia inicjalizacji do oddzielnego bloku:

Listing 2. Usunięcie else przez Extract Method

private void initService(final Service service) {
		if (Assertions.isNull(service)) {
			super.service = new Service();
			return;
		}
		super.service = service;
	}

Metoda prosta i skuteczna. Życie nie jest jednak takie proste za każdym razem.

Określony przepływ

Trochę bardziej skomplikowane zadanie. Jest sobie obiekt State reprezentujący różne stany konfiguracji – prawidłowy, nieprawidłowy i niezainicjowany. Trzeba zaprogramować prawidłową zmianę stanu, czyli:

• Ze stanu niezainicjowany można zmienić stan na prawidłowy i nieprawidłowy.
• Ze stanu prawidłowy można zmienić stan na nieprawidłowy.
• Ze stanu nieprawidłowy nie można zmienić już stanu.

Oczywistą sprawą będzie użycie enuma. Mniej oczywiste jest zmienianie stanu:

Listing 3. Uzależnienie wartości zwracanej od różnych warunków

package pl.koziolekweb.eowp2;

public enum State {

	VALID, INVALID, NOT_INIT;

	public State changeState(State target) {
		if (target == VALID && this != INVALID) {
			return VALID;
		} else if (target == INVALID) {
			return INVALID;
		} else if (target == NOT_INIT && this == NOT_INIT) {
			return NOT_INIT;
		} else {
			return this;
		}
	}
}

Zaszalałem Ok, co można tu zrobić? Można oczywiście zamiast konstrukcji else if zastosować kilka ifów, a zamiast ostatniego else zwracać this jako wartość domyślną. wtedy będzie to wyglądało mniej więcej tak:

Listing 4. Uzależnienie wartości zwracanej od różnych warunków bez else

package pl.koziolekweb.eowp2;

public enum State {

	VALID, INVALID, NOT_INIT;

	public State changeState(State target) {
		if (target == VALID && this != INVALID) {
			return VALID;
		}
		if (target == INVALID) {
			return INVALID;
		}
		if (target == NOT_INIT && this == NOT_INIT) {
			return NOT_INIT;
		}
		return this;

	}
}

W sumie nie zmieniło się nic.

Drugi if w metodzie to tak naprawdę ukryty else

Nie ma w tym nic dziwnego. Po prostu formułkę “Jeżeli a to b w przeciwnym wypadku c” rozbijamy na “Jeżeli a to b. Jeżeli nie a to c”. Zysku żadnego, kod niby lepszy, a w praktyce gorszy, bo else choć złe to jednak coś oznacza. Kilka ifów z rzędu tylko gmatwa kod.
W tym konkretnym przypadku rozwiązaniem jest wykorzystanie szmocy… znaczy się wykorzystamy polimorfizm^W. Zachowanie będzie zależało od konkretnej implementacji:

Listing 5. Uzależnienie wartości zwracanej od różnych warunków za pomocą polimorfizmu

package pl.koziolekweb.eowp2;

public enum State {

	VALID {
		@Override
		public State changeState(State target) {
			if (target != NOT_INIT) {
				return target;
			}
			return this;
		}
	},
	INVALID {
		@Override
		public State changeState(State target) {
			return this;
		}
	},
	NOT_INIT {
		@Override
		public State changeState(State target) {
			return target;
		}
	};

	public abstract State changeState(State target);
}

Z zestawu kilku ifów wybraliśmy jeden istotny, a resztę usunęliśmy. Nie ma ifów, nie ma elseów udających ify. Ładnie.

Motywacja

Po co tak naprawdę stosujemy tą regułę. Powód jest prosty i nazywa się złożoność cyklomatyczna^W (mądre słowo). Jednostką złożoności jest ilość WTF/s. Inaczej mówiąc jest to liczba określająca zagmatwanie kodu. Ściślejsza definicja mówi coś o ilości brzegów, wierzchołków i punktów wejścia i wyjścia w grafie przepływu programu. Takie matematyczne pieprzenie, które nas malo obchodzi na chwilę obecną
Generalnie sama złożoność nie będzie wiele mówić jeżeli programujemy obiektowo. Trochę lepszą metryką jest średnia złożoność na metodę w danej klasie. Jeżeli jednak korzystamy z tej metryki to trzeba pamiętać, że limity podane na wiki są znacznie niższe.

Jak mierzyć CC?

Potrafi to i Cobertura i JDepend i JavaNCSS.

Po co mierzyć CC?

Ponieważ nie tylko else wpływa na zagmatwanie kodu. Jest to dobra metryka obrazująca ogólną złożoność kodu i pozwala w połączeniu z prezentowaną tu regułą na uproszczenie kodu.

Jak stosować ta regułę

Istnieje kilka sposobów na to jak wprowadzić dziś omawianą regułę do kodu. Oto kilka z nich. Nie wszystkie, bo dużo w tym wypadku zależy od konkretnego przypadku, ale to te najpopularniejsze.

Odwróć warunek

Czasami można pozbyć się else odwracając warunek. Zamiast używać == można użyć !=. Trochę bardziej skomplikowaną sztuczką może być tu wykorzystanie prawa De Morgana^W choć to czasami wprowadza znacznie więcej zamieszania. Warto tu mieć już gotowy komplet testów, które pokrywają wszystkie kombinacje warunków.

Polimorfizm

Czyli uzależnienie przebiegu programu nie tyle co od warunku co od dostarczonej wersji metody. Bardzo fajna sprawa, szczególnie jak popatrzymy na scalowe Case Classes. Na dłuższą metę jest to bardzo trudne ponieważ zacznie się biegunka klas spowodowana koniecznością dostarczanie nie tylko klas realizujących różne wersje algorytmu w zależności od warunku, ale też odpowiednich fabryk. Tu ratunkiem mogą okazać się wzorce dekorator i builder oraz rozsądna delegacja zadań, które będą choć trochę upraszczać tworzenie klas.

Delegacja do bibliotek zewnętrznych

Każdy zna konstrukcję jeżeli null to NPE. W Bean Validation API 1.1 będzie walidacja argumentów metod. To pozwoli nam na adnotowanie argumentu i nie martwienie się o walidacje lokalne. Podobnie ma się sprawa z metodami takimi jak equals, hashCode i toString, które są niewyczerpanym źródłem elseów.

Programowanie aspektowe

Tak jak wyżej, ale w trochę inny sposób. Niektóre instrukcje można przenieść do aspektu i nie martwić się ich obsługa w kodzie.

Kontrowersyjny Null Object

Na koniec pozostawiłem sobie najbardziej kontrowersyjną metodę wprowadzenia tej reguły. Generalnie znaczna część instrukcji warunkowych sprawdza czy dany obiekt nie jest null. W zamian można wprowadzić wzorzec Null Object. W skrócie jest to użycie specjalnej implementacji klasy, która “robi nic” zamiast zwrócenia null. Upraszcza to znacznie implementację ponieważ nie trzeba sprawdzać warunków. Z drugiej strony należy pamiętać, że jest to wzorzec wirusowy. Oznacza to, że jeżeli dana metoda będzie zwracać jakiś obiekt, to w implementacji Null Object powinniśmy zwracać Null Object danego obiektu. Zatem obok drzewka realnych obiektów otrzymujemy ich nullowe odpowiedniki. Coś za coś.

Podsumowanie

Kolejna stosunkowo prosta reguła. Pozwala ona na tworzenie stabilnego, prostego kodu, który jest bardzo łatwy w testowaniu. Ograniczenie ilości warunków w instrukcjach warunkowych pozwala na uzyskanie lepszego pokrycia testami dla tych instrukcji.
Wadą jest konieczność kombinowania ponieważ czasami ciężko wymyślić jakieś dobre rozwiązanie problemu i trzeba zmieniać wszystkie założenia co do klasy.
Warto jednak wprowadzać tą regułę tak często jak tylko się da ponieważ dzięki temu nasz kod staje się prosty, a ilość WTF/s dąży do 1.

Dodaj do

Witam w pierwszej części cyklu Ekstremalna Obiektowość w Praktyce. Z głośników płynie sobie Another Brick on the Wall part II, a my zajmiemy się pierwszą z zasad Jeff’a Bay’a. Brzmi ona

Tylko jeden poziom zagłębienia na metodę

Jest to jedna z prostszych zasad, której wprowadzenie wymaga tylko umiejętnego wykorzystania refaktoryzacji typu Extract Method. Pytania:

• Gdzie w Twoim ulubionym IDE jest dostępna ta refaktoryzacja?
• Jaki jest jej skrót klawiaturowy?

Mam nadzieję, że odpowiedziałeś/aś poprawnie na oba pytania i to bez chwili zastanowienia. Dlaczego to takie ważne? Pisałem o tym w części zerowej, ale przypomnę. Zasady przedstawione w tym cyklu wymagają dobrego warsztatu pracy tak by nie tracić czasu na szukanie narzędzi, a korzystać z nich.

Na czym to polega?

Załóżmy, na początek, że potrzebujesz wypełnić trójwymiarową tablicę za pomocą kolejnych liczb naturalnych, a następnie wypisać ją na standardowe wyjście. Wiem, że przykład jest głupi i mało rzeczywisty, ale bardziej namacalne za chwilę. Program realizujący taką funkcjonalność będzie wyglądał mniej więcej tak:

Listing 1. Wypełnienie i wypisanie tablicy 3D

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			for (int j = 0; j < array3d[i].length; j++) {
				for (int k = 0; k < array3d[i][j].length; k++, current++) {
					array3d[i][j][k] = current;
				}
			}
		}
		//----------------------------------------
		//poziom 0
		//--poziom 1 - to jest dopuszczalne
		//------poziom 2 - tego robić nie wolno
		//----------poziom 3 - tego tym bardziej robić nie wolno
		//----------------------------------------
		for (int i = 0; i < array3d.length; i++) {
			for (int j = 0; j < array3d[i].length; j++) {
				for (int k = 0; k < array3d[i][j].length; k++, current++) {
					System.out.print(String.format("%2s ",array3d[i][j][k]));
				}
				System.out.println();
			}
			System.out.println();
		}

	}

}

Realizacja w main tylko dla wygody uruchamiania. Z tego powodu dalej będę używał metod statycznych.

Jak widać jest to niezbyt ciekawy, zagmatwany kod. Tu o tyle prosty, że w poszczególnych pętlach niewiele się dzieje. Pierwsza z reguł Bay'a mówi, że należy tak pisać kod by w metodzie był tylko jeden poziom wcięcia. Co to oznacza? Oznacza to, że masz prawo zrobić 4 spacje/1 tab w celu wcięcia kodu metody, a następnie kolejne 4 spacje/1 tab w celu wcięcia dla np. instrukcji warunkowej czy pętli. W tej wciętej instrukcji nie możesz używać dalszych wcięć. Na listingu 1 komentarze oznaczają poszczególne poziomy wcięć.
Spróbujmy teraz wyekstrahować poszczególne metody tak by osiągnąć kod zgodny z założeniami. W tym celu będziemy używać refaktoryzacji Extract Method.

Listing 2. Kod po pierwszej refaktoryzaci

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}

		for (int i = 0; i < array3d.length; i++) {
			current = print2dArray(array3d, current, i);
			System.out.println();
		}

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static int print2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = printRow(array3d, current, i, j);
			System.out.println();
		}
		return current;
	}

	private static int printRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
		return current;
	}

}

Jak widać kod wygląda już zdecydowanie lepiej. Nie jest może idealny, ale jest znacznie bardziej czytelny. Możemy oczywiście pogłębić refaktoryzację wyciągając jeszcze pętle z main do osobnych metod:

Listing 3. Kod po drugiej refaktoryzaci

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		int current = 0;
		current = fillArray(array3d, current);

		current = printArray(array3d, current);

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillArray(int[][][] array3d, int current) {
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static int print2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = printRow(array3d, current, i, j);
			System.out.println();
		}
		return current;
	}

	private static int printArray(int[][][] array3d, int current) {
		for (int i = 0; i < array3d.length; i++) {
			current = print2dArray(array3d, current, i);
			System.out.println();
		}
		return current;
	}

	private static int printRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
		return current;
	}

}

Co dzięki temu uzyskaliśmy? Już po pierwszej refaktoryzacji można zauważyć, nadmiarową część kodu. Jaką? Przyjrzyjmy się wypisywaniu tablicy... po co nam zmienna current? Oczywiście kod tworzony za pomocą kopiuj wklej jest zawsze podatny na tego typu potknięcia. Nie zmienia to jednak faktu, że w pierwotnej wersji kodu umyka ten szczegół. Co ważne, zmienna ta nie jest też potrzebna w metodzie main można zatem przenieść ją głębiej w kod. Dzięki temu osiągamy też ukrycie implementacji przed klientem. Klient nie musi wnikać jak wypełniana jest tablica. W szczególności nie obchodzą go zmienne wykorzystywane przez metodę wypełniającą.
W wyniku wszystkich tych kroków otrzymujemy poniższy kod.

Listing 4. Kod zakończeniu pracy

package pl.koziolekweb.eowp1;

public class Array3DFiller {

	public static void main(String[] args) {
		int[][][] array3d = new int[3][3][3];
		fillArray(array3d);

		printArray(array3d);

	}

	private static int fill2dArray(int[][][] array3d, int current, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			current = fillRow(array3d, current, i, j);
		}
		return current;
	}

	private static int fillArray(int[][][] array3d) {
		int current = 0;
		for (int i = 0; i < array3d.length; i++) {
			current = fill2dArray(array3d, current, i);
		}
		return current;
	}

	private static int fillRow(int[][][] array3d, int current, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++, current++) {
			array3d[i][j][k] = current;
		}
		return current;
	}

	private static void print2dArray(int[][][] array3d, int i) {
		for (int j = 0; j < array3d[i].length; j++) {
			printRow(array3d, i, j);
			System.out.println();
		}
	}

	private static void printArray(int[][][] array3d) {
		for (int i = 0; i < array3d.length; i++) {
			print2dArray(array3d, i);
			System.out.println();
		}
	}

	private static void printRow(int[][][] array3d, int i, int j) {
		for (int k = 0; k < array3d[i][j].length; k++) {
			System.out.print(String.format("%2s ", array3d[i][j][k]));
		}
	}

}

Nie jest to oczywiście kod idealny. Metody mają za dużo parametrów, a klasa ma kilka odpowiedzialności (wypełnienie i wypisanie). Jak go ulepszyć będę jeszcze pisał w następnych częściach. Na chwilę obecną osiągnęliśmy wyznaczony cel. Metody nie mają więcej niż jeden poziom wcięcia.

A może coś bardziej życiowego?

Przykład był mało życiowy, ale prosty. Czas na coś bardziej życiowego.
Jak wspomniałem wcześniej realizowałem ostatnio niewielki projekt, który postanowiłem napisać zgodnie z tymi zasadami. Jedną z funkcjonalności było przepisanie odpowiedzi serwera z tekstu (XML) na kolekcję obiektów. Sprawa prosta, a nie chciało mi się szukać biblioteki mapującej. Zresztą powoli robi mi się w projekcie jar-hell więc dołączanie biblioteki tylko dla jednej metody traci sens.
W uproszczeniu cały program wyglądał by mniej więcej tak

Listing 5. Kod mapowania XML - Obiekt

package pl.koziolekweb.eowp1;

import java.io.ByteArrayInputStream;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;

import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class TransactionUnmarshaller {

	public static void main(String[] args) throws Exception {
		String transaction1 = "
" + "1"
				+ "OK" + "100"
				+ "101" + "";
		String transaction2 = "
" + "2"
				+ "OK" + "101"
				+ "100" + "";
		String response = "
" + transaction1 + transaction2
				+ "";

		Unmarshaller unmarshaller = new Unmarshaller();
		Collection unmarshallFromStringXml = unmarshaller
				.unmarshallFromStringXml(response);
		System.out.println(unmarshallFromStringXml);
	}

}

class Transaction {
	int id;
	String state;
	long senderId;
	long reciverId;

	@Override
	public String toString() {
		return "Transaction [id=" + id + ", state=" + state + ", senderId="
				+ senderId + ", reciverId=" + reciverId + "]";
	}
}

class Unmarshaller {

	Collection unmarshallFromStringXml(String response)
			throws Exception {
		DocumentBuilder newDocumentBuilder = DocumentBuilderFactory
				.newInstance().newDocumentBuilder();
		Document responseAsXml = newDocumentBuilder
				.parse(new ByteArrayInputStream(response.getBytes()));
		NodeList transactionNodes = responseAsXml
				.getElementsByTagName("transaction");
		int length = transactionNodes.getLength();
		List transactions = new ArrayList(length);
		for (int i = 0; i < length; i++) {
			Node transactinoNode = transactionNodes.item(i);
			Transaction transaction = new Transaction();
			NodeList transactionDataNodes = transactinoNode.getChildNodes();
			for (int j = 0; j < transactionDataNodes.getLength(); j++) {
				Node item = transactionDataNodes.item(j);
				if (item.getNodeName().equalsIgnoreCase("id")) {
					transaction.id = Integer.parseInt(item.getTextContent());
				}
				if (item.getNodeName().equalsIgnoreCase("state")) {
					transaction.state = item.getTextContent();
				}
				if (item.getNodeName().equalsIgnoreCase("senderId")) {
					transaction.senderId = Long
							.parseLong(item.getTextContent());
				}
				if (item.getNodeName().equalsIgnoreCase("reciverId")) {
					transaction.reciverId = Long.parseLong(item
							.getTextContent());
				}
			}
			transactions.add(transaction);
		}
		return transactions;
	}
}

Klasa Unmarshaller to istne pobojowisko. Oczywiście to działa poprawnie i jest nawet szybkie. Tyle tylko, że w czasie testów wyszły nam pewne bugi i poszukiwanie źródła było dość uciążliwe. W pierwszym odruchu refaktoryzacja w duchu zasady Jeff'a Bay'a przebiegła bardzo sprawnie i w jej wyniku otrzymałem coś takiego:

Listing 6. Kod po szybkiej refaktoryzacji

class Unmarshaller {

	Collection unmarshallFromStringXml(String response)
			throws Exception {
		DocumentBuilder newDocumentBuilder = DocumentBuilderFactory
				.newInstance().newDocumentBuilder();
		Document responseAsXml = newDocumentBuilder
				.parse(new ByteArrayInputStream(response.getBytes()));
		NodeList transactionNodes = responseAsXml
				.getElementsByTagName("transaction");
		int length = transactionNodes.getLength();
		List transactions = new ArrayList(length);
		for (int i = 0; i < length; i++) {
			Node transactinoNode = transactionNodes.item(i);
			Transaction transaction = visitTransaction(transactinoNode);
			transactions.add(transaction);
		}
		return transactions;
	}

	private void visitId(Transaction transaction, Node item) {
		if (item.getNodeName().equalsIgnoreCase("id")) {
			transaction.id = Integer.parseInt(item.getTextContent());
		}
	}

	private void visitReciverId(Transaction transaction, Node item) {
		if (item.getNodeName().equalsIgnoreCase("reciverId")) {
			transaction.reciverId = Long.parseLong(item
					.getTextContent());
		}
	}

	private void visitSenderId(Transaction transaction, Node item) {
		if (item.getNodeName().equalsIgnoreCase("senderId")) {
			transaction.senderId = Long
					.parseLong(item.getTextContent());
		}
	}

	private void visitState(Transaction transaction, Node item) {
		if (item.getNodeName().equalsIgnoreCase("state")) {
			transaction.state = item.getTextContent();
		}
	}

	private Transaction visitTransaction(Node transactinoNode) {
		Transaction transaction = new Transaction();
		NodeList transactionDataNodes = transactinoNode.getChildNodes();
		for (int j = 0; j < transactionDataNodes.getLength(); j++) {
			Node item = transactionDataNodes.item(j);
			visitId(transaction, item);
			visitState(transaction, item);
			visitSenderId(transaction, item);
			visitReciverId(transaction, item);
		}
		return transaction;
	}
}

Kod stał się czytelniejszy, a i przetestować było go łatwiej. Jednak dzięki temu uzyskujemy dodatkowy bonus. Otóż widać, że część kodu powtarza się. Można zatem pozbyć się tego powtórzenia do osobnej metody.

Listing 7. Kod po dokładniejszej refaktoryzacji

class Unmarshaller {

	Collection unmarshallFromStringXml(String response)
			throws Exception {
		DocumentBuilder newDocumentBuilder = DocumentBuilderFactory
				.newInstance().newDocumentBuilder();
		Document responseAsXml = newDocumentBuilder
				.parse(new ByteArrayInputStream(response.getBytes()));
		NodeList transactionNodes = responseAsXml
				.getElementsByTagName("transaction");
		int length = transactionNodes.getLength();
		List transactions = new ArrayList(length);
		for (int i = 0; i < length; i++) {
			Node transactinoNode = transactionNodes.item(i);
			Transaction transaction = visitTransaction(transactinoNode);
			transactions.add(transaction);
		}
		return transactions;
	}

	private boolean isNode(Node item, String nodeName) {
		return item.getNodeName().equalsIgnoreCase(nodeName);
	}

	private int toInt(Node item) {
		return Integer.parseInt(item.getTextContent());
	}

	private long toLong(Node item) {
		return Long.parseLong(item.getTextContent());
	}

	private void visitId(Transaction transaction, Node item) {
		if (isNode(item, "id")) {
			transaction.id = toInt(item);
		}
	}

	private void visitReciverId(Transaction transaction, Node item) {
		if (isNode(item, "reciverId")) {
			transaction.reciverId = toLong(item);
		}
	}

	private void visitSenderId(Transaction transaction, Node item) {
		if (isNode(item, "senderId")) {
			transaction.senderId = toLong(item);
		}
	}

	private void visitState(Transaction transaction, Node item) {
		if (isNode(item, "state")) {
			transaction.state = item.getTextContent();
		}
	}

	private Transaction visitTransaction(Node transactinoNode) {
		Transaction transaction = new Transaction();
		NodeList transactionDataNodes = transactinoNode.getChildNodes();
		for (int j = 0; j < transactionDataNodes.getLength(); j++) {
			Node item = transactionDataNodes.item(j);
			visitId(transaction, item);
			visitState(transaction, item);
			visitSenderId(transaction, item);
			visitReciverId(transaction, item);
		}
		return transaction;
	}
}

Jak widać kod stał się jeszcze prostszy. Oczywiście to nie był koniec prac nad nim i tak jak w poprzednim przykładzie jeszcze wrócę do niego przy omawianiu innych zasad. Na teraz jednak wystarczy tej zabawy. Mamy dobry punkt wyjścia do kolejnych prac.

Czas na małe podsumowanie

Zasada jednego poziomu wcięcia na metodę jest bardzo prosta do zastosowania. Nie wymaga dużego nakładu pracy, a efekty są zadowalające i uzyskiwane bardzo szybko.

Zalety

• Prostota - zasada prosta do zachowania. Nie wymaga dużo czasu i nakładu pracy.
• Rozsądna granulacja kodu - po zastosowaniu metody pracują na swoim "poziomie" bez wnikania w niższe i wyższe poziomy. Tak jak w pierwszym przykładzie metody pracujące na wierszu tablicy pracują na wierszu, a pracujące na całej tablicy pracują na całej tablicy. W drugim przykładzie metody pracują na swoim poziomie drzewa XML.
• Łatwe testowanie - jednostki kodu podlegające testowaniu są małe, a dzięki temu łatwe do testowania.
• Łatwe wyszukiwanie powtórzeń - w ramach jednej klasy można bardzo łatwo odnaleźć powtarzający się kod. W przypadku kilku klas też o ile użyjemy odpowiednich narzędzi szukających powtórzeń. Dzięki temu możemy usunąć powtórzenia i tym samym uzyskać jeszcze mniejszy i lepszy kod.
• Łatwe wyszukiwanie drobnych błędów - w czasie refaktoryzacji możemy odnaleźć kod zbędny, wykonujący niepotrzebne operacje czy w końcu tworzony metodą kopiuj wklej.
• Pomaga przestrzegać SRP - jeżeli powstaje dużo drobnych metod to możemy z łatwością stwierdzić, że klasa ma wiele odpowiedzialności i przeciwdziałać już na samym początku.

Wady

• Duża ilość metod - w krótkim czasie otrzymujemy dużo małych metod. Trzeba umieć korzystać z mechanizmów IDE by swobodnie pomiędzy nimi wędrować. Rozwiązanie - część metod można przenieść do nowych klas pomocniczych, gdzie będą testowane i utrzymywane niezależnie od obecnego kontekstu użycia w kodzie.
• Metody o podobnych nazwach - w czasie ekstrakcji metody otrzymują podobne nazwy. Rozwiązanie - jeżeli nazwy dobrze opisują metodę to dobrze. Jeżeli trudno dobrać taka nazwę to może oznaczać, że klasa ma za wiele odpowiedzialności.

Wrażenia i zalecenia

Użycie tej zasady jest proste i dzięki temu można ją stosować na najniższym poziomie. W praktyce tak samo jak puszczenie testów co chwilę tak i tu warto na bieżąco dbać o zachowanie tej zasady. Pozwoli to na szybką lokalizację błędów oraz naruszeń SRP. Wymaga to jednak dobrego opanowania IDE ponieważ dość szybko zamiast Extract Method zaczniemy używać Extract Class, a to już nie jest takie proste. No i najważniejsze. Drobne małe metody są wygodne jeżeli chcemy lokalizować błędy.

Dodaj do