Przejdź do:

1. 1. Języki JVM
2. 2. Kotlin vs Java
3. 3. Co ma Kotlin, czego nie ma Java?
4. 4. Czego nie ma Kotlin, a ma to Java?
5. 5. Zastosowanie języka Kotlin
6. 6. Kotlin Android Development
7. 7. Programuję w Javie – czy warto się przestawić na Kotlin?
8. 8. Czy Kotlin zastąpi Javę?
9. 9. Podsumowanie
10. 10. Skąd czerpać wiedzę?

Języki JVM

„Napisz raz, uruchamiaj wszędzie” – taka idea inspirowała twórców Javy. Aby to osiągnąć, potrzebowali czegoś, co uniezależniałoby kod aplikacji od konkretnej platformy sprzętowej. Stworzyli więc wirtualną maszynę Javy (JVM), która interpretuje kod bajtowy niezależnie od urządzenia, na którym jest zainstalowana. Z czasem powstało więcej języków, które kompilowane są do tego samego kodu pośredniego i mogą być uruchamiane poprzez JVM. Wśród nich pojawiły się między innymi Groovy, Scala oraz Kotlin.

Kotlin vs Java

O Kotlinie często mówi się, że jest następcą Javy. Język ten wprowadza pewne ułatwienia, które sprawiają, że kod jest bardziej zwięzły i przejrzysty. Mechanizmy, które Kotlin oferuje, mogą sprawić, że praca programisty będzie efektywniejsza, a kod bardziej odporny na błędy. Ponadto język ten oferuje interoperacyjność z Javą.  Oznacza to, że mamy możliwość użycia obu języków w tworzonym przez nas projekcie, jak i korzystania z bibliotek i frameworków znanych z Javy.

Chciałbym zwrócić uwagę na niektóre z różnic pomiędzy Javą a Kotlinem.

Co ma Kotlin, czego nie ma Java? – przykłady

Obsługa typów nie pustych (ang. non-nullable types)

W Kotlinie rozróżniane są typy, które mogą przyjmować wartości puste lub nie. Aby zmienna mogła przyjąć wartość „null”, musimy ją oznaczyć, dodając znak „?”, tak jak w poniższym przykładzie.

1.	val a: String? = null

Mechanizm ten pozwala na uniknięcie wielu błędów typu „NullPointerException”, które spowodowane są odwołaniem się do pola nieistniejącego obiektu. Już na poziomie kompilacji programista zostanie poinformowany, że coś jest nie tak.

Istnieje jeszcze operator „!!”, który konwertuje dowolną wartość na typ nieakceptujący wartości pustych. Jeżeli wykorzystamy ten mechanizm, musimy się liczyć z możliwością wystąpienia „NullPointerException”. Ten operator powinien być stosowany bardzo ostrożnie, tylko wtedy, gdy jest się przekonanym, że wartości nie będą puste w momencie ich użycia.

1.   val a: String? = null 

2.   println(a!!.length)    // NullPointerException 

Gdy nie jesteśmy pewni, czy możemy odwołać się do danego pola, z pomocą przychodzi nam operator bezpiecznego wywołania (ang. safe call operator) „?.”, który sprawdza, czy referencja ma wartość pustą bez wyrzucania wyjątku „NullPointerException”.

1.   val a: String? = "Kotlin" 

2.   val b: String? = null 

3.   println(a?.length)  // 6 

4.   println(b?.length) // null 

Java wraz z nadejściem wersji 8 otrzymała mechanizm pozwalający wyrazić potencjalny brak wartości. Dodana została klasa „Optional”, która wzbogaca zmienną, na której pracujemy, o dodatkowe metody pozwalające obsłużyć brak zasobu. Jednakże Kotlin radzi sobie z tym problemem w sposób generalnie bardziej zwięzły. Użycie operatorów wymaga mniej kodu niż odwoływanie się do wartości opakowanej w dodatkową klasę. 

Domniemanie typów

W Kotlinie, inaczej niż w Javie, typ w wielu przypadkach jest określany automatycznie na podstawie kontekstu (możemy pominąć deklarację typu). Ilustruje to poniższy przykład, w którym zmiennej „a” zostanie przydzielony typ „int”.

1.   var a = 1 

2.   a = 5 

Podczas deklaracji zmiennych mamy do dyspozycji dwa słowa kluczowe „var” i „val”. Użycie pierwszego z nich („var”) powoduje to, że wartość będzie mogła zostać zmieniona. Natomiast pole zadeklarowane z „val” nie będzie mogło ulec modyfikacji. Zatem kod:

1.   val a = 1 

2.   a = 5 // błąd 

zostanie potraktowany jako błąd.

Inteligentne rzutowanie (ang. smart casts)

Kompilator Kotlina jest w stanie samodzielnie zapamiętać sprawdzenie typu i odpowiednio rzutować zmienną na dany typ. W ten sposób w większości przypadków można automatycznie używać zmiennych zgodnie z potrzebami, bez konieczności ręcznego wykonywania oczywistych rzutowań.

Przykład:

1.  fun printStringLength(any:Any) { 

2.  if(any is String) { 

3.    println(any.length) 

4.  } 

5. }  

Zmienna „any” jest automatycznie rzutowana na typ String.

Funkcje rozszerzające (ang. extension functions)

Zdarza się, że jakaś klasa (np. z biblioteki) nie posiada metod, które mogłyby być dla nas bardzo przydatne. Funkcje rozszerzające pozwalają w łatwy sposób rozszerzyć daną klasę o nową funkcjonalność. Takie rozwiązanie pozwala nam po prostu na dodanie nowej funkcji do danej klasy. 

Przykład:

1. fun Activity.showToast(message:String){ 

2.   Toast.makeText(this, message, Toast.LENGTH_LONG).show() 

3. }  

Wartości domyślne

Kotlin oferuje także wsparcie dla wartości domyślnych. Definiując funkcję, możemy ustawić domyślny parametr, którego nie trzeba już będzie podawać w wywołaniu funkcji.

1.   fun sayHello(name: String = „World”){ 

2.   	println(„Hello $name”) 

3.   } 

 

1.    sayHello()    // Hello World 

„Data classes”

To klasy, które są tylko kontenerem na dane. Domyślnie implementują metody takie jak equals(), hashCode(), toString(), które w Javie należałoby samodzielnie zaimplementować.

1.   data class User(val name: String, val age: Int)

Brak getterów i setterów

W Kotlinie gettery i settery są generowane automatycznie. Pozwala to na zaoszczędzenie wielu linii kodu i czasu poświęconego na ich pisanie. 

Oczywiście w Javie również powstały narzędzia, które pozwalają zredukować powtarzalny kod. „Lombok” jest biblioteką, która na podstawie adnotacji automatycznie generuje kod w celu ograniczenia tzw. „boilerplate code”.

Czego nie ma Kotlin, a ma to Java?

Typy prymitywne

Podstawowe typy danych takie, jak: boolean, byte, short, int, long, float, double, char. Nie przechowują one obiektów, lecz pojedyncze wartości. A operacje na nich są szybsze niż w przypadku typów złożonych.

„Checked exceptions”

Wyjątki, które muszą być obsłużone przez programistę. Żeby skompilować kod, programista musi „naprawić” błąd wyrzucony przez wywołaną funkcję (użyć instrukcji try…catch…).

Jest to kontrowersyjny koncept. Niektórzy uważają, że nie poprawia to jakości kodu, a zmniejsza produktywność programisty. Narzucenie konieczności obsługi wyjątków czasami skutkuje pustymi blokami „catch”. Obsługa wyjątków np. typu „IOException” w niskopoziomowej metodzie nie zawsze ma sens. Być może lepiej byłoby obsłużyć je gdzieś na wyższym poziomie. Kotlin świadomie nie przyjął tego konceptu.

Słowo kluczowe „static”

Kotlin nie posiada słowa kluczowego „static”. Zamiast tego ma mechanizmy takie jak „companion object”, czy deklarowanie zmiennej/funkcji poza klasą (ang. top-level declaration).

“Companion object” to obiekt typu “singleton”, powiązany z klasą, w której się znajduje, i zawierający pola i metody, do których możemy się odwołać w ten sam sposób co do elementów statycznych w Javie.

1.   class MyClass { 

2.       companion object Factory { 

3.           fun create(): MyClass = MyClass() 

4.       } 

5.   } 

 

1.   val myClass = MyClass.create() 

Zastosowanie języka Kotlin

Odkąd w 2019 r. Google ogłosiło Kotlin rekomendowanym językiem dla aplikacji na ich system operacyjny na urządzenia mobilne, może być on przez wielu developerów kojarzony głównie z Androidem. Jednak warto pamiętać, że to niejedyne zastosowanie Kotlina.

Język ten sprawdza się też w przypadku tworzenia aplikacji serwerowych czy desktopowych. Ogólnie rzecz ujmując, sprawdzi się wszędzie tam, gdzie może być używana Java (z ciekawostek – Kotlin został wykorzystany przy tworzeniu zintegrowanego środowiska developerskiego IntelliJ IDEA)

Projekt Kotlin Multiplatform

Warto wspomnieć też o tym, że rozwijany jest projekt o nazwie „Kotlin Multiplatform”. Dzięki niemu możliwe jest pisanie wspólnego kodu logiki biznesowej aplikacji, która będzie działać na wielu platformach, takich jak między innymi Android, iOS, Windows, Linux, macOS oraz jako aplikacja webowa. 

Kotlin Android Development

Kotlin zyskał ogromną popularność dzięki Androidowi. Obecnie większość nowych aplikacji na tę platformę powstaje właśnie w tym języku. Jedne z najbardziej znanych aplikacji na Androida stworzonych z użyciem Kotlina to: Slack, Trello, Evernote, Pinterest, Tinder czy Uber.

Także nowe narzędzia dla Android developerów, takie jak np. Jetpack Compose, wykorzystują cechy Kotlina i wymagają jego użycia. W wielu nowo powstających tutorialach przykładowy kod często jest również zaprezentowany w tym właśnie języku.

Programuję w Javie – czy warto się przestawić na Kotlin?

Niełatwo jest porównywać języki programowania, ponieważ każdy ma swoje wady i zalety. Zarówno Kotlin, jak i Java ciągle są rozwijane i oferują coraz to nowsze mechanizmy. Java jest z nami od 1991 roku i od wielu lat znajduje się w czołówce najpopularniejszych języków programowania na świecie. Przez ten czas powstało wiele projektów. Czy warto więc się przestawić? To zależy.

Czy Kotlin zastąpi Javę?

Choć dla tysięcy programistów na świecie królowa jest tylko jedna, wiele argumentów wskazuje na to, że Kotlin to godny następca Javy. Najważniejsze z nich to:

• Czytelniejszy kod
• Odporność na błędy typu „NullPointerException”
• Mechanizmy wspierające programowanie funkcyjne czy narzędzia (takie jak np. Jetpack Compose dla Androida)

Podsumowanie

Moim zdaniem, rozpoczynając nowy projekt, warto się przestawić na język stworzony przez firmę JetBrains. Pozostaje jednak jeszcze pytanie, co z istniejącymi projektami napisanymi w Javie? Czy warto je migrować do Kotlina? Kotlin został zaprojektowany tak, żeby zachować pełną kompatybilność z Javą. Migracja może więc następować w sposób stopniowy. W bazie kodu mogą być dwa języki. Wiele firm wykorzystuje ten fakt i przekształca swoje aplikacje, aby mogły być one dalej rozwijane z wykorzystaniem zalet Kotlina. Jednakże dwa języki w kodzie mogą powodować pewne zamieszanie. Warto więc, jak zawsze, zachować szerszy kontekst i dopasować język indywidualnie do potrzeb i specyfiki projektu.

Kotlin – skąd czerpać wiedzę?

Strony internetowe

• Oficjalna strona Kotlina – https://kotlinlang.org/
• https://www.w3schools.com/kotlin/index.php
• Kotlin Academy – https://blog.kotlin-academy.com/

Książki:

• „Kotlin w Akcji” – Dmitry Jemerov, Svetlana Isakova

Materiały dla programistów Android: 

• https://proandroiddev.com/
• https://developer.android.com/kotlin

Kanały na YouTube:

• https://www.youtube.com/c/AndroidDevelopers
• https://www.youtube.com/stevdza_san

Przejdź do:

1. 1. Czym jest Pair Programming
2. 2. Korzyści programowania w parach
3. 3. Programowanie w parach – techniki
4. 4. Czy to faktycznie działa?
5. 5. Pair Programming online
6. 6. Podsumowanie

Czym jest Pair Programming

Pair Programming ewoluował przez dekady, zyskał jednak na popularności dzięki metodologii Extreme Programming (XP), która została sformalizowana przez Kenta Becka w książce „Extreme Programming Explained: Embrace Change”. Istnieje kilka technik programowania w parach, a każda
z nich charakteryzuje się innymi założeniami. Uogólniając, całość polega na współpracy dwóch programistów, współdzielących jedną stację roboczą, którzy razem pracują nad rozwiązaniem danego problemu programistycznego. Programista aktualnie piszący kod to tzw. driver, drugi to navigator, zwany również obserwatorem – on także aktywnie uczestniczy w procesie twórczym, jednak skupia się bardziej na ogólnym kierunku oraz na ciągłej weryfikacji kodu napisanego przez „kierowcę”.

Korzyści programowania w parach

Z moich obserwacji wynika, że programiści pracujący w parach wzajemnie wywierają na siebie pewnego rodzaju presję. Zdają sobie oni sprawę, jak cenny jest czas ich partnerów, przez co chcą go maksymalnie wydajnie wykorzystać. W zależności od zastosowanej techniki (opowiem o nich w dalszej części artykułu) korzyści programowania w parach mogą być następujące:

• lepsza jakość kodu, przy czym istotne jest, aby osoba pisząca aktualnie kod formułowała swoje myśli na głos – często pozwala to rozwiązać dany problem, nawet bez znacznej ingerencji drugiej strony,
• łatwiejsze dzielenie się wiedzą domenową między członkami zespołu,
• szybszy rozwój mniej doświadczonych programistów dzięki parowaniu ich z tymi bardziej doświadczonymi,
• potencjalnie większa odporność na zewnętrzne zakłócenia – jedna osoba z pary zawsze może pozostawać skupiona na zadaniu, podczas gdy druga może np. uczestniczyć w zewnętrznej dyskusji z pozostałymi członkami zespołu.

Należy jednak pamiętać, że programowanie w parach jest trudne, bywa wyczerpujące, wymaga samodyscypliny i pokory, a także umiejętności udzielania i dawania feedbacku. Często już sama świadomość, że ktoś przez część dnia będzie nam zaglądał przez ramię i oceniał to, co robimy, może zdezorganizować wewnętrzny spokój. No bo kto nie lubi czasem założyć słuchawek, odciąć się od otoczenia i zanurzyć w jakimś ciekawym problemie?

Programowanie w parach – techniki

Dobre praktyki

Zanim opiszę poszczególne techniki programowania w parach, rzecz najistotniejsza, niezależna od stosowanej techniki: chodzi o robienie przerw oraz oraz nieprzeznaczanie na programowanie w parach zbyt dużo czasu w ciągu dnia – celem jest tu utrzymanie wydajności. Zaczynając od krótkich sesji (1-2 godz.), z czasem można zwiększać liczbę godzin poświęconych na Pair Programming, jednak według mnie dobrze jest nigdy nie przekraczać 5-6 godz. Jak wspomniałem wcześniej, do wyboru mamy kilka technik, każda z nich ma swoje wady i zalety. Daną technikę należy dobierać do konkretnej sytuacji. Proces programowania w parach będzie wyglądał inaczej, jeżeli planujemy przekazać wiedzę lub przeprowadzić onboarding nowej osoby w zespole, a inaczej, jeżeli chcemy zaimplementować jakąś skomplikowaną funkcjonalność. Poniżej opiszę te, z którymi ja się spotkałem i które – według mnie – powinny znaleźć się w arsenale każdego szanującego się programisty.

Backseat navigator

Prawdopodobnie najpopularniejsza metoda, stosowana zazwyczaj instynktownie. Jest wykorzystywana w sytuacji, gdy rozwiązując jakiś problem, doszliśmy do ściany. Bywa, że tak bardzo skupiamy się na znalezieniu rozwiązania, że nie widzimy alternatywnych możliwości, dochodzimy do ślepej uliczki i koniec. W takim wypadku prosimy innego programistę o wsparcie – taka osoba będzie zdolna spojrzeć na naszą zagwozdkę z innej perspektywy. Z drugiej strony, wariant ten jest idealny dla mniej doświadczonych programistów pod kątem nauki nowych umiejętności. Mamy wtedy do czynienia z relacją nowicjusz – ekspert. Jedna strona pisze kod (nowicjusz), druga natomiast pełni rolę wsparcia / mentora (ekspert).

Driver-navigator

Klasyczny Pair Programming, zderzenie dwóch różnych perspektyw na kod. „Kierowca” (ang. driver) zajmuje się pisaniem kodu, skupia się na detalach implementacyjnych, nawigator (ang. navigator) natomiast myśli o rozwiązaniu bardziej ogólnie, jest partnerem do dyskusji, decyduje o kierunku, wychwytuje braki w implementacji oraz przypadkach testowych (real-time code review). Według mnie technika ta jest idealna do rozwiązywania złożonych problemów, gdzie mnogość reguł biznesowych znacząco wydłużyłaby samodzielne próby rozwiązania problemu.

Ping-pong

Bywa, że od początku znamy kierunek, w którym powinniśmy pójść, a dany problem nie jest dla nas wyzwaniem. Takie arcynudne zadania również wymagają od nas profesjonalnego podejścia. Jeżeli TDD (Test-Driven Development) nie jest nam obce, to ta technika sprawdzi się idealnie. Całość polega na naprzemiennym pisaniu testów oraz implementacji. Ping – pierwszy programista pisze nieprzechodzący test, pong – drugi programista pisze implementację, sprawiając, że test zaczyna przechodzić. Po tym następuje faza refaktoryzacji i cały proces rozpoczyna się od nowa.

Czy to faktycznie działa?

Teoria teorią, ale czy Pair Programming faktycznie jest tak wyjątkowy i zawsze da nam oczekiwane efekty?

Jak zwykle, to zależy. Osobiście miałem okazję stosować głównie dwie pierwsze techniki, niestety – rzadziej, niż bym chciał. Spowodowane jest to faktem, że w świecie IT mamy wokół siebie wielu ludzi, często świetnych specjalistów, jednak różnica charakterów jest czynnikiem, który znacząco ogranicza powodzenie wspólnego programowania.

Trzeba pamiętać, że przynoszący rezultaty Pair Programming to przede wszystkim budowanie relacji
z członkami zespołu oraz przełamywanie wszelkich barier komunikacyjnych. Poniżej przedstawię kilka wniosków z mojej przygody z Pair Programming, które według mnie poprawiają efektywność całego procesu:

• dobrze jest określić cel sesji, który będzie można zweryfikować po jej zakończeniu,
• innym ważnym aspektem jest ustalenie przerw oraz częstotliwość zmian,
• jeżeli rozwiązujemy jakiś skomplikowany problem, pierwsza w rolę nawigatora niech wcieli się osoba z większą wiedzą domenową. W przypadku zadania typowo technicznego, niech to będzie osoba z większym doświadczeniem / umiejętnościami,
• będąc w roli drivera, komunikujmy na głos wszystko, co robimy – niejednokrotnie samo mówienie na głos o danym problemie pozwoliło mi znaleźć rozwiązanie.

Te rzeczy sprawdziły się u mnie, jednak zdecydowanie jestem daleki od twierdzenia, że takie podejście jest idealne. Moja sugestia jest taka, aby po prostu zacząć, wyciągać wnioski i próbować usprawniać cały proces tak, aby czuć się komfortowo i czerpać z tego satysfakcję.

Pair Programming online

Pytanie, które pojawia się często w kontekście zdalnego programowanie w parach, brzmi: czy to w ogóle ma sens?

Odpowiedź brzmi: zdecydowanie tak. O ile nasz zespół nie pracuje w sposób asynchroniczny, to według mnie zdalny Pair Programming nie różni się w zasadzie niczym od tego standardowego, przeprowadzanego w biurze. Co więcej, w dzisiejszych czasach, kiedy wszyscy przenieśliśmy się z biur do domów, może nieść za sobą ogrom korzyści, wymusza bowiem kontakt z innymi członkami zespołu, który z reguły jest bardziej naturalny w środowisku biurowym – rozmawiamy w pokoju, na korytarzu czy w kuchni. Jeżeli chodzi o narzędzia, istnieje ich wiele i tak naprawdę to, które wybierzemy, zależy od osobistych preferencji. Jednym wystarczy Google Meet, Skype czy jakiekolwiek inne narzędzie z opcją udostępniania ekranu, inni natomiast, chcąc ze zdalnego programowania w parach wyciągnąć jak najwięcej, skorzystają w tym celu z dedykowanego narzędzia. W zależności od preferowanego edytora kodu będą to Floobits, Saros, Live Share czy Teamhub.

Podsumowanie

Niestety, pomimo tego, że większość osób zajmujących się zawodowo programowaniem słyszała o programowaniu w parach, to ciągle można zauważyć, że jest ono traktowane po macoszemu. Moim zdaniem wynika to poniekąd z faktu, że korzyści z jego stosowania nie zawsze są widoczne od razu. Jest to umiejętność, która wymaga systematycznego stosowania, dlatego warto regularnie poświęcać jej część czasu przeznaczonego na kodowanie. Po zakończonej sesji wskazane jest spisać to, co poszło dobrze, a co nie zadziałało, dać sobie nawzajem feedback, tak aby kolejne sesje były lepsze od poprzednich.

Przejdź do:

1. 1. Czym jest Pact Consumer Driven Contract Testing
2. 2. Czym jest Spring WebFlux
3. 3. Pact i WebFlux – jak to działa razem
4. 4. Podsumowanie
5. 5. Źródła

Czym jest Pact Consumer Driven Contract Testing

Consumer Driven Contract Testing to wzorzec wykorzystywany w testowaniu kompatybilności pomiędzy konsumentami (consumer) i dostawcami (provider) serwisów. Ogólna idea jest taka, że pomiędzy tymi dwoma systemami istnieje kontrakt opisujący zachodzące między nimi interakcje. Jeżeli obydwa systemy wypełniają jego założenia, test kończy się powodzeniem. Podejście „Consumer driven” oznacza, że siłą napędową ewolucji kontraktu są konsumenci serwisu, a nie dostawca.

Wsparciem dla Consumer Contract Testing jest zestaw frameworków DiUS Pact. Frameworki te koncentrują się głównie na komunikacji HTTP, choć dla niektórych platform dostępne jest również wsparcie dla kolejek. Obecnie implementacje pokrywają większość popularnych środowisk uruchomieniowych, takich jak JVM, .NET, JavaScript czy Ruby.

Czym jest Spring WebFlux

Spring WebFlux to reaktywny framework webowy wprowadzony w Springu 5. Jest to odpowiednik dobrze znanego Spring MVC, z tą różnicą, że opiera się na nieblokującym API dostarczanym przez reactive streams. WebFlux jest w stanie obsługiwać duże obciążenia na małej liczbie wątków, co skutkuje mniejszym zużyciem zasobów sprzętowych.

WebFlux oferuje dwa modele programowania:

• adnotowane kontrolery
• endpointy funkcyjne

Pact obsługuje oba modele, natomiast dla potrzeb tego artykułu skupię się na endpointach funkcyjnych.

Pact i WebFlux – jak to działa razem

Ponieważ to na kliencie spoczywa odpowiedzialność za dostarczanie kontraktu, testy Pact pisane są najpierw dla niego. Każdy z testów zawiera opis interakcji pomiędzy klientem i dostawcą, np. requesty i spodziewane odpowiedzi HTTP. Mając te dane, pact framework uruchomi tymczasowy serwer HTTP zwracający predefiniowane odpowiedzi i wykona testy klienta.

Niejako efektem ubocznym wykonania testu jest utworzenie pliku kontraktu. Ten sam plik zostanie później użyty do sprawdzenia, czy dostawca serwisu spełnia założenia kontraktu. Po stronie serwera Pact wykona testy, używając requestów zapisanych w kontrakcie i zweryfikuje poprawność odpowiedzi. Możemy tutaj dokonać wyboru, czy chcemy przetestować serwis jako całość, czy tylko jego wycinek odpowiedzialny za komunikację HTTP. W tym artykule opiszę ten drugi przypadek.

Test dla klienta

Załóżmy, że dostawca udostępnia endpoint HTTP. Odpowiada on na żądania HTTP GET, zwracając JSONa reprezentującego kolekcję obiektów Foo. Użyjmy frameworka Spock do zakodowania pact-testu klienta.

Najpierw zdefiniujmy pakt w sekcji given naszego testu. Wykorzystajmy do tego celu klasę ConsumerPactBuilder, którą udostępnia biblioteka Pact:

given:
def pact = ConsumerPactBuilder.consumer("consumerService")
    .hasPactWith("providerService")
    .uponReceiving("sample request")
    .method("GET")
    .path("/foo")
    .willRespondWith()
    .status(200)
    .headers(["Content-Type": "application/json"])
    .body("""
            [
                {"id": 1, "name": "Foo"},
                {"id": 2, "name": "Bar"}
            ]
        """.stripIndent())
    .toPact()

Widzimy tutaj, że  kontakt definiuje interakcje nazwaną sample request pomiędzy klientem o nazwie consumerService i dostawcą providerService. W reakcji na żądanie będące wywołaniem metody HTTP GET na ścieżce /foo, dostawca powinien odpowiedzieć statusem HTTP 200, a w sekcji body odpowiedzi powinny być dostarczone reprezentacje dwóch obiektów Foo.

Zakodujmy teraz część z asercjami oraz wywołaniem naszego klienta w sekcji when:

when:
def result = ConsumerPactRunnerKt.runConsumerTest(
    pact, MockProviderConfig.createDefault()) { mockServer, context ->

    def webClient = WebClient.create(mockServer.getUrl())
    def consumerAdapter = new ConsumerAdapter(webClient)

    def resultFlux = consumerAdapter.invokeProvider()

    StepVerifier.create(resultFlux)
        .expectNext(new Foo(1l, 'Foo'))
        .expectNext(new Foo(2l, 'Bar'))
        .verifyComplete()
}

Do wykonania testu klienta użyjemy klasy ConsumerPactRunnerKt dostarczanej przez bibliotekę Pact. Metoda runConsumerTest, przed wykonaniem kodu z domknięcia, uruchomi tymczasowy serwer, który będzie odpowiadać na żądania HTTP zdefiniowane wcześniej w pakcie. Zapisze również kontrakt w postaci pliku JSON, który będzie współdzielony z dostawcą usługi. Ostatnim z parametrów tej metody będzie blok kodu zawierający wywołanie napisanego przez nas klienta serwisu. W tym przypadku utworzymy reaktywnego webClienta i przekażemy mu URL utworzonego przez Pact serwera HTTP. Następnie stworzymy instancję naszego adaptera (ConsumerAdapter), na której wywołamy metodę invokeProvider() odpowiedzialną za interakcję HTTP z dostawcą. Ponieważ wynikiem tej interakcji będzie Flux do zbadania jej poprawności, możemy użyć StepVerifiera z projektu Reactor.

Ostatnią fazą będzie sprawdzenie w sekcji then, czy weryfikacja kontraktu się powiodła:

then:
result instanceof PactVerificationResult.Ok

To właśnie tutaj możemy sprawdzić, czy StepVerifier nie wygenerował wyjątku (będzie on owinięty w klasie PactVerificationResult.Error) lub jakaś opisana w kontakcie interakcja nie została wywołana lub była z nim niezgodna.

Napiszmy teraz kod przykładowego klienta wykorzystywanego w teście. Będzie to standardowy przypadek użycia reaktywnego webClienta do odczytu danych z endpointu /foo:

public Flux<Foo> invokeProvider() { 
    return webClient 
            .get() 
            .uri("/foo") 
            .accept(MediaType.APPLICATION_JSON) 
            .retrieve() 
            .bodyToFlux(Foo.class); 
}

Jesteśmy teraz gotowi do wykonania testu. Uruchomi on dostarczany przez framework serwer HTTP – wywoła go, używając należącej do klienta klasy adaptera, a następnie zweryfikuje odpowiedzi. Dodatkowo Pact utworzy w katalogu build/pacts plik JSON będący reprezentacją paktu. Plik ten należy następnie udostępnić testom kontraktu providera serwisu.

Test dla dostawcy

Ponieważ mamy już gotowy plik kontraktu, test dla providera serwisu będzie nieco bardziej zwięzły. Tym razem użyjemy frameworku JUnit, ponieważ Spockowy wzorzec given – when – then nie byłby tutaj zbyt pomocny:

@RunWith(RestPactRunner.class) 
@Provider("providerService") 
@PactFolder("pacts") 
public class ProviderRouterPactTest { 
 
    @TestTarget 
    public WebFluxTarget target = new WebFluxTarget(); 
 
    private ProviderHandler handler = new ProviderHandler(); 
    private RouterFunction<ServerResponse> routerFunction 
            = new ProviderRouter(handler).routes(); 
 
    @Before 
    public void setup() { 
        target.setRouterFunction(routerFunction); 
    } 
}

Jak możemy zauważyć, kod nie zawiera żadnych metod testowych. Dzieje się tak dlatego, że testowane wywołania i asercje są już obecne w pliku kontraktu. RestPactRunner (wskazany w adnotacji @RunWith) użyje tego pliku i zajmie się wykonaniem przypadków testowych w nim opisanych oraz weryfikacją odpowiedzi. Musimy jeszcze poinformować runnera o lokalizacji kontraktów (w tym przypadku poprzez adnotację @PactFolder wskazujemy katalog na dysku) i nazwie dostawcy (za pomocą adnotacji @Provider). Nazwa ta jest o tyle istotna, że silnik Pactu będzie wybierać kontrakty do przetestowania, porównując ją z nazwą podaną w teście klienta jako .hasPactWith(„providerService”). Adnotacja @TestTarget jest odpowiedzialna za wskazanie celu do testowania. Dla endpointów WebFluxowych będzie to instancja WebFluxTarget. Należy w niej ustawić już bezpośrednio routerFunction, której używamy w kodzie dostawcy. Wygodnym miejscem do zrobienia tego jest tutaj metoda setup() testu.

Należy jeszcze wspomnieć o klasach ProviderHandler oraz ProviderRouter. Są to elementy implementacji przykładowego dostawcy. Router jest odpowiedzialny za budowanie instancji RouterFunction, które wiążą ścieżki URL z kodem handlera:

@Configuration 
@RequiredArgsConstructor 
@FieldDefaults(level = AccessLevel.PRIVATE, makeFinal = true) 
class ProviderRouter { 
 
    ProviderHandler handler; 
 
    @Bean 
    RouterFunction<ServerResponse> routes() { 
        return route() 
                .GET("/foo", accept(APPLICATION_JSON), handler::getFoo) 
                .build(); 
    } 
 
}

Natomiast metoda handler::getFoo z powyższego przykładu jest odpowiedzialna za zwracanie Mono zawierającego odpowiedź dostawcy:

Mono<ServerResponse> getFoo(ServerRequest request) { 
    return ServerResponse 
            .ok() 
            .contentType(APPLICATION_JSON) 
            .body(Flux.just( 
                    new Foo(1l, "Foo"), 
                    new Foo(2l, "Bar") 
            ), Foo.class); 
}

Handler zwraca tutaj dwa obiekty Foo tak jak jest to określone w kontakcie między dostawcą a klientem.

Uruchomienie testu dla dostawcy będzie teraz skutkować wczytaniem pliku kontraktu, dopasowaniem odpowiedniego dla ścieżki HTTP handlera, wywołaniem go i weryfikacją, czy odpowiedź systemu jest zgodna z tą określoną w kontrakcie.

Podsumowanie

Pact Consumer Driven Contracts to bardzo przydatne narzędzie do zapewniania spójności pomiędzy elementami złożonego systemu. Z pewnością jego zaletą jest szeroki wachlarz wspieranych technologii, który pozwala na testowanie oparte na kontraktach w heterogenicznym środowisku. Teraz do tego spektrum dołączył kolejny element – technologia Spring WebFlux, dzięki czemu zyskaliśmy możliwość wykonywania testów względem reaktywnych dostawców.

Kod źródłowy przykładów użytych w tym artykule jest dostępny w repozytorium Githuba.

Źródła

• Strona Github Pact JVM
• Dokumentacja Spring WebFlux
• „Consumer-Driven Contracts: A Service Evolution Pattern”, Ian Robinson
• Przykład integracji Pact – WebFlux na Githubie

Przejdź do:

1. 1. Wstęp
2. 2. Reguły pani Barbary Liskov
3. 3. Czysta abstrakcja
4. 4. Wada tego podejścia
5. 5. Kompozytor wyjeżdża w delegację
6. 6. Wady kompozycji
7. 7. Kaczki, a kacze typowanie
8. 8. Lombok na ratunek
9. 9. Czas na podsumowanie

Wstęp

Programując w Javie (a właściwie w każdym języku zorientowanym obiektowo), co chwilę korzystamy z dobrodziejstw tego, co oferuje nam programowanie obiektowe: klasy, interfejsy, polimorfizm, dziedziczenie. I można by tak jeszcze długo wymieniać. Szczególnie ta ostatnia opcja (dziedziczenie) pozwala nam w łatwy sposób opisać wiele podobnych do siebie bytów w prosty sposób – tę część, która jest dla nich wspólna, deklarujemy tylko raz w klasie nadrzędnej; natomiast część zmienną umieszczamy w kodzie klas podrzędnych po niej dziedziczących.

Okazuje się jednak, iż zarówno w życiu codziennym (spadek z długami po dalekim krewnym, o którym nawet nie mieliśmy pojęcia!), jak i w programowaniu, dziedziczenie może nam przysporzyć wielu niespodziewanych trudności. Na czym polega problem? Aby to wyjaśnić, posłużymy się na początek rysunkiem odnoszącym się do zasady, o której będziemy mówić w dalszej części artykułu. Następnie zmienimy rysunek w prostą aplikację złożoną z kilku klas. Spójrzmy na dwa poniższe rodzaje kaczek:

A teraz spróbujmy zapisać powyższy obrazek za pomocą klas Javy. Teoretycznie powinny nam do tego wystarczyć dwie klasy – jedna reprezentująca żywą kaczkę, a druga kaczkę elektryczną. Żywa kaczka potrafi pływać i kwakać:

Natomiast kaczka elektryczna zachowuje się tak jak żywa (i dlatego po niej dziedziczy)… O ile oczywiście ktoś pamiętał i włożył do niej baterie! W przeciwnym razie reaguje niespodziewanymi wyjątkami.

Teraz (ponieważ jesteśmy w XXI wieku) zamiast tworzyć klasę z metodą main, napiszmy test, który sprawdzi poprawność działania klasy Duck:

Stworzony test celowo sparametryzowaliśmy tak, aby dało się przekazać do niego różne obiekty klasy Duck. Skoro bowiem przyjęliśmy, iż klasa Electric Duck dziedziczy po klasie Duck, to przekazanie do testu obiektu tej klasy nie powinno niczego zepsuć. Tymczasem czeka nas bardzo nieprzyjemna niespodzianka:

Wygląda na to, że obiekt klasy ElectricDuck zachowuje się niestety inaczej niż obiekt klasy Duck. To bardzo niedobrze, gdyż w innej części systemu możemy mieć metody, które przyjmują obiekt kaczki i jeżeli przekażemy w takim miejscu kaczkę elektryczną (a możemy to zrobić, gdyż kaczka elektryczna dziedziczy po żywej), to system zachowa się w sposób nieprzewidziany! W takiej sytuacji pierwsze rozwiązanie, jakie przychodzi nam do głowy, to sprawdzenie, jaki typ kaczki otrzymaliśmy w rzeczywistości:

Jednakże takie podejście:

• po pierwsze – tak naprawdę nie pozwala nam skorzystać z zalet polimorfizmu
• po drugie – powoduje, że z każdym kolejnym typem kaczki nasz kod brzydko się rozrasta o nowy if

Wygląda na to, że sytuacja, do której doprowadziliśmy, ewidentnie złamała jakąś regułę programowania obiektowego. Nietrudno domyślić się, że chodzi tu o jedną z zasad SOLID, a konkretnie o odpowiadającą literze L – zasadę podstawienia Liskov. Zapoznajmy się z nią bliżej.

Reguły pani Barbary Liskov

Nazwa tej zasady pochodzi od nazwiska bardzo zasłużonej dla informatyki pani profesor Barbary Liskov [1]. Sama definicja zasady podstawienia Liskov jest dość prosta [2]:

Funkcje, które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.

Powyższe zdanie nie wygląda ani na zbyt skomplikowane, ani na trudne do wykorzystania w praktyce. Okazuje się jednak, że już w bardzo prostym przypadku mamy problem z powyższą regułą. Dlaczego? Odpowiedź tkwi w warunkach, które muszą być spełnione przez podklasę w stosunku do nadklasy, aby ta reguła była faktycznie spełniona. A oto one [3]:

• Typ zwracany przez metodę w podklasie musi być taki sam jak w klasie bazowej albo być jego podtypem
• Typy argumentów przekazywane do metody w podklasie muszą być takie same jak w klasie bazowej – albo być ich nadtypem
• Metoda podklasy może rzucać wyjątek tylko wtedy, jeśli czyni to metoda w klasie bazowej. Typ wyjątku musi być taki sam jak w klasie bazowej albo musi być jego podtypem
• Warunki wejściowe metody w podklasie nie mogą być silniejsze niż warunki wejściowe w klasie bazowej
• Warunki wyjściowe metody w podklasie nie mogą być słabsze niż warunki wyjściowe w klasie bazowej
• Metoda w podklasie nie może niszczyć niezmienników klasy bazowej

O ile spełnienie trzech pierwszych warunków skontroluje za nas kompilator Javy (w przypadku drugiego warunku nawet nadmiarowo – do metody w podklasie można przekazać tylko ten sam typ argumentu, a nie nadtyp), o tyle niestety o spełnienie pozostałych warunków musimy już zadbać sami. Tu pojawia się relatywnie wysokie ryzyko popełnienia błędu. Nietrudno domyśleć się, że w naszym konkretnym przypadku złamaliśmy czwarty warunek, ponieważ w klasie Duck metoda getVoice() nie posiada żadnych warunków wejściowych – można ją wywołać w dowolnym momencie.

Natomiast w klasie Electric Duck nie jest to już niestety prawda – metoda nie wyrzuci wyjątku tylko wtedy, gdy wcześniej wywołamy metodę insertBatteries(). O czym kod korzystający z takiego obiektu może nawet „nie wiedzieć”, gdyż taka metoda nie występuje w ogóle w klasie Duck!

Jak widać, ze względu na łatwą możliwość złamania reguł, poprawne dziedziczenie w Javie wcale nie jest proste do przeprowadzenia. Co gorsza, kompilator nie zawsze wykryje, że miało to miejsce, a to skazuje nas na weryfikację kodu w sposób ręczny (a więc – zawodny). Jakie mamy wobec tego możliwości rozwiązania problemu?

Czysta abstrakcja

Pierwszą metodą, jaką moglibyśmy zastosować, jest modyfikacja istniejącej hierarchii klas tak, aby klasy reprezentujące konkretne byty (w naszym przypadku żywa kaczka i kaczka elektryczna) dziedziczyły po klasie abstrakcyjnej, do której przenosimy maksymalnie wiele wspólnego kodu. Ktoś może zapytać: „Co to właściwie daje, skoro dalej zostajemy przy dziedziczeniu, a kaczka elektryczna dalej będzie zachowywać się inaczej niż żywa?”. Otóż cały haczyk tego rozwiązania polega na tym, iż nie będzie można powiedzieć, że klasa dziedzicząca „psuje” zachowanie klasy bazowej, gdyż obiekty klasy bazowej… po prostu nie będą istniały (wszak jest abstrakcyjna)! A skoro nie będą istniały – to i nie będzie czego zepsuć.

Proste – czyż nie? Oczywiście puryści programowania obiektowego zapewne stwierdzą, że takie tłumaczenie jest mocno naciągane… Ale to nie matematyka – tu nie ma jednego słusznego rozwiązania. Można mieć raczej zastrzeżenia co do innych wad tego podejścia – ale o nich opowiemy później. Pokażmy zatem nasz kod w akcji! Zacznijmy od klasy abstrakcyjnej, do której przeniesiemy wspólny kod. Nazwiemy ją w sposób mało wysublimowany – Base Duck. Po tej klasie będą dziedziczyć klasy reprezentujące żywe kaczki:

Klasa reprezentująca żywą kaczkę w tej sytuacji staje się praktycznie pusta (gdyż funkcjonalność przeszła do klasy abstrakcyjnej) – wygląda jak wydmuszka:

Klasa odpowiedzialna za kaczkę elektryczną zmienia się nieco mniej, ale i w niej będą odwołania do klasy abstrakcyjnej:

Nieco zmieniają się również testy do klasy Duck. Ponieważ klasa ElectricDuck nie dziedziczy już po tej klasie, nie możemy już przetestować jej zachowania w tym miejscu:

W związku z powyższym klasę ElectricDuck musimy przetestować oddzielnie:

Może pojawić się w tym miejscu wątpliwość: „Czy nie jest błędem, że tak naprawdę zwiększyła się nam ilość kodu w testach?”. Wbrew pozorom, nie powinno nas to niepokoić. Duża ilość kodu testowego (jeżeli tylko napisanego czysto), nie jest uważana za błąd, a w niektórych metodykach (np. TDD) – jest to normalne zjawisko. Jak widać, rozwiązanie z klasą abstrakcyjną nie wydaje się być zbytnio skomplikowane oraz nie wymaga dużych zmian w kodzie. W wielu przypadkach to wystarcza.

Wada tego podejścia

Sygnalizowałem wcześniej, że to rozwiązanie ma wady. Otóż każda klasa reprezentująca w naszej hierarchii konkretny byt ma narzucone z góry, iż musi dziedziczyć po klasie abstrakcyjnej. To zamyka możliwość dziedziczenia po czymkolwiek innym (Java nie posiada dziedziczenia wielobazowego). Możemy boleśnie odczuć skutki na własnej skórze w momencie, gdy takie dziedziczenie będzie nam potrzebne przy integracji z jakimś frameworkiem lub biblioteką. Jest na to jednak sposób – o tym, jak poradzić sobie w sytuacji, gdy nie możemy sobie pozwolić na zablokowanie dziedziczenia dla naszych klas, napiszę w kolejnej części artykułu.

Kompozytor wyjeżdża w delegację

Tak jak wspominałem na początku, dziedziczenie często stosujemy po to, aby uniknąć wielokrotnego pisania kodu. Kod staje się składową klasy bazowej, a klasy dziedziczące mogą dzięki temu również z niego skorzystać. Okazuje się jednak, że podobny efekt można osiągnąć poprzez ekstrakcję wspólnego kodu do oddzielnego obiektu, a następnie uczynienie tego obiektu składnikiem klasy. W efekcie można powiedzieć, że klasa nie dziedziczy jakiejś funkcjonalności, ale ta funkcjonalność jest w nią wkomponowana. Bardziej szczegółowo można takie podejście podzielić na dwa nurty: agregację i kompozycję [4].

My w dalszej części artykułu będziemy używać sformułowania „kompozycja”, aczkolwiek może być ono nie do końca ścisłe. Dodatkowo wkomponowany obiekt będziemy od tej pory nazywać „delegatem” – bo tak naprawdę delegujemy do niego odpowiedzialność za wykonanie części zadań naszej klasy. Tego typu podejście nazywane jest często kompozycją ponad dziedziczeniem [5]. W jaki sposób zrealizowalibyśmy to w przypadku naszych kaczek? Przede wszystkim należałoby stworzyć nasz obiekt – delegata:

Zauważmy, że zawiera on mniej więcej to samo, co mamy w klasie abstrakcyjnej BaseDuck. Nic w tym dziwnego – w końcu delegat ma tę klasę zastąpić. A skoro tak – to w takim razie usuwamy ją, gdyż nie jest już nam potrzebna. Po usunięciu klasy abstrakcyjnej musimy zmodyfikować klasę Duck. Niezbędne jest dodanie metod, które dotychczas były zdefiniowane w klasie abstrakcyjnej, oraz ich implementacja z użyciem delegata:

I podobnie robimy w klasie ElectricDuck:

I to na razie wszystko! Jeśli uruchomimy nasze testy, to dalej powinny działać. Potrzebna będzie tylko jedna zmiana – klasy, z której wykonujemy statyczne importy.

Nietrudno zauważyć, iż kompozycja ma wiele zalet w porównaniu do klasycznego dziedziczenia:

• Jest o wiele bardziej elastyczna i naturalna – o wiele łatwiej jest opisać strukturę obiektów w systemie, używając kompozycji niż dziedziczenia – często to drugie jest tworzone trochę „na siłę”
• Zachowanie obiektu można modyfikować w trakcie działania programu (podmieniając wkomponowany obiekt na inny. Przy dziedziczeniu jest to niemożliwe – część odziedziczona jest „sztywna”

Wady kompozycji

Oczywiście należy także wspomnieć o wadach kompozycji:

• Zwiększa się zużycie pamięci – używamy bowiem większej liczby małych obiektów
• Lekko spada wydajność wywoływania metod – wywołując metodęnaobiekcie, tak naprawdę musimy wywołać metodę z delegata – jest to jedna ramka na stosie więcej
• Klasy mające tę samą funkcjonalność i metody (w naszym przypadku Duck i ElectricDuck) stają się zupełnie rozłączne w hierarchii typów, co w przypadku niektórych języków uniemożliwia proste zastępowanie ich wzajemnie.
• Powstaje sporo metod, których jedynym zadaniem jest wywołanie odpowiedniej metody delegata (tzw. metody przekazujące).

Dwie ostatnie wady są zależne od języka, z jakiego korzystamy, i w niektórych językach programowania nie występują. Niestety w przypadku Javy tak nie jest i trzeba włożyć więcej pracy, żeby się od nich uwolnić. Piszę o tym w dwóch kolejnych częściach artykułu.

Kaczki, a kacze typowanie

W poprzedniej części wspomnieliśmy, iż nasze klasy reprezentujące kaczki stały się zupełnie rozłączne w hierarchii typów. W związku z tym, mimo tego, iż współdzielą de facto te same metody (getVoice() i getSwimVoice()), dla kompilatora Javy są to zupełnie różne byty.

Dlaczego tak się dzieje? Otóż język Java jest językiem z silną kontrolą typów i o tym, jakie metody można wywołać na danym obiekcie, decyduje tylko i wyłącznie jego typ (klasa i implementowane interfejsy). Dlatego też nie ma w nim zastosowania tak zwane (nomen omen) kacze typowanie – w którym o możliwościach obiektu nie decyduje jego typ, lecz udostępnione przezeń metody [6]:

Jeśli coś chodzi jak kaczka i kwacze jak kaczka, to musi być kaczką.

Teoretycznie w Javie można wprowadzić kacze typowanie, posiłkując się mechanizmem refleksji. Powstały w ten sposób kod wygląda jednak bardzo nieczytelnie. Co gorsza, pozbawia nas silnej kontroli typów (co moim zdaniem jest jednak sporą i często niedocenianą zaletą języka Java). Na szczęście jest też do zastosowania o wiele prostszy sposób – wystarczy wprowadzić interfejs opisujący zachowanie kaczki. W przeciwieństwie do dziedziczenia (gdzie możemy mieć maksymalnie jednego przodka), każda klasa może implementować dowolną ilość interfejsów. Wprowadźmy zatem taki interfejs DuckBehaviour:

A następnie zaimplementujmy go w klasach opisujących kaczki (nietrudno się domyślić, że nie wymaga to wielkich zmian)

Jak widać, rozwiązanie z delegatem pozwoliło nam pozbyć się problemów z błędnym dziedziczeniem. Jednocześnie kod odpowiedzialny za bazowe zachowanie kaczki istnieje tylko w jednym miejscu (w klasie delegata). Czyżby sukces? Niestety jeszcze nie! Radość psują nam bowiem metody przekazujące w klasach Duck i ElectricDuck. Musimy je napisać, aby odbywało się wywołanie odpowiedniej metody w delegacie. Co gorsza – te metody będziemy musieli stworzyć w każdej klasie reprezentującej kaczkę, więc nie wygląda to za dobrze. Czyżby „zamienił stryjek siekierkę na kijek?” Aby zaradzić temu problemowi, będziemy musieli jeszcze nieco przerobić kod i wezwać na ratunek dobrze wszystkim znanego Lomboka

Lombok na ratunek

Problem z metodami przekazującymi tak naprawdę wynika z faktu, iż język Java sam w sobie nie wspiera mechanizmu delegacji (w przeciwieństwie do języków takich jak Groovy czy Kotlin, pozostając w świecie JVM). Wiemy też, że często takie braki języka są w całkiem rozsądny sposób „łatane” przez bibliotekę Lombok (żeby np. wspomnieć o setterach i getterach).

Tak jest i tym razem, ale jest pewien haczyk. Lombok oferuje adnotację @Delegate, która rozwiązuje nasz problem. Należy jednak mieć na uwadze, że jest ona traktowana jako eksperymentalna. Oznacza to, że może w przyszłości zniknąć. Nie jest to idealna sytuacja, ale dobre i to! Aby móc skorzystać z tej adnotacji, musimy doprowadzić do sytuacji, w której wszystkie metody przekazujące nie zawierają żadnej logiki poza wywołaniem odpowiadającej metody delegata. W klasie Duck nie jest to problemem, gdyż już tak się dzieje. Natomiast w klasie ElectricDuck metody przekazujące wykonują dodatkowe sprawdzenie (czy baterie są włożone).

Musimy zatem wyciągnąć te sprawdzenia na zewnątrz, korzystając ze wzorca strategii i takie strategie przekazać do delegata. W naszym przypadku będą to zwykłe dwa pola typu Runnable reprezentujące blok kodu do wykonania przed wydaniem głosu i próbą płynięcia:

Dodatkowo dołożyliśmy stałą reprezentującą „pustą” strategię nierobiącą niczego. Ułatwi nam to za chwilę przerobienie klasy Duck. Samo użycie adnotacji @Delegate jest proste – wystarczy użyć jej na polu reprezentującym delegata. Następnie usuwamy metody przekazujące – i to wszystko!

Klasa Duck będzie prezentować się następująco:

Nietrudno w takim razie przerobić i klasę ElectricDuck:

Możemy odetchnąć z ulgą, bo wynikowy kod wygląda już o niebo lepiej! Możemy teraz przyjrzeć się efektom pracy i spróbować przejść jeszcze raz wszystkie kroki.

Czas na podsumowanie

Jak pokazał nam przedstawiony przykład, tworząc hierarchię obiektów w Javie, można relatywnie łatwo popełnić błąd przy dziedziczeniu z istniejącej klasy. Co prawda powinna nas chronić przed tym zasada podstawienia Liskov, ale niestety łatwo ją nieświadomie złamać. Dlatego zamiast prostego dziedziczenia warto rozważyć inne podejścia, takie jak wprowadzenie klasy abstrakcyjnej (prostsze) lub zastąpienie dziedziczenia kompozycją (bardziej złożone, ale dające większą elastyczność).

W przypadku zastosowania kompozycji należy także pamiętać, iż z powodu silnej kontroli typów w Javie, należy stworzyć interfejs zawierający wspólne metody klas, tak aby w przyszłości nie zamykać sobie drogi do zamiany obiektu jednego typu na obiekt drugiego typu. Z kolei nadmiarowy kod spowodowany użyciem delegatów można skrócić z wykorzystaniem (eksperymentalnej co prawda) adnotacji @Delegate z Lomboka. Wymaga to czasami ekstrakcji dodatkowych interfejsów w delegacie, tak aby można było zastosować wzorzec strategii, ale w efekcie końcowym otrzymujemy maksymalnie prosty i elastyczny kod. Warto więc rozważyć i tę opcję.

Oczywiście kod zawarty w niniejszym artykule jest dostępny publicznie w moim repozytorium na GitHubie. Zapraszam zatem do klonowania i eksperymentowania na własną rękę. Przyjemnego tworzenia hierarchii i niech Wam obiekty lekkimi będą!

Literatura

[1] „Barbara Liskov [online]. Wikipedia: wolna encyklopedia”,, 2020-07-13 12:48Z. [dostęp: 2020-07-20 13:24Z]. Dostępny w Internecie.
[2] „Zasada podstawienia Liskov [online]. Wikipedia, wolna encyklopedia”, 2020-04-17 21:56Z. [dostęp: 2020-07-17 13:45Z]. Dostępny w Internecie.
[3] Wikipedia contributors, „Liskov substitution principle — Wikipedia, the free encyclopedia”, 2020. [Online; accessed 17July-2020].
[4] „Agregacja (programowanie obiektowe) [online]. Wikipedia, Wolna encyklopedia”, 2020-03-20 12:29Z. [dostęp: 2020-07-20 10:36Z]. Dostępny w Internecie.
[5] Wikipedia contributors, „Composition over inheritance — Wikipedia, the free encyclopedia” [Online; accessed 20-July-2020].
[6] „Duck typing [online]”. Wikipedia, wolna encyklopedia, 2020-04-17 21:54Z. [dostęp: 2020-07-20 12:06Z]. Dostępny w Internecie.

Idź do:

1. 1. Architektura wzorca porty i adaptery
2. 2. Porty i adaptery – przykładowa implementacja
3. 3. Architektura hexagonalna – organizacja i opis pakietów
4. 4. Architektura hexagonalna – opis implementacji klas
5. 5. Porty i adaptery – najczęstsze pytania
6. 6. Podsumowanie

Architektura wzorca porty i adaptery

Wzorzec porty i adaptery (ang. ports & adapters) określany również jako architektura hexagonalna (ang. hexagonal architecture) to nic innego jak wzorzec narzucający sposób budowy i organizacji kodu aplikacji. Głównym założeniem tego wzorca jest tworzenie kodu w taki sposób, aby maksymalnie odseparować implementację logiki biznesowej od wszelkich zależności zewnętrznych, takich jak frameworki, bazy danych, usługi zewnętrzne itp. Dzięki temu zyskujemy większą kontrolę nad kodem i niezależność od zewnętrznych bibliotek oraz wprowadzanych w nich zmian. Przyjrzyjmy się bliżej wzorcowi:

Wzorzec portów i adapterów dzieli strukturę kodu na dwa obszary:

• wewnętrzny (application / domain)
• zewnętrzny (infrastructure)

Obszar wewnętrzny skupia się na rozwiązaniu i implementacji głównego problemu (use case). Obszar ten nie ma żadnych odniesień do frameworków, baz danych i innych usług lub bibliotek zewnętrznych, ani nie czerpie z nich. Obszar zewnętrzny z kolei zawiera implementację portów w postaci adapterów oraz klasy związane z frameworkami, jak na przykład Spring, Hibernate itp. Komunikacja pomiędzy obszarem wewnętrznym i zewnętrznym realizowana jest za pomocą portów i ich implementacji, czyli adapterów (stąd też nazwa wzorca).

Kilka podstawowych założeń architektury typu porty i adaptery:

1. Obszar wewnętrzny, czyli właściwa implementacja logiki, „nic nie wie” o obszarze zewnętrznym. Nie ma zależności pomiędzy tym obszarem a frameworkami (jak wspomniane Spring, Hibernate itp.).
2. Logika rozwiązania problemu zamknięta jest w obszarze wewnętrznym. Dostęp do niej mamy wyłącznie za pośrednictwem klasy fasady domenowej, o której piszę więcej w dalszej części artykułu.

Porty i adaptery – przykładowa implementacja

Głównym celem przykładu jest zaprezentowanie implementacji klas i organizacja pakietów w oparciu o idee architektury typu ports & adapters. Za przykład niech posłuży obszar domeny odpowiedzialny za rejestrację nowych użytkowników w systemie. Zaimplementowane zostały tutaj dwa przypadki użycia:

• rejestracja nowego użytkownika – obejmuje funkcjonalności związane z wygenerowaniem kodu aktywacji konta oraz wysłanie maila aktywacyjnego.
• aktywacja konta użytkownika – weryfikuje wygenerowany kod i aktywuje konto oraz wysyła komunikat do systemu zewnętrznego.

Architektura hexagonalna – organizacja i opis pakietów

1. Pakiet: user

To główny pakiet domeny, w obrębie której będziemy się poruszali. Czyli domeny użytkowników. Pakiet ten zawiera dwa podpakiety: crud oraz registration 

2. Pakiet: user.crud 

W pakiecie tym została zamknięta logika związana z prostymi operacjami pobierania danych. Ponadto może on zawierać inne operacje, które nie posiadają złożonej logiki biznesowej i służą wyłącznie prostym operacjom typu CRUD (od: create, read, update and delete).

3. Pakiet: user.registration 

Ten pakiet zawiera wszystkie klasy związane z logiką rejestracji nowych użytkowników w aplikacji (implementacja i obsługa wspomnianych wcześniej przypadków użycia).

4. Pakiet: user.registration.domain

Pakiet zawiera klasy z główną implementację logiki biznesowej oraz definicje portów (interfejsy Java), za pośrednictwem których odbywa się komunikacja z innymi komponentami systemu. Pakiet core.user.registration.domain zawiera kod vanilla Java, tzn. kod, który nie jest zależny od frameworków i innych bibliotek zewnętrznych. Jedynym punktem dostępu do zaimplementowanej logiki w tym pakiecie jest klasa fasady. Co ważne: to, jakich bibliotek będziemy używali (np.: commons-lang, Dozer, Orika) wewnątrz pakietu, zależy od zespołu i ogólnych ustaleń w projekcie.

5. Pakiet: user.registration.infrastructure

Pakiet ten zawiera implementację adapterów, które wykorzystywane są za pośrednictwem zdefiniowanych w kodzie domeny portów. W pakiecie zamknięta jest implementacja i konfiguracja komponentów korzystających z funkcji i metod frameworków. Często używane są tutaj biblioteki innych dostawców rozwiązań, które są odpowiedzialne np. za generowanie plików PDF, wysyłanie maili czy komunikację z systemami zewnętrznymi, takimi jak Kafka, SOAP itp.

6. Pakiet: user.registration.infrastructure.config

W pakiecie tym powinna znaleźć się konfiguracja związana z tworzeniem i obsługą komponentów wykorzystywanego frameworka.

7. Pakiet: user.registration.infrastructure.entrypoint

Pakiet ten zawiera klasy kontrolerów i klasy typu DTO, za pośrednictwem których inne systemy czy moduły mogą korzystać z funkcji naszej domeny. Klasy DTO opisują struktury danych wejściowych i wyjściowych dla REST API.           

8. Pakiet: user.registration.infrastructure.repository

Pakiet klas związanych z warstwą persystencji, czyli klasy odpowiedzialne za pobieranie i zapisywanie danych w bazie. Są to definicje modelu danych (ORM), klasy DAO. Pakiet ten zawiera m.in. implementację klasy adaptera dostępu do danych. W bardziej rozbudowanych przypadkach możemy mieć więcej klas modelu lub odwoływać się do klas modelu (ORM) z innych pakietów.

Architektura hexagonalna – opis implementacji klas

1. Klasy z pakietu user.registration.domain:

• UserRegistration – główna klasa implementacji logiki biznesowej. Dostęp do klasy ograniczony na poziomie pakietu.
• UserRegistrationDataProvider – port dla operacji wejścia / wyjścia (we/wy) związanych z dostępem do bazy danych,
• UserRegistrationNotifier – port wyjściowy do wysyłania komunikatów na kolejkę,
• ConfirmationMailSender – port wyjściowy do wysyłania wiadomości mailem.

Wyżej wymienione porty to publiczne interfejsy klas Java, których implementacja odbywa się na poziomie pakietów infrastruktury.

UserRegistrationFacade – fasada domeny. Klasa, za pośrednictwem której mamy dostęp do metod (funkcji) domeny. W przedstawionym przykładzie klasa fasady pełni funkcję wywołującą dla klasy UserRegistration, czyli pełni dla niej funkcję wrappera. W bardziej złożonych przypadkach możemy posiadać więcej klas zawierających logikę biznesową. Wówczas fasada stanowi punkt dostępu do wywołań wszystkich tych funkcji domeny. Czasami może się zdarzyć, że będziemy potrzebowali dołożyć na tym etapie określone walidacje związane z frameworkami. Może być to podyktowane tym, że niektóre inne obszary domenowe będą potrzebowały wykorzystać logikę z innej domeny. Można wówczas na poziomie fasady korzystać z funkcji walidacji. Oczywiście wszystko podobnie jak we wspomnianych wcześniej przypadkach zależy od ogólnych ustaleń i założeń projektowych w zespole.

2. Klasy z pakietu user.registration.infrastructure

Implementacja adapterów:

• ConfirmationMailSenderAdapter
• UserRegistrationNotifierAdapter
• UserRegistrationDataProviderAdapter

3. Klasa UserRegistrationService jest odpowiedzialna za transakcyjność wykonywanych operacji. Klasa ta za pośrednictwem klasy fasady UserRegistrationFacade wywołuje kod logiki biznesowej. W przypadku bardziej złożonych operacji na poziomie tej klasy mogą być wstrzykiwane fasady pochodzące z innych obszarów.
4. Klasy z pakietu user.registration.entrypoint.
5. Klasa kontrolera UserRegistrationController wystawia REST API. Używa klasy UserRegistrationService realizującej operacje wymagające. transakcji. W przypadku gdy operacje nie wymagają od nas transakcji, możemy w klasie tej bezpośrednio korzystać z klasy fasady.

W przykładowej implementacji pakietu domain widać dużą liczbę klas – jest to jeden z atrybutów tego wzorca. Dzięki temu uzyskujemy hermetyczność implementacji logiki biznesowej i struktur z nią związanych. Punktem dostępu do funkcji domeny jest klasa fasady. Z założenia klasy pakietu domain nie powinny używać klas frameworków, stąd też większa liczba klas POJO (plain old Java object) związanych z danymi. W wypadku złożonych przypadków użycia można tworzyć większą liczbę klas z implementacją logiki biznesowej. W przykładzie można np. wydzielić aktywację konta do osobnej klasy.

Przeczytaj także: Test-Driven Development na co dzień

Porty i adaptery – najczęstsze pytania

Dlaczego musimy ograniczać dostęp do niektórych klas na poziomie pakietu?

Za pomocą modyfikatorów dostępu do klas i metod ukrywamy szczegóły implementacji – czyli stosujemy tzw. hermetyzację klas. Zapewniamy tym samym kontrolę nad dostępem, stanem i zachowaniem obiektu.  W naszym przykładzie w pakiecie domain dostęp publiczny posiadają: klasa fasady oraz klasy reprezentujące dane wejściowe i wyjściowe. Cała implementacja logiki jest zamknięta na poziomie pakietu i dostęp do operacji jest możliwy wyłącznie za pośrednictwem metod zdefiniowanych w klasie fasady.

Co z bibliotekami typu Lombok, JSR 303 (walidacja) lub loggerami w pakiecie domain?

Zgodnie z główną ideą architektury hexagonalnej nie powinniśmy używać bibliotek zewnętrznych. Praktyka dowodzi jednak czegoś innego. To, jakich bibliotek użyjemy wewnątrz domeny, zależy od decyzji zespołu, gdyż każda osoba w zespole ma inne doświadczenia i pomysły. Warto jednak zastosować pewne ograniczenia co do tych narzędzi. W projektach, w których brałem udział, ograniczaliśmy się głównie do bibliotek typu java commons, biblioteki mapperów oraz walidacji.

Porty i adaptery – gdzie zakładać transakcje?

Jednym z ważniejszych elementów implementacji operacji jest ich transakcyjność.
Często wymagana operacja będzie potrzebowała wykorzystać funkcję z innej domeny kodu lub będziemy chcieli wywołać funkcję domeny w transakcji. Wówczas musimy zapewnić transakcyjność dla wywołań tych funkcji. Dla takiego przypadku można zbudować dedykowany serwis, który będzie zawierał klasy fasad domenowych.
W przykładzie serwis został zaimplementowany w klasie UserRegistrationService.

Dlaczego nie powinniśmy zakładać transakcji w klasie fasady?

Brak transakcji w klasie fasady wynika z założenia, że kod w pakiecie domain ma być wolny od wszelkich frameworków.

Czy można używać DDD razem ze wzorcem ports & adapters?

DDD (Domain-Driven Design) skupia się na domenie i zawartej w niej logice biznesowej. Nie ma nic wspólnego z frameworkami i transakcjami. W przykładzie część związana z DDD została zaimplementowana w pakiecie domain. Wzorzec ports & adapters pomaga nam uporządkować kod i odseparować dostęp do zaimplementowanej logiki. Można stwierdzić, że wzorzec ten bardziej odpowiada za warstwę aplikacyjną rozwiązania, ponieważ odpowiada m.in. za dostarczenie mechanizmów konfiguracji, transakcji czy persystencji. Podejście DDD oraz wzorzec ports & adapters współgrają ze sobą w strukturach kodu. DDD rozwiązuje problem logiczny, a P&A zapewnia dostęp do technicznych mechanizmów i bibliotek.

Czy zawsze powinniśmy stosować wzorzec ports & adapters?

Jeżeli zastanawiamy się, kiedy stosować architekturę hexagonalną, decydujący będzie aspekt logiki biznesowej. Wzorzec ports & adapters idealnie sprawdzi się w przypadku rozbudowanej logiki biznesowej, gdy chcemy skupić się na rozwiązaniu problemów, które zostały tam postawione. Kod jest wolny od wszelkich frameworków, dzięki czemu łatwo się nim zarządza i testuje. jest to, że testy uruchamia się szybko i pisze łatwo. Piszemy mniej testów integracyjnych – dużą część logiki pokrywają testy jednostkowe. W testach integracyjnych weryfikujemy krytyczne ścieżki.

Podejście to narzuca nam tworzenie większej liczby klas w celu odseparowania się od reszty kodu spoza pakietu, co na pierwszy rzut oka wydaje się nadmiarowe. Dzięki temu jednak łatwiej jest wydzielić logikę do osobnych niezależnych modułów (w architekturach mikroserwisowych często pojawia się potrzeba wydzielenia logiki do osobnej usługi).

W przypadku aplikacji, które posiadają mało logiki biznesowej lub wręcz jej nie ma (aplikacje typu CRUD), lepszym podejściem jest budowa struktury kodu w formie wielowarstwowej (Controller – Service – Repository). W przykładzie został wydzielony pakiet CRUD, w którym zaimplementowana została prosta operacja pobrania listy użytkowników.

Podsumowanie

Mam nadzieję, że udało mi się przedstawić główne idee budowy kodu w architekturze portów i adapterów oraz odpowiedzieć na część pytań, które mogą pojawić się podczas implementacji. Oczywiście w każdym projekcie może wyglądać to inaczej. Wszystko zależy od Was. To zespół tworzy oprogramowanie – organizacja i struktura kodu powinna być czytelna dla wszystkich i umożliwiać wygodną pracę. Tak naprawdę to, jak zaimplementowany zostanie wzorzec, zależy więc od zespołu i jego decyzji.

Zobacz więcej:

• przykładowa implementacja aplikacji
• Clean architecture

Przejdź do:

1. 1. Mikroserwis, czyli czy rozmiar ma znaczenie
2. 2. Microserwis vs aplikacja monolityczna
3. 3. Ograniczenia architektury mikroserwisowej
4. 4. Błędne założenia
5. 5. Mikroserwisy czy rozproszony monolit?
6. 6. Od monolitu do mikroserwisów

Na początku należałoby jednak znaleźć odpowiedź na jeszcze inne pytanie: skąd taka popularność architektury mikroserwisowej? Odpowiedź wydaje się dosyć prosta: programiści zazwyczaj nie przepadają za rozwojem i utrzymaniem dużych, ciężkich projektów, a idea mikroserwisów zakłada rozwój niezależnych, małych projektów, nic więc dziwnego, że dla wielu z nich wydaje się być strzałem w dziesiątkę.

Mikroserwis, czyli czy rozmiar ma znaczenie

Ale co to właściwie znaczy, że pojedynczy mikroserwis jest mały? W Internecie można znaleźć wiele absurdalnych pomysłów na ten temat. Jedni uważają, że mikroserwis powinien mieć nie więcej niż tysiąc linii kodu. Inni, że zespół, który go tworzy, powinien być w stanie go napisać, żywiąc się przy tym jedynie trzema pizzami. Inny pomysł jest taki, że mikroserwis powinien być na tyle mały, żeby można go przepisać w ciągu jednego scrumowego sprintu, czyli około dwóch tygodni. Ja osobiście uważam, że mikroserwis powinien być tak mały, jak to możliwe i tylko tak duży, jak to jest absolutnie niezbędne.

Oczywiście rozmiar to tylko jeden z aspektów, który opisuje mikroserwisy. Mikroserwis poza tym powinien cechować się także pojedynczą odpowiedzialnością, czyli być zbudowany w oparciu o pojedynczą domenę biznesową. Jego implementacja powinna być ukryta, czyli komunikacja pomiędzy mikroseriwsami powinna się odbywać wyłącznie w oparciu o ustalony kontrakt. Kolejne cechy to niezależność wdrażania oraz odporność na awarie. Ta ostatnia cecha oznacza, że awaria jednego mikroserwisu nie powinna wpływać na pozostałe.

Microserwis vs aplikacja monolityczna

Jeśli weźmiemy pod uwagę jedynie powyższe cechy, możemy dojść do pochopnego wniosku, że mikroserwisy w porównaniu do tradycyjnej, monolitycznej architektury, rzeczywiście zawsze wypadają znacznie lepiej. Programiści dostają to, czego chcieli, ale i biznes powinien być usatysfakcjonowany, ponieważ dostaje skalowalną i odporną na awarie aplikację. Niestety jest tak głównie w teorii, ponieważ praktyka przynosi wiele problemów i zagrożeń.

Ograniczenia architektury mikroserwisowej

Największe wyzwanie związane z architekturą mikroserwisową dotyczy spójności danych. W systemach rozproszonych nie jest możliwe jednoczesne osiągnięcie spójności, dostępności i odporności na podział, musimy zawsze dokonać wyboru dwóch z pośród tych trzech cech. Jeżeli założymy, że w aplikacjach rozproszonych zawsze występuje podział sieci i odporność na nią musi być zapewniona, to do wyboru pozostaje spójność lub dostępność. W praktyce najczęściej wybierana jest dostępność kosztem spójności, co oznacza problemy dla biznesu, ponieważ może występować czasowa niespójność danych. Możliwe jest również utrzymanie spójności, ale bez gwarancji, że system będzie zawsze dostępny w 100%.

Przeczytaj także: Wykorzystujesz mikroserwisy? Poznaj Service Mesh i nowe możliwości, jakie daje!

Błędne założenia

Dodatkowo w dobie popularnych i ogólnodostępnych chmur obliczeniowych zbyt wiele osób zapomina o komunikacji sieciowej i problemach, jakie może ona stwarzać. Dwie aplikacje, które się ze sobą komunikują, nie robią tego w sposób magiczny. W tej komunikacji trzeba uwzględnić co najmniej kilka zagrożeń, które niestety zazwyczaj są bagatelizowane. Najczęściej występujące błędne założenia, dotyczące komunikacji między aplikacjami, zostały wskazane przez L. Petera Deutscha:

• Sieć jest niezawodna.
• Opóźnienie wynosi zero.
• Przepustowość jest nieskończona.
• Sieć jest bezpieczna.
• Topologia się nie zmienia.
• Jest jeden administrator.
• Koszt transportu wynosi zero.
• Sieć jest jednorodna.

Jeżeli powyższe błędne założenia o sieci nie zostaną zweryfikowane i aplikacja rozproszona nie zostanie na nie odpowiednio przygotowana, to z dużym prawdopodobieństwem problemy w komunikacji pomiędzy mikroserwisami pojawią się szybciej niż się tego spodziewamy.

Mikroserwisy czy rozproszony monolit?

Jest jeszcze jeden często pojawiający się problem. Jak napisałem na początku tego artykułu, każdy mikroserwis powinien być związany z pojedynczą odpowiedzialnością, czyli być związany ściśle z określoną domeną biznesową. Ale nowo tworzone systemy mają to do siebie, że wymagania względem nich często się zmieniają, co może powodować zamazywanie granicy pomiędzy poszczególnymi mikroserwisami, poprzez migrację wzajemnych odpowiedzialności. Skutek jest taki, że system składa się wprawdzie z wielu mikroserwisów, ale każdy z nich odpowiada za wszystko. Nie ma to oczywiście nic wspólnego z aplikacją mikroserwisową, powstaje natomiast rozproszony monolit.

Od monolitu do mikroserwisów

Celem tego artykułu nie było przekonanie czytelnika do tego, że mikroserwisy są dobre lub złe, ale uświadomienie, jakie problemy mogą powodować. A także tego, że przejście z architektury monolitycznej na mikroserwisową nie rozwiązuje z automatu wszystkich problemów, a jedynie przenosi je w inne miejsce. Z drugiej jednak strony, jeżeli podejdziemy do mikroserwisów w sposób odpowiedzialny i przemyślany, to może się to okazać bardzo dobry wybór. Uważam jednak, że w przypadku nowych projektów warto rozważyć rozpoczęcie od monolitycznej architektury i przejście na mikroserwisową po wstępnej fazie rozwoju aplikacji, kiedy główne wymagania nie będą się już zmieniać tak często, a granica pomiędzy domenami nie będzie przesuwana. Zawsze bowiem łatwiej będzie nam wydzielić domeny i określić granice w monolicie, czyli czymś, co już istnieje, niż dzielić coś, czego jeszcze nawet nie ma.