Category:

Java

JWT w Spring Security

by Grzegorz Sowa 18 września, 2021

written by Grzegorz Sowa

Jeśli rozmawiamy o autoryzacji, zawsze przychodzi na myśl JWT w Spring Security. Ale dlaczego właśnie JWT? Spring Security przecież świetnie sobie radzi z Session Cookie, w dodatku jest to domyślna metoda autoryzacji w tym frameworku. Spróbujmy sobie więc odpowiedzieć, czym jest JWT i jakie korzyści daje nad ciasteczkiem sesji. Na koniec spróbujmy w prosty sposób zaimplementować JWT w aplikacji opartej na Spring Boot.

Kod zawarty w tym artykule znajdziecie tutaj. Nie zapomnijcie przejrzeć innych branchy, zawierających kod odpowiadający kolejnym sekcjom artykułu.

JWT w teorii

JWT, czyli JSON Web Token to otwarty standard bezpiecznego transferu informacji o uprawnieniach, opisany w rfc7519. Każdy token jest ciągiem znaków, składających się z 3 części: nagłówka (Header), danych (Payload) i podpisu (Signature). Header zawiera takie informacje, jak typ tokenu i algorytm wykorzystany do podpisu. Payload natomiast zawiera dane zależne od aplikacji, część z nich jest opisana w standardzie:

iss (Issuer) – aplikacja wydająca token.
sub (Subject) – odbiorca tokenu.
aud (Audience) – lista podmiotów, w komunikacji z którymi token powinien być używany.
exp (Expiration Time) – timestamp momentu w przyszłości, po którym token nie powinien być akceptowany.
nbf (Not Before) – timestamp momentu w przyszłości, przed którym token nie powinien być akceptowany.
iat (Issued At) – timestamp momentu, w którym token został wydany.
jti (JWT ID) – unikalny identyfikator tokenu.

Wszystkie te parametry są opcjonalne, powstały tylko po to, aby developerzy mieli pewien punkt zaczepienia, definiując najczęściej używane w tokenach rzeczy.

Zarówno Header, jak i Payload są w tokenie w formie enkodowanej w Base64 i w takiej formie są składnikami do podpisu, który jest ostatnią częścią tokena. Do podpisu jest też używany sekret, który zna tylko serwer go wydający. W zależności od potrzeb JWT może być podpisywane algorytmem symetrycznym (wtedy zweryfikować go może tylko aplikacja-wydawca) lub asymetrycznym (wtedy część klucza jest dostępna publicznie i każdy może zweryfikować poprawność podpisu).

JWT w praktyce

JWT jest bardzo często używany jako standard nadawania uprawnień, również w implementacji innych frameworków jak OAuth2 czy Device Cookie. Przekazywanie tokena JWT w nagłówku zapytania ma kilka przewag nad standardowym Session Cookie:

O wiele lepiej się skaluje, gdyż aby zweryfikować JWT aplikacja nie musi wykonywać kosztownych zapytań do bazy danych.
Nie dotyczą go ataki CSRF, przez co jest jedynym sensownym wyborem dla Single Page Application, gdzie trudno jest przekazać token CSRF z backendu.
Zapewnia prawdziwie bezstanową komunikację, w przeciwieństwie do Session Cookie.

JWT w Spring Security

Teraz zobaczmy, jak zmienić standardowy sposób autoryzacji w Spring Security na JSON Web Token.

Implementacja użytkowników

Ponieważ standardowa implementacja danych użytkownika w Spring Security nie posiada ID, musimy zrobić własną, implementującą interfejs UserDetails:

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PACKAGE)
public class AppUser implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;

    @Convert(converter = AuthoritiesToStringConverter.class)
    private Set<Authority> authorities;

    public static AppUser newInstance(String username, String password, Authority... authorities) {
        final AppUser user = new AppUser();
        user.username = username;
        user.password = password;
        user.authorities = Set.of(authorities);
        return user;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

Dlaczego AppUser a nie User? Nazwa User mogłaby sprawiać problemy w zapytaniach do bazy danych. Natomiast użyty w klasie enum Authority musi implementować interfejs GrantedAuthority:

public enum Authority implements GrantedAuthority {
    USER, ADMIN;

    @Override
    public String getAuthority() {
        return this.name();
    }
}

Teraz pozostał już tylko serwis odpowiedzialny za użytkowników, implementujący interfejs UserDetailsService.

@Component
@RequiredArgsConstructor
public class AppUserService implements UserDetailsService {

    private final AppUserRepository repository;
    private final PasswordEncoder passwordEncoder;

    public AppUser createUser(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER));
    }

    public AppUser createAdmin(String username, String password) {
        return repository.save(AppUser.newInstance(username, passwordEncoder.encode(password), Authority.USER, Authority.ADMIN));
    }

    @Override
    public AppUser loadUserByUsername(String username) throws UsernameNotFoundException {
        return repository.findByUsername(username)
                .orElseThrow(() -> new UsernameNotFoundException("No user with such username!"));
    }
}

PasswordEncoder zdefiniujmy w oddzielnej klasie konfiguracyjnej:

@Configuration
public class PasswordHandlingConfiguration {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

Mając to, możemy stworzyć kilku przykładowych użytkowników do testów, na starcie aplikacji:

@Component
@RequiredArgsConstructor
public class AddExampleUserRunner implements CommandLineRunner {

    private final AppUserService userService;

    @Override
    public void run(String... args) {
        userService.createUser("user", "pass");
        userService.createUser("user2", "pass");
        userService.createAdmin("admin", "pass");
    }

}

Konfiguracja

Następnie przechodzimy do konfiguracji Spring Security, na początek musimy podpiąć stworzony UserDetailsService oraz PasswordEncoder:

@Configuration
@RequiredArgsConstructor
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    private final PasswordEncoder passwordEncoder;
    private final AppUserService userService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userService)
                .passwordEncoder(passwordEncoder);
    }
    // more..
}

Dalej w konfiguracji mamy do zrobienia jeszcze kilka rzeczy:

wyłączyć mechanizm tworzenia sesji, ustawiając go na wartość STATELESS,
podłączyć filtr, który będzie „rozpakowywał” token JWT jeszcze zanim Spring sprawdzi tożsamość użytkownika,
podłączyć AuthenticationSuccessHandler, który będzie tworzył nowy token JWT.

    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .addFilterBefore(new AccessTokenPreAuthorizationFilter(accessTokenProvider), UsernamePasswordAuthenticationFilter.class)
                .authorizeRequests()
                .antMatchers(GET, "/posts/**").permitAll()
                .anyRequest().authenticated()
                .and()
                .formLogin()
                .successHandler(new AccessTokenAuthenticationSuccessHandler(accessTokenProvider, userService))
                .and()
                .exceptionHandling()
                .authenticationEntryPoint((req, resp, ex) -> resp.setStatus(UNAUTHORIZED.value()))
                .and()
                .sessionManagement().sessionCreationPolicy(STATELESS)
                .and()
                .csrf().disable();
    }

AccessTokenPreAuthorizationFilter

Filtr odczytuje nagłówek Authorization i wyciąga z niego token JWT, aby potem zamienić go na obiekt Authentication i wstawić go w SecurityContext sesji. Do operacji na JWT używa on AccessTokenProvider, który zdefiniujemy później.

@Slf4j
@RequiredArgsConstructor
public class AccessTokenPreAuthorizationFilter extends OncePerRequestFilter {

    private final AccessTokenProvider accessTokenProvider;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String authorizationHeader = request.getHeader(AUTHORIZATION);
        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            String token = authorizationHeader.substring("Bearer ".length());
            SecurityContextHolder.getContext()
                    .setAuthentication(accessTokenProvider.extractAuthentication(token));
        }
        filterChain.doFilter(request, response);
    }

}

AccessTokenAuthenticationSuccessHandler

Teraz zdefiniujmy AuthenticationSuccessHandler, który po pomyślnym uwierzytelnieniu wygeneruje dla usera Access Token i przekaże go w nagłówku. On również do operacji na JWT używa obiektu AccessTokenProvider.

@RequiredArgsConstructor
public class AccessTokenAuthenticationSuccessHandler implements AuthenticationSuccessHandler {

    private final AccessTokenProvider accessTokenProvider;
    private final AppUserService userService;

    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, Authentication auth) {
        final AppUser user = (AppUser) auth.getPrincipal();
        final String accessToken = accessTokenProvider.getAccessToken(
                userService.loadUserByUsername(user.getUsername()).getId().toString(),
                user.getAuthorities().stream()
                        .map(GrantedAuthority::getAuthority)
                        .collect(Collectors.toList()));
        response.setHeader("access_token", accessToken);
    }

}

AccessTokenProvider

Interfejs AccessTokenProvider zawiera tylko dwie metody, używane do tej pory przez klasy obsługujące flow JWT:

public interface AccessTokenProvider {

    String getAccessToken(String userId, List<String> roles);

    Authentication extractAuthentication(String token);

}

Aby go zaimplementować, potrzebujemy biblioteki obsługującej JWT. Ja wybrałem na potrzeby tego przykładu implementację od auth0:

<dependency>
	<groupId>com.auth0</groupId>
	<artifactId>java-jwt</artifactId>
	<version>3.18.1</version>
</dependency>

Obsługując tokeny JWT warto skupić się na minimum, definiując tylko „sub” (Subject) w postaci id użytkownika, „exp” (Expiration Time), po upłynięciu którego biblioteka automatycznie odrzuci token, oraz role użytkownika w polu „roles”.

@Component
public class JwtAccessTokenProvider implements AccessTokenProvider {

    private final JwtAccessTokenProperties properties;
    private final Algorithm algorithm;
    private final JWTVerifier verifier;

    public JwtAccessTokenProvider(JwtAccessTokenProperties properties) {
        this.properties = properties;
        this.algorithm = Algorithm.HMAC256(properties.getSecret().getBytes(StandardCharsets.UTF_8));
        this.verifier = JWT.require(algorithm).build();
    }

    @Override
    public String getAccessToken(String userId, List<String> roles) {
        return JWT.create()
                .withSubject(userId)
                .withExpiresAt(new Date(System.currentTimeMillis() + properties.getTokenLifespanSeconds() * 1000))
                .withClaim("roles", roles)
                .sign(algorithm);
    }

    @Override
    public UsernamePasswordAuthenticationToken extractAuthentication(String token) {
        DecodedJWT jwt = verifier.verify(token);
        return new UsernamePasswordAuthenticationToken(
                jwt.getSubject(),
                null,
                jwt.getClaim("roles").asList(String.class).stream()
                        .map(SimpleGrantedAuthority::new)
                        .collect(Collectors.toList())
        );
    }
}

Kontrola dostępu

Zdefiniujmy teraz kontroler, w którym użytkownik może tworzyć własne wpisy i przeglądać wpisy innych. Ponadto, oddajmy w ręce użytkowników opcję usuwania wpisów.

@RestController
@RequestMapping("posts")
@RequiredArgsConstructor
public class PostController {

    private final PostService postService;

    @GetMapping("{postId}")
    public Post getPost(@PathVariable Long postId) {
        return postService.getPost(postId);
    }

    @PostMapping
    public ResponseEntity<Void> createPost(@RequestBody CreatePostDto dto) {
        postService.createPost(dto.content);
        return ResponseEntity.status(CREATED).build();
    }

    @DeleteMapping("{postId}")
    // …
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

    @Data
    public static class CreatePostDto {
        private String content;
    }
}

Tutaj pojawia się zagadnienie Ownership-based Access Control, ponieważ użytkownik powinien móc usunąć tylko własny wpis. Poza tym, administrator, którego wcześniej stworzyliśmy, powinien być w stanie usunąć każdy wpis (Role-based Access Control). To drugie zagadnienie załatwimy, dodając nad deletePost() adnotację @PreAuthorize("hasAuthority('ADMIN')"). To jednak nie wszystko, musimy jeszcze włączyć ten mechanizm, dodając nad klasą konfiguracyjną @EnableGlobalMethodSecurity(prePostEnabled = true). Ownership-based Access Control jest już trudniejszy, musimy zdefiniować komponent, który będzie mógł wyciągnąć wpis z bazy i sprawdzić, czy id jego autora jest takie samo jak to, które przyszło w JWT.

@Component
@RequiredArgsConstructor
public class AuthorChecker {

    private final PostService postService;

    public boolean check(Long postId) {
        final Post post = postService.getPost(postId);
        final Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        return post.getAuthorId().equals(principal);
    }

}

Teraz musimy jeszcze użyć metody check() w adnotacji @PreAuthorize. Gotowa metoda delete będzie wyglądała tak:

    @DeleteMapping("{postId}")
    @PreAuthorize("hasAuthority('ADMIN') or @authorChecker.check(#postId)")
    public ResponseEntity<Void> deletePost(@PathVariable Long postId) {
        postService.deletePost(postId);
        return ResponseEntity.status(NO_CONTENT).build();
    }

JWT vs Session Cookie

Zajrzyjmy jeszcze do zapytań do bazy żeby zobaczyć, jak dużą przewagę ma JWT nad Session Cookie. Niestety nie odnotujemy wewnętrznych zapytań robionych przez Springa na poziomie Hibernate, musimy zejść poziom niżej. W tym celu pobieramy bibliotekę zdolną założyć proxy na DataSource:

<dependency>
	<groupId>net.ttddyy</groupId>
	<artifactId>datasource-proxy</artifactId>
	<version>1.4.1</version>
</dependency>

Teraz musimy jeszcze zapakować oryginalny DataSource w nasze proxy i sprawdzić, aby był używany w całej aplikacji. Idealnie nadaje się do tego BeanPostProcessor, który pozwala modyfikować beany po ich zainicjalizowaniu:

@Component
public class DatasourceProxyBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(final Object bean, final String beanName) {
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(final Object bean, final String beanName) {
        if (bean instanceof DataSource dataSourceBean) {
            return ProxyDataSourceBuilder
                    .create(dataSourceBean)
                    .name("DataSourceProxyLogger")
                    .listener(new QueryLoggingListener())
                    .build();
        }
        return bean;
    }

}

@Slf4j
public class QueryLoggingListener implements QueryExecutionListener {

    @Override
    public void afterQuery(ExecutionInfo executionInfo, List<QueryInfo> list) {
        for (QueryInfo queryInfo: list) {
            log.info("Query: " + queryInfo.getQuery());
        }
    }
    // …
}

Zobaczmy więc, co nasz logger powie, jeśli użytkownikowi uda się usunąć wpis:

QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?

Tyle, dwa zapytania – wyjmij wpis, usuń wpis. Dla porównania skonfigurowałem tę aplikację, żeby korzystała z sesji zapisywanej w JDBC. Oto wynik jednej operacji usunięcia wpisu:

QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]
QueryLoggingListener: Query: select post0_.id as id1_1_0_, post0_.author_id as author_i2_1_0_, post0_.content as co[...]
QueryLoggingListener: Query: delete from post where id=?
QueryLoggingListener: Query: UPDATE SPRING_SESSION SET SESSION_ID = ?, LAST_ACCESS_TIME = ?, MAX_INACTIVE_INTERVAL [...]
QueryLoggingListener: Query: SELECT S.PRIMARY_ID, S.SESSION_ID, S.CREATION_TIME, S.LAST_ACCESS_TIME, S.MAX_INACTIVE[...]

Spring aby usunąć jeden post wykonał aż pięć zapytań. Choć JWT również nie jest bez kosztów, ponieważ wymaga sprawdzenia poprawności podpisu, zdecydowanie wygrywa on w tym starciu. Kod użyty to testu z Session Cookie znajdziecie na branchu session-cookie.

Podsumowanie

JWT w Spring Security to konieczność w większych aplikacjach i technologia, którą na pewno warto znać. W artykule zobaczyliśmy, czym jest JWT i jak skorzystać z niego w Springu, rozwiązując 2 problemy: Ownership-based i Role-based Access Control, a także przewagę wydajnościową, jaką JWT daje nad Session Cookie.

18 września, 2021 5 komentarzy

Java Security

OAuth2 Authorization Code Flow w Springu

by Grzegorz Sowa 5 września, 2021

written by Grzegorz Sowa

Każdy programista styka się na jakimś etapie swojej kariery z OAuth2. W artykule przyjrzymy się, na czym polega ten protokół, a właściwie framework. Szczególnie omówimy Authorization Code Flow i czym się różni od innych flow. Potem zobaczymy w praktyce, jak użyć go do pobrania listy znajomych na Facebooku w aplikacji opartej o Spring Boot. Enjoy! 🙂

Cały kod zawarty w tym artykule znajdziecie tutaj.

Co to jest OAuth2 Authorization Code Flow?

OAuth2 to framework autoryzacji, wymyślony na potrzeby delegacji uprawnień do zasobów. W ramach OAuth2 właściciel zasobu (Resource Owner ) udziela jakiejś aplikacji (Client Application) dostępu do swoich informacji w innej aplikacji, przechowywanych na serwerze zasobu (Resource Server). W tym procesie pośredniczy serwer autoryzacji (Authorization Server). Resource Server sprawdza uprawnienia Client Application na podstawie Access Tokenu, który musi ona otrzymać od Authorization Servera. Tutaj pojawia się pojęcie flow, czyli sposobu, w jaki Client Application otrzymuje Access Token. OAuth2 definiuje 4 podstawowe typy flow:

Authorization Code Flow – najczęściej używany standard, w którym Client Application otrzymuje Authorization Code, który wymienia na Access Token.
Client Credential Flow – używany do transmisji serwer-serwer, bez udziału Resource Ownera. Client Application wysyła do Authorization Servera wcześniej uzgodnione dane uwierzytelnienia, a w zamian otrzymuje Access Token.
Implicit Flow – cały odbywa się w przeglądarce, dlatego jest najmniej bezpieczny. Używany np. w aplikacjach mobilnych, zastępowany przez bezpieczniejszy Authorization Code Flow rozszerzony o PKCE.
Resource Owner Password Flow – Powstał na potrzeby aplikacji desktopowych, teraz jednak jest uznawany za protokół legacy.

Warto jeszcze wspomnieć, że OAuth2 nie służy do uwierzytelnienia, a tylko do autoryzacji. . Wszędzie tam, gdzie używamy Google czy Facebooka do zalogowania się, aplikacja korzysta z OpenID Connect, który jest nakładką na OAuth2, umożliwiającą uwierzytelnienie.

Czemu framework autoryzacji? Często możemy się spotkać z określeniem, że OAuth2 jest protokołem. Nie jest to jednak prawdą, bo OAuth2 nie opisuje ze szczegółami sposobu nawiązania autoryzacji, a tylko definiuje luźne reguły procesu. Implementację niektórych jego elementów (np. Access Token) pozostawia w gestii użytkownika.

Przebieg OAuth2 Authorization Code Flow

Zajmijmy się najczęściej używanym flow, z którego często korzystamy na co dzień. OAuth2 Authorization Code Flow składa się z kilku kroków:

Użytkownik odpytuje specjalny endpoint wystawiany przez Client Application, który służy do rozpoczęcia procesu autoryzacji.
Client Application przekierowuje go na Authorization Server. W URL-u znajdują się dane mówiące o Client Application, zakresie uprawnień, jakich wymaga od Resource Ownera oraz redirect_uri na który należy przekierować użytkownika.
Authorization Server generuje ekran zgody, na którym wylistowane są wszystkie uprawnienia wymagane przez Client Application oraz przycisk akceptacji.
Gdy Resource Owner zgodzi się na podane warunki, zostaje przekierowany na redirect_uri, spowrotem do Client Application.
Jako query parameter „doklejony” do URL-a jest Authorization Code, który Client Application odczytuje.
Ze zdobytym kodem Client Application odpytuje Authorization Server i otrzymuje w odpowiedzi Access Token.
Client Application może teraz odpytywać Resource Server w zakresie pokrywanym przez Access Token.

Każdy z tych kroków jest opisany w dokumentacji OAuth2.

Client OAuth2 w Spring Boot

Spróbujmy stworzyć aplikację, która dla będzie w stanie pobrać i wyświetlić zalogowanemu użytkownikowi listę znajomych, którzy też z niej korzystają.

Konfiguracja

Zacznijmy od zaimportowania niezbędnych projektów w pom.xml:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-security</artifactId>
</dependency>

Do wyświetlenia widoku z listą znajomych potrzebujemy jeszcze:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

Teraz skonfigurujmy logowanie do aplikacji z jednym zarejestrowanym użytkownikiem w pamięci. Poza tym, musimy dodać odpowiednią konfigurację, aby Spring przygotował beany odpowiadające klientowi OAuth2.

@Configuration
@EnableWebSecurity
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(final AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("user")
                .password(passwordEncoder().encode("pass"))
                .roles("USER");
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .authorizeRequests()
                .anyRequest().authenticated()
                .and()
                .oauth2Client()
                .and()
                .formLogin()
                .and()
                .logout()
                .and()
                .httpBasic()
                .and()
                .csrf().disable();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

Musimy jeszcze dodać szczegółową konfigurację klienta OAuth2 dla Facebooka w application.yml:

spring:
  security:
    oauth2:
      client:
        registration:
          facebook:
            client-id: {client id of the Facebook app}
            client-secret: {client secret of the Facebook app}
            authorization-grant-type: authorization_code
            redirect-uri: "{baseUrl}/friends"
            scope: user_friends

Client-id i client-secret to parametry pozwalające Facebookowi zidentyfikować naszą aplikację. Nie wiesz skąd wziąć te parametry? Sprawdź ten tutorial.

Redirect-uri to url, na który Spring ma przekierować użytkownika po zakończonym procesie.

Parametr scope to zakres uprawnień, o jakie prosimy. Jego wartość tutaj jest wzięta z dokumentacji Facebooka i pozwala m. in. na pobranie listy znajomych.

Widok

Stwórzmy kontroler, który będzie zwracał widok znajomych:

@Controller
@RequestMapping("friends")
@RequiredArgsConstructor
public class FriendsController {

    private final FriendsProvider friendsProvider;

    @GetMapping
    public String friendsSite(Model model) {
        model.addAttribute("friends", friendsProvider.getFriends());
        return "friends";
    }

}

Sam widok znajomych możemy zdefiniować dzięki bibliotece Thymeleaf:

<table>
    <thead>
    <tr>
        <th> ID </th>
        <th> Name </th>
    </tr>
    </thead>
    <tbody>
    <tr th:if="${friends.empty}">
        <td colspan="2"> You have no friends </td>
    </tr>
    <tr th:each="friend : ${friends}">
        <td><span th:text="${friend.id}"> ID </span></td>
        <td><span th:text="${friend.name}"> Name </span></td>
    </tr>
    </tbody>
</table>

Facebook Client

Teraz możemy już zdefiniować klienta, który spełni kontrakt interfejsu FriendsProvider i będzie w stanie pobrać znajomych z Facebooka.

@Component
@RequiredArgsConstructor
public class FacebookClient implements FriendsProvider {

    private final RestTemplate restTemplate = new RestTemplate();

    private final String FRIENDS_URL = "https://graph.facebook.com/me/friends";
    private final String CLIENT_ID = "facebook";

    @Override
    public Set<FacebookFriend> getFriends() {
        HttpHeaders headers = new HttpHeaders();
        headers.set("Authorization", String.format("Bearer %s", accessToken()));
        return restTemplate.exchange(
                FRIENDS_URL,
                HttpMethod.GET,
                new HttpEntity<Void>(headers),
                FacebookUserFriendsResponse.class
        ).getBody().getData();
    }

    // …
}

Oczywiście, ponieważ potrzebujemy do nagłówka autoryzacji Access Token, musimy go skądś wziąć. W tym celu pobieramy beana typu OAuth2AuthorizedClientService, z którego będziemy mogli wyciągnąć obiekt OAuth2AuthorizedClient, zawierający Access Token użytkownika. Potrzebujemy jeszcze kontekstu zalogowanego usera, jednak ten wyciągniemy w łatwy sposób z użyciem statycznej metody SecurityContextHolder.getContext().

    private final OAuth2AuthorizedClientService clientService;

    private String accessToken() {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        OAuth2AuthorizedClient client = clientService.loadAuthorizedClient(CLIENT_ID, authentication.getName());
        if (client == null) {
            throw new UserNotAuthorizedException(CLIENT_ID);
        }
        return client.getAccessToken().getTokenValue();
    }

Jeśli nie znajdziemy OAuth2AuthorizedClient rzucamy customowy exception, który możemy wyłapać w ErrorController. Chcemy tutaj zwrócić użytkownikowi redirect na endpoint w aplikacji, który zainicjuje OAuth2 Authorization Code Flow z Facebookiem.

@ControllerAdvice
public class ErrorController {

    @ExceptionHandler(UserNotAuthorizedException.class)
    public String handleUserNotAuthorizedException(UserNotAuthorizedException exception) {
        return String.format("redirect:oauth2/authorization/%s", exception.getClient());
    }

}

OAuth2 Authorization Code Flow

Gdy użytkownik trafia na endpoint /oauth2/authorization/facebook Spring konstruuje URL z danych z konfiguracji i przekierowuje tam użytkownika. Dzięki temu Facebook wie, jaka aplikacja przekierowała użytkownika, jakie zgody mu wyświetlić i gdzie przekierować spowrotem. Request wygląda mniej-więcej tak:

GET /v2.8/dialog/oauth?response_type=code&client_id={client id}&scope=user_friends&state=ZT--DzCsz-neIZ4kjSUiEVmBMyJzOBtS3opw9SOYe1E%3D&redirect_uri=http://localhost:8080/friends HTTP/2
Host: www.facebook.com

Parametr state, który aplikacja dodała do URL-a to losowo wygenerowany string, którego aplikacja będzie musiała potem użyć w zapytaniu o Access Token. Serwer Autoryzacji sprawdzi zgodność parametru state pomiędzy requestami, co pozwala na uniknięcie ataku CSRF. W odpowiedzi Authorization Server Facebooka zwraca Consent Screen, na którym wg OAuth2 musi się znaleźć m.in. nazwa aplikacj i lista uprawnień, jakich jej udzielamy:

Jeśli zgodzimy się na nadanie aplikacji uprawnień, serwer autoryzacji przekierowuje nas z powrotem na adres naszej aplikacji, w URL-u zawierając Authorization Code:

HTTP/2 302 Found
Location: http://localhost:8080/friends?code=AQCXt29Kwz81qmAVM-[...]hSvvnc&state=ZT--DzCsz-neIZ4kjSUiEVmBMyJzOBtS3opw9SOYe1E%3D

Teraz nasza aplikacja przekierowuje użytkownika spowrotem na skonfigurowany adres url, w tym przypadku /friends. W międzyczasie odpytuje ona serwer autoryzacji o Access Token, posługując się otrzymanym wsześniej Authorization Code:

GET /v11.0/oauth/access_token?client_id={client_id}&client_secret={client_secret}&redirect_uri=http://localhost:8080/friends&code=AQCXt29Kwz81qmAVM-[...]hSvvnc HTTP/2
Host: graph.facebook.com

Następnie aplikacja, mając już Access Token, pobiera listę znajomych z Resource Servera Facebooka, aby zasilić nimi widok:

GET /me/friends HTTP/2
Host: graph.facebook.com
Authorization: Bearer EAAOfs9ZCz[…]de10cwi81slujv

Podsumowanie

OAuth2 to zdecydowanie temat, który warto znać. Oczywiście, w jednym artykule nie da się wyczerpać tematu OAuth2 Authorization Code Flow, a co dopiero innych typów flow. Dlatego w kolejnych artykułach postaram się napisać coś o innych typach flow, zagrożeniach związanych z OAuth2 i być może coś o OpenID Connect. Bardzo dobrym źródłem nauki jest też dokumentacja OAuth2 i spróbowanie tego w praktyce, na własnej testowej apce 🙂

5 września, 2021 6 komentarzy

Clean Code Java Wzorce projektowe

3 behawioralne wzorce projektowe które warto znać

by Grzegorz Sowa 19 lipca, 2021

written by Grzegorz Sowa

Behawioralne wzorce projektowe, chociaż często mniej znane niż strukturalne czy kreacyjne, mogą przynieść bardzo dużą wartość w projekcie. Postaram się więc przedstawić trzy wzorce, które moim zdaniem naprawdę warto znać. Są to: strategia, obserwujący i odwiedzający. Mam wrażenie, że w kilku projektach, które robiłem w przeszłości te wzorce mogły mi zaoszczędzić wiele trudu.

Kod zawarty w tym artykule znajdziecie tutaj. Nie zapomnijcie przejrzeć innych branchy, zawierających kod odpowiadający kolejnym sekcjom artykułu.

Strategia

Strategia to chyba najczęściej używany z przedstawionych tutaj behawioralnych wzorców projektowych. Warto go używać w miejscach, gdzie logika biznesowa jest dość złożona i często ulega zmianie. Dzięki strategii możemy dynamicznie podstawiać różne operacje do wykonania, w zależności od zdefiniowanych warunków. Strategia pozwala też wynieść część logiki z naszej domeny, dzięki czemu staje się ona bardziej uporządkowana i czytelna.

Idealnym problemem, aby przedstawić wzorzec strategii, wydaje się określanie ceny produktu w supermarkecie na podstawie różnych promocji. Promocje dla każdego produktu muszą być dobierane dynamicznie, na podstawie kategorii, daty, ceny i różnych innych czynników. Co więcej, wartość promocji też może się zmieniać, w zależności od decyzji biznesu. Zobaczmy najprostszą implementację logiki promocji przy określaniu zbiorczej ceny pozycji w zamówieniu:

public class PriceService {

    Integer calculatePrice(OrderPosition position) {
        int price = position.getQuantity() * position.getProduct().getPrice();
        final LocalDateTime now = LocalDateTime.now();

        // multi item promotion for fashion and health
        if (Arrays.asList(FASHION, HEALTH).contains(position.getProduct().getCategory())
                && position.getQuantity() > 3) {
            price = (int) Math.ceil(price * 0.8);
        }
        // cyber monday electronics promotion
        if (now.toLocalDate().equals(getCyberMondayFor(now.getYear()))
                && position.getProduct().getCategory().equals(ELECTRONICS)) {
            price = (int) Math.ceil(price * 0.65);
        }
        // new year's happy hours
        if (now.toLocalDate().isEqual(LocalDate.of(now.getYear(), JANUARY, 1))
                && now.getHour() > 6 && now.getHour() < 10) {
            price = (int) Math.ceil(price * 0.5);
        }

        return price;
    }

    private LocalDate getCyberMondayFor(Integer year) {
        return LocalDate.of(year, NOVEMBER, 1)
                .with(TemporalAdjusters.dayOfWeekInMonth(4, DayOfWeek.THURSDAY));
    }
}

Mamy tutaj już 3 dosyć skomplikowane instrukcje warunkowe, a promocji na pewno będzie więcej. Po jakimś czasie utrzymywania takiej aplikacji to miejsce będzie pewnie jednym z najczęściej zmienianych przez programistów. To może prowadzić do ogromnego „spuchnięcia” klasy i licznych konfliktów przy merge’owaniu.

Aby temu zapobiec spróbujmy zastosować wzorzec strategii. Musimy zacząć od zdefiniowania dodatkowego interfejsu Discount, reprezentującego reguły promocji:

public interface Discount {

    Predicate<OrderPosition> applicable();

    int apply(int price);

}

Przykładowa implementacja interfejsu Discount to po prostu przeniesiona instrukcja if z naszego PriceService:

public class CyberMondayDiscount implements Discount {

    @Override
    public Predicate<OrderPosition> applicable() {
        return position -> {
            final LocalDateTime now = LocalDateTime.now();
            return now.toLocalDate().equals(getCyberMondayFor(now.getYear()))
                    && position.getProduct().getCategory().equals(ELECTRONICS);
        };
    }

    @Override
    public int apply(int price) {
        return (int) Math.ceil(price * 0.65);
    }

    private LocalDate getCyberMondayFor(Integer year) {
        return LocalDate.of(year, NOVEMBER, 1)
                .with(TemporalAdjusters.dayOfWeekInMonth(4, DayOfWeek.THURSDAY));
    }
}

Teraz mamy bardzo schludnie wyciągniętą logikę biznesową promocji z serwisu cen, który teraz jest bardzo uproszczony i wygląda tak:

public class PriceService {

    private List<Discount> discounts;

    Integer calculatePrice(OrderPosition position) {
        int price = position.getQuantity() * position.getProduct().getPrice();

        for (Discount discount : discounts) {
            if (discount.applicable().test(position)) {
                price = discount.apply(price);
            }
        }

        return price;
    }

}

Obserwator

Obserwator to wzorzec, który warto zaimplementować w sytuacji, gdy wiele obiektów musi być powiadomionych o jakimś wydarzeniu. Powiadamianie wszystkich zainteresowanych w logice domenowej może być żmudne i sprawiać, że kod staje się nieczytelny. Dlatego wzorzec obserwatora definiuje mechanizm subskrypcji, dzięki czemu nasz obiekt domenowy może udostępnić metodę do subskrypcji i notyfikować wszystkich zainteresowanych, nie wiedząc nawet, kto się zapisał.

Wyobraźmy sobie logikę zamówień internetowego supermarketu, w której w pewnym momencie zamówienie użytkownika zostaje zamknięte. Oznacza to kilka rzeczy:

trzeba utworzyć płatność, aby użytkownik mógł zamówienie opłacić,
należy wysłać maila podsumowującego zamówienie,
dane marketingowe muszą zostać zaktualizowane, aby w przyszłości proponować użytkownikowi produkty podobne do tych, które właśnie zakupił

Każda z tych rzeczy dotyczy innego kontekstu, dlatego w najprostszej implementacji stworzymy odpowiednie interfejsy i „podepniemy” je pod naszą logikę domenową:

public class OrderFacade {

    private OrderRepository orderRepository;

    private MailService mailService;
    private MarketingService marketingService;
    private PaymentService paymentService;

    public void closeOrder(UUID orderId) {
        final Order order = orderRepository.findById(orderId)
                .orElseThrow(EntityNotFoundException::new);
        order.close();

        mailService.notifyOrderClosed(orderId);
        marketingService.notifyOrderClosed(orderId);
        paymentService.notifyOrderClosed(orderId);

    }

}

Jak widać, nasza metoda closeOrder() jest bardzo zagracona logiką powiadamiania różnych części aplikacji o zamknięciu zamówienia. W dodatku będzie się ona wciąż zmieniać, bo w przyszłości dodamy moduł raportowania, fakturowania itp. Znacznie lepiej byłoby po prostu powiadamiać wszystkich zainteresowanych, którzy taką chęć zakomunikują. W najprostszej wersji możemy zaimplementować wzorzec obserwatora definiując dwa interfejsy, Publisher i Subscriber:

public interface Publisher<T> {

    void subscribe(Subscriber<T> subscriber);

}

public interface Subscriber<T> {

    void onNext(T event);

}

Publisher udostępnia metodę służącą do „zapisania się” do subskrypcji jakiegoś wydarzenia T, a potem rozgłasza to wydarzenia, na każdym swoim subskrybencie wywołując metodę onNext(). Dzięki temu rozpoczęcie subskrypcji spada na samego zainteresowanego, implementującego interfejs Subscriber.

Zobaczmy więc, jak będzie wyglądać metoda closeOrder() po zaimplementowaniu wzorca obserwatora:

public class OrderFacade implements Publisher<OrderClosedEvent> {

    private OrderRepository orderRepository;

    private final List<Subscriber<OrderClosedEvent>> orderClosedSubscribers = new ArrayList<>();

    @Override
    public void subscribe(Subscriber<OrderClosedEvent> subscriber) {
        orderClosedSubscribers.add(subscriber);
    }

    public void closeOrder(UUID orderId) {
        final Order order = orderRepository.findById(orderId)
                .orElseThrow(EntityNotFoundException::new);
        order.close();

        final OrderClosedEvent event = new OrderClosedEvent(orderId, Instant.now().getEpochSecond());
        for (var subscriber : orderClosedSubscribers) {
            subscriber.onNext(event);
        }

    }

}

Jak widać kod jest prostszy, ale przede wszystkim – mniej podatny na zmiany. OrderFacade implementuje interfejs Publisher, który wymusza na niej nadpisanie metody subscribe(), do której każdy obiekt zainteresowany wydarzeniem OrderClosedEvent może się „zgłosić”, jeśli tylko implementuje interfejs Subscriber. Może to wyglądać przykładowo tak:

class MailService implements Subscriber<OrderClosedEvent> {

    public MailService(Publisher<OrderClosedEvent> publisher) {
        publisher.subscribe(this);
    }

    @Override
    public void onNext(OrderClosedEvent event) {
        sendConfirmationMail(event.orderId(), event.timestamp());
    }

    private void sendConfirmationMail(UUID orderId, Long timestamp) {
        // sending mail
    }

}

Jeśli natomiast dodamy MonitoringService i on też będzie musiał reagować na OrderClosedEvent, logika zamówień nie musi o tym wiedzieć, nic się w niej nie zmienia.

Odwiedzający

Odwiedzający to wzorzec zapewne mniej popularny niż pozostałe dwa, jednak wciąż rozwiązuje poważny problem w bardzo sprytny sposób. Wyobraźmy sobie grafową strukturę obiektów, gdzie każdy węzeł może mieć kilka innych zagnieżdżonych węzłów. Jeśli teraz musimy przekazać naszą strukturę w innym formacie, np. xml czy pdf, od razu przychodzi na myśl rekursywne wywoływanie metody od głównego obiektu, do kolejnych obiektów zależnych. To jednak nie zawsze jest najlepsze rozwiązanie, zwłaszcza, gdy nasz graf reprezentuje logikę biznesową. Nie chcemy przecież naszego kodu zaśmiecać technicznymi metodami. Tu właśnie najbardziej pomaga wzorzec odwiedzającego, pozwalający tą logikę wyeksportować do innych klas, „odwiedzających” węzły grafu aby wyciągnąć potrzebne informacje.

Wyobraźmy sobie, że nasza klasa zamówienia Order składa się z kilku pozycji OrderPosition, które to zawierają ilość i klasę danego produktu Product. Aby wyeksportować zamówienie do xml w każdej z tych klas musimy dodać „brzydką” metodę toXml(), która może być wywoływana rekursywnie:

public class Order {

    private UUID id;
    private UUID clientId;
    private Set<OrderPosition> positions;
    private Boolean closed;

    // other methods

    String toXml() {
        return """
                <order>
                    <id>%s</id>
                    <clientId>%s</clientId>
                    <positions>
                    %s
                    </positions>
                </order>
                """.formatted(id, clientId,
                positions.stream()
                .map(OrderPosition::toXml)
                .collect(Collectors.joining())
                );
    }
}

Dużo dodatkowego kodu, który nie pasuje do logiki biznesowej. Co więcej, co z eksportem do pdf? Albo do json? To dodatkowe metody, a nasza klasy domenowe „puchną” coraz bardziej. Zobaczmy teraz, czy obserwator rozwiąże wszystkie problemy. Na początek zdefiniujmy interfejs Visitor:

public interface Visitor {

    void doForOrder(Order order);

    void doForOrderPosition(OrderPosition position);

    void doForProduct(Product product);

}

Odwiedzający musi mieć gotową metodę dla każdego obiektu domenowego. Jednak dzięki temu w obiektach domenowych pozostaje nam już tylko zdefiniować metodę accept():

public class Order {

    private UUID id;
    private UUID clientId;
    private Set<OrderPosition> positions;
    private Boolean closed;

    // other methods

    public void accept(Visitor visitor) {
        visitor.doForOrder(this);
    }
}

Wprawdzie musimy ją zdefiniować w każdej klasie, jednak teraz możemy już akceptować dowolną ilość odwiedzających, bez wiedzy klasy domenowej. Co więcej, logika eksportu do xml została już wyniesiona do oddzielnej klasy:

class XmlExportVisitor implements Visitor {

    private final StringBuilder result;

    public XmlExportVisitor() {
        result = new StringBuilder();
    }

    public String getResult() {
        return result.toString();
    }

    @Override
    public void doForOrder(Order order) {
        result.append(
                """
                        <order>
                            <id>%s</id>
                            <clientId>%s</clientId>
                            <positions>
                        """.formatted(order.getId(), order.getClientId())
        );
        order.getPositions()
                .forEach(position -> position.accept(this));
        result.append(
                """
                            </positions>
                        </order>
                        """
        );
    }

    @Override
    public void doForOrderPosition(OrderPosition position) {
        // some logic…
    }

    @Override
    public void doForProduct(Product product) {
        // some logic…    
    }
}

Podsumowanie

Trzy wzorce projektowe opisane w artykule pozwalają zaimplementować skomplikowaną logikę w bardzo spójny i błyskotliwy sposób, a jednocześnie zachowują czytelność kodu. Umiejętność wybrania dobrego wzorca i dostosowania go do sytuacji to oczywiście kwestia doświadczenia, jednak mam nadzieję że powyższe przykłady pozwoliły zapoznać się z benefitami, które oferują 3 opisane wzorce 🙂

Więcej o podobnych wzorcach możesz poczytać na tym blogu.

19 lipca, 2021 2 komentarze

Clean Code Java

Dziedziczenie a kompozycja

by Grzegorz Sowa 12 lipca, 2021

written by Grzegorz Sowa

Co jest nie tak z tym dziedziczeniem? Czemu w ogóle konflikt kompozycja vs dziedziczenie? I czemu, według większości programistów, kompozycja jest lepsza? Spróbujmy sobie odpowiedzieć na te pytania, patrząc na konkretne przykłady.

Kod wykorzystany w tym artykule znajdziecie tutaj.

Po co dziedziczyć?

Zarówno dziedziczenie, jak i kompozycja to w świecie programowania obiektowego mechanizmy, które prowadzą do ponownego używania raz już napisanego kodu. Bez nich pisalibyśmy tylko spaghetti, poprawiali jedną rzecz w wielu miejscach, a głównym mechanizmem re-użycia kodu byłoby Ctrl+C Ctrl+V. Oprócz tego, mechanizmy te pomagają nam odwzorować zależności ze świata realnego w naszym kodzie. Na przykład, skoro kwadrat jest prostokątem to klasa Square powinna dziedziczyć po klasie Rectangle. Albo skoro samochód posiada koła, kierownicę i silnik to obiekt klasy Car zdecydowanie powinien posiadać SteeringWheel, Engine i co najmniej trzy obiekty Wheel, plus może koło zapasowe.

HAS-A vs IS-A

Przyjęło się, że kompozycja oddaje relację HAS-A a dziedziczenie – relację IS-A. Czyli Car HAS-A Engine ale Car IS-A Vehicle. O ile każdy się zgodzi, że kompozycja jest najlepsza do oddania relacji HAS-A, o tyle dziedziczenie już nie zawsze jest faworytem dla IS-A. Jeśli ktoś twierdzi, że kompozycja jest „lepsza” od dziedziczenia, to pewnie ma właśnie na myśli jej przewagę w oddawaniu relacji IS-A. Jednak należy pamiętać, że takie stwierdzenie jest pewnym uogólnieniem i nie powinno być traktowane jako dogmat. Aby dobrze ocenić problem zobaczmy, czemu ktoś może uważać, że dziedziczenie jest złym wyborem.

Zasada podstawienia Liskov

Żeby przejść dalej, przypomnijmy sobie jedną z zasad tworzenia SOLIDnego oprogramowania, zasadę podstawienia Liskov:

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.
Barbra Liskov

Oznacza to, że jeśli mamy wagę, czyli obiekt klasy Scale i ważymy na nim obiekt Vehicle – to powinniśmy być w stanie uzyskać jego masę niezależnie, czy to Car czy Bike. Co więcej, waga nie powinna nawet wiedzieć, czy waży samochód czy motocykl.

Problem elipsy

Problem elipsy jest często używanym zagadnieniem w kontekście porównania kompozycji do dziedziczenia. Załóżmy, że mamy zdefiniowaną klasę Ellipse:

class Ellipse {

    private float r1;
    private float r2;

    public Ellipse(float r1, float r2) {
        this.r1 = r1;
        this.r2 = r2;
    }

    public void increaseR1(float dr) {
        this.r1 = this.r1 + dr;
    }

    public void increaseR2(float dr) {
        this.r2 = this.r2 + dr;
    }

    public double area() {
        return Math.PI * r1 * r2;
    }

}

Tak zdefiniowana klasa ma swoje dwa promienie, które można dowolnie skalować. Jeśli teraz mamy też zaimplementować okrąg, to kod Ellipse aż się prosi o re-użycie w klasie Circle. Zobaczmy więc, jak możemy ten problem ugryźć.

Czy okrąg jest elipsą?

Zdefiniujmy sobie klasę Circle dziedziczącą po Ellipse:

class Circle extends Ellipse {

    public Circle(float r) {
        super(r, r);
    }
    // …
}

Na razie idzie nam świetnie, ale co z metodami increaseR1() i increaseR2()? Żadna z nich nie ma sensu logicznego, ponieważ jeśli zwiększymy tylko jeden promień to okrąg przestanie być elipsą. Spróbujmy jednak obejść to ograniczenie, zwiększając jednocześnie drugi promień:

    @Override
    public void increaseR1(float dr) {
        super.increaseR1(dr);
        super.increaseR2(dr);
    }

    @Override
    public void increaseR2(float dr) {
        super.increaseR1(dr);
        super.increaseR2(dr);
    }

Robiąc to, złamaliśmy zasadę podstawienia Liskov. Żeby to zobrazować, wyobraźmy sobie klasę Magnifier, której obiekty mają jeden cel – powiększać elipsy dwukrotnie.

class Magnifier {

    public void magnify(Ellipse ellipse) {
        ellipse.increaseR1(ellipse.getR1() * 2);
        ellipse.increaseR2(ellipse.getR2() * 2);
    }

}

Gdy podamy do naszej nowej klasy elipsę, pewnie zostanie powiększona dwukrotnie. Ale co, jeśli podamy zamiast niej okrąg? Okrąg przecież też jest elipsą i dzięki cudowi polimorfizmu możemy podać go do metody magnify(). Wtedy okaże się, że Magnifier, niczego nieświadomy powiększy okrąg czterokrotnie. To jest właśnie przykład złamania zasady podstawienia Liskov.

Kompozycja nie ratuje, ale zmienia perspektywę

Zobaczmy teraz, czy kompozycja wjedzie na białym koniu i rozwiąże problem. Zdefiniujmy sobie klasę Circle, która zamiast dziedziczyć po Ellipse będzie przechowywać jej instancję.

class Circle {

    private final Ellipse ellipse;

    public Circle(float r) {
        this.ellipse = new Ellipse(r, r);
    }

    public void increaseR(float dr) {
        this.ellipse.increaseR1(dr);
        this.ellipse.increaseR2(dr);
    }

    public float getR() {
        return this.ellipse.getR1();
    }

    public double area() {
        return ellipse.area();
    }
    // …
}

Świetnie, teraz już nikt nie może zarzucić nam, że mamy z Circle te „dziwne” metody increaseR1() i increaseR2(). Co jednak, jeśli chcemy wciąż używać klasy Magnifier? Nie mamy już polimorfizmu, więc czy kompozycja naprawdę pomogła? Otóż pomogła, bo sprawę polimorfizmu powinniśmy załatwić innym mechanizmem – interfejsem. To zmusi nas do zdefiniowania jednorodnego interfejsu dla figur geometrycznych, który pozwoli Magnifier powiększać je bez obaw o implementację.

interface Scalable {

    void scale(int factor);

}

Teraz klasa Magnifier będzie wyglądała trochę inaczej:

class Magnifier {
    
    public void magnify(Scalable scalable) {
        scalable.scale(2);
    }
    
}

Natomiast zarówno Circle, jak i Ellipse mogą spokojnie zaimplementować sobie metodę scale(). Inna sytuacja, kiedy łatwo przez dziedziczenie zasmucić Barbrę Liskov, pojawi się dalej.

Założenia metod podstawowych

W Javie podstawowe metody, takie jak na przykład hashCode(), equals(), clone() – są zdefiniowane w klasie Object i każda klasa, którą utworzymy będzie je posiadała, ponieważ będzie po klasie Object dziedziczyć. Możemy te metody nadpisywać, jednak mają one swoje założenia, które są często uznawane za pewnik w innych klasach API Javy. Dlatego jeśli je złamiemy, bardzo łatwo możemy paść ofiarą trudnych do zidentyfikowania bugów, kiedy na przykład nasze obiekty włożymy do HashMap. Jeśli chcesz dowiedzieć się, jak dokładnie działa HashMap w Javie, sprawdź ten artykuł.

Jedną z najważniejszych metod podstawowych jest equals(). Aby przejść dalej, omówmy sobie podstawowe jej założenia:

Zwrotność – dla każdego obiektu x – x.equals(x) musi zwrócić true
Symetria – dla każdej pary x i y – x.equals(y) musi zwracać true wtedy i tylko wtedy, gdy y.equals(x)
Przechodniość – dla każdej trójki x, y i z, jeśli x.equals(y) oraz y.equals(z) – to również x.equals(z)
Spójność – dla każdej pary x i y – x.equals(y) przy wielokrotnych wywołaniach musi zawsze zwracać ten sam wynik
dla dowolnego x – x.equals(null) musi zwracać false

Dziedzicz i łam założenia

Zdefiniujmy sobie teraz klasę Point, reprezentującą punkt w przestrzeni dwuwymiarowej.

public class Point {

    private final int x;
    private final int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object o) {
        if (o instanceof Point other) {
            return x == other.x && y == other.y;
        }
        return false;
    }
    
}

Point nadpisuje metodę equals() w taki sposób, że dwa punkty o tych samych współrzędnych są sobie równe. Co jednak, jeśli biznes przyjdzie do nas z osobliwą prośbą, aby zacząć rysować kolorowe punkty? Nie ma problemu, korzystając z dziedziczenia definiujemy ColorPoint:

class ColorPoint extends Point {

    private Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }
    // …
}

Jak jednak powinniśmy zdefiniować metodę equals()? Jeśli w ogóle jej nie nadpiszemy, zostanie odziedziczona po klasie Point, więc będzie ignorować kolor w porównaniu, co jest niedopuszczalne. Zdefiniujmy więc najprostszą metodę equals():

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return super.equals(other) && this.color == other.color;
        }
        return false;
    }

Takie zdefiniowanie metody equals() jest błędem – narusza zasadę symetrii. To znaczy, że jeśli zdefiniujemy x = Point(1, 2) oraz y = Point(1, 2, RED) to x.equals(y) zwróci nam true, a y.equals(x) – false. Możemy naprawić ten błąd, ignorując kolor, jeśli dostaniemy obiekt klasy Point:

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return super.equals(other) && this.color == other.color;
        }
        if (o instanceof Point other) {
            return super.equals(other);
        }
        return false;
    }

Teraz x.equals(y) powinno już zwrócić to samo, co y.equals(x). Jednak to rozwiązanie również jest błędne, ponieważ łamie zasadę przechodniości metody equals(). Aby to udowodnić, zdefiniujmy sobie 3 punkty:

ColorPoint x = new ColorPoint(1, 2, RED);
Point y = new Point(1,2);
ColorPoint z = new ColorPoint(1, 2, BLUE);

Ponieważ x.equals(y) jest prawdą i y.equals(z) też – oczekiwalibyśmy, że x.equals(z) również zwróci true. Tak jednak się nie stanie, co łamie zasadę przechodniości.

Nie ma łatwego sposobu na rozszerzanie definicji klasy o nowe składniki z zachowaniem zasad zdefiniowanych dla metody equals, chyba że rezygnujemy z zalet abstrakcji obiektowej.
Joshua Bloch, „Effective Java”, rozdział 3. temat 10.

getClass() zamiast instanceof

Niektórzy twierdzą, że możemy uratować zasadę przechodniości, modyfikując metodę equals() w bazowej klasie Point.

    @Override
    public boolean equals(Object o) {
        if (o != null && o.getClass() == this.getClass()) {
            Point other = (Point) o;
            return x == other.x && y == other.y;
        }
        return false;
    }

Faktycznie, mają rację – teraz x.equals(y) zwróci false, więc zasada przechodniości zostanie zachowana. Teraz jednak znów wjeżdża Barbra Liskov, cała na czarno i nakazuje nam zdefiniować okrąg jednostkowy i sprawdzić, czy punkt leży na tym okręgu:

public class UnitCircle {

    private final Set<Point> points;

    public UnitCircle(int x, int y) {
        this.points = new HashSet<>();
        this.points.add(new Point(x, y + 1));
        this.points.add(new Point(x, y - 1));
        this.points.add(new Point(x + 1, y));
        this.points.add(new Point(x - 1, y));
    }

    public boolean contains(Point point) {
        return this.points.contains(point);
    }
    
}

Nie jest to najszybsza, lecz jak najbardziej poprawna implementacja, ponieważ mamy prawo się spodziewać, że każda instancja klasy Point będzie funkcjonować jako Point. Gdy jednak dostaniemy ColorPoint, to niezależnie od jego współrzędnych metoda contains() zwróci false. To właśnie przejaw złamania zasady podstawienia Liskov.

Kompozycja ratuje dzień

Spróbujmy teraz zdefiniować ColorPoint za pomocą kompozycji:

class ColorPoint {

    private Point point;
    private Color color;

    public Point asPoint() {
        return this.point;
    }

    @Override
    public boolean equals(Object o) {
        if (o instanceof ColorPoint other) {
            return this.point.equals(other.point) && this.color.equals(other.color);
        }
        return false;
    }

}

Teraz dalej re-używamy kod, który napisaliśmy w klasie Point, jednak czy kiedykolwiek porównanie obiektów ColorPoint i Point zwróci true? Odpowiedź brzmi: nie, i nie musi. Do każdego kontekstu wymagającego klasy Point możemy przekazać asPoint() – Liskov syty i założenia metody equals() całe.

Kiedy dziedziczenie?

Trzeba jeszcze zauważyć, że powyższe problemy nie występują, jeśli dziedziczymy po klasach abstrakcyjnych. Nie możemy w końcu mieć problemów z metodą equals(), jeśli nie możemy utworzyć obiektu klasy bazowej 🙂 Pamiętajmy jednak, że długie łańcuchy dziedziczenia sprawiają, że kod staje się nieczytelny i trudny do utrzymania.

Podsumowanie

Porównanie między dziedziczeniem a kompozycją to nie zawsze trywialny problem. Dlatego warto zdawać sobie sprawę z wad i zalet każdego podejścia, aby podejmować świadome decyzje. Inspiracją do tego artykułu był ten wpis na Wikipedii, oraz książka Joshua Bloch – „Effective Java”. Zachęcam serdecznie do ich lektury, na pewno nie będzie to stracony czas.

12 lipca, 2021 2 komentarze

Java Kolekcje

Jak działa HashMap w Javie? (3 poziomy wtajemniczenia)

by Grzegorz Sowa 22 maja, 2021

written by Grzegorz Sowa

Oprócz oczywistej wartości praktycznej, znajomość odpowiedzi na to pytanie często przydaje się na rozmowach rekrutacyjnych na Java Developera. Jak działa HashMap w Java? Aby w pełni odpowiedzieć na to pytanie, omówmy sobie HashMap na trzech „poziomach wtajemniczenia”. Najczęściej poziom pierwszy będzie wystarczył do „zaliczenia” rozmowy na poziomie juniora natomiast poziomy drugi i trzeci to już raczej poziom regular (i może jakaś rozgrzewka dla seniora).

Poziom 1 – główne założenia HashMap

Wkraczamy w pierwszy poziom wtajemniczenia, co to jest ogólnie HashMap? W skrócie jest to kolekcja, do której wkładamy pary klucz-wartość, a potem, mając klucz, możemy wyjąć konkretną wartość.

Jak działa insert do HashMap

Kiedy „wkładamy” do HashMap parę klucz-wartość metodą put(), para jest dodawana do kolekcji. Jeżeli dodamy inną wartość z identycznym kluczem, nadpisze ona wartość poprzednią. Natomiast jeśli dodamy parę z kluczem null – para również zostanie dodana. Oczywiście, możemy ją potem „wyjąć” podając jako klucz null. HashMap nie zachowuje jednak kolejności dodawanych par.

Jak działa szukanie w HashMap

Gdy chcemy wyciągnąć jakąś wartość z HashMap, używamy metody get(). Mapa porównuje wartość klucza z już posiadanymi kluczami, i w zależności, czy znajdzie, zwraca wartość lub null. Więc jak mapa określa, czy klucze są równe? No właśnie – używając metod hashCode() i equals().

Bardzo podobny zestaw czynności wystąpi przy każdej metodzie wymagającej wyszukania elementu, jak remove() czy containsKey().

Poziom 2 – wewnętrzne mechanizmy i Big O notation

Schodzimy poziom niżej, zobaczmy więc jak HashMap w Java zachowuje się „pod maską”. Otóż pary klucz-wartość mapa przechowuje razem, w obiekcie Node<K, V>, który implementuje interfejs Map.Entry<K, V>. Obiekty te są zorientowane w kolekcję, która odpowiada jednokierunkowej LinkedList – każde Entry ma referencję do następnego.

Insert pod maską i buckety

HashMap to tak naprawdę tablica java o stałej długości składająca się umownie z tzw. bucketów. Każdy bucket to właśnie LinkedList złożony z obiektów Entry. Gdy wywołujemy metodę put() na mapie, HashMap z tablicą o długości n w pierwszej kolejności wylicza indeks bucketu, do którego trafi nowe Entry. A robi to, używając bitowej operacji AND na hashu klucza.

index = key.hashCode() & (n - 1)

Gdy już określi index bucketu, dodaje do niego parę. Warto tutaj zauważyć, że jeśli w buckecie już coś jest, mapa będzie porównywać metodą equals() klucze, które już buckecie są, z nowym kluczem. Jeśli któryś z nich okaże się równy to zamiast dodawać nową parę, podmieni wartość w tej z identycznym kluczem. Natomiast jeśli klucz jest null – cały algorytm przebiega tak samo, tyle że wartość trafia zawsze do bucketu z indeksem 0.

Złożoność dodawania nowej pary do HashMap jest taka sama, jak do LinkedList, czyli O(1).

Lookup pod maską – uważaj na hashCode() i equals()

Gdy wywołujemy metodę wymagającą wyszukania po kluczu, HashMap wykonuje to samo wyliczenie, co przy put(), obliczając indeks bucketu odpowiadającego kluczowi. Jeśli jest tam tylko jedno Entry – nie ma problemu, mapa od razu zwraca wartość. Jednak jeśli będzie tam więcej obiektów, mapa porówna klucz z każdym w buckecie operacją equals(). Dopiero, jeśli dla któregoś z nich equals() zwróci true, mapa zwróci odpowiadającą mu wartość.

Złożoność wyciągania obiektów z HashMap to również 0(1). Załóżmy jednak, że źle zdefiniowaliśmy metodę hashCode(). Na przykład, jakiś niedoświadczony developer uznał że może tam zawsze zwracać taką samą wartość. Wtedy złożoność szukania osiągniemy taką samą, jak w LinkedList – O(n). A to dlatego, że wszystkie Entry będą trafiać do jednego bucketu.

Synchronizacja

HashMapa nie jest bezpieczna dla równoległego przetwarzania przez wiele wątków – używając jej, musimy więc zapewnić synchronizację jakimś innym mechanizmem. Alternatywnie możemy użyć ConcurrentHashMap. Więcej o użyciu kolekcji w środowisku wielowątkowym możesz poczytać tutaj

Poziom 3 – optymalizacja

Gdyby HashMap utworzone z ośmioma bucketami miało ich już na zawsze 8, to w miarę dodawania kolejnych obiektów złożoność szukania w niej dążyłaby szybko do O(n). Dlatego aby pozostać przy pożądanym O(1) potrzebujemy pewnych optymalizacji.

Pojemność

Startową liczbę bucketów możemy określić, kiedy tworzymy HashMap – parametrem initialCapacity. Jeśli go nie podamy, otrzyma on domyślna wartość, czyli 16. Możemy też zdefiniować dodatkowy parametr loadFactor typu float w zakresie od 0 do 1. Parametr ten odpowiada za moment, w którym mapa podwoi liczbę swoich bucketów, wywołująć metodę resize(). Dokładniej, mając loadFactor równy 0.75 (wartość domyślna), HashMap wywoła resize() w momencie, gdy ponad 75% bucketów będzie miała co najmniej jedno Entry. Podczas powiększania jest tworzona nowa tablica bucketów, dwukrotnie większa, a indeks dla każdego Entry jest wyliczany ponownie.

Złożoność operacji dodawania, przy której HashMap będzie się powiększać, to już nie O(1), a O(n). Dlatego, jeśli znamy przybliżoną liczbę obiektów, jakie będziemy obsługiwać – warto od razu zainicjalizować większą mapę.

treeify/untreeify

Jest jeszcze jedna optymalizacja działania HashMap w Java – jeśli dany bucket „urośnie” i będzie miał 8 Entry – zostaje na nim wywołana metoda treeifyBin() i wszystkie instancje Node<K, V> w tym buckecie zostaną zamienione na TreeNode<K, V>, efektywnie tworząc drzewo binarne. Dodatkowym warunkiem, jaki musi być spełniony jest osiągnięcie liczby bucketów większej od 64. Jeśli jest ich mniej, mapa wywołuje metodę resize(). Natomiast jeśli liczba Entry w buckecie zmniejszy się do 6 – zostanie wywołana metoda untreeify() i bucket znowu będzie listą.

Optymalizacja ta ma konkretną korzyść – złożoność wyszukiwania elementów w danym buckecie z O(n) zmienia się na O(log(n)), jeśli ma on wiele elementów.

Podsumowanie

Mam nadzieję, że we w miarę przystępny sposób przybliżyłem zasadę działania HashMap w Java. Prawdopodobnie z wiedzą z tego artykułu nawet pytania najdociekliwszego rekrutera nie powinny stanowić problemu. 🙂

22 maja, 2021 0 comment