subjects.md

Subjects

Diverse subiecte/intrebari discutate la laborator.

SOLID Principles & Constant Interface

Aveti aici despre: SOLID Principles Si despre Constant Interface

Mostenire abstract/normal class

Am mai incercat niste chestii pe care le-am discutat la laborator cu unul din colegii vostrii, nu stiu cat de clar a fost pentru toata lumea, dar sunt cazurile urmatoare:

• Am o clasa de baza: BaseClass, o clasa Animal care extinde clasa BaseClass si dupa aceea clasa Cat, toate clase normale, atunci constructorii nu sunt necesari.

Codul compileaza si fara sa adaugam constructorii. In cazul in care avem constructor in BaseClass, nu avem constructor in Animal si avem constructor in clasa Cat, atunci o sa se apeleze constructorul din BaseClass, chiar daca apelam sau nu constructorul din BaseClass in clasa Animal.

Totul se apeleaza normal, se apeleaza constructorul din Cat(), dupa aceea cel din Animal() si dupa aceea cel din BaseClass().

Ideea din spate este ca in Java se apeleaza constructorul din clasa de baza implicit, inainte de a apela constructorul din clasa derivata.

Astfel, daca in clasa de baza, BaseClass, avem constructori cu parametrii, iar noi nu avem un constructor care sa apeleze constructorul cu parametrii in clasa Animal, o sa primim o eroare de compilare deoarece compilatorul nu gaseste niciun constructor care sa mapeze pe constructorul din clasa BaseClass. (asta in cazul in care nu definim un constructor fara parametrii in BaseClass)

Din acelasi motiv, nu merge sa facem constructorul privat in clasa BaseClass, daca clasa Animal extinde clasa BaseClass, o sa tipe compilatorul la noi.

• Am o clasa de baza BaseClass, o clasa Animal care extinde clasa BaseClass, iar clasa Animal este o clasa abstracta, iar clasa Cat care extinde clasa Animal, clasa Cat fiind o clasa normala, atunci totul se intampla exact la fel.

Am pus pe github si codul la "incercarea" asta.

Gasiti aici si mai multe explicatii.

Order of initialization

'final' keyword on method parameters

V-am zis la primul laborator ca se poate adauga 'final' si la parametrii metodelor.

Cred ca merita aruncat un ochi peste asta si asta.

Abstract Rules

• Only instance methods can be marked abstract within a class, not variables, constructors, or static methods.
• An abstract method can only be declared in an abstract class.
• A non-abstract class that extends an abstract class must implement all inherited abstract methods.
• An abstract class is most commonly used when you want another class to inherit properties of a particular class, but you want the subclass to fill in some of the implementation details.
• An abstract class is not required to include any abstract methods.

A method cannot be marked as both abstract and private. This rule makes sense if you think about it. How would you define a subclass that implements a required method if the method is not inherited by the subclass? The answer is that you can't, which is why the compiler will complain if you try to do it.

While it is not possible to declare a method abstract and private, it is possible (albeit redundant) to declare a method final and private.

Declaring an Immutable Class

Although there are a variety of techniques for writing an immutable class, you should be familiar with a common strategy for making a class immutable:

• Mark the class as final or make all of the constructors private.
• Mark all the instance variables private and final.
• Don't define any setter methods.
• Don't allow referenced mutable objects to be modified.
• Use a constructor to set all properties of the object, making a copy if needed.

COPY ON READ ACCESSOR METHODS

Besides delegating access to any private mutable objects, another approach is to make a copy of the mutable object any time it is requested.

public ArrayList<String> getFavoriteFoods() {
    return new ArrayList<String>(this.favoriteFoods);
}

Of course, changes in the copy won't be reflected in the original, but at least the original is protected from external changes. This can be an expensive operation if called frequently by the caller.

Enum Classes - Constructors

Enum Classes can only have private constructors.

Enum without a constructor:

enum Day{
SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY;
}

Enum with a constructor:

enum Size {
    SMALL("The size is small."),
    MEDIUM("The size is medium."),
    LARGE("The size is large."),
    EXTRALARGE("The size is extra large.");

    private final String pizzaSize;
    // private enum constructor
    private Size(String pizzaSize) {
        this.pizzaSize = pizzaSize;
    }

    public String getSize() {
        return pizzaSize;
    }
}

Why can’t we have a public enum constructor?

We need the enum constructor to be private because enums define a finite set of values (SMALL, MEDIUM, LARGE). If the constructor was public, people could potentially create more value. (for example, invalid/undeclared values such as ANYSIZE, YOURSIZE, etc.).

Enum in Java contains fixed constant values. So, there is no reason in having a public or protected constructor as you cannot create an enum instance. Also, note that the internally enum is converted to class. As we can’t create enum objects explicitly, hence we can’t call the enum constructor directly.

Method References

V-am zis la laborator de method reference, poate asta va ajuta sa va clarificati mai mult despre idee.

Program to interfaces

Un lucru foarte important pe care vi l-am mentionat la laborator este sa programati folosind interfete.

Cred ca v-ar ajuta sa cititi urmatorul articol pentru a intelege problema mai bine. Nu este neaparat de Java, acest lucru trebuind sa fie respectat in orice limbaj de programare, cu mai mult sau mai putin POO.

Incercati sa va faceti putin timp sa il cititi.

Exceptions

Java exceptions are a mechanism for handling errors or exceptional events that occur during program execution. Exceptions allow programmers to write code that gracefully handles unexpected situations that may occur during runtime.

Checked Exceptions

Checked exceptions are exceptions that the Java compiler forces you to handle. If a method throws a checked exception, the calling code must either catch the exception or declare that it throws the exception.

Examples of Checked Exceptions

Examples of checked exceptions include IOException, SQLException, and ClassNotFoundException. These exceptions are typically caused by external factors such as network failures, file I/O errors, or missing resources.

Unchecked Exceptions

Unchecked exceptions are exceptions that do not have to be handled by the calling code. Unchecked exceptions are typically caused by bugs or errors in the code itself.

Examples of Unchecked Exceptions

Examples of unchecked exceptions include NullPointerException, ArrayIndexOutOfBoundsException, and ClassCastException. These exceptions are typically caused by programming errors such as dereferencing null objects, accessing array indices out of bounds, or attempting to cast objects to incompatible types.

Catching Exceptions

To catch an exception in Java, you use a try-catch block. The try block contains the code that may throw an exception, and the catch block contains the code that handles the exception.

Throwing Exceptions

To throw an exception in Java, you use the throw keyword. You can throw any exception, whether it is checked or unchecked.

Best Practices for Exception Handling

Use checked exceptions for recoverable errors and unchecked exceptions for unrecoverable errors. Catch specific exceptions rather than catching general Exception classes. Always log exceptions to help with debugging and troubleshooting. Handle exceptions as close to the source as possible. Use finally blocks to release resources and clean up after exceptions.

Exceptions are an important part of Java programming, allowing you to handle errors and exceptional events during runtime. By following best practices for exception handling, you can write more robust and reliable code.