Przykład innego związku między klasami

import java.util.Objects;

public class Author {
    private String name;
    private int age;

    public Author(String name, int age) {
        this.name = name != null ? name : "";
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name != null ? name : "";
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    @Override
    public String toString() {
        return "Author{" +
                "name='" + name + '\'' +
                ", age=" + age +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Author author = (Author) o;
        return age == author.age &&
                Objects.equals(name, author.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

import java.util.Objects;

public class Book {
    private Author author;
    private double price;

    public Book(Author author, double price) {
        this.author = author != null ? new Author(author.getName(), author.getAge()) : new Author("", 0);
        this.price = price;
    }

    public Author getAuthor() {
        return new Author(author.getName(), author.getAge());
    }

    public void setAuthor(Author author) {
        this.author = author != null ? new Author(author.getName(), author.getAge()) : new Author("", 0);
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }

    @Override
    public String toString() {
        return "Book{" +
                "author=" + author +
                ", price=" + price +
                '}';
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Book book = (Book) o;
        return Double.compare(book.price, price) == 0 &&
                Objects.equals(author, book.author);
    }

    @Override
    public int hashCode() {
        return Objects.hash(author, price);
    }
}

public class TestBook {

    public static void main(String[] args) {
        Author author = new Author("George Orwell", 46);
        Book book = new Book(author, 19.99);

        System.out.println(book);
        Author author1 = book.getAuthor();
        author1.setName("Adam Mickiewicz");
        System.out.println(book);

        Book sameBook = new Book(new Author("George Orwell", 46), 19.99);
        System.out.println("Are books equal? " + book.equals(sameBook));
        System.out.println("Hashcode of book: " + book.hashCode());
        System.out.println("Hashcode of sameBook: " + sameBook.hashCode());
    }
}

Główne kategorie to:

1. Sprawdzone Wyjątki (Checked Exceptions) To wyjątki, które muszą być obsłużone (przechwycone lub zadeklarowane w sygnaturze metody) w kodzie programu. Są to wyjątki, które nie są wynikiem błędów programisty, ale raczej zewnętrznych okoliczności, na które programista nie ma wpływu. Przykłady to:

• IOException: występuje podczas operacji wejścia/wyjścia, np. odczytu pliku.
• SQLException: występuje w trakcie interakcji z bazami danych.
• ClassNotFoundException: pojawia się, gdy próbujemy załadować klasę, która nie istnieje.

2. Niesprawdzone Wyjątki (Unchecked Exceptions) To wyjątki, które nie muszą być jawnie obsługiwane w kodzie programu. W większości przypadków są one wynikiem błędów w kodzie. Do tej kategorii zaliczamy:

• RuntimeException: Jest to klasa bazowa dla wielu wyjątków związanych z błędami, które pojawiają się podczas działania programu. Przykłady to:
  • NullPointerException: występuje, gdy odwołujemy się do metody lub zmiennej obiektu, który jest null.
  • ArrayIndexOutOfBoundsException: występuje, gdy próbujemy uzyskać dostęp do elementu tablicy poza jej zakresem.
  • IllegalArgumentException: wyrzucany, gdy metoda otrzymuje argument, który jest nieprawidłowy lub nieodpowiedni.
• Error: Reprezentuje poważne błędy, które zazwyczaj nie powinny być obsługiwane przez aplikację. Są to sytuacje, które zazwyczaj są poza kontrolą programisty, np. OutOfMemoryError lub StackOverflowError.

Blok try-catch-finally

W Javie, blok try-catch-finally jest mechanizmem do obsługi wyjątków, umożliwiającym wykrycie i eleganckie zarządzanie błędami, które mogą wystąpić podczas wykonania programu. Każda część tego bloku ma swoją specyficzną rolę:

1. Blok try Blok try zawiera kod, który może wygenerować wyjątek. Jest to kod, który jest “ryzykowny” i może powodować błędy w czasie wykonania, takie jak operacje wejścia/wyjścia, parsowanie danych, itp. Jeśli wewnątrz bloku try pojawi się wyjątek, wykonanie kodu w tym bloku jest natychmiast przerywane, a kontrola jest przekazywana do odpowiedniego bloku catch.

2. Blok catch Blok catch służy do przechwycenia i obsługi wyjątków, które mogą zostać zgłoszone w bloku try. Można mieć wiele bloków catch po bloku try, z których każdy może przechwytywać różne typy wyjątków. Blok catch jest wykonany tylko wtedy, gdy typ wyjątku zgłoszonego w bloku try pasuje do typu wyjątku zadeklarowanego w bloku catch.

3. Blok finally Blok finally jest opcjonalny i służy do wykonania kodu, który ma zostać wykonany niezależnie od tego, czy wyjątek został zgłoszony czy nie. Jest to idealne miejsce do umieszczenia kodu czyszczącego lub zamykającego, takiego jak zamknięcie połączenia z bazą danych lub plikiem. Nawet jeśli w bloku try lub catch wystąpi instrukcja return, blok finally zostanie wykonany przed opuszczeniem metody.

Prywatne metody w interfejsie?

Od Javy 9 wprowadzono możliwość definiowania prywatnych metod w interfejsach. Prywatne metody w interfejsach umożliwiają enkapsulację wspólnej logiki, która jest wykorzystywana tylko wewnątrz danego interfejsu, nie będąc dostępną dla klas, które go implementują.

public interface MyInterface {

    // Prywatna metoda niestatyczna
    private void privateMethod() {
        // Implementacja metody
        System.out.println("To jest prywatna metoda w interfejsie.");
    }

    // Prywatna metoda statyczna
    private static void privateStaticMethod() {
        // Implementacja metody
        System.out.println("To jest prywatna statyczna metoda w interfejsie.");
    }

    // Metoda domyślna wykorzystująca prywatną metodę
    default void defaultMethod() {
        privateMethod();
    }

    // Metoda statyczna wykorzystująca prywatną statyczną metodę
    static void staticMethod() {
        privateStaticMethod();
    }
}

Kiedy używać?

1. Unikanie duplikacji kodu: Prywatne metody w interfejsach umożliwiają wyodrębnienie wspólnej logiki używanej przez metody domyślne (default) i/lub statyczne. Dzięki temu można uniknąć powielania tego samego kodu w wielu metodach, co jest zgodne z zasadą DRY (Don’t Repeat Yourself).

2. Enkapsulacja logiki wewnętrznej: Prywatne metody w interfejsie pozwalają na ukrycie szczegółów implementacyjnych, które nie są istotne dla konsumentów interfejsu. Pozwala to na utrzymanie czystości API i zapewnia lepszą separację odpowiedzialności.

3. Ułatwienie utrzymania i rozwoju: Kiedy logika jest skoncentrowana w prywatnych metodach, modyfikacje tej logiki są łatwiejsze do przeprowadzenia i mają mniejszy wpływ na klasy implementujące interfejs, co ułatwia utrzymanie i rozwój kodu.

4. Poprawa czytelności i organizacji kodu: Użycie prywatnych metod pozwala na lepszą organizację kodu w interfejsach, co przekłada się na lepszą czytelność i łatwość zrozumienia struktury interfejsu.

Jednakże, warto pamiętać o kilku ograniczeniach i najlepszych praktykach:

• Ograniczony dostęp: Prywatne metody są dostępne tylko wewnątrz interfejsu, w którym są zdefiniowane. Nie mogą być wykorzystywane przez klasy implementujące interfejs ani inne interfejsy.
• Używaj z umiarem: Chociaż prywatne metody są przydatne, ważne jest, aby nie przesadzać z ich ilością i złożonością. Interfejsy powinny pozostać skoncentrowane na definiowaniu kontraktu, a nie na zbyt szczegółowej implementacji.