Въпроси и информация за подготовка за интервю за работа като Java Developer

Какво представляват SOLID принципите?

Какво представлява Single Responsibility Principle (SRP)

Един клас трябва да има само една отговорност и само една причина да бъде променян.
Ползите включват по-лесно тестване, по-ниско nиво на coupling и по-добра организация.
Пример:

public class Book {
private String name;
private String author;
private String text;
// constructor, getters, and setters
}

Какво представлява принципът Open-Closed (OCP)

Софтуерните компоненти (класове, модули, функции) трябва да бъдат отворени за разширяване, но затворени за промяна.
Това се постига чрез използване на interfaces, abstract classes и inheritance.
Пример:

interface Shape {
double area();
}
class Circle implements Shape 
{ /* implementation / } 
class Rectangle implements Shape 
{ / implementation */ }

Какво представлява Liskov Substitution Principle (LSP)

Подтиповете трябва да могат да заместят своите базови типове, без да променят коректността на програмата. Това следва връзката „is-a“.
Пример:

class Bird 
{ /* common bird behavior / } 
class Sparrow extends Bird 
{ / specific sparrow behavior */ }

Какво представлява Interface Segregation Principle (ISP)

Клиентите не трябва да бъдат принуждавани да зависят от interfaces, които не използват. Разделяй големи interfaces на по-малки и по-специфични.
Пример:

interface Worker {
void work();
}
interface Eater {
void eat();
}
class Robot implements Worker 
{ /* implementation */ }

Какво представлява Dependency Inversion Principle (DIP)

Модулите от по-високо ниво не трябва да зависят от модули от по-ниско ниво; и двата вида трябва да зависят от абстракции. Абстракциите не трябва да зависят от детайли; детайлите трябва да зависят от абстракции.

// Abstraction
interface MessageSender {
void sendMessage(String message);
}
// High-level module
class NotificationService {
private MessageSender messageSender;
public NotificationService(MessageSender messageSender) {
this.messageSender = messageSender;
  }
public void send(String message) {
messageSender.sendMessage(message);
  }
}
// Low-level module
class EmailSender implements MessageSender {
@Override
public void sendMessage(String message) {
System.out.println("Sending Email: " + message);
  }
}
// Another Low-level module
class SmsSender implements MessageSender {
@Override
public void sendMessage(String message) {
System.out.println("Sending SMS: " + message);
  }
}
// Use SmsSender
MessageSender smsSender = new SmsSender();
NotificationService notificationService2 = 
              new NotificationService(smsSender);
notificationService2.send("Hello via SMS!");

Интерфейсът MessageSender служи като абстракцията. Модулът от по-високо ниво NotificationService зависи от тази абстракция вместо от конкретни имплементации.
Модулите от по-ниско ниво като EmailSender и SmsSender също зависят от абстракцията, като имплементират интерфейса MessageSender.

Какво представлява Normalization в SQL

Какво е Normalization?
Normalization включва структуриране на данните в релационна база данни, за да се елиминират аномалии като redundancy. То разбива големи, сложни таблици на по-малки, като същевременно запазва релациите между данните.

Защо Normalization е важна?
Намалява redundancy: Като разделяме данните в по-малки таблици, избягваме съхранението на една и съща информация многократно.
Подобрява query performance: По-малките normalized таблици водят до по-бързо изпълнение на заявки.
Минимизира update anomalies: Промените могат да се правят, без да се засягат други записи.
Подобрява data integrity: Осигурява последователни и точни данни.

Сценарии за прилагане на Normalization
Data integrity: Предотвратява несъответствия при обновяване на данни (например, когато възрастта на клиент се промени).
Efficient querying: Опростява сложни заявки чрез разбиване на данните.
Storage optimization: Премахва излишната redundancy, за да се спести място.

Какво е Microservices monolith?

Какво е monolith?

Monolithic application е изградено като единен, цялостен модул. То стегнато свързва всички компоненти (като client-side UI, database и server-side application) в една обща code base.

Advantages:
Easy Deployment: Тъй като е един единствен executable файл или директория, deployment-ът е лесен и директен.
Development Speed: В ранните етапи от живота на даден проект monolith позволява бързо разработване благодарение на своята простота.
Performance: Централизираната code база може да обработва различни функции ефективно.

Какво представляват Microservices?

Microservices разбиват приложението на по-малки, независимо deploy-ваеми услуги. Всяка услуга е фокусирана върху конкретен бизнес домейн.

Предимства:
Scalability: Microservices позволяват скалиране на отделните компоненти независимо един от друг.
Flexibility: Разработчиците могат да избират различни технологии за всяка услуга.
Isolation: Грешки в една услуга не засягат останалите.

Предизвикателства:
Complexity: Управлението на множество услуги изисква надеждна оркестрация.
Network Overhead: Комуникацията между услугите въвежда latency.
Deployment Complexity: Координирането на updates през множество услуги може да бъде предизвикателство.

Какво е Polymorphism?

Method Overriding:
Когато даден subclass предоставя конкретна имплементация за метод, който вече е дефиниран в неговия superclass.

Method Overloading:
Когато един class има множество методи със същото име, но с различни parameters (различен брой или типове arguments).

Какво е предназначението на Private constructors?

Private constructors се използват в utility класове или constant класове.
Тези класове съдържат само static методи или членове.

Избягване на наследяване (Avoiding Subclassing)

Constructor Delegation:
Private constructors позволяват constructor delegation, при което конкретни конструктори извикват общ private constructor.

Singleton Pattern

За JVM

Compilation:
Когато компилираш .java файл, Java compiler генерира .class файлове, които съдържат bytecode (intermediate representation).
Bytecode е platform-independent и може да се изпълнява на всяка система с съвместима JVM.

Class Loader Subsystem:
Отговаря за зареждането на класовете в паметта.
Чете .class файловете, генерира двоични данни и ги съхранява в method area.
Създава Class object, който представя заредения клас в heap memory.

Example: 
Student s1 = new Student(); 
Class c1 = s1.getClass();

Linking:
Състои се от три стъпки:
Verification: Проверява коректността на .class файла.
Preparation: За side памет за class variables и ги инициализира.
Resolution (optional): Разрешава symbolic references към други класове или methods.

Initialization:
Изпълнява static initializers (напр. static blocks) и инициализира static variables.
Instance variables се инициализират, когато се създаде object.

Execution Engine:
Преобразува bytecode в machine code.
Включва Just-In-Time (JIT) compilation за оптимизация на performance-а.

Накратко, JVM позволява Java програмите да се изпълняват навсякъде, като интерпретира bytecode и управлява memory-то.

Какво представлява private abstract метод?

Use Cases за private методи в abstract класове:

Въпреки че abstract методите не могат да бъдат private, можеш да използваш private методи в abstract клас за различни цели:

Helper Methods: Имплементират обща функционалност, която се споделя от други методи.
Encapsulation: Скриват детайлите на имплементацията от subclasses.
Struct-like класове: Създават малки класове с private методи, които служат като data containers

What is Garbage collector?

Heap Memory:
Java обектите се създават в heap паметта, специално отделена памет зона.
Някои обекти стават недостъпни (вече не са реферирани от програмата).

Garbage Collector (GC):
GC идентифицира и изтрива неизползвани обекти, за да освободи памет.
Работи автоматично на заден фон.
Два типа:
Minor GC: Премахва недостъпните обекти в young generation.
Major GC (Full GC): Изчиства обектите в old generation.

Benefits:
Developers нямат нужда ръчно да изтриват обекти.
GC осигурява наличност на памет и предотвратява OutOfMemoryErrors.

What is OOP?

Four Principles of OOP:

Encapsulation: Групиране на данни (attributes) и методи (functions) заедно в един class, за да се скрият детайлите по имплементацията и да се осигури изчистен interface.

Inheritance: Създаване на нови classes на базата на вече съществуващи, като се наследяват техните attributes и behavior. Това насърчава code reuse.

Polymorphism: Позволява на objects от различни classes да бъдат третирани по един и същи начин чрез общ interface. Това дава гъвкавост и прави системата по-лесна за разширяване (extensibility).

Abstraction: Фокусиране върху важните характеристики, като се скриват ненужните сложности. Abstraction опростява дизайна и го прави по-лесен за поддръжка и управление.

ACID properties играят ключова роля за гарантиране на надеждността и консистентността на транзакциите.

Atomicity:
Транзакциите се изпълняват или изцяло, или изобщо не се изпълняват.
Няма частично изпълнение: ако една транзакция се провали по средата, всички промени, направени в базата данни, се връщат назад (rollback).
Пример: Да разгледаме прехвърляне на $100 от сметка X към сметка Y. Ако транзакцията се провали след като сумата е изтеглена от X, но преди да бъде добавена към Y, базата данни остава консистентна.

Consistency:
Базата данни трябва да поддържа своите integrity constraints преди и след дадена транзакция.
Пример: Ако общата сума преди транзакцията е $700 (X: $500, Y: $200), тя трябва да остане същата и след транзакцията (X: $400, Y: $300).

Isolation:
Множество транзакции могат да се изпълняват едновременно, без да си влияят една на друга.
Промените, направени от една транзакция, не са видими за останалите, докато не бъдат commit-нати.
Гарантира се резултат, еквивалентен на такъв, сякаш транзакциите са изпълнени последователно (serially).
Пример: Изолирането на транзакции предотвратява неконсистентни състояния, причинени от преплетени операции.

Durability:
След като една транзакция бъде commit-ната, нейните промени стават постоянни.
Промените оцеляват при системни повреди или crash-ове.
Гарантира се дълготрайно съхранение на данните.
Пример: Дори след restart на системата, commit-натите промени остават запазени.
Запомни, ACID properties осигуряват основата за надеждни и консистентни операции с бази данни!

Какво представлява Strategy шаблонът?

Описание: Дефинира семейство от algorithms, капсулира всеки от тях и ги прави взаимозаменяеми. Това позволява даден algorithm да се променя независимо от clients, които го използват.
Пример:

// Interface for eat behavior
interface EatBehavior {
void eat();
}
// Concrete implementations of eat behavior
class NormalDiet implements EatBehavior {
@Override
public void eat() {
// Normal food
  }
}
class LosingWeightDiet implements EatBehavior {
@Override
public void eat() {
// Healthy food
  }
}
// Cat class with eat behavior
abstract class Cat {
EatBehavior eatBehavior;
public void eat() {
    eatBehavior.eat();
  }
public void setEatBehavior(EatBehavior eatBehavior) {
 this.eatBehavior = eatBehavior;
  }
}
// Usage
Cat cat = new Cat();
cat.setEatBehavior(new LosingWeightDiet());
cat.eat(); // Cat eats with a healthier diet

Creational Patterns

Тези шаблони са фокусирани върху инстанцирането на класове.
Примери включват

Factory Method,
Problem Statement: Да предположим, че искаме да създаваме различни типове продукти (напр. cars, bikes, cycles), без да обвързваме плътно кода си с конкретни имплементации.
Key Components:
Product: Абстрактен клас или interface, който дефинира общите операции за обектите, които factory-то ще създава.
Concrete Products: Реални класове, които имплементират Product interface-а и представят конкретни типове обекти.
Creator: Абстрактен клас или interface, който декларира factory method-а. Той е отговорен за създаването на Product обекти, но делегира реалното създаване на подкласи.
Concrete Creators: Подкласове на Creator, които имплементират factory method-а. Те решават кой конкретен Concrete Product да създадат, базирано на входни параметри или конфигурация.
Factory Method: Метод, дефиниран в Creator класа, който създава Product обекти. Обикновено е деклариран като abstract в Creator и е имплементиран в Concrete Creators.
Example in Java: Да кажем, че имаме Factory, което произвежда различни типове vehicles. Ето един опростен пример:

// Abstract Product
interface Product {
void display();
}
// Concrete Products
class Car implements Product {
public void display() {
System.out.println("Car created");
  }
}
class Bike implements Product {
public void display() {
System.out.println("Bike created");
  }
}
// Creator (Factory)
interface Factory {
Product factoryMethod();
}
// Concrete Creators
class ConcreteFactoryA implements Factory {
public Product factoryMethod() {
return new Car();
  }
}
class ConcreteFactoryB implements Factory {
public Product factoryMethod() {
return new Bike();
  }
}
public class FactoryMethodExample {
public static void main(String[] args) {
Factory factoryA = new ConcreteFactoryA();
Product productA = factoryA.factoryMethod();
productA.display();
Factory factoryB = new ConcreteFactoryB();
    Product productB = factoryB.factoryMethod();
    productB.display();
}

Builder

Builder Pattern е creational design pattern, който позволява да конструирате сложни обекти стъпка по стъпка,
като разделяте тяхната конструкция от тяхната репрезентация. Ето един прост пример in Java:

// Define the class you want to build
class Post {
private final String title;
private final String text;
private final String category;
Post(Builder builder) {
    this.title = builder.title;
    this.text = builder.text;
    this.category = builder.category;
}
// Getters for properties
public String getTitle() {
    return title;
}
public String getText() {
    return text;
}
public String getCategory() {
    return category;
}
// Builder class
public static class Builder {
    private String title;
    private String text;
    private String category;
    public Builder title(String title) {
        this.title = title;
        return this;
    }
    public Builder text(String text) {
        this.text = text;
        return this;
    }
    public Builder category(String category) {
        this.category = category;
        return this;
    }
    public Post build() {
        return new Post(this);
    }
}
// Usage
public class Main {
public static void main(String[] args) {
Post post = new Post.Builder()
.title("Java Builder Pattern")
.text("Explaining how to implement the Builder Pattern in Java")
.category("Design Patterns")
.build();
System.out.println("Title: " + post.getTitle());
    System.out.println("Text: " + post.getText());
    System.out.println("Category: " + post.getCategory());
  }
}

Prototype

Prototype

Prototype Pattern е creational design pattern, който позволява да създавате нови обекти, като копирате вече съществуващ обект.
Вместо да създавате нови инстанции от нулата, вие clone-вате съществуващ prototype, което може да бъде по-ефективно и по-гъвкаво. Нека разгледаме пример в Java:
Define the Prototype Interface: Първо създаваме abstract class или interface, наречен Tree, с abstract метод copy():

public abstract class Tree {
public abstract Tree copy();
}

Concrete Prototypes: След това имплементираме два concrete класа, които extend-ват Tree: PlasticTree དང་ PineTree. Тези класове представят конкретни видове дървета и предоставят своя собствена имплементация на метода copy():

public class PlasticTree extends Tree {
@Override
public Tree copy() {
PlasticTree plasticTreeClone = new PlasticTree(this.getMass(), 
this.getHeight());
plasticTreeClone.setPosition(this.getPosition());
return plasticTreeClone;
  }
}
public class PineTree extends Tree {
@Override
public Tree copy() {
PineTree pineTreeClone = new PineTree(this.getMass(), 
this.getHeight());
pineTreeClone.setPosition(this.getPosition());
return pineTreeClone;
  }
}

В тези класове ние custom-изираме процеса на cloning според конкретния тип дърво. Например копираме mass, height དང་ position на оригиналното дърво.
Usage: Сега нека създадем инстанции на нашите concrete prototypes:
ཇ་ཝ།

public class Main {
public static void main(String[] args) {
Tree originalPlasticTree = new PlasticTree(10, 5);
Tree clonedPlasticTree = originalPlasticTree.copy();
    Tree originalPineTree = new PineTree(15, 8);
    Tree clonedPineTree = originalPineTree.copy();
    // Use the cloned trees as needed
    // ...
  }
}

Какво представляват Structural Patterns?

Тези шаблони се отнасят до структурата и композицията на един клас.

Adapter Pattern

Adapter Pattern е structural design pattern, който позволява на два несъвместими интерфейса да работят заедно.
Той действа като мост между тези интерфейси, като им позволява да си сътрудничат, без да се променя техният source code.

Object Adapter:
При този подход използваме composition, за да делегираме логиката към adapter-а.
Adapter-ът съдържа Adaptee и делегира метода request() към метода specificRequest() в Adaptee.

class Adaptee {
void specificRequest() {
System.out.println("Adaptee's specific request");
  }
}
// Target interface
interface Target {
void request();
}
// Adapter (using composition)
class Adapter implements Target {
private final Adaptee adaptee;
Adapter(Adaptee adaptee) {
    this.adaptee = adaptee;
}
@Override
public void request() {
    adaptee.specificRequest();
  }
}

Class Adapter:
Изисква multiple inheritance (директно невъзможно в Java).
Можем да го постигнем, използвайки interfaces с default methods.
Adapter-ът наследява както Target, така и Adaptee класовете.

// Target interface
interface Target {
void request();
}
// Adaptee (existing class)
class Adaptee {
void specificRequest() {
System.out.println("Adaptee's specific request");
  }
}
// Adapter (using class inheritance)
class Adapter extends Adaptee implements Target {
@Override
public void request() {
specificRequest();
  }
}

Benefits and Trade-Offs:
Class Adapter работи добре при one-to-one mapping на методи.
Object Adapter осигурява повече гъвкавост и избягва модификация на source code.

Decorator Pattern

Decorator Pattern е creational design pattern, който позволява динамично да добавяш функционалност и поведение към даден обект, без
да влияеш на поведението на други съществуващи обекти в същия клас. Той е особено полезен, когато искаш да разшириш възможностите на един обект,
без да променяш неговата структура.

Overview:
Decorator Pattern предоставя разширен интерфейс към оригиналния обект, като го „обвива“ с допълнителна функционалност.
Предпочитаме composition пред inheritance, за да намалим overhead-а от subclassing.
Decorators могат да бъдат добавяни по време на изпълнение (runtime), което осигурява гъвкавост.
Example Scenario: Да приемем, че имаме ChristmasTree обект и искаме да го декорираме с различни елементи като garland, tinsel и bubble lights. Ще следваме оригиналните Gang of Four design конвенции.
Implementation:

First, create a ChristmasTree interface:
Java
public interface ChristmasTree {
String decorate();
}
Implement the interface with a basic tree:
Java
public class ChristmasTreeImpl implements ChristmasTree {
@Override
public String decorate() {
return "Christmas tree";
  }
}
Next, create an abstract TreeDecorator class that implements 
ChristmasTree and holds the decorated tree:
Java
public abstract class TreeDecorator implements ChristmasTree {
private final ChristmasTree tree;
public TreeDecorator(ChristmasTree tree) {
    this.tree = tree;
}
@Override
public String decorate() {
    return tree.decorate();
  }
}
Now create specific decorators. For example, BubbleLights:
Java
public class BubbleLights extends TreeDecorator {
public BubbleLights(ChristmasTree tree) {
  super(tree);
  }
@Override
public String decorate() {
    return super.decorate() + " with Bubble Lights";
  }
}
public class Garland extends TreeDecorator {
public Garland(ChristmasTree tree) {
super(tree);
}
@Override
public String decorate() {
    return super.decorate() + " with Garland";
}
}
Usage:
Create decorated trees:
public class DecoratorPatternDemo {
public static void main(String[] args) {
ChristmasTree tree1 = new Garland(new ChristmasTreeImpl());
System.out.println(tree1.decorate()); 
// Output: "Christmas tree with Garland"
ChristmasTree tree2 = new BubbleLights(
new Garland(new Garland(new ChristmasTreeImpl())));
    System.out.println(tree2.decorate()); 
    // Output: "Christmas tree with Garland with Garland 
    // with Bubble Lights"
  }
}

Pattern-ът позволява добавяне на decorators по време на изпълнение, което дава гъвкавост да декорираш според нуждите.
Запомни, Decorator Pattern е широко използван в ситуации, в които искаш да разшириш поведението на даден обект, без да модифицираш неговата основна структура.

Facade Pattern

Facade Pattern е структурен design pattern, който опростява взаимодействието с комплексен subsystem, като предоставя унифициран interface.
Той действа като „front door“, за да скрие вътрешната complexност и да направи system-а по-лесен за използване от client-ите.

Composite

Composite Pattern е структурен design pattern, който позволява да композирате обекти в tree структури, за да представите part-whole йерархии.
Основната идея зад Composite Pattern е да се изгради tree структура от обекти, при която отделните (leaf) обекти и composite обектите споделят общ interface.

Base Component (Department): Ще дефинираме прост Department interface като наш base component:

public interface Department {
void printDepartmentName();
}
Leaf Components (FinancialDepartment and SalesDepartment): 
Let’s create classes for financial and sales departments, 
both implementing the Department interface:
public class FinancialDepartment implements Department {
  // Implementation details (e.g., id, name)
  public void printDepartmentName() {
  System.out.println(getClass().getSimpleName());
  }
}
public class SalesDepartment implements Department {
  // Implementation details (e.g., id, name)
  public void printDepartmentName() {
  System.out.println(getClass().getSimpleName());
  }
}
These leaf classes implement the printDepartmentName() 
method and don’t contain references to other Department objects.
Composite Element (HeadDepartment): As a composite class, 
let’s create a HeadDepartment that holds a collection of 
Department components:
import java.util.ArrayList;
import java.util.List;
public class HeadDepartment implements Department {
  private Integer id;
  private String name;
  private List childDepartments;
  public HeadDepartment(Integer id, String name) {
    this.id = id;
    this.name = name;
    this.childDepartments = new ArrayList<>();
  }
  public void printDepartmentName() {
    childDepartments.forEach(Department::printDepartmentName);
  }
  public void addDepartment(Department department) {
    childDepartments.add(department);
  }
  public void removeDepartment(Department department) {
    childDepartments.remove(department);
  }
}

HeadDepartment класът имплементира метода printDepartmentName() и предоставя методи за добавяне и премахване на child departments.
Употреба: Можете да създадете инстанции на leaf departments (например FinancialDepartment, SalesDepartment) и composite department (например HeadDepartment). Добавете leaf departments към composite-а и принтирайте техните имена.

public class Main {
public static void main(String[] args) {
    Department finance = new FinancialDepartment();
    Department sales = new SalesDepartment();
    HeadDepartment headDepartment = new HeadDepartment(1, 
    "Company Departments");
    headDepartment.addDepartment(finance);
    headDepartment.addDepartment(sales);
    headDepartment.printDepartmentName();
  }
}
Output:
FinancialDepartment
SalesDepartment

The Composite Pattern allows you to create flexible tree structures where
individual objects and compositions (composites) can be treated uniformly.

Какво е HASH функция !!!

Hash функцията е математическа функция, която приема вход (или „message“) и връща низ от символи с фиксирана дължина,
който обикновено е последователност от числа и букви. Този изход се нарича „hash value“ или просто „hash“.
Hash функциите се използват широко в computer science и cryptography и имат няколко важни свойства:

Как се използва hash функция и как работи?

Deterministic: Един и същ вход винаги ще генерира един и същ hash.

Fast: Функцията може бързо да изчисли hash стойността за произволен вход.
Unique (almost): Два различни входа трябва да генерират различни hash стойности (стремим се да минимизираме „collisions“).
Irreversible (One-way): При даден hash трябва да е изчислително неизпълнимо да възстановим оригиналния вход.
Uniform: Hash стойностите са равномерно разпределени в изходното пространство.

Hash функциите се използват широко в различни приложения, като например:

Data Integrity: За да се гарантира, че данните не са били променени или фалшифицирани, чрез сравняване на hash стойности.
Password Storage: За сигурно съхранение на hashed пароли вместо реалните пароли.
Cryptography: Използват се в digital signatures и други cryptographic алгоритми.
Hash Tables: За ефективно извличане на данни в програмирането.

Дай ми пример за hash map – как би го имплементирал?

SHA (Secure Hash Algorithm):
Включва варианти като SHA-1, SHA-256, SHA-384 и SHA-512.
SHA-256 и SHA-512 се използват широко в cryptography и blockchain технологии (напр. Bitcoin).

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public class HashExample {
public static void main(String[] args) {
try {
// The input string to be hashed
String input = "Hello, world!";
        // Create a MessageDigest instance for SHA-256
        MessageDigest digest = 
        MessageDigest.getInstance("SHA-256");
        // Compute the hash
        byte[] hash = digest.digest(input.getBytes());
        // Convert the hash bytes to a hexadecimal string
        StringBuilder hexString = new StringBuilder();
        for (byte b : hash) {
            String hex = String.format("%02x", b);
            hexString.append(hex);
        }
        // Print the resulting hash
        System.out.println("SHA-256 Hash: " + 
        hexString.toString());
    } catch (NoSuchAlgorithmException e) {
        System.err.println("Error: " + e.getMessage());
    }
  }
}

Input Data: Променливата за вход съдържа данните, които искаме да „hash“-нем.
MessageDigest Initialization: Инстанцията на MessageDigest се създава чрез getInstance(“SHA-256”), което указва алгоритъма за хеширане SHA-256.
Hashing: Методът digest изчислява hash стойността на входните данни.
Hexadecimal Conversion: Тъй като hash стойността е в двоичен формат, използваме цикъл, за да я преобразуваме в по-четим hexadecimal низ.

Put and Patch ? Кога да ги използваме ?

PUT и PATCH са HTTP методи, използвани за обновяване на ресурси на сървъра, но се различават по начина, по който прилагат промените:

PUT:
Пълно обновяване:
PUT се използва, за да замени напълно съществуващ ресурс.
Целият ресурс трябва да бъде изпратен в заявката, дори ако се променя само част от него.

Ако ресурсът не съществува, PUT често го създава (макар че това поведение може да варира).

Idempotent:

Повтарящите се PUT заявки със същите данни винаги водят до едно и също състояние на ресурса.
Пример: обновяване на потребителски профил:

json
PUT /users/123
{
"name": "Velislav",
"email": "velislav@example.com",
"age": 30
}

Ако се променя само name, но email и age остават същите, те пак трябва да присъстват в заявката.

PATCH:
Частично обновяване:

PATCH се използва за частично обновяване на съществуващ ресурс.
В заявката се изпращат само полетата, които се променят.

Idempotent (Mostly):

Подобно на PUT, повтарящите се PATCH заявки със същите данни обикновено водят до едно и също състояние на ресурса.
Въпреки това поведението може да зависи от имплементацията на сървъра.

Пример: обновяване само на потребителското name:

json
PATCH /users/123
{
"name": "Velislav"
}

Тук се обновява само полето name, а останалите полета остават непроменени.

Основна разлика:
PUT замества целия ресурс, докато PATCH променя само конкретно посочените полета на ресурса.

HTTP methods с кратко описание.

GET: Използва се за извличане на данни от сървъра без да ги променя. Често се използва за fetch на resources или информация.
POST: Използва се за изпращане на данни към сървъра, обикновено за създаване на нов resource. Например, при изпращане на form или upload на file.
PUT: Използва се за update или пълна подмяна на съществуващ resource на сървъра. Ако resource не съществува, може да бъде създаден.
PATCH: Използва се за частичен update на съществуващ resource, като се модифицират само посочените полета.
DELETE: Използва се за изтриване на resource от сървъра.
HEAD: Подобен на GET, използва се за извличане само на headers без body на resource.
OPTIONS: Показва кои HTTP methods са позволени.
TRACE: Used mainly for diagnostic purposes by echoing the request back to the client
CONNECT: Establishes a tunnel to the server, often used for SSL/TLS connections.

Functional Interface

Functional interface в Java е interface, който съдържа точно един abstract method. Тези interfaces се използват основно с lambda expressions и method references, като позволяват по-кратък и по-четим functional programming стил.

Основни характеристики:

1. Single Abstract Method: Functional interface има само един abstract method. Това е същността на неговата функционалност.
2. Default и Static Methods: Functional interfaces могат да съдържат default и static methods, но те не се броят като единствения abstract method.
3. @FunctionalInterface Annotation: Макар тази анотация да е по избор, тя помага, като показва, че даденият interface е предназначен да бъде functional. Ако към interface-а се добавят допълнителни abstract methods, компилаторът хвърля грешка.

Пример:

@FunctionalInterface
interface Calculator {
    int calculate(int a, int b);
}
// Using lambda expression
public class Main {
    public static void main(String[] args) {
        // Implementing the calculate method using a lambda
        Calculator addition = (a, b) -> a + b;
        Calculator multiplication = (a, b) -> a * b;
        System.out.println("Addition: " + 
        addition.calculate(5, 3));  // Output: 8
        System.out.println("Multiplication: " + 
        multiplication.calculate(5, 3));  // Output: 15
    }
}

Use Case:

Интерфейсът Calculator в примера има единствен abstract method calculate, което го прави functional interface.
Това ни позволява да използваме lambda expressions за по-кратка и елегантна имплементация.

Често използвани Functional Interfaces в Java:

Java предоставя няколко вградени functional interfaces в пакета java.util.function, като например:

• Predicate: Приема вход и връща boolean.
• Function: Приема вход и връща резултат от тип R.
• Supplier: Осигурява стойност без вход.
• Consumer: Приема стойност и извършва действие.

Functional interfaces улесняват работата, особено в сценарии като работа с collections, streams или asynchronous tasks.

Те позволяват на Java да възприема functional programming парадигми, като същевременно запазва своя object-oriented характер.

Какво е higher-order function?

Higher-order function е функция, която или приема други функции като аргументи, или връща функция като свой резултат. С други думи, тя оперира с функции, третирайки ги като “first-class citizens”. Това е мощна възможност във функционалните програмни парадигми, която позволява абстракция, повторно използване на код и composition.

Пример за Higher-Order Function в Java:

import java.util.function.Function;
public class Main {
    public static void main(String[] args) {
        // Higher-order function: applies a function to a value
        Function<Integer, Integer> squareFunction = x -> x * x;
        int result = applyFunction(5, squareFunction);
        System.out.println("Square of 5: " + result);  
          // Output: 25
    }
    public static int applyFunction(int value, 
    Function<Integer, Integer> function) {
        return function.apply(value);
    }
}

В горния пример:

• Методът applyFunction е higher-order function, защото приема друга функция (Function<Integer, Integer>) като параметър.

Характеристики:

1. Accepts Functions as Arguments: Higher-order functions могат да приемат други функции като вход, за да изпълнят конкретни операции.
2. Returns Functions: Те могат динамично да генерират и връщат нови функции.
3. Encourages Code Reuse: Насърчава модулен и многократно използваем код, тъй като функциите могат да се предават и комбинират помежду си.

Use Case:

В Java higher-order functions се използват често във функционалното програмиране със streams, lambdas и method references. Например:

List<String> names = Arrays.asList("John", "Jane", "Jake");
names.stream()
     .filter(name -> name.startsWith("J"))  
     // Takes a lambda function as argument
     .forEach(System.out::println);         
  // Takes a method reference as argument

Higher-order functions придават гъвкавост и мощ на Java програмите, позволявайки на разработчиците да пишат чист, стегнат и изразителен код!

Access modifiers (Модификатори за достъп)

В Java, access modifiers контролират видимостта и достъпността на classes, methods и variables.

Ето кратък преглед на четирите access modifiers за един class:

public: Class-ът е достъпен от всеки друг class, независимо в кой package се намира.

protected: Не е приложим за самия class, тъй като protected modifier се използва само за members в рамките на class-а или неговите subclasses (видимост в рамките на същия package или от наследени classes).

default (package-private): Ако не е посочен access modifier, class-ът е достъпен само в рамките на собствения си package.

private: Classes не могат да бъдат декларирани като private. Този modifier е приложим само за inner classes или за class members.

Ще запазвам Java терминологията на английски език, а обясненията ще превеждам на български, като ще се придържам към оригиналната структура и смисъл на текста.

Atomic vs volatile

В Java, както AtomicInteger, така и volatile променливите се използват за управление на concurrency (едновременна работа на няколко threads), но служат за различни цели и имат различно поведение.

Ето подробно обяснение на двете понятия и случаите, в които се използват:

1. AtomicInteger

AtomicInteger е част от package-а java.util.concurrent.atomic и предоставя начин за извършване на atomic (thread-safe) операции върху стойност от тип integer, без да е необходимо изрично използване на synchronization.

Основни характеристики (Key Features)

• Предоставя methods като incrementAndGet(), decrementAndGet() དང་ compareAndSet() за thread-safe, lock-free операции.
• Вътрешно използва hardware-level atomic instructions, за да гарантира thread safety.
• Премахва необходимостта от използване на synchronized blocks или изрични locks.

Пример за AtomicInteger

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicIntegerExample {
    public static void main(String[] args) {
        AtomicInteger counter = new AtomicInteger(0);

        // Increment and get the value atomically
        int newValue = counter.incrementAndGet();
        System.out.println("New Value: " + newValue); 
        // Output: 1

        // Compare and set
        boolean wasUpdated = counter.compareAndSet(1, 100);
        System.out.println("Was Updated: " + wasUpdated); 
        // Output: true
        System.out.println("Updated Value: " + counter.get()); 
        // Output: 100
    }
}

Приложения на AtomicInteger (Use Cases)

1. Counter: Безопасно увеличаване или намаляване на обща integer стойност, достъпвана от няколко threads.
2. Non-blocking Operations: Извършване на thread-safe актуализации без използване на locks.
3. Optimized Performance: По-добра производителност в сравнение със synchronized blocks при среди с висока степен на concurrency.

2. volatile Integer

volatile е Java keyword, който се използва за маркиране на променлива, така че промените в нейната стойност да бъдат видими за всички threads.

Това гарантира visibility на последната стойност на променливата между threads, но не гарантира atomicity.

Основни характеристики (Key Features)

• Гарантира, че всички threads виждат най-актуалната стойност на променливата.
• Не осигурява synchronization, поради което операции като increment (x++) не са thread-safe.
• Полезен е само в по-прости сценарии, при които променливата се чете и записва без междинни изчисления.

Пример за volatile

public class VolatileExample {
    private static volatile int counter = 0;
    public static void main(String[] args) {
        counter++;
        System.out.println("Counter: " + counter); 
        // Not thread-safe!
    }
}

Приложения на volatile (Use Cases)

1. Flags: Прости boolean или integer flags, които се задават или четат от няколко threads.
2. State Management: Променливи, които не изискват съставни операции (като increment) да бъдат atomic.
3. Lightweight Synchronization: Когато е необходима visibility, но не и atomicity.

Основни разлики между AtomicInteger དང་ volatile

Кога кое да използваме? (When to Use What?)

1. Използвайте AtomicInteger, когато:

• Имате нужда от atomic operations (например increment или compare-and-set).
• Променливата се достъпва и променя едновременно от няколко threads.

2. Използвайте volatile, когато:

• Трябва да гарантирате visibility на споделена променлива между threads.
• Не се извършват съставни операции (като increment или addition).

Важно уточнение: volatile не означава, че променливата се съхранява физически само в main memory. То осигурява гаранции за visibility и memory ordering според Java Memory Model (JMM). Също така AtomicInteger не е непременно по-бърз от synchronized във всички ситуации – производителността зависи от натоварването и броя на threads.

Authentication vs Authorisation (Удостоверяване срещу оторизация)

Authentication (Удостоверяване): Процесът на проверка на самоличността на даден потребител. Може да се разглежда като доказване на това кой сте, например чрез Login с username དང་ password.

Видове Authentication

Authorization (Оторизация): Процесът на определяне какво има право да прави даден потребител. След като потребителят премине успешно Authentication, Authorization определя неговите permissions, например достъп до конкретни файлове или функционалности на приложението.

Основна разлика (Key Difference)

• Authentication: „Кой си ти?“ (Who are you?)
• Authorization: „Какво имаш право да правиш?“ (What are you allowed to do?)

Пример:

Ако влезете успешно в една Web Application чрез username དང་ password, това е Authentication.

Ако след Login имате право да отваряте определени страници, да редактирате данни или да изтривате записи според вашата роля (Admin, User, Manager), това е Authorization.

Collections and Big O (Java Collections Framework и времева сложност)

Java Collections Framework (JCF) е набор от interfaces и classes, които позволяват ефективно управление и манипулиране на групи от objects.

Той включва различни data structures (структури от данни), като:

• List – колекция, която съхранява елементите в определен ред и позволява дублиращи се елементи.
• Set – колекция, която не позволява дублиращи се елементи.
• Map – структура, която съхранява данни под формата на двойки key-value. Всеки key трябва да бъде уникален.
• Queue – структура, която обикновено обработва елементите по реда на тяхното добавяне (FIFO – First In, First Out).
• Deque – Double Ended Queue, която позволява добавяне и премахване на елементи от двата края.

Популярни implementations са ArrayList, LinkedList, HashSet, TreeSet, HashMap, TreeMap, PriorityQueue и други.

1. Какво представлява Big O Notation?

Big O Notation е математическа нотация, която описва как нараства времето за изпълнение (Time Complexity) или използваната памет (Space Complexity) на един algorithm спрямо размера на входните данни (n).

С други думи, Big O показва как ще се променя производителността на дадена операция, когато броят на елементите в колекцията се увеличава.

Важно: Big O не измерва конкретното време за изпълнение в секунди, а описва скоростта на нарастване на необходимите операции.

Най-често срещани Big O complexities

Практическо правило: Колкото по-бавно нараства Big O complexity, толкова по-добре обикновено се мащабира algorithm-ът при големи входни данни.

2. Common Big O Complexities in Java Collections

2.1. ArrayList

ArrayList е implementation на List interface. Той използва динамичен array, който автоматично увеличава капацитета си при необходимост.

Кога да използваме ArrayList?

• Когато често достъпваме елементи чрез index.
• Когато добавяме елементи основно в края на колекцията.
• Когато имаме нужда от бърз достъп и последователна обработка на елементите.

2.2. HashMap

HashMap е implementation на Map interface. Той съхранява данните като двойки key-value и използва hashing mechanism за бързо намиране на стойностите.

Забележка: При много hash collisions производителността може да се влоши. В съвременните Java implementations на HashMap някои collision-heavy buckets могат да бъдат преобразувани в balanced trees, което при определени условия подобрява worst-case complexity до O(log n) за операции в съответния bucket.

Основни характеристики:

• Не гарантира реда на елементите.
• Позволява един null key.
• Позволява множество null values.
• Не е thread-safe при конкурентен достъп и промяна от няколко threads.

Кога да използваме HashMap?

• Когато имаме нужда от бързо намиране на стойност по key.
• Когато съхраняваме данни във формат key-value.
• Когато редът на елементите не е от значение.

2.3. TreeMap

TreeMap е implementation на NavigableMap interface и съхранява своите entries сортирани според естествения ред на keys или чрез зададен Comparator.

Вътрешно използва Red-Black Tree – self-balancing binary search tree.

Основни характеристики:

• Поддържа сортиран ред на keys.
• Не позволява null keys при естествено сортиране.
• Позволява null values.
• Предоставя methods като firstKey(), lastKey(), higherKey() དང་ lowerKey().

Кога да използваме TreeMap?

• Когато е необходимо данните да бъдат автоматично сортирани.
• Когато имаме нужда от търсене на най-близък по стойност key.
• Когато използваме операции за работа с диапазони от keys (Range Queries).

2.4. HashSet

HashSet е implementation на Set interface и използва вътрешно HashMap за съхраняване на своите елементи.

Подобно на HashMap, при hash collisions производителността може да се влоши, като съвременните implementations използват tree bins при определени условия.

Основни характеристики:

• Не позволява дублиращи се елементи.
• Не гарантира реда на елементите.
• Позволява един null елемент.
• Използва hashCode() དང་ equals() за определяне на уникалността на обектите.

Кога да използваме HashSet?

• Когато трябва да съхраняваме само уникални елементи.
• Когато искаме бързо да проверяваме дали даден елемент съществува.
• Когато редът на елементите няма значение.

3. Допълнителни важни Java Collections

За интервю за Java Developer е полезно да познавате и следните implementations:

3.1. LinkedList

LinkedList реализира List དང་ Deque interfaces. Вътрешно използва Doubly Linked List, при който всеки node съдържа references към предходния и следващия node.

Важно: LinkedList не е автоматично по-бърз от ArrayList при insertion и removal. Ако трябва първо да намерим позицията по index, пак ще са необходими O(n) операции.

3.2. TreeSet

TreeSet е implementation на NavigableSet и използва вътрешно TreeMap (Red-Black Tree).

Основни характеристики:

• Не позволява дублиращи се елементи.
• Поддържа автоматично сортиран ред.
• Не позволява null при естествено сортиране.

3.3. PriorityQueue

PriorityQueue реализира Queue interface и използва вътрешно Binary Heap.

Основни характеристики:

• Елементът с най-висок приоритет (според зададения ordering) се намира на head позицията.
• По подразбиране използва natural ordering – най-малкият елемент е първи.
• Не гарантира пълно сортиране при итерация.
• Не позволява null elements.

4. Comparison Table – Java Collections

Обобщена таблица за бързо запомняне:

Average/amortized complexity при стандартни условия.

За LinkedList: O(1) при операции в началото или края, или когато вече разполагаме с необходимия node. Операциите по index обикновено са O(n).

*За PriorityQueue: O(1) се отнася до достъп до head чрез peek(), а не до произволен елемент.

5. Важни понятия за Java Developer Interview

1. What is the difference between ArrayList and LinkedList?

• ArrayList използва dynamic array и осигурява O(1) достъп чрез index.
• LinkedList използва Doubly Linked List и осигурява O(n) достъп чрез index.
• LinkedList е подходящ за операции в началото и края на списъка, но има допълнителен memory overhead за references.

2. What is the difference between HashMap and TreeMap?

• HashMap използва hashing и осигурява средно O(1) операции.
• TreeMap използва Red-Black Tree и осигурява O(log n) операции.
• HashMap не гарантира реда на елементите, докато TreeMap поддържа сортирани keys.

3. What is the difference between HashSet and TreeSet?

• HashSet използва hashing и осигурява средно O(1) операции.
• TreeSet използва Red-Black Tree и осигурява O(log n) операции.
• HashSet не гарантира реда, докато TreeSet поддържа сортирани елементи.

4. What is Hash Collision?

Hash Collision възниква, когато два различни objects имат еднакъв hashCode().

HashMap དང་ HashSet използват hashCode() དང་ equals() за правилното съхраняване и намиране на objects.

Важно е да се помни:

• Ако два objects са равни според equals(), те трябва да имат еднакъв hashCode().
• Два objects могат да имат еднакъв hashCode(), но да не са равни според equals().

5. Are Java Collections thread-safe?

Повечето стандартни implementations като ArrayList, HashMap དང་ HashSet не са thread-safe при едновременна промяна от няколко threads.

Java предоставя специализирани concurrent collections:

• ConcurrentHashMap – thread-safe Map.
• CopyOnWriteArrayList – подходящ за сценарии с много read операции и малко write операции.
• BlockingQueue – поддържа thread-safe операции и блокиращо изчакване при определени условия.
• ConcurrentLinkedQueue – non-blocking thread-safe Queue.

6. Най-важното за запомняне

Съвет за Java Developer Interview: Не е достатъчно само да запомните Big O стойностите. Трябва да можете да обясните каква вътрешна структура използва всяка Collection, защо дадена операция е O(1), O(log n) или O(n) и в какъв практически сценарий бихте избрали съответната implementation.

Composite Indexes in Databases (Съставни индекси в бази данни)

Composite Index е един database index, изграден върху две или повече columns в една table.

Използва се за оптимизиране на SQL queries, които филтрират, сортират или търсят данни по няколко columns едновременно.

1. How Composite Indexes Work

Database съхранява стойностите на посочените columns заедно в един index.

Редът на columns е много важен!

Например, ако създадем index върху (A, B, C):

• Ефективен е при търсене по A.
• Ефективен е при търсене по A དང་ B.
• Ефективен е при търсене по A, B དང་ C.
• Обикновено не е ефективен при самостоятелно търсене само по B или C.

Това правило се нарича Leftmost Prefix Rule.

2. Example

Да разгледаме следната table Employees:

Създаваме Composite Index:

CREATE INDEX idx_employee_name
ON Employees (LastName, FirstName);

Query 1:

SELECT * FROM Employees
WHERE LastName = 'Smith'
AND FirstName = 'Jane';

Efficient

Database може ефективно да използва Composite Index.

Query 2:

SELECT * FROM Employees
WHERE FirstName = 'Alice';

Less efficient

Index-ът обикновено не може да се използва ефективно, защото FirstNameне е първата column.

3. Advantages and Disadvantages

Advantages:

• Improved Query Performance – по-бързо изпълнение на queries.
• Reduced Disk I/O – намалява необходимостта от сканиране на голям брой records.
• Better Filtering – по-ефективно филтриране по няколко columns.

Disadvantages:

• Заема допълнително storage space.
• Може да забави INSERT, UPDATE དང་ DELETE, защото index-ът трябва да се актуализира.
• Неправилният ред на columns може да намали ефективността му.

4. When to Use Composite Indexes?

Използвайте Composite Index, когато често изпълнявате queries с комбинация от няколко columns в WHERE, JOIN или ORDER BY.

Важно за Java Developer Interview:

Запомнете три основни неща:

1. Composite Index съдържа две или повече columns.
2. Редът на columns е от съществено значение (Leftmost Prefix Rule).
3. Index-ите ускоряват SELECT, но могат да забавят операциите за промяна на данните (INSERT, UPDATE, DELETE).

Допълнително: Наличието на Composite Index не гарантира, че Database ще го използва. Това зависи от Query Optimizer, статистиката и структурата на конкретния SQL query.

Composite Key (Съставен ключ)

Composite Key е комбинация от две или повече columns в една database table, които заедно осигуряват уникална идентификация на всеки record (ред).

Поотделно тези columns може да не съдържат уникални стойности, но тяхната комбинация трябва да бъде уникална.

1. Example

Да разгледаме database table StudentCourses, която съхранява записванията на студентите за различни курсове.

• StudentID не е уникален, защото един студент може да посещава няколко курса.
• CourseID не е уникален, защото един курс може да има много студенти.
• Комбинацията (StudentID, CourseID) е уникална за всяко записване.

Създаване на Composite Primary Key:

CREATE TABLE StudentCourses (
    StudentID INT,
    CourseID INT,
    EnrollmentDate DATE,
    PRIMARY KEY (StudentID, CourseID)
);

2. When to Use Composite Key?

• При Many-to-Many Relationships – например Students и Courses.
• Когато уникалната идентификация изисква комбинация от няколко columns.
• Когато не е необходим отделен идентификатор (ID) за всеки record.

3. Composite Key vs Composite Index

Важно е да не се бъркат двете понятия:

Важно за Java Developer Interview: Composite Key се използва често при Many-to-Many relationships. В JPA/Hibernate може да бъде реализиран чрез @EmbeddedId или @IdClass.

Composition and Aggregation (Композиция и агрегация)

В Java Composition и Aggregation са два принципа на Object-Oriented Programming (OOP), които описват взаимоотношенията между objects.

И двата представляват форми на Association (асоциация) и описват връзка тип Has-A, но се различават по зависимостта между жизнените цикли на обектите.

1. Composition (Композиция)

Definition: Силна Has-A връзка, при която жизненият цикъл на child object е зависим от жизнения цикъл на parent object.

Key Feature: Parent object притежава child object. Ако parent object бъде премахнат, child object вече няма самостоятелен собственик и обикновено се премахва заедно с него.

Example:

class Engine {
}
class Car {
    private final Engine engine = new Engine();
}

Тук Engine е част от Car. Car създава и притежава своя Engine.

2. Aggregation (Агрегация)

Definition: По-слаба Has-A връзка, при която child object има независим жизнен цикъл от parent object.

Key Feature: Parent и child objects могат да съществуват независимо един от друг.

Example:

class Book {
}
class Library {
    private List<Book> books;
    public Library(List<Book> books) {
        this.books = books;
    }
}

Тук Library съдържа references към Book objects, но книгите могат да съществуват независимо от библиотеката.

3. Key Differences

4. Important for Java Developer Interview

• Composition – силна връзка, при която parent object управлява жизнения цикъл на child object.
• Aggregation – child object може да съществува независимо от parent object.
• И двете са разновидности на Association.
• Java не предоставя специални keywords за Composition и Aggregation. Те се реализират чрез обикновени object references и design decisions.

Запомнете: Composition = Strong ownership. Aggregation = Independent lifecycle.

Важно уточнение: Java не унищожава автоматично child object при премахване на parent object. Garbage Collector освобождава обектите, когато вече няма достижими references към тях. Composition и Aggregation описват логическия дизайн и собствеността, а не автоматичен механизъм за унищожаване.

Concurrency vs Parallelism (Конкурентност срещу паралелизъм)

В Java Concurrency и Parallelism описват два различни начина за изпълнение на множество задачи (tasks).

1. Concurrency (Конкурентност)

Definition: Concurrency означава управление на няколко задачи, които напредват в припокриващи се времеви интервали. Те не е задължително да се изпълняват едновременно.

• Използва се при работа с множество Threads или ExecutorService.
• Един CPU core може да превключва между различни tasks чрез Context Switching.
• Основната цел е ефективно управление на множество задачи.

Example: Един thread обработва заявка към Database, докато друг обработва потребителски input.

2. Parallelism (Паралелизъм)

Definition: Parallelism означава реално едновременно изпълнение на няколко задачи.

• Обикновено използва множество CPU cores.
• В Java се реализира чрез ForkJoinPool དང་ parallelStream().
• Основната цел е увеличаване на производителността чрез едновременно изпълнение на изчисления.

Example: Разделяне на голям набор от данни на няколко части, които се обработват едновременно от различни CPU cores.

3. Key Differences

4. Simple Example

• Concurrency: Един готвач приготвя няколко ястия, като превключва между тях.
• Parallelism: Няколко готвачи приготвят различни ястия едновременно.

Важно за Java Developer Interview:

• Concurrency = Dealing with multiple tasks.
• Parallelism = Doing multiple tasks simultaneously.
• Concurrency може да съществува без Parallelism.
• Parallelism обикновено използва Concurrency, но двете понятия не са идентични.

Допълнително: Не бъркайте Concurrency с Thread Safety. Дори когато няколко threads изпълняват задачи конкурентно, трябва да се осигури правилен достъп до споделените ресурси чрез synchronized, Lock, AtomicInteger и други механизми.

Concurrent vs Synchronized Collections (Конкурентни срещу синхронизирани колекции)

В Java и двата вида Collections осигуряват Thread Safety, но използват различни механизми за управление на едновременния достъп до данните.

1. Synchronized Collections

Definition: Това са стандартни Java Collections, обвити чрез synchronized wrappers от класа java.util.Collections.

Основни характеристики:

• Използват intrinsic locks (monitor locks).
• При извикване на синхронизиран method само един thread може да изпълнява съответната операция върху wrapper-а в даден момент.
• При висока Concurrency могат да създадат bottleneck и да намалят производителността.

Examples:

List<String> list =
    Collections.synchronizedList(new ArrayList<>());
Set<String> set =
    Collections.synchronizedSet(new HashSet<>());
Map<String, Integer> map =
    Collections.synchronizedMap(new HashMap<>());

Use Case: Подходящи са за приложения с ниска Concurrency, когато е необходима проста Thread Safety.

Важно: При обхождане с Iterator трябва допълнително да използваме synchronized върху самата collection.

2. Concurrent Collections

Definition: Това са специализирани Thread-Safe Collections от package-а java.util.concurrent, проектирани за приложения с висока Concurrency.

Основни характеристики:

• Използват Fine-Grained Locking, Lock-Free Algorithms и други оптимизирани механизми.
• Позволяват по-ефективен едновременен достъп от множество threads.
• Обикновено осигуряват по-добра Scalability при висока Concurrency.

Examples:

Use Case: Подходящи са за Multi-threaded applications с интензивен едновременен достъп до данните.

3. Key Differences

4. When to Use What?

• Synchronized Collections: При ниска Concurrency и когато е необходима проста синхронизация.
• Concurrent Collections: При висока Concurrency и когато производителността и Scalability са важни.

Важно за Java Developer Interview:

1. Collections.synchronizedList() използва общ lock за достъпа през wrapper-а.
2. ConcurrentHashMap позволява конкурентни операции без един общ lock за цялата Map.
3. CopyOnWriteArrayList е подходящ при много READ и малко WRITE операции, защото при всяка промяна създава ново копие на вътрешния array.
4. Thread-Safe не означава автоматично, че последователност от няколко операции е atomic.

Запомнете: Synchronized Collections = Shared Lock. Concurrent Collections = Optimized Concurrent Access.

Critical Section (Критична секция)

Critical Section в Java е част от кода, в която се осъществява достъп или промяна на Shared Resources (споделени ресурси), използвани от няколко threads.

Тя трябва да бъде защитена в Multi-threaded environment, за да се избегнат проблеми като Race Conditions, неконсистентни данни и непредвидимо поведение.

1. Key Concepts

1. Shared Resources: Ресурси (variables, objects, data structures), до които имат достъп няколко threads.
2. Mutual Exclusion: Гарантира, че само един thread може да изпълнява защитената секция едновременно.
3. Synchronization: Java предоставя механизми като synchronized དང་ Locks за контрол на достъпа до Critical Section.

2. Example: Critical Section with synchronized

public class Counter {
    private int count = 0;
    public synchronized void increment() {
        count++;
    }
    public synchronized int getCount() {
        return count;
    }
}

Explanation:

• increment() དང་ getCount() са synchronized methods.
• synchronized гарантира, че само един thread едновременно може да изпълнява synchronized method върху същия object.
• Използва се Intrinsic Lock (Monitor Lock) на обекта.
• Предотвратява Race Conditions при достъпа до count.

3. Other Synchronization Tools in Java

Освен synchronized, Java предоставя и други механизми:

1. Locks (java.util.concurrent.locks)

Например ReentrantLock предоставя по-голяма гъвкавост при управление на synchronization.

Lock lock = new ReentrantLock();
lock.lock();
try {
    // Critical Section
} finally {
    lock.unlock();
}

2. Atomic Variables (java.util.concurrent.atomic)

Например AtomicInteger осигурява atomic и thread-safe операции без изрично използване на locks.

AtomicInteger count = new AtomicInteger(0);
count.incrementAndGet();

4. Important for Java Developer Interview

• Critical Section: Част от кода, която работи със shared resources.
• Race Condition: Възниква, когато резултатът зависи от непредвидимото преплитане на операциите на няколко threads.
• Mutual Exclusion: Само един thread изпълнява защитената секция в даден момент.
• Synchronization: Контролира достъпа до shared resources и осигурява необходимата memory visibility.

Запомнете: Целта на Critical Section е да предпази shared data от едновременни несъвместими операции и да гарантира коректността на резултатите.

Dynamic and Static Polymorphism in Java (Статичен и динамичен полиморфизъм)

Polymorphism (Полиморфизъм) е един от основните принципи на Object-Oriented Programming (OOP). Той позволява един и същ method или reference да има различно поведение в зависимост от контекста.

В Java има два основни вида Polymorphism:

1. Static Polymorphism (Compile-Time Polymorphism)

Нарича се още Compile-Time Polymorphism, защото изборът на method се извършва по време на compilation.

Най-често се реализира чрез Method Overloading.

Method Overloading: Няколко methods имат едно и също име, но различни parameters (брой, тип или ред).

Example:

class Calculator {
    int add(int a, int b) {
        return a + b;
    }
    double add(double a, double b) {
        return a + b;
    }
    int add(int a, int b, int c) {
        return a + b + c;
    }
}

Compiler определя кой method да извика въз основа на подадените arguments.

2. Dynamic Polymorphism (Runtime Polymorphism)

Нарича се още Runtime Polymorphism, защото конкретният method се определя по време на изпълнение (runtime).

Реализира се чрез Method Overriding.

Method Overriding: Subclass предоставя собствена implementation на method, наследен от Parent Class.

Example:

class Animal {
    void makeSound() {
        System.out.println("Animal sound");
    }
}
class Dog extends Animal {
    @Override
    void makeSound() {
        System.out.println("Bark");
    }
}
Animal animal = new Dog();
animal.makeSound(); // Bark

Въпреки че reference type е Animal, реалният object е Dog. Затова JVM извиква Dog implementation на makeSound().

3. Key Differences

4. Important for Java Developer Interview

• Overloading = Same method name, different parameters.
• Overriding = Subclass changes the inherited method implementation.
• @Override annotation помага на compiler да провери дали действително се прави overriding.
• static, private དང་ final methods не участват в Dynamic Method Dispatch по същия начин като обикновените instance methods.

Важно уточнение: При Static Polymorphism изборът на overloaded method се извършва според типовете, известни по време на compilation. При Dynamic Polymorphism JVM определя коя overridden instance method implementation да изпълни според реалния object type.

Запомнете:

• Static Polymorphism → Method Overloading → Compile Time.
• Dynamic Polymorphism → Method Overriding → Runtime.

Functional Interface (Функционален интерфейс)

Functional Interface в Java е interface, който има точно един Abstract Method (SAM – Single Abstract Method).

Използва се основно при Lambda Expressions и Method References, за да направи кода по-кратък и четим и да подпомогне Functional Programming.

1. Key Features

1. Single Abstract Method: Functional Interface трябва да има точно един abstract method.
2. Default and Static Methods: Може да съдържа default དང་ static methods, без те да се броят към единствения abstract method.
3. @FunctionalInterface Annotation: Незадължителна annotation, която указва намерението interface-ът да бъде Functional Interface. Compiler проверява дали има точно един abstract method.

2. Example

@FunctionalInterface
interface Calculator {
    int calculate(int a, int b);
}
public class Main {
    public static void main(String[] args) {
        Calculator addition = (a, b) -> a + b;
        System.out.println(addition.calculate(5, 3));
    }
}

Резултат: 8

Тук:

• Calculator има един abstract method – calculate().
• (a, b) -> a + b е Lambda Expression.
• Lambda Expression предоставя implementation на calculate().

3. Common Functional Interfaces in Java

Java предоставя готови Functional Interfaces в package-а java.util.function.

4. Important for Java Developer Interview

• Functional Interface = Exactly one Abstract Method.
• Използва се с Lambda Expressions и Method References.
• @FunctionalInterface не е задължителна, но помага за проверка от compiler.
• Може да съдържа множество default དང་ static methods.
• Methods, съвпадащи с public methods от Object (например toString()), не се броят като допълнителни abstract methods.

Запомнете: Functional Interface е основата на Lambda Expressions в Java и позволява да подаваме поведение (behavior) като аргумент на methods.

Functional Programming (FP) – Функционално програмиране

Functional Programming (FP) е програмна парадигма, при която изчисленията се разглеждат като изпълнение на математически функции.

Основната идея е да се избягват променливото състояние (Mutable State) и страничните ефекти (Side Effects), като се използват Pure Functions и Immutable Data.

1. Core Ideas of Functional Programming

• Pure Functions: Функции, които при еднакви входни данни винаги връщат еднакъв резултат и нямат Side Effects.
• Immutability: Данните не се променят след създаването им.
• First-Class Functions: Функциите могат да се съхраняват в променливи, да се подават като аргументи и да се връщат от други функции.
• Higher-Order Functions: Функции, които приемат други функции като аргументи или връщат функции.
• Declarative Style: Описва се какво трябва да се направи, вместо подробно как да се направи.
• Recursion: Използване на функция, която извиква сама себе си, вместо традиционни loops.
• Lazy Evaluation: Изчисленията се извършват само когато резултатът е необходим (поддържа се от някои езици).

2. Examples of Functional Programming Languages

Pure / Primarily Functional

Multi-paradigm (FP + OOP / Imperative)

3. Functional Programming in Java

Java не е Pure Functional Programming Language, а Multi-paradigm Language – комбинира OOP, Imperative Programming и Functional Programming.

От Java 8 са въведени важни функционални възможности:

• Lambda Expressions – кратък начин за реализиране на Functional Interfaces.
• Functional Interfaces – например Predicate, Function, Consumer དང་ Supplier.
• Stream API – обработка на колекции чрез filter(), map() དང་ reduce().
• Method References – използване на съществуващи methods като функционални операции.
• Optional – помага за по-ясна обработка на възможно липсващи стойности.

Example:

List<Integer> numbers = List.of(1, 2, 3, 4, 5);
List<Integer> result = numbers.stream()
        .filter(n -> n % 2 == 0)
        .map(n -> n * n)
        .toList();
System.out.println(result); // [4, 16]

Тук:

• filter() избира четните числа.
• map() повдига всяко число на квадрат.
• toList() създава нов List с резултатите.

4. Summary

• Functional-only / Primarily Functional: Haskell, Erlang, Elixir, Scheme, OCaml, F#.
• Multi-paradigm: Scala, Kotlin, JavaScript, Python, Rust, Swift, Java.

Важно за Java Developer Interview: Java поддържа Functional Programming чрез Lambda Expressions, Functional Interfaces и Stream API, но остава Multi-paradigm Language, а не Pure Functional Language.

Garbage Collector (GC) – Събирач на неизползвана памет

1. Heap Memory

Heap Memory е област от паметта на JVM, в която се съхраняват Java objects и arrays.

Когато даден object вече не може да бъде достигнат чрез references от активната програма, той става Eligible for Garbage Collection (подлежащ на освобождаване от GC).

2. Garbage Collector (GC)

Garbage Collector е автоматичен механизъм на JVM, който открива и освобождава паметта, заета от objects, които вече не са достижими (Unreachable Objects).

GC работи автоматично, без програмистът да трябва ръчно да изтрива objects.

Основни видове Garbage Collection

• Minor GC (Young GC): Обработва Young Generation – областта, в която се намират новосъздадени objects.
• Major GC: Термин, използван за събиране на памет в Old Generation. Точното значение зависи от GC implementation.
• Full GC: По-широка операция, която обикновено включва обработка на целия Heap.

3. Generations in Heap Memory

При традиционната Generational GC организация Heap Memory се разделя на:

• Young Generation: За новосъздадени objects. Включва Eden Space и Survivor Spaces.
• Old Generation (Tenured Generation): За objects, които са оцелели след няколко GC cycles.

4. Benefits of Garbage Collection

• Automatic Memory Management: Не е необходимо ръчно освобождаване на паметта.
• Reduced Memory Leaks: Намалява риска от грешки при управление на паметта.
• Memory Reclamation: Освобождава памет от unreachable objects.

5. Important for Java Developer Interview

• GC освобождава паметта от unreachable objects, а не просто от objects, които не използваме логически.
• System.gc() само предлага на JVM да извърши Garbage Collection – не гарантира изпълнението му.
• Garbage Collection не предотвратява всички OutOfMemoryError ситуации.
• Дори при автоматичен GC могат да възникнат Memory Leaks, например когато ненужни objects продължават да бъдат достижими чрез references.
• GC може временно да спира изпълнението на application threads (Stop-The-World Pause), в зависимост от използвания Garbage Collector.

Запомнете: Garbage Collector автоматично управлява освобождаването на Heap Memory, но програмистът все още носи отговорност за правилното управление на references и ресурсите.

GoF – Gang of Four (Design Patterns)

GoF (Gang of Four) е наименованието на четиримата автори на известната книга Design Patterns: Elements of Reusable Object-Oriented Software (1994).

Четиримата автори

1. Erich Gamma
2. Richard Helm
3. Ralph Johnson
4. John Vlissides

1. What are GoF Design Patterns?

GoF не е един конкретен принцип, а съвкупност от 23 класически Design Patterns, които предлагат доказани решения на често срещани проблеми при Object-Oriented Software Design.

Те са разделени в три основни категории:

A. Creational Patterns (Създаващи модели)

Свързани са със създаването и инициализирането на objects.

1. Singleton
2. Factory Method
3. Abstract Factory
4. Builder
5. Prototype

B. Structural Patterns (Структурни модели)

Описват как се комбинират classes и objects за изграждане на по-големи структури.

1. Adapter
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy

C. Behavioral Patterns (Поведенчески модели)

Описват взаимодействието между objects и разпределянето на отговорностите между тях.

1. Observer
2. Strategy
3. Command
4. State
5. Visitor
6. Mediator
7. Iterator
8. Memento
9. Template Method
10. Chain of Responsibility
11. Interpreter

2. Underlying Design Principles

GoF популяризират няколко важни принципа на Software Design:

• Encapsulation of Change: Изолиране на частите от кода, които се променят, от тези, които остават постоянни.
• Program to an Interface, Not an Implementation: Използване на interfaces вместо директна зависимост от конкретни implementations.
• Favor Composition Over Inheritance: Предпочитане на Composition пред Inheritance, когато това осигурява по-гъвкав дизайн.
• Loose Coupling: Намаляване на зависимостите между components.
• High Cohesion: Групиране на свързани функционалности в един component.
• Reusability and Maintainability: Създаване на код, който е лесен за повторна употреба и поддръжка.

3. Important for Java Developer Interview

Запомнете трите категории:

Важно уточнение: GoF Design Patterns не са задължителни правила или готов код за копиране. Те са общоприети решения, които се адаптират според конкретния проблем.

Запомнете: GoF = 4 authors + 23 Design Patterns + 3 categories.

Hash Function (Хешираща функция)

Hash Function е математическа функция, която приема входни данни с произволна дължина (Input) и генерира резултат с фиксирана дължина, наречен Hash Value или Hash.

Hash Functions се използват широко в Java, Databases, Cryptography и Data Structures.

1. Key Properties of Hash Functions

• Deterministic: Един и същ Input винаги генерира един и същ Hash.
• Fast: Hash Value се изчислява бързо.
• Collision Resistance: Трудно е да се намерят два различни inputs с еднакъв Hash.
• Irreversible (One-way): Практически е невъзможно да се възстанови оригиналният Input само от Hash.
• Uniform Distribution: Hash Values трябва да бъдат равномерно разпределени.

Hash Collision: Възниква, когато два различни inputs генерират еднакъв Hash Value.

2. Where Are Hash Functions Used?

3. SHA (Secure Hash Algorithm)

SHA е семейство от Cryptographic Hash Algorithms.

Важно: SHA-1 вече не се счита за сигурен срещу collision attacks. SHA-256 и SHA-512 продължават да се използват широко в Cryptography.

4. Java Example – SHA-256

В Java използваме MessageDigest от package-а java.security.

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.HexFormat;
public class HashExample {
    public static void main(String[] args)
            throws NoSuchAlgorithmException {
        String input = "Hello Java";
        MessageDigest digest =
                MessageDigest.getInstance("SHA-256");
        byte[] hash = digest.digest(
                input.getBytes(
                java.nio.charset.StandardCharsets.UTF_8)
        );
        String hexHash = HexFormat.of().formatHex(hash);
        System.out.println(hexHash);
    }
}

Explanation

1. Input Data: input съдържа данните, които искаме да хешираме.
2. MessageDigest Initialization: getInstance("SHA-256") създава instance с избрания hashing algorithm.
3. Hashing: digest() изчислява Hash Value и връща резултат като byte[].
4. Hexadecimal Conversion: HexFormat преобразува binary резултата в четим hexadecimal String.

5. HashMap in Java – Example

HashMap е Data Structure, която използва Hashing за съхраняване и намиране на данни чрез двойки key-value.

import java.util.HashMap;
import java.util.Map;
public class Main {
    public static void main(String[] args) {
        Map<Integer, String> employees = new HashMap<>();
        employees.put(101, "John");
        employees.put(102, "Alice");
        employees.put(103, "Peter");
        // Retrieve value by key
        System.out.println(employees.get(102));
        // Check if key exists
        System.out.println(employees.containsKey(101));
        // Remove entry
        employees.remove(103);
    }
}

Как работи HashMap?

1. Извиква hashCode() върху Key.
2. Изчислява позицията (Bucket) във вътрешната структура.
3. Съхранява Key и Value в съответния Bucket.
4. При get(key) отново използва Hashing, за да намери Bucket-а.
5. Използва equals() за проверка на конкретния Key, особено при Hash Collisions.

HashMap – принцип на работа

put(101, "John")

hashCode() → Hash Value

Calculate Bucket Index

Bucket → Key + Value

6. Important for Java Developer Interview

Не бъркайте двата вида Hashing:

Запомнете още три неща:

• hashCode() དང་ equals() трябва да бъдат правилно реализирани при създаване на собствен Key за HashMap.
• Два обекта с еднакъв hashCode() не са задължително равни.
• Passwords не трябва да се съхраняват чрез обикновен SHA-256. За тях се използват специализирани алгоритми като Argon2id, bcrypt или PBKDF2, със Salt.

Най-важното: Hash Function преобразува данни в Hash Value. В Java HashMap използва Hashing за бързо съхраняване и намиране на key-value pairs.

Higher-Order Function (Функция от по-висок ред)

Higher-Order Function е функция (или method), която приема други функции като arguments или връща функция като резултат.

Тя третира функциите като First-Class Citizens, което позволява по-гъвкав и многократно използваем код.

1. Example in Java

import java.util.function.Function;
public class Main {
    public static int applyFunction(
            int value,
            Function<Integer, Integer> function) {
        return function.apply(value);
    }
    public static void main(String[] args) {
        int result = applyFunction(5, x -> x * x);
        System.out.println(result); // 25
    }
}

Explanation:

• applyFunction() е Higher-Order Function, защото приема друга функция като argument.
• Function<Integer, Integer> е Functional Interface.
• x -> x * x е Lambda Expression.
• function.apply(value) изпълнява подадената функция.

2. Characteristics

1. Accepts Functions as Arguments: Приема функции като входни параметри.
2. Returns Functions: Може да връща функции като резултат.
3. Code Reusability: Позволява повторна употреба на код.
4. Function Composition: Позволява комбиниране на няколко функции.

3. Use Cases in Java

Higher-Order Functions се използват широко със Stream API, Lambda Expressions и Method References.

Example – Stream API:

List<Integer> numbers = List.of(1, 2, 3, 4, 5);
List<Integer> result = numbers.stream()
        .filter(n -> n > 2)
        .map(n -> n * 10)
        .toList();
System.out.println(result); // [30, 40, 50]

Тук:

• filter() приема Predicate функция.
• map() приема Function функция.
• И двата methods са Higher-Order Functions.

4. Important for Java Developer Interview

• Higher-Order Function: Приема или връща функции.
• First-Class Function: Функцията може да бъде предавана и използвана като стойност.
• Lambda Expression: Кратък начин за предоставяне на implementation на Functional Interface.
• Functional Interface: Interface с точно един abstract method.

Запомнете: Higher-Order Functions позволяват да предаваме поведение (Behavior) като параметър, вместо да предаваме само данни.

Main HTTP Error Codes (Основни HTTP статус кодове)

HTTP Status Codes са трицифрени кодове, които server изпраща към client, за да покаже резултата от обработката на HTTP request.

Те са разделени на пет основни категории:

1. Informational (100–199)

Информация за състоянието на request-а.

2. Success (200–299)

Request-ът е обработен успешно.

3. Redirection (300–399)

Необходимо е допълнително действие от client, обикновено пренасочване.

4. Client Errors (400–499)

Проблем с request-а, изпратен от client.

5. Server Errors (500–599)

Проблем при обработката на request-а от server.

6. Important for Java Developer Interview

Особено важно е да запомните следните HTTP Status Codes:

Важна разлика:

• 401 Unauthorized = Не сте успешно Authentication.
• 403 Forbidden = Идентифицирани сте, но нямате необходимите Permissions.

Запомнете петте категории:

• 1xx – Informational
• 2xx – Success
• 3xx – Redirection
• 4xx – Client Errors
• 5xx – Server Errors

HTTP Methods (HTTP методи)

HTTP Methods определят какво действие иска да извърши client върху даден resource на server. Използват се при REST APIs и Web Applications.

1. Main HTTP Methods

2. Important Concepts

HTTP Methods имат няколко важни характеристики:

• Safe Methods: Не трябва да променят състоянието на server. Например GET, HEAD དང་ OPTIONS.
• Idempotent Methods: Повторното изпълнение на един и същ request има същия предвиден ефект върху server, както еднократното изпълнение. Например GET, PUT དང་ DELETE.
• Non-idempotent: Повторното изпълнение може да създаде допълнителни промени. Типичен пример е POST.

3. Example – REST API

Да разгледаме API за управление на Users:

4. Important for Java Developer Interview

Запомнете най-важните разлики:

• GET – Read.
• POST – Create.
• PUT – Full Update / Replace.
• PATCH – Partial Update.
• DELETE – Delete.

Особено важно:

• PUT е Idempotent, докато POST по принцип не е.
• PATCH не е задължително Idempotent – зависи от операцията.
• GET не трябва да променя данни на server.
• PUT དང་ DELETE са Idempotent по дефиниция на HTTP semantics, дори ако server връща различни status codes при повторни заявки.

Запомнете: HTTP Methods определят действието, а HTTP Status Codes показват резултата от изпълнението на request-а.

Interface vs Abstract Class (Интерфейс срещу абстрактен клас)

В Java Interface и Abstract Class се използват за постигане на Abstraction (абстракция), но имат различни характеристики и приложения.

1. Interface

Definition: Interface дефинира договор (Contract), който един class трябва да спазва, когато го имплементира чрез implements.

Основни характеристики:

• Може да съдържа abstract, default དང་ static methods.
• От Java 9 може да съдържа и private methods.
• Abstract methods са public по подразбиране.
• Всички fields са public static final по подразбиране (константи).
• Един class може да имплементира множество interfaces.
• Не може да има constructors.

Example:

interface Animal {
    void makeSound();
}
class Dog implements Animal {
    @Override
    public void makeSound() {
        System.out.println("Bark");
    }
}

2. Abstract Class

Definition: Abstract Class е базов class, който служи за наследяване чрез extends и предоставя обща структура и функционалност на своите subclasses.

Основни характеристики:

• Може да съдържа abstract དང་ concrete methods.
• Може да има fields с различни access modifiers.
• Може да има constructors.
• Може да има static, final и обикновени instance methods.
• Не може да бъде инстанциран директно.
• Един class може да наследява само един class.

Example:

abstract class Animal {
    String name;
    Animal(String name) {
        this.name = name;
    }
    abstract void makeSound();
    void sleep() {
        System.out.println("Sleeping...");
    }
}
class Dog extends Animal {
    Dog(String name) {
        super(name);
    }
    @Override
    void makeSound() {
        System.out.println("Bark");
    }
}

3. Key Differences

4. When to Use What?

Use Interface when:

• Искаме да дефинираме общ Contract за различни classes.
• Искаме един class да имплементира множество interfaces.
• Classes нямат задължително общ Parent Class.

Use Abstract Class when:

• Искаме да споделяме общ код между наследени classes.
• Имаме общи fields и constructors.
• Искаме да предоставим частична implementation, която subclasses да допълват.

5. Important for Java Developer Interview

Пример:

Представете си, че имаме Car, Airplane དང་ Boat.

• Interface Flyable може да дефинира fly() – както за Airplane, така и за други летящи обекти.
• Abstract Class Vehicle може да съдържа общи fields като speed, brand и methods като start().

Запомнете:

• Interface = What a class can do (Contract).
• Abstract Class = What a class is and what common functionality it shares.
• Interface позволява Multiple Inheritance на типове.
• Abstract Class позволява споделяне на state и implementation.

Допълнително уточнение: Interface вече не означава само abstract methods. От Java 8 поддържа default དང་ static methods, а от Java 9 – private methods.

Java Versions – История и основни нововъведения

Java се развива чрез нови версии, които въвеждат подобрения в езика, JVM, Performance, Security, Garbage Collection и Concurrency.

От Java 9 насам Oracle следва приблизително шестмесечен цикъл на издаване – през март и септември.

Важно разграничение:

• LTS (Long-Term Support): Версии с дългосрочна поддръжка.
• Non-LTS: Междинни версии с по-кратък период на поддръжка.
• GA (General Availability): Официално издадена стабилна версия.
• Preview / Incubator: Експериментални или предварителни функционалности, които не трябва да се приемат за окончателни.

1. Java Versions and Highlights

Следващата таблица включва официално издадените версии до Java 27 (ноември 2026). Посочени са основно финализираните функционалности, а не Preview features.

Източници: официалните JDK Release Notes དང་ Oracle Java SE Support Roadmap. Oracle+3

2. Important Java Features Explained

A. Virtual Threads (Java 21)

Virtual Threads са леки threads, управлявани от JVM, вместо да съответстват директно едно към едно на OS threads.

• Могат да бъдат създавани в много голям брой.
• Използват малко памет спрямо традиционните Platform Threads.
• При blocking I/O могат автоматично да бъдат suspended, освобождавайки carrier thread.
• Подходящи са за приложения с много едновременни заявки – Web Servers, REST APIs и Microservices.

B. Structured Concurrency

Structured Concurrency третира група от паралелни задачи като една логическа единица.

Основни предимства:

• Simplicity: Всички задачи се управляват в общ scope.
• Reliability: По-лесно обработване на exceptions.
• Cancellation: Свързани задачи могат да бъдат отменени при грешка.
• Resource Management: По-добър контрол върху жизнения цикъл на задачите.

Preview in Java 27

Важно: Structured Concurrency все още не е финализирана дори в Java 27.

C. Scoped Values (Java 25)

Scoped Values предоставят механизъм за споделяне на неизменяеми данни между methods и threads в рамките на определен scope.

Предимства:

• По-безопасна алтернатива на много употреби на ThreadLocal.
• Неизменяеми bindings.
• Автоматично ограничаване на достъпа според scope.
• Подходящи за Virtual Threads и предаване на Request ID, User Context и други данни.

Final in Java 25

D. Stable Values / Lazy Constants

Това е функционалност, която все още се развива.

Идеята е да се създават стойности, които се инициализират отложено (Lazy Initialization), но след инициализация се третират като неизменяеми константи.

Ползи:

• По-гъвкава инициализация.
• Възможност за JVM оптимизации.
• Полезни при Configuration и Caching.

Preview in Java 27

Важно: Това не е механизъм за произволни Atomic Updates или променливи със семантика на volatile.

E. Compact Object Headers (Java 25–27)

Compact Object Headers намаляват размера на заглавната част на Java objects в Heap Memory.

Предимства:

• По-малко използвана памет.
• По-добра Memory Density.
• По-добро използване на CPU Cache.
• Потенциално по-добра производителност при приложения с милиони objects.

В Java 27 Compact Object Headers стават Default в HotSpot JVM. Oracle

F. Generational Shenandoah GC (Java 25)

Generational Shenandoah разделя Heap Memory на:

• Young Generation: За новосъздадени objects.
• Old Generation: За дълго живеещи objects.

Предимства:

• По-ефективно събиране на неизползвана памет.
• По-ниски GC pauses.
• По-добра производителност при приложения с много allocations.
• Запазва ниската латентност на Shenandoah.

G. Generational ZGC (Java 23)

Generational ZGC използва Young и Old Generations, за да оптимизира Garbage Collection.

Основни предимства:

• По-рядко сканиране на дълго живеещи objects.
• По-малко GC overhead.
• Много ниски pause times.
• Подходящ за приложения с големи Heap Memory размери.

В Java 23 Generational Mode става стандартният режим на ZGC.

H. HTTP/3 Support (Java 26)

Java 26 добавя поддръжка на HTTP/3 в Java HTTP Client API.

HTTP/3 използва QUIC вместо TCP и предоставя:

• По-бързо установяване на връзки.
• По-добра работа при загуба на пакети.
• По-ефективна мрежова комуникация.

I. Post-Quantum Cryptography (Java 27)

Java 27 добавя Post-Quantum Hybrid Key Exchange за TLS 1.3.

Това комбинира традиционни и quantum-resistant cryptographic algorithms с цел по-добра защита срещу бъдещи заплахи от квантови компютри. Oracle

3. LTS Versions – най-важните версии

Към ноември 2026 официалните LTS версии са:

Следващата планирана LTS версия е Java 29 през септември 2027 г. Oracle United Kingdom

4. Which Java Version Should You Know for a Java Developer Interview?

Моят съвет е да обърнеш най-голямо внимание на:

1. Java 8 – Lambda Expressions, Stream API, Functional Interfaces, Optional.
2. Java 11 – HTTP Client API, String methods, локални var променливи в Lambda parameters.
3. Java 17 – Sealed Classes, Pattern Matching, Records (финализирани още в Java 16).
4. Java 21 – Virtual Threads, Pattern Matching for switch, Record Patterns, Sequenced Collections.
5. Java 25 – Scoped Values, Compact Source Files, Module Import Declarations.

Най-важното за запомняне

• Latest GA Version: Java 27
• Latest LTS Version: Java 25
• Previous LTS Version: Java 21
• Virtual Threads: Java 21
• Structured Concurrency: все още Preview в Java 27.
• Scoped Values: Final в Java 25.
• Compact Object Headers: Default в Java 27.

Сравнение на съвременните възможности (Modern Features Comparison): Kotlin vs Java

И двата езика работят върху JVM (Java Virtual Machine) и имат сходни възможности, но се различават по синтаксис, типова система и начин на разработка.

1. Сравнение на основните функционалности

Важно уточнение: Java вече има record, Pattern Matching и Virtual Threads. Затова някои от традиционните предимства на Kotlin вече имат частичен или функционален еквивалент в съвременната Java.

2. Кога да изберем Kotlin?

Изберете Kotlin, когато:

• Разработвате нови Android приложения.
• Създавате съвременни Microservices със Spring Boot или Ktor.
• Искате по-кратък и изразителен код с по-малко Boilerplate.
• Имате нужда от по-добра защита срещу NullPointerException.
• Използвате Coroutines за асинхронни и конкурентни операции.
• Създавате много DTO и Domain Models, подходящи за data class.

3. Кога да изберем Java?

Изберете Java, когато:

• Поддържате или разширявате големи съществуващи Enterprise системи.
• Екипът ви има основно Java Developers.
• Проектът изисква консервативен и дългосрочно утвърден технологичен избор.
• Използвате библиотеки, Frameworks и инструменти с приоритетна поддръжка на Java.
• Разполагате с утвърдени Java Development процеси и инструменти.

4. Кой език да използваме?

За нови проекти, особено при Back-end Services, Cloud Microservices и Android Applications, Kotlin може да бъде много добър избор.

Основните му предимства са:

• По-кратък и четим синтаксис.
• Вградена Null Safety.
• data class за DTO и Domain Objects.
• Coroutines за асинхронна обработка.
• Отлична интеграция със Spring Boot и JVM Frameworks.

За големи съществуващи Java проекти и Enterprise системи Java често остава по-практичният избор благодарение на:

• Огромна екосистема от библиотеки.
• Зрели Development Tools и документация.
• Голям брой опитни Java Developers.
• Дългогодишна стабилност и съвместимост.

5. Смесен подход (Java + Kotlin)

В много реални проекти най-доброто решение е използването на двата езика едновременно.

དཔེར་ན:

• Съществуващите Legacy Modules остават написани на Java.
• Новите Services и Components могат да бъдат разработвани на Kotlin.
• Двата езика могат да взаимодействат чрез JVM Interoperability.

Това позволява постепенно модернизиране на системата, без да се налага цялостно пренаписване.

Важно за Java Developer Interview

1. Kotlin и Java се компилират до JVM Bytecode.
2. Kotlin е напълно interoperable с Java, но има някои особености при взаимодействието между типовете.
3. Java има record, който частично покрива функционалността на Kotlin data class.
4. Java Virtual Threads (Java 21+) улесняват създаването на мащабируеми concurrent приложения.
5. Kotlin Coroutines и Java Virtual Threads са различни технологии и не трябва да се разглеждат като едно и също.

Запомнете: Kotlin не заменя Java. Двата езика могат да работят заедно в една JVM система. Изборът зависи от проекта, екипа, архитектурата и съществуващата технологична инфраструктура.

Сравнение на съвременните възможности (Modern Features Comparison): Kotlin vs Java

И двата езика работят върху JVM (Java Virtual Machine) и имат сходни възможности, но се различават по синтаксис, типова система и начин на разработка.

1. Сравнение на основните функционалности

Важно уточнение: Java вече има record, Pattern Matching и Virtual Threads. Затова някои от традиционните предимства на Kotlin вече имат частичен или функционален еквивалент в съвременната Java.

2. Кога да изберем Kotlin?

Изберете Kotlin, когато:

• Разработвате нови Android приложения.
• Създавате съвременни Microservices със Spring Boot или Ktor.
• Искате по-кратък и изразителен код с по-малко Boilerplate.
• Имате нужда от по-добра защита срещу NullPointerException.
• Използвате Coroutines за асинхронни и конкурентни операции.
• Създавате много DTO и Domain Models, подходящи за data class.Изберете Kotlin и когато:
• Разработвате мобилни приложения за Android и iPhone.
• Искате да споделяте Business Logic между Android и iOS.
• Искате да използвате общ код за Networking, Database и Data Models.
• Искате да създавате Cross-platform приложения чрез Compose Multiplatform, без задължително да използвате Flutter или React Native.

Допълнителни възможности на Kotlin – Mobile Development

Kotlin позволява разработване на мобилни приложения както за Android, така и за iPhone (iOS) чрез технологията Kotlin Multiplatform (KMP).

• Android: Kotlin е официално поддържан и предпочитан език за Android Development. Може да се използва с Android Studio и Jetpack Compose.
• iPhone (iOS): Чрез Kotlin Multiplatform може да се споделя общ код между Android и iOS приложенията – например Business Logic, Networking, Data Models и Database Access.
• Cross-platform Development: Kotlin Multiplatform позволява повторно използване на код между различни операционни системи, като същевременно запазва възможността за Native UI.
• Compose Multiplatform: Позволява изграждане на потребителски интерфейси за Android, iOS, Desktop и Web с общ Kotlin код.

Важно: Kotlin не компилира директно обикновен Android код за iPhone. За iOS Kotlin Multiplatform използва Kotlin/Native, който генерира Native код за Apple платформите. За разработка и компилиране на iOS приложение обикновено е необходим macOS с Xcode.

3. Кога да изберем Java?

Изберете Java, когато:

• Поддържате или разширявате големи съществуващи Enterprise системи.
• Екипът ви има основно Java Developers.
• Проектът изисква консервативен и дългосрочно утвърден технологичен избор.
• Използвате библиотеки, Frameworks и инструменти с приоритетна поддръжка на Java.
• Разполагате с утвърдени Java Development процеси и инструменти.

4. Кой език да използваме?

За нови проекти, особено при Back-end Services, Cloud Microservices и Android Applications, Kotlin може да бъде много добър избор.

Основните му предимства са:

• По-кратък и четим синтаксис.
• Вградена Null Safety.
• data class за DTO и Domain Objects.
• Coroutines за асинхронна обработка.
• Отлична интеграция със Spring Boot и JVM Frameworks.

За големи съществуващи Java проекти и Enterprise системи Java често остава по-практичният избор благодарение на:

• Огромна екосистема от библиотеки.
• Зрели Development Tools и документация.
• Голям брой опитни Java Developers.
• Дългогодишна стабилност и съвместимост.

5. Смесен подход (Java + Kotlin)

В много реални проекти най-доброто решение е използването на двата езика едновременно.

དཔེར་ན:

• Съществуващите Legacy Modules остават написани на Java.
• Новите Services и Components могат да бъдат разработвани на Kotlin.
• Двата езика могат да взаимодействат чрез JVM Interoperability.

Това позволява постепенно модернизиране на системата, без да се налага цялостно пренаписване.

Важно за Java Developer Interview

1. Kotlin и Java се компилират до JVM Bytecode.
2. Kotlin е напълно interoperable с Java, но има някои особености при взаимодействието между типовете.
3. Java има record, който частично покрива функционалността на Kotlin data class.
4. Java Virtual Threads (Java 21+) улесняват създаването на мащабируеми concurrent приложения.
5. Kotlin Coroutines и Java Virtual Threads са различни технологии и не трябва да се разглеждат като едно и също.

Запомнете: Kotlin не заменя Java. Двата езика могат да работят заедно в една JVM система. Изборът зависи от проекта, екипа, архитектурата и съществуващата технологична инфраструктура.

Какво може JBoss / WildFly, което Spring Boot не предлага директно

Този материал сравнява възможностите на JBoss / WildFly и Spring Boot. Основната разлика е, че JBoss / WildFly е пълноценен Application Server, докато Spring Boot е Application Framework, който позволява изграждането на самостоятелни приложения със собствен вграден Runtime.

Важно е да се отбележи, че Spring Boot може да реализира много от тези функционалности чрез допълнителни библиотеки и конфигурации, но не ги предоставя като единен стандартизиран Application Server Container.

1. Пълноценни Java EE / Jakarta EE Container Services

JBoss е сертифициран Application Server с интегрирани Enterprise услуги.

Основни възможности:

• CDI Container – управление на Dependency Injection, Scopes и Portable Extensions.
• EJB Container – поддръжка на Stateful и Stateless Beans, Remote EJB Calls и EJB Timers.
• Container-managed JTA – управление на транзакции, включително XA Transactions между няколко ресурса.
• JCA Resource Adapters – интеграция с външни и Legacy системи.
• Jakarta Messaging (JMS) – конфигуриране и управление на Messaging Services на ниво сървър.
• Jakarta Security – Container-managed Security и Security Realms.
• JSF, JAX-RS, JAX-WS, JPA – интегрирани технологии за Web Applications, REST Services, SOAP Services и Persistence.

В Spring Boot: тези функционалности трябва да бъдат конфигурирани допълнително или заменени със съответните Spring решения. Някои възможности, като Remote EJB и JCA, нямат естествен еквивалент в типичните Spring Boot приложения.

2. Споделена сървърна инфраструктура (Server-Wide Shared Infrastructure)

JBoss може да хоства и централизирано да управлява множество приложения, които използват общи ресурси.

Основни възможности:

• Shared Datasources – споделени JDBC Connection Pools и XA Pools.
• Shared JMS Queues / Topics – общи Messaging ресурси.
• Shared Security Realms – централизирана автентикация чрез LDAP, Kerberos или файлови системи.
• Server-level Thread Pools – централизирано управление на Thread Pools и Work Managers.
• Central Logging Configuration – обща конфигурация на Logging за всички приложения.
• JGroups Clustering – управление на клъстери и Session Replication.
• Global Transaction Manager – централизирано управление на транзакции.

В Spring Boot: всяко приложение обикновено управлява собствените си DataSources, JMS Connections, Logging и други ресурси. Споделянето е възможно, но се организира чрез външни инфраструктурни услуги или допълнителна конфигурация.

3. Enterprise Packaging: EAR Modules и Multi-Module Deployment

JBoss поддържа традиционния Enterprise Deployment Model, който позволява обединяване на множество модули в едно приложение.

Основни възможности:

• EAR Packaging (Enterprise Archive) – един EAR файл може да съдържа множество WAR и JAR модули.
• Shared Classloader – споделяне на класове между отделни модули според правилата на ClassLoader архитектурата.
• Version Isolation – възможност различни приложения да използват различни версии на библиотеки, например App A с Hibernate 5 и App B с Hibernate 6.
• Hot Redeploy – повторно Deployment на EAR/WAR приложения без рестартиране на целия Application Server.

Spring Boot: обичайно използва Executable JAR (Fat JAR) или WAR. Всяко приложение обикновено се стартира като отделен процес. Няма стандартна поддръжка на EAR Deployment Model като при JBoss.

4. JBoss-Specific Management & Subsystems

JBoss предоставя централизирани инструменти за администриране и управление на целия Application Server.

Основни възможности:

• Management CLI – команден интерфейс за управление на сървъра.
• HTTP Management API – управление на сървърната конфигурация чрез HTTP API.
• Server Configuration – централизирано конфигуриране на Datasources, Security Realms, JMS и Modules.
• Domain Mode – един Domain Controller управлява множество JBoss Servers.
• Clustering Subsystems – използване на JGroups и Infinispan за Cluster Management и Distributed Caching.
• Subsystem-based Configuration – отделни подсистеми за Messaging, Naming, Transactions и други услуги.

Spring Boot: управлява основно конфигурацията на конкретното приложение. Няма вграден централен Server Management модел, еквивалентен на JBoss Domain Mode.

5. Функционалности, които са трудни или неестествени за Spring Boot

Следните възможности са естествена част от JBoss, но изискват допълнителна инфраструктура или различен архитектурен подход при Spring Boot:

• Remote EJB – отдалечени извиквания на EJB методи чрез RMI-базиран механизъм.
• JCA Connectors – управление на жизнения цикъл и Connection Pooling от Application Server.
• Multiple Enterprise Applications in One JVM – множество Enterprise приложения в една JVM със споделени ресурси.
• Container-managed Security – централизирана Security конфигурация за JSF и EJB приложения.
• EJB Timers with HA Failover – автоматизирано управление на Timers с High Availability и Failover.
• Central JTA/XA Management – централизирано управление на транзакции между множество приложения и ресурси.

Spring предлага алтернативи за много от тези функционалности, но те не са стандартизирани по същия начин като Jakarta EE Container Services.

6. Защо съществуват тези различия? (Conceptual Explanation)

7. Практическо правило – кога да изберем JBoss или Spring Boot?

Изберете JBoss / WildFly, когато:

• Поддържате съществуващи EJB / EAR / JSF / JCA системи.
• Имате нужда от Container-managed JTA/XA между множество ресурси.
• Deployment-вате множество Enterprise приложения със споделена сървърна конфигурация.
• Използвате Remote EJB или Server-managed Security Realms.
• Имате нужда от централизирано управление на Clustering, Messaging и JMS.
• Работите с традиционна Enterprise Java EE / Jakarta EE архитектура.

Изберете Spring Boot, когато:

• Разработвате нови Microservices (REST APIs, Cloud-native Applications).
• Искате простота, бърза разработка и независимост на отделните Services.
• Нямате нужда от традиционния Java EE Deployment Model (EAR, EJB, JCA).
• Искате да избегнете сложността на тежките Application Servers.
• Deployment-вате приложения в Kubernetes, Docker или Cloud Platforms.

Важно за Java Developer Interview

Запомнете трите основни разлики:

1. JBoss / WildFly е Application Server, който предоставя Jakarta EE Container Services. Spring Boot е Application Framework.
2. JBoss управлява приложенията и техните общи ресурси централизирано, докато Spring Boot обикновено насърчава независими приложения.
3. Spring Boot не е ограничен до Microservices – може да се използва и за големи Monolithic Enterprise Applications.

Основен извод: JBoss / WildFly е подходящ за традиционни Enterprise системи, които разчитат на централизирани Container Services. Spring Boot е по-гъвкав избор за съвременни приложения, при които се търсят независимост, лесно Deployment и Microservices Architecture.

JVM (Java Virtual Machine)

JVM (Java Virtual Machine) е виртуална машина, която изпълнява Java Bytecode. Тя осигурява независимост на Java приложенията от конкретната операционна система и управлява изпълнението на програмите, паметта и зареждането на класовете.

1. Компилация (Compilation)

Когато компилираме .java файл, Java Compiler (javac) генерира един или повече .class файлове, съдържащи Bytecode (междинно представяне на програмния код).

• Bytecode е независим от конкретната операционна система и процесорна архитектура.
• Може да се изпълнява на всяка система, която разполага със съвместима JVM.
• За разлика от Native Machine Code, Bytecode не се изпълнява директно от процесора.

Пример:

javac Student.java

Резултатът е:

Student.class

2. Подсистема за зареждане на класове (Class Loader Subsystem)

Class Loader Subsystem отговаря за зареждането на класовете в JVM.

Основни задачи:

• Зарежда .class файловете.
• Преобразува Bytecode представянето в структури от данни, използвани от JVM.
• Създава обект от тип Class, който представя заредения клас.
• Свързва заредения клас с необходимите структури в паметта.

Пример:

Student s1 = new Student();
Class<?> c1 = s1.getClass();

Тук getClass() връща обект от тип Class, който представлява класа Student.

Важно: Зареденият клас не се съхранява като обикновен Java Object в Heap Memory. Информацията за класовете се управлява от JVM, а обектите от тип Class са в Heap.

3. Свързване (Linking)

Linking е процесът, при който JVM подготвя заредения клас за изпълнение.

Състои се от три стъпки:

Важно: Resolution може да се извърши отложено (Lazily), а не задължително при първоначалното зареждане на класа.

4. Инициализация (Initialization)

При Initialization JVM изпълнява статичните инициализатори и присвоява зададените начални стойности на Static Variables.

Пример:

public class Student {
    static int count = 10;
    static {
        System.out.println("Class initialized");
    }
    int age = 20;
}

• count се инициализира при Initialization на класа.
• static блокът се изпълнява при инициализацията на класа.
• age се инициализира при създаването на всеки нов обект от Student.

5. Двигател за изпълнение (Execution Engine)

Execution Engine отговаря за изпълнението на Bytecode.

Основни компоненти:

• Interpreter – изпълнява Bytecode инструкции една по една.
• JIT Compiler (Just-In-Time Compiler) – компилира често изпълнявани участъци от Bytecode до Native Machine Code за по-добра производителност.
• Garbage Collector (GC) – автоматично освобождава паметта, заета от обекти, които вече не са достижими.

JIT Compiler позволява на JVM да оптимизира изпълнението на програмата по време на работа (Runtime).

6. Обобщение – как работи JVM?

Важно за Java Developer Interview

Запомнете следните пет компонента:

1. Compilation – преобразува .java файловете в Bytecode (.class).
2. Class Loader – зарежда класовете в JVM.
3. Linking – включва Verification, Preparation и Resolution.
4. Initialization – изпълнява Static Initializers и инициализира Static Variables.
5. Execution Engine – изпълнява Bytecode чрез Interpreter и JIT Compiler.

Основен извод: JVM позволява на Java програмите да бъдат Platform Independent, като изпълнява Bytecode чрез Interpreter и JIT Compiler и управлява паметта чрез Garbage Collector.

Apache Kafka

Apache Kafka е Distributed Event Streaming Platform (платформа за разпределена обработка на потоци от събития), която често се използва като Message Broker.

Тя позволява на приложенията да публикуват (Publish), съхраняват (Store), обработват (Process) и получават (Subscribe) потоци от съобщения в реално време (Real Time).

Kafka е проектирана за:

• Висока пропускателна способност (High Throughput).
• Мащабируемост (Scalability).
• Устойчивост при откази (Fault Tolerance).
• Ниска латентност (Low Latency).
• Надеждна комуникация между различни системи.

1. Основни концепции (Core Concepts)

Topics – логически категории, в които се публикуват съобщенията (Messages или Records).

Partitions – всеки Topic може да бъде разделен на множество Partitions. Те позволяват паралелна обработка и хоризонтално мащабиране.

Producers – приложения или услуги, които изпращат съобщения към Kafka Topics.

Consumers – приложения или услуги, които получават и обработват съобщенията.

Brokers – Kafka сървъри, които съхраняват и управляват Partitions.

Consumer Groups – групи от Consumers, които разпределят обработката на Partitions помежду си.

2. Поток на данните (Data Flow)

Пример: Online Shop публикува събитие OrderCreated в Kafka Topic. Отделни Consumers могат да обработят поръчката, да изпратят имейл и да актуализират складовата наличност.

3. Съхранение на данните (Storage)

Kafka съхранява съобщенията на диска (Disk Storage), а не само в оперативната памет (RAM).

Основни характеристики:

• Persistence – съобщенията се съхраняват за определен период или според зададен размер.
• Replication – Partitions могат да имат копия (Replicas) на различни Brokers.
• Fault Tolerance – при отказ на Broker може да бъде избран друг Replica за Leader.
• Retention – съобщенията остават достъпни според конфигурираната Retention Policy.

Важно: Kafka не изтрива автоматично съобщението веднага след прочитането му от Consumer. То остава достъпно до изтичане на Retention периода или до прилагане на друга политика за съхранение.

4. Предимства на Apache Kafka като Message Broker

4.1. Висока производителност и ниска латентност (High Throughput & Low Latency)

• Обработва много големи обеми от съобщения.
• Поддържа висока пропускателна способност.
• Осигурява ниска латентност при правилна конфигурация.
• Подходяща е за системи с голям брой събития в реално време.

4.2. Мащабируемост (Scalability)

• Поддържа хоризонтално мащабиране чрез добавяне на Brokers.
• Partitions позволяват паралелна обработка.
• Може да обслужва много Producers и Consumers едновременно.

4.3. Устойчивост и надеждност (Durability & Fault Tolerance)

• Съобщенията се записват на диска.
• Replication осигурява копия на данните на различни Brokers.
• При отказ на Leader Replica може да бъде избран нов Leader.
• Позволява възстановяване след откази.

4.4. Независимост между Producers и Consumers (Decoupling)

Producers и Consumers работят независимо един от друг.

དཔེར་ན:

• Order Service публикува събитие за нова поръчка.
• Payment Service обработва плащането.
• Notification Service изпраща уведомление.
• Warehouse Service актуализира складовата наличност.

Producer не е необходимо да знае кои Consumers ще обработват събитието.

4.5. Обработка на потоци от данни (Stream Processing)

Kafka поддържа Stream Processing чрез:

• Kafka Streams – библиотека за обработка и трансформация на потоци от събития.
• Apache Flink – платформа за разпределена обработка на потоци.
• Apache Spark – поддържа обработка на Streaming Data.

Това позволява Real-Time Analytics, филтриране, агрегиране и трансформация на данни.

4.6. Повторно прочитане и съхранение (Replay & Retention)

• Съобщенията се съхраняват според конфигурираната Retention Policy.
• Consumers могат да прочитат съобщенията повторно.
• Чрез Offset може да се определи от коя позиция да започне четенето.
• Полезно е при възстановяване на данни, повторна обработка и одит (Audit).

4.7. Интеграционна екосистема (Integration Ecosystem)

Kafka Connect предоставя готова инфраструктура за интеграция с различни системи:

• Databases.
• Cloud Services.
• File Systems.
• External Applications.
• Други Data Sources и Data Sinks.

4.8. Гаранции за доставка (Delivery Semantics)

Kafka поддържа три основни модела:

Важно: Exactly-once не означава автоматично, че всяка външна операция – например запис в произволна Database или изпращане на Email – ще се изпълни точно веднъж. За такива сценарии са необходими допълнителни механизми за координация и Idempotency.

5. Важно за Java Developer Interview

Запомнете следните понятия:

1. Topic – логическа категория за съхранение на съобщения.
2. Partition – част от Topic, която позволява паралелна обработка.
3. Producer – изпраща съобщения към Kafka.
4. Consumer – чете съобщения от Kafka.
5. Consumer Group – група Consumers, които си разпределят Partitions.
6. Offset – позиция на съобщение в даден Partition.
7. Broker – Kafka Server, който съхранява и обслужва данните.
8. Replication – създаване на копия на Partitions за надеждност.
9. Kafka Connect – интеграция с външни системи.
10. Kafka Streams – обработка на потоци от събития.

Основен извод: Apache Kafka е разпределена Event Streaming платформа, която позволява надежден обмен, съхранение и обработка на големи обеми от събития в реално време. Тя е особено полезна при Microservices Architecture, Event-Driven Architecture и системи с голямо натоварване.

Apache Kafka vs. RabbitMQ

Apache Kafka и RabbitMQ са технологии за обмен на съобщения между приложения (Message Broker / Messaging Systems), но имат различна архитектура и предназначение.

Kafka е ориентирана към Event Streaming и обработка на големи потоци от данни, докато RabbitMQ е традиционен Message Broker, подходящ за Message Queues, Routing и асинхронна комуникация между приложения.

1. Сравнение на основните характеристики

2. Основна разлика в архитектурата (Architecture)

Apache Kafka – Event Streaming

RabbitMQ – Message Queuing

3. Основни предимства на Kafka

• High Throughput – обработва много големи обеми от съобщения.
• Event Replay – позволява повторно прочитане на съобщенията чрез Offset.
• Scalability – лесно хоризонтално мащабиране чрез Partitions и Brokers.
• Event Streaming – подходяща за Real-Time Analytics и Data Pipelines.
• Multiple Consumers – различни Consumer Groups могат независимо да обработват едни и същи събития.

4. Основни предимства на RabbitMQ

• Advanced Message Routing – маршрутизиране чрез Direct, Topic, Fanout и Headers Exchanges.
• Message Acknowledgement – потвърждаване на успешно обработени съобщения.
• Message Queues – подходящ за Background Jobs и Task Processing.
• Flexible Protocols – поддържа AMQP, MQTT и STOMP.
• Dead Letter Exchanges (DLX) – обработка на съобщения, които не могат да бъдат доставени или обработени успешно.
• Priority Queues – възможност за приоритизиране на съобщенията.

5. Кога да изберем Kafka и кога RabbitMQ?

Изберете Apache Kafka, когато:

• Разработвате Event-Driven Microservices Architecture.
• Трябва да обработвате големи потоци от събития.
• Изграждате Real-Time Analytics системи.
• Имате нужда от Event Replay.
• Създавате Data Pipelines.
• Множество независими приложения трябва да получават едни и същи събития.

Изберете RabbitMQ, когато:

• Изграждате Task Queues и Background Jobs.
• Имате нужда от сложни Message Routing правила.
• Използвате асинхронна Request/Response комуникация.
• Искате Message Acknowledgement и контрол върху доставката.
• Изграждате системи за обработка на поръчки, плащания и известия.
• Нуждаете се от традиционен Message Broker с гъвкаво маршрутизиране.

6. Могат ли Kafka и RabbitMQ да се използват заедно?

Да. В някои Enterprise системи двете технологии се използват едновременно.

Например при Online Shop:

• RabbitMQ – изпраща задачи към Payment Service и Notification Service.
• Kafka – съхранява събития като OrderCreated, PaymentCompleted དང་ OrderShipped за последваща обработка, Analytics и Event Replay.

Така RabbitMQ може да управлява оперативните задачи, а Kafka – потока от бизнес събития.

Важно за Java Developer Interview

Запомнете най-важните разлики:

Основен извод:

• Kafka = Data Streaming Backbone – съхранение и обработка на потоци от събития.
• RabbitMQ = Messaging Backbone – маршрутизиране и доставка на съобщения между приложения.

Нито една от двете технологии не е универсално по-добра. Изборът зависи от архитектурата и конкретните изисквания на системата.

Livelock в Threads (Livelock при нишките)

Livelock е проблем при Concurrent Programming в Java, при който две или повече Threads продължават активно да реагират една на друга, опитвайки се да разрешат конфликт, но в крайна сметка нито една от тях не успява да постигне напредък (Progress).

За разлика от Deadlock, при който нишките са блокирани и чакат безкрайно, при Livelock нишките продължават да работят и да променят състоянието си, но не могат да завършат задачите си.

1. Основни характеристики (Key Characteristics of Livelock)

1. Threads are active – нишките не са блокирани, а продължават да изпълняват инструкции.
2. Continuous State Changes – непрекъснато променят състоянието си в отговор на действията на другите нишки.
3. No Progress – въпреки активността си, не постигат напредък и не завършват задачите си.
4. Repeated Conflict Resolution – многократно се опитват да разрешат един и същ конфликт, но действията им взаимно си пречат.

2. Пример за Livelock

Представете си двама души, които се опитват да се разминат в тесен коридор.

• Първият човек прави крачка наляво, за да пропусне втория.
• Вторият също прави крачка наляво.
• Първият отново се опитва да отстъпи.
• Вторият прави същото.

Така двамата непрекъснато променят позицията си, но никой не успява да премине.

Това е аналогия на Livelock при Threads.

3. Java пример (Livelock Example)

Следният пример демонстрира Livelock чрез две нишки, които постоянно си отстъпват при опит да получат общ ресурс.

import java.util.concurrent.atomic.AtomicBoolean;
public class LivelockExample {
    static class Person {
        private final String name;
        private volatile boolean active = true;
        Person(String name) {
            this.name = name;
        }
        public boolean isActive() {
            return active;
        }
        public void giveWay() {
            System.out.println(name + " gives way.");
            active = false;
        }
        public void tryProceed() {
            active = true;
            System.out.println(name + " tries to proceed.");
        }
    }
    public static void main(String[] args) {
        Person person1 = new Person("Person 1");
        Person person2 = new Person("Person 2");
        Thread t1 = new Thread(() -> {
            while (person1.isActive()) {
                if (person2.isActive()) {
                    person1.giveWay();
                } else {
                    person1.tryProceed();
                }
            }
        });
        Thread t2 = new Thread(() -> {
            while (person2.isActive()) {
                if (person1.isActive()) {
                    person2.giveWay();
                } else {
                    person2.tryProceed();
                }
            }
        });
        t1.start();
        t2.start();
    }
}

Забележка: Това е илюстративен пример, а не надеждна демонстрация на Livelock. Изходът зависи от Thread Scheduling, а цикълът може да завърши или да се държи различно. AtomicBoolean import-ът също не е необходим.

4. Обяснение на примера (Explanation of the Example)

1. Person Class – представя участник в конфликта, като всеки участник има собствено състояние.
2. Threads – t1 དང་ t2 представят двамата участници, които се опитват да преминат.
3. State Changes – всеки участник променя състоянието си в зависимост от състоянието на другия.
4. Conflict – двамата могат да продължат да си отстъпват, без да постигнат напредък.

Основната идея е, че нишките не са блокирани, а са активни, но действията им взаимно възпрепятстват завършването на задачите.

5. Как да избегнем Livelock? (How to Avoid Livelock)

1. Timeouts – използвайте времеви ограничения при повторни опити за получаване на ресурс.
2. Fixed Strategy – определете предварително коя нишка има приоритет или право да продължи първа.
3. Randomization – добавете случайно закъснение (Random Delay) между повторните опити, за да прекъснете синхронния цикъл.
4. Better Coordination – използвайте подходящи механизми за координация, като Semaphore, Lock и ясна стратегия за управление на ресурсите.
5. Bounded Retries – ограничете броя на повторните опити, вместо да използвате безкраен Retry Loop.

6. Разлика между Deadlock, Livelock и Starvation

Важно за Java Developer Interview

Запомнете:

• Deadlock: Threads са блокирани и чакат безкрайно.
• Livelock: Threads са активни, но не постигат напредък.
• Starvation: Една Thread не получава необходимите ресурси заради конкуренция или несправедливо разпределение.

Основен извод: При Livelock нишките не са спрели да работят – те продължават да изпълняват действия, но взаимно си пречат да завършат задачите си.

Marker Interfaces (Маркерни интерфейси)

Marker Interface в Java е интерфейс, който не съдържа методи или полета. Той се използва, за да маркира (Tag) даден Class и да указва, че този клас притежава определено свойство или трябва да бъде обработван по специален начин от Java Runtime или Frameworks.

С други думи, Marker Interface предоставя информация за даден клас чрез самия факт, че той го имплементира (implements).

1. Примери за Marker Interfaces

Java предоставя няколко стандартни Marker Interfaces:

1. Serializable

• Маркира клас, чиито обекти могат да бъдат Serialized.
• Serialization преобразува обекта в поток от байтове (Byte Stream), който може да бъде съхранен или предаден по мрежата.
• Използва се от ObjectOutputStream.

import java.io.Serializable;
public class Student implements Serializable {
    private String name;
    private int age;
}

2. Cloneable

• Указва, че даден клас позволява създаването на копия на своите обекти чрез Object.clone().
• Ако класът не имплементира Cloneable, извикването на clone() върху него води до CloneNotSupportedException.

public class Student implements Cloneable {
    private String name;
    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

3. Remote

• Използва се при RMI (Remote Method Invocation).
• Маркира интерфейси, чиито методи могат да бъдат извиквани от отдалечени JVM процеси.

import java.rmi.Remote;
import java.rmi.RemoteException;
public interface StudentService extends Remote {
    void getStudent() throws RemoteException;
}

2. Как работят Marker Interfaces? (How It Works)

Marker Interfaces използват Type Checking – проверка дали даден клас имплементира конкретен интерфейс.

Например Serializable указва на ObjectOutputStream, че обектът може да бъде Serialized.

import java.io.Serializable;
public class Student implements Serializable {
    private String name = "John";
}
public class Main {
    public static void main(String[] args) {
        Student student = new Student();
        if (student instanceof Serializable) {
            System.out.println("Object is Serializable");
        }
    }
}

Резултат:

Object is Serializable

Ако класът не имплементира Serializable, опитът за стандартна Java Serialization на такъв обект ще доведе до NotSerializableException (освен ако не се използва специален механизъм като writeReplace()).

3. Marker Interfaces срещу Annotations

С въвеждането на Annotations в Java 5 много от случаите на използване на Marker Interfaces могат да бъдат реализирани чрез Annotations.

Пример с Annotation:

@interface Important {
}
@Important
public class Student {
}

Кога да използваме Marker Interface?

• Когато искаме да маркираме клас като определен тип.
• Когато е необходима проверка чрез instanceof.
• Когато поведението зависи от имплементирането на конкретен интерфейс.

Кога да използваме Annotation?

• Когато искаме да добавим метаданни към класове, методи или полета.
• Когато използваме Frameworks като Spring или Hibernate.
• Когато информацията се обработва чрез Reflection или Annotation Processing.

4. Важно за Java Developer Interview

Запомнете:

1. Marker Interface е интерфейс без методи и полета.
2. Използва се за маркиране на класове с определено свойство.
3. Основни примери са Serializable, Cloneable དང་ Remote.
4. instanceof позволява проверка дали даден обект имплементира Marker Interface.
5. Annotations са алтернативен механизъм за добавяне на метаданни, но не заменят напълно Marker Interfaces.

Основен извод: Marker Interface е начин Java да идентифицира определени класове чрез Type System, без да е необходимо интерфейсът да дефинира методи.

Как един Method в Java може да връща повече от една стойност? (Returning Multiple Values)

В Java един Method не може директно да връща няколко отделни стойности. Той може да връща само една стойност или един Object.

Въпреки това има няколко начина да постигнем ефекта на връщане на повече от една стойност.

1. Използване на Custom Class или Object

Можем да създадем собствен Class, който съдържа няколко Fields. Методът връща един Object, съдържащ всички необходими стойности.

public class StudentInfo {
    private String name;
    private int age;
    public StudentInfo(String name, int age) {
        this.name = name;
        this.age = age;
    }
    public String getName() {
        return name;
    }
    public int getAge() {
        return age;
    }
}

Метод, който връща Object:

public StudentInfo getValues() {
    return new StudentInfo("John", 25);
}

Използване:

StudentInfo info = getValues();
System.out.println(info.getName());
System.out.println(info.getAge());

Това е чист и подходящ за многократна употреба подход. В съвременната Java може да използваме и record.

public record StudentInfo(String name, int age) {}
public StudentInfo getValues() {
    return new StudentInfo("John", 25);
}

2. Използване на Arrays

Можем да върнем Array, когато всички стойности са от един и същи тип.

public int[] getValues() {
    return new int[] {10, 20, 30};
}

Използване:

int[] values = getValues();
System.out.println(values[0]);
System.out.println(values[1]);
System.out.println(values[2]);

Този подход е подходящ за фиксиран брой стойности от един тип.

3. Използване на Map

Можем да върнем Map, когато стойностите имат връзка Key-Value.

import java.util.Map;
public Map<String, Object> getValues() {
    return Map.of(
        "name", "John",
        "age", 25,
        "salary", 3000.0
    );
}

Използване:

Map<String, Object> values = getValues();
System.out.println(values.get("name"));
System.out.println(values.get("age"));
System.out.println(values.get("salary"));

Този подход е гъвкав, защото можем да използваме описателни Keys. Недостатъкът е, че при Map<String, Object> често се налага Type Casting.

4. Използване на Pair или Tuple

Можем да използваме готови класове от външни библиотеки, които позволяват връщане на две или повече стойности.

Например Apache Commons Lang – Pair:

import org.apache.commons.lang3.tuple.Pair;
public Pair<String, Integer> getValues() {
    return Pair.of("John", 25);
}

Използване:

Pair<String, Integer> result = getValues();
System.out.println(result.getLeft());
System.out.println(result.getRight());

Този подход е удобен за малък брой стойности, без да е необходимо да създаваме собствен Class.

5. Използване на List или Set

Когато трябва да върнем множество стойности от един и същи тип, можем да използваме Collections.

List Example:

import java.util.List;
public List<String> getNames() {
    return List.of("John", "Peter", "Michael");
}

Set Example:

import java.util.Set;
public Set<Integer> getNumbers() {
    return Set.of(10, 20, 30);
}

List запазва реда и допуска дублирани стойности, докато Set съхранява уникални стойности.

6. Сравнение на подходите

Важно за Java Developer Interview

Запомнете:

1. Java Method може да връща само една стойност.
2. Тази стойност може да бъде Primitive Type, Array, Collection или Object.
3. Custom Class и Record са предпочитан подход, когато връщаме няколко различни стойности.
4. Map е полезен при Key-Value структури, но може да изисква Type Casting.
5. Pair དང་ Tuple са удобни алтернативи, но не винаги са най-добрият избор за сложни резултати.

Основен извод: В съвременната Java най-чистият подход за връщане на няколко различни стойности е използването на Custom Class или Record, защото осигуряват Type Safety, четимост и лесна поддръжка на кода.

Microservices Patterns (Архитектурни модели при Microservices)

Microservices Patterns са архитектурни модели и практики, които помагат при проектирането, разработването, комуникацията, Deployment и управлението на Microservices Architecture.

Те решават различни проблеми, свързани с независимостта на услугите, комуникацията, управлението на данните, сигурността и устойчивостта на системата.

1. Decomposition Patterns (Модели за разделяне на системата)

Тези модели определят как една голяма система (Monolithic Application) да бъде разделена на независими Microservices.

Decompose by Business Capability

• Разделяне на системата според бизнес функциите.
• Всеки Service отговаря за конкретна бизнес дейност.
• Пример: Billing Service, Inventory Service, Payment Service.

Decompose by Subdomain

• Използва се подходът Domain-Driven Design (DDD).
• Системата се разделя на отделни Subdomains според бизнес логиката.
• Всеки Microservice обслужва определен бизнес Subdomain.

2. Communication Patterns (Модели за комуникация)

Определят как Microservices обменят информация помежду си.

API Gateway

• Единна входна точка за клиентските приложения.
• Маршрутизира заявките към съответните Microservices.
• Може да предоставя Authentication, Rate Limiting и Load Balancing.

Service Registry

• Поддържа списък с наличните Services и техните адреси.
• Позволява Dynamic Service Discovery.
• Пример: Eureka, Consul.

Circuit Breaker

• Предотвратява Cascading Failures.
• При многократни неуспешни заявки прекратява временно извикванията към проблемния Service.
• След определен период проверява дали Service отново работи.

Message Broker

• Осигурява асинхронна комуникация между Microservices.
• Използва Message Queues или Event Streaming.
• Примери: RabbitMQ и Apache Kafka.

3. Data Management Patterns (Модели за управление на данните)

Определят как Microservices съхраняват, обработват и споделят информация.

Database per Service

• Всеки Microservice има собствена Database.
• Данните се управляват независимо.
• Намалява Coupling между услугите.

Shared Database

• Няколко Microservices използват една обща Database.
• По-лесно споделяне на данни, но създава по-силна зависимост между услугите.
• Може да затрудни независимото развитие и Deployment.

Event Sourcing

• Вместо да съхранява само текущото състояние на обекта, системата записва последователност от Events.
• Текущото състояние може да бъде възстановено чрез Replay на Events.
• Осигурява добра проследимост на промените.

CQRS (Command Query Responsibility Segregation)

• Разделя операциите за промяна на данни (Commands) от операциите за четене (Queries).
• Позволява отделна оптимизация на Read и Write моделите.
• Полезен при системи с различно натоварване за четене и запис.

Saga Pattern

• Управлява Distributed Transactions между няколко Microservices.
• Всяка услуга изпълнява собствена Local Transaction.
• При неуспех се изпълняват Compensating Transactions, които компенсират вече извършените действия.

4. Deployment Patterns (Модели за внедряване)

Определят как Microservices се Deployment-ват и управляват в производствена среда.

Sidecar

• Разполага помощен компонент до основния Service.
• Помощният компонент може да обработва Logging, Monitoring, Proxy или Security.
• Често се използва в Kubernetes.

Service Mesh

• Управлява Service-to-Service Communication.
• Осигурява Load Balancing, Traffic Management, Security и Observability.
• Примери: Istio, Linkerd.

Blue-Green Deployment

• Поддържа две среди – Blue (текуща версия) и Green (нова версия).
• Новата версия се тества в Green средата.
• След успешен тест трафикът се пренасочва към нея.
• Позволява бърз Rollback при проблем.

Canary Deployment

• Новата версия се предоставя първоначално на малка част от потребителите.
• Следи се поведението и стабилността.
• При успешен резултат постепенно се увеличава процентът на трафика към новата версия.

5. Resilience Patterns (Модели за устойчивост)

Целта им е да предотвратят откази и да запазят работоспособността на системата при проблеми.

Retry

• Повтаря неуспешна заявка автоматично.
• Често се използва Exponential Backoff между опитите.
• Трябва да се прилага внимателно, за да не се увеличава натоварването при вече претоварена услуга.

Bulkhead

• Изолира ресурсите на различните услуги или операции.
• Проблем в една част от системата не трябва да изчерпи ресурсите на останалите.
• Името идва от преградите във водонепроницаемите отделения на корабите.

Timeout

• Определя максималното време за изчакване на отговор от друга услуга.
• Предотвратява безкрайно чакане и изчерпване на ресурси.

Failover

• Пренасочва трафика към резервен Service или Instance при отказ на основния.
• Подобрява Availability и Fault Tolerance.

6. Observability Patterns (Модели за наблюдение)

Позволяват да се следи състоянието и производителността на Microservices.

Log Aggregation

• Събира Logs от всички Microservices на едно място.
• Улеснява Debugging и анализирането на грешки.
• Примери: ELK Stack, Grafana Loki.

Distributed Tracing

• Проследява една заявка през множество Microservices.
• Позволява откриване на Bottlenecks и забавяния.
• Примери: OpenTelemetry, Jaeger, Zipkin.

Health Check

• Проверява дали даден Service работи правилно.
• Обикновено включва Liveness и Readiness Checks.
• Използва се от Kubernetes за управление на приложенията.

Metrics Collection

• Събира показатели за производителност и натоварване.
• Примери: CPU Usage, Memory Usage, Request Rate, Error Rate и Response Time.
• Инструменти: Prometheus и Grafana.

7. Security Patterns (Модели за сигурност)

Осигуряват защита на комуникацията, достъпа и данните.

Access Token

• Използва Tokens за Authentication и Authorization.
• Често се използва OAuth 2.0 и OpenID Connect.
• Пример: JWT (JSON Web Token).

Encryption

• Защитава данните при предаване (Data in Transit) и при съхранение (Data at Rest).
• Примери: TLS/HTTPS и Database Encryption.

API Throttling

• Ограничаване на броя заявки за определен период.
• Предотвратява злоупотреби и прекомерно натоварване.
• Често се реализира чрез Rate Limiting.

8. Testing Patterns (Модели за тестване)

Помагат за проверка на правилната работа на отделните Microservices и взаимодействието между тях.

Consumer-Driven Contracts

• Consumer определя очакванията си към API на Provider Service.
• Provider проверява дали изпълнява тези очаквания.
• Намалява риска от несъвместими промени в API.
• Примерен инструмент: Pact.

Service Virtualization

• Симулира поведението на външни Services, които не са налични по време на тестване.
• Позволява тестване без реална зависимост от външната система.

Chaos Engineering

• Въвежда контролирани откази в системата.
• Проверява дали Microservices могат да продължат да работят при проблеми.
• Пример: временно прекъсване на мрежова връзка или спиране на Service Instance.

9. Integration Patterns (Модели за интеграция)

Използват се за свързване на различни Microservices и външни системи.

Aggregator

• Изпраща заявки към няколко Microservices.
• Обединява получените резултати в един общ Response.
• Например Dashboard, който събира информация от Customer, Order и Payment Services.

Proxy

• Действа като посредник между Client и Service или между две Services.
• Препраща заявките и отговорите.
• Може да добавя Authentication, Logging и Routing.

Adapter

• Преобразува Data Formats или Communication Protocols.
• Позволява интеграция между системи с различни интерфейси.
• Например преобразуване на XML към JSON.

10. Най-важните Microservices Patterns за Java Developer Interview

Основен извод

Microservices Patterns помагат за изграждането на мащабируеми, независими и устойчиви разпределени системи.

За Java Developer е особено важно да разбира API Gateway, Service Discovery, Circuit Breaker, Saga, CQRS, Kafka/RabbitMQ, Database per Service и Distributed Tracing, защото тези модели се срещат често при разработката на съвременни Enterprise Applications и Microservices Architecture.

Microservices vs Monolith Architecture

Monolithic Architecture и Microservices Architecture са два основни архитектурни подхода за изграждане на софтуерни приложения.

Основната разлика е, че при Monolith цялото приложение се разработва и Deployment-ва като една основна единица, докато при Microservices системата се разделя на множество независими Services.

1. Monolithic Architecture (Монолитна архитектура)

Monolithic Application е приложение, изградено като една цялостна система. Неговите компоненти, като User Interface, Business Logic и Data Access Layer, обикновено са част от една Codebase и се Deployment-ват заедно.

medium.com

Предимства (Advantages)

Easy Deployment

• Приложението се Deployment-ва като една единица.
• Не е необходимо координиране на множество независими Services.

Development Speed

• В началото на проекта разработката е по-бърза поради по-простата архитектура.
• По-лесно Debugging и Testing.

Performance

• Вътрешната комуникация между компонентите обикновено е чрез директни Method Calls.
• Не се налага Network Communication между отделни Services.
• Намалява Network Latency.

Simplicity

• По-лесно управление на Configuration, Logging и Deployment.
• По-малко инфраструктурни зависимости.

Недостатъци (Disadvantages)

• Limited Scalability – обикновено цялото приложение се мащабира, дори когато само един компонент има нужда от повече ресурси.
• Tight Coupling – компонентите могат да станат силно зависими един от друг.
• Technology Lock-in – по-трудно е да се използват различни технологии за отделните компоненти.
• Deployment Risk – промяна в един компонент може да наложи повторно Deployment на цялото приложение.
• Maintenance Complexity – при разрастване на системата Codebase може да стане трудна за поддръжка.

2. Microservices Architecture (Микросървисна архитектура)

Microservices Architecture разделя приложението на множество малки, независими Services. Всеки Service отговаря за определена Business Capability или Business Domain.

Отделните Services могат да бъдат разработвани, Deployment-вани и мащабирани независимо.

freecodecamp.org

Например една Online Shop система може да включва:

• Customer Service – управление на клиентите.
• Order Service – управление на поръчките.
• Payment Service – обработка на плащанията.
• Inventory Service – управление на складовите наличности.
• Notification Service – изпращане на Email и други известия.

Предимства (Advantages)

Scalability

• Всеки Service може да бъде мащабиран независимо.
• Например Payment Service може да получи повече Instances при увеличено натоварване на плащанията.

Flexibility

• Различните Services могат да използват различни Programming Languages, Frameworks и Databases.
• Позволява избор на най-подходящата технология за конкретната задача.

Isolation

• Проблем в един Service не е задължително да засегне цялата система.
• Чрез Circuit Breaker, Timeout и Bulkhead може да се ограничи разпространението на откази.

Independent Deployment

• Всеки Service може да бъде Deployment-ван независимо.
• Не е необходимо цялата система да бъде спирана при всяка промяна.

Team Autonomy

– Различни Development Teams могат да работят независимо върху отделни Services.

Предизвикателства (Challenges)

Complexity

• Управлението на множество Services изисква допълнителна инфраструктура.
• Често се използват Docker, Kubernetes и Service Discovery.

Network Overhead

• Комуникацията между Services преминава през мрежата.
• Това добавя Network Latency и възможност за Network Failures.

Deployment Complexity

• Необходимо е управление на множество независими Deployments и версии.
• Изисква се добре организиран CI/CD процес.

Data Management

• Всеки Service обикновено притежава собствена Database.
• Distributed Transactions са по-сложни и често изискват Saga Pattern.

Monitoring and Debugging

• Проследяването на една заявка през множество Services е по-трудно.
• Необходими са Centralized Logging и Distributed Tracing.

3. Monolith vs Microservices – Сравнение

4. Пример с Online Shop

При Monolith всички бизнес функции са част от едно приложение и обикновено използват обща Database.

При Microservices всяка услуга управлява собствените си данни и комуникира с останалите чрез API или Message Broker.

5. Кога да изберем Monolith и кога Microservices?

Изберете Monolith, когато:

• Разработвате малко или средно приложение.
• Проектът е в начална фаза.
• Екипът е малък.
• Нямате нужда от независимо мащабиране на отделни компоненти.
• Искате по-просто Deployment и Maintenance.
• Нямате необходимост от сложна Distributed Infrastructure.

Изберете Microservices, когато:

• Разработвате голяма Enterprise система.
• Имате множество независими Business Domains.
• Различни Teams разработват отделни функционалности.
• Отделните Services имат различни изисквания за Scalability.
• Имате нужда от Independent Deployment.
• Разполагате с необходимата инфраструктура за управление на Distributed Systems.

6. Може ли Monolith да бъде добър архитектурен избор?

Да! Съществува и архитектурен подход, наречен Modular Monolith.

При него приложението остава едно цяло за Deployment, но вътрешно е разделено на независими Modules с ясно дефинирани граници.

དཔེར་ན:

• Customer Module
• Order Module
• Payment Module
• Inventory Module

Тези Modules имат отделна Business Logic и контролират достъпа до собствените си данни.

Modular Monolith позволява добра организация на кода, без сложността на Distributed Systems. При необходимост отделен Module може по-късно да бъде отделен като Microservice.

Важно за Java Developer Interview

Запомнете следните основни разлики:

1. Monolith – едно приложение, което се Deployment-ва като една единица.
2. Microservices – множество независими Services, които комуникират чрез API или Messaging.
3. Scalability – Microservices позволяват независимо мащабиране на отделните Services.
4. Communication – Monolith използва предимно вътрешни Method Calls, докато Microservices използват Network Communication.
5. Database per Service – основен принцип за независимост на данните при Microservices.
6. Modular Monolith – добра междинна архитектура между традиционния Monolith и Microservices.

Основен извод: Microservices не са автоматично по-добри от Monolith. За малки и средни проекти Modular Monolith често е по-прост и икономически ефективен избор. Microservices са подходящи, когато независимото Deployment, Scalability и организационната независимост на екипите оправдават допълнителната сложност.

Pass-by-Value vs Pass-by-Reference в Java

Java винаги използва Pass-by-Value, независимо дали подаваме Primitive Types или Objects към даден Method.

Разликата е в това каква стойност се копира и предава на метода:

• При Primitive Types се предава копие на самата стойност.
• При Objects се предава копие на Reference (препратката) към обекта.

Важно е да се разбере, че Java не използва Pass-by-Reference.

1. Pass-by-Value (Предаване по стойност)

Когато подаваме променлива към Method, Java създава копие на нейната стойност.

Промяната на параметъра вътре в метода не променя оригиналната променлива.

2. Primitive Types Example

При Primitive Types, като int, char, boolean, double и други, методът получава копие на действителната стойност.

public class Main {
    public static void changeValue(int num) {
        num = 100;
    }
    public static void main(String[] args) {
        int num = 5;
        changeValue(num);
        System.out.println(num);
    }
}

Резултат:

5

Обяснение:

1. Създаваме променлива num със стойност 5.
2. Извикваме changeValue(num).
3. Методът получава копие на стойността 5.
4. Променяме локалното копие на 100.
5. Оригиналната променлива num остава непроменена със стойност 5.

3. Objects Example

При Objects Java също използва Pass-by-Value, но стойността, която се копира, е Reference към обекта.

Това означава, че методът получава копие на Reference, което сочи към същия обект в Heap Memory.

Следователно промяната на полетата (Fields) на обекта се отразява върху оригиналния обект.

class Box {
    int size;
}
public class Main {
    public static void changeBox(Box box) {
        box.size = 15;
    }
    public static void main(String[] args) {
        Box myBox = new Box();
        myBox.size = 10;
        changeBox(myBox);
        System.out.println(myBox.size);
    }
}

Резултат:

15

Обяснение:

1. Създаваме обект myBox със size = 10.
2. Подаваме Reference към обекта на метода changeBox().
3. Методът получава копие на Reference.
4. И двете References сочат към един и същ обект.
5. Променяме box.size на 15.
6. Промяната се вижда и чрез оригиналната променлива myBox.

4. Какво става, ако променим самия Reference?

Ако присвоим нов обект на параметъра вътре в метода, оригиналната променлива няма да бъде променена.

class Box {
    int size;
}
public class Main {
    public static void changeBox(Box box) {
        box = new Box();
        box.size = 100;
    }
    public static void main(String[] args) {
        Box myBox = new Box();
        myBox.size = 10;
        changeBox(myBox);
        System.out.println(myBox.size);
    }
}

Резултат:

10

Обяснение:

1. myBox сочи към първия обект със size = 10.
2. Методът получава копие на Reference.
3. box = new Box() създава нов обект.
4. Локалният Reference box вече сочи към новия обект.
5. Оригиналният Reference myBox продължава да сочи към първоначалния обект.
6. Следователно myBox.size остава 10.

5. Сравнение – Primitive Types vs Objects

Важно за Java Developer Interview

Запомнете следните три правила:

1. Java is ALWAYS Pass-by-Value.
2. При Primitive Types се копира действителната стойност.
3. При Objects се копира Reference към обекта, а не самият обект.

Правилен отговор на интервю

Does Java support Pass-by-Reference?

No. Java is strictly Pass-by-Value. When an object is passed to a method, a copy of its reference is passed by value. Therefore, the method can modify the object’s state, but it cannot change the caller’s original reference.

Основен извод: Java винаги предава копие на стойността. При Objects това е копие на Reference, което позволява промяна на състоянието на оригиналния обект, но не и промяна на оригиналната Reference променлива.

Private Methods в Abstract Class

В Java един Abstract Class може да съдържа private methods, въпреки че самите abstract methods не могат да бъдат private.

Причината е, че abstract methods трябва да бъдат достъпни за имплементация (Override) от наследяващите класове, докато private methods са предназначени само за вътрешна употреба в Abstract Class.

1. Helper Methods (Помощни методи)

Private Methods могат да съдържат обща функционалност, която се използва от други методи в Abstract Class.

Това предотвратява дублирането на код в наследяващите класове.

Example:

abstract class Employee {
    public void displaySalary(double salary) {
        validateSalary(salary);
        System.out.println("Salary: " + formatSalary(salary));
    }
    private void validateSalary(double salary) {
        if (salary < 0) {
            throw new IllegalArgumentException(
                "Salary cannot be negative"
            );
        }
    }
    private String formatSalary(double salary) {
        return String.format("%.2f", salary);
    }
}
class Manager extends Employee {
}
public class Main {
    public static void main(String[] args) {
        Manager manager = new Manager();
        manager.displaySalary(3500.50);
    }
}

Резултат:

Salary: 3500.50

Обяснение:

• displaySalary() е public и може да бъде извикан от наследяващите класове и външния код.
• validateSalary() проверява дали заплатата е валидна.
• formatSalary() форматира стойността.
• Двата private methods не могат да бъдат извикани директно от Manager.

2. Encapsulation (Капсулация)

Private Methods позволяват да скрием вътрешната реализация на дадена функционалност от наследяващите класове.

Така Abstract Class контролира как се изпълняват определени операции.

Example:

abstract class Payment {
    public final void processPayment(double amount) {
        validateAmount(amount);
        executePayment(amount);
        System.out.println("Payment completed.");
    }
    private void validateAmount(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Invalid payment amount"
            );
        }
    }
    protected abstract void executePayment(double amount);
}
class CreditCardPayment extends Payment {
    @Override
    protected void executePayment(double amount) {
        System.out.println(
            "Processing credit card payment: " + amount
        );
    }
}
public class Main {
    public static void main(String[] args) {
        Payment payment = new CreditCardPayment();
        payment.processPayment(100);
    }
}

Резултат:

Processing credit card payment: 100.0
Payment completed.

Обяснение:

• processPayment() дефинира общия алгоритъм.
• validateAmount() е private и не може да бъде променян чрез Override.
• executePayment() е protected abstract и трябва да бъде имплементиран от наследяващия клас.
• final предотвратява Override на целия processPayment() метод.

Този пример демонстрира Template Method Design Pattern.

3. Internal Data Processing (Вътрешна обработка на данни)

Private Methods могат да обработват данни вътре в Abstract Class, без наследяващите класове да имат достъп до детайлите на обработката.

Example:

abstract class DataProcessor {
    public void process(String data) {
        String cleanedData = cleanData(data);
        saveData(cleanedData);
    }
    private String cleanData(String data) {
        return data.trim().toUpperCase();
    }
    protected abstract void saveData(String data);
}
class DatabaseProcessor extends DataProcessor {
    @Override
    protected void saveData(String data) {
        System.out.println("Saving: " + data);
    }
}
public class Main {
    public static void main(String[] args) {
        DataProcessor processor = new DatabaseProcessor();
        processor.process("  hello world  ");
    }
}

Резултат:

Saving: HELLO WORLD

Обяснение:

• process() управлява процеса.
• cleanData() обработва входните данни и е скрит от наследяващите класове.
• saveData() предоставя възможност на наследяващия клас да реализира конкретното съхранение.

4. Могат ли Abstract Methods да бъдат Private?

Не. Следният код е невалиден:

abstract class Employee {
    private abstract void calculateSalary();
}

Причината е, че private методите не са достъпни за наследяващите класове и не могат да бъдат Override-нати.

Правилният вариант е:

abstract class Employee {
    protected abstract void calculateSalary();
    private void validateEmployee() {
        System.out.println("Employee validated");
    }
}

5. Обобщение

Важно за Java Developer Interview

Запомнете:

1. Abstract Class може да съдържа private methods с реална имплементация.
2. private methods се използват за Helper Methods и Encapsulation.
3. Private Methods не се наследяват и не могат да бъдат Override-нати.
4. Abstract Methods не могат да бъдат private, защото трябва да бъдат достъпни за Override.
5. Template Method Design Pattern често използва final public method, protected abstract methods и private helper methods.

Основен извод: Private Methods в Abstract Class позволяват да скрием вътрешната логика и да контролираме как наследяващите класове използват общата функционалност.

Private Constructors в Java (Използване на Private Constructors)

Private Constructor е конструктор, деклариран с private Access Modifier. Той не позволява създаването на обекти от класа извън самия клас.

Използва се основно за контролиране на създаването на Objects, предотвратяване на наследяване и реализиране на Design Patterns като Singleton.

1. Utility Classes (Помощни класове)

Utility Classes съдържат само static methods དང་ static members. Не е необходимо да създаваме обекти от тези класове.

Private Constructor предотвратява случайното създаване на Instance.

Example:

public final class MathUtils {
    private MathUtils() {
        // Prevent object creation
    }
    public static int add(int a, int b) {
        return a + b;
    }
    public static int multiply(int a, int b) {
        return a * b;
    }
}

Използване:

public class Main {
    public static void main(String[] args) {
        int result = MathUtils.add(10, 20);
        System.out.println(result);
    }
}

Резултат:

30

Следният код няма да работи:

MathUtils utils = new MathUtils();

Причината е, че конструкторът е private.

Важно: final предотвратява наследяването на класа, докато private constructor предотвратява създаването на обекти отвън. Това са две различни ограничения.

2. Constant Classes (Класове с константи)

Private Constructor може да се използва при класове, които съдържат само константи.

Example:

public final class AppConstants {
    private AppConstants() {
    }
    public static final String APP_NAME = "MyApplication";
    public static final int MAX_USERS = 100;
    public static final double TAX_RATE = 0.20;
}

Използване:

public class Main {
    public static void main(String[] args) {
        System.out.println(AppConstants.APP_NAME);
        System.out.println(AppConstants.MAX_USERS);
    }
}

Резултат:

MyApplication
100

Не е необходимо да създаваме Instance на AppConstants.

3. Avoiding Subclassing (Предотвратяване на наследяване)

Private Constructor може да предотврати наследяването на клас от други класове.

Example:

public class Parent {
    private Parent() {
    }
}

Следният код няма да се компилира:

public class Child extends Parent {
}

Причината е, че Child трябва да извика Constructor на Parent, но той е private и не е достъпен.

Важно: За да забраним изцяло наследяването, по-ясният и стандартен подход е използването на final class.

public final class Parent {
}

Така Java изрично забранява създаването на Subclasses.

4. Constructor Delegation (Делегиране между конструктори)

Private Constructor може да се използва за централизиране на общата логика при инициализация на обекти.

Другите Constructors извикват общия Private Constructor чрез this().

Example:

public class Employee {
    private String name;
    private int age;
    private String department;
    private Employee(String name, int age, String department) {
        this.name = name;
        this.age = age;
        this.department = department;
    }
    public Employee(String name, int age) {
        this(name, age, "IT");
    }
    public Employee(String name) {
        this(name, 25, "IT");
    }
    public void display() {
        System.out.println(name + " - " + age + " - " + 
        department);
    }
}

Използване:

public class Main {
    public static void main(String[] args) {
        Employee e1 = new Employee("John");
        Employee e2 = new Employee("Peter", 30);
        e1.display();
        e2.display();
    }
}

Резултат:

John - 25 - IT
Peter - 30 - IT

Обяснение:

• Private Constructor съдържа общата логика за инициализация.
• Public Constructors извикват Private Constructor чрез this().
• Избягваме дублиране на код.
• Обектите могат да бъдат създавани само чрез публичните Constructors.

5. Singleton Pattern (Singleton Design Pattern)

Една от най-известните употреби на Private Constructor е реализацията на Singleton Pattern.

Singleton гарантира, че от даден клас ще съществува само един Instance, предоставен чрез публичен метод.

Example – Eager Initialization:

public class DatabaseConnection {
    private static final DatabaseConnection INSTANCE =
            new DatabaseConnection();
    private DatabaseConnection() {
        System.out.println("Database connection created");
    }
    public static DatabaseConnection getInstance() {
        return INSTANCE;
    }
}

Използване:

public class Main {
    public static void main(String[] args) {
        DatabaseConnection db1 =
                DatabaseConnection.getInstance();
        DatabaseConnection db2 =
                DatabaseConnection.getInstance();
        System.out.println(db1 == db2);
    }
}

Резултат:

Database connection created
true

Обяснение:

1. private constructor не позволява създаването на обекти извън класа.
2. static final INSTANCE създава единствената Instance.
3. getInstance() предоставя достъп до същия обект.
4. db1 == db2 връща true, защото двете променливи сочат към един и същ обект.

Този вариант е Thread-safe при нормалната инициализация на Java Classes.

6. Сравнение на приложенията на Private Constructor

Важно за Java Developer Interview

Запомнете:

1. private constructor предотвратява създаването на обекти извън класа.
2. Използва се при Utility Classes и Classes с Constants.
3. Може да предотврати наследяването, но final class е по-ясният начин за забрана на Subclassing.
4. this() позволява Constructor Delegation.
5. Singleton Pattern използва Private Constructor, за да контролира броя на Instances.
6. Private Constructor не означава, че обект не може да бъде създаден изобщо – самият клас може да го създаде.

Основен извод: Private Constructor е механизъм за контрол върху създаването на Objects. Най-честите му приложения са Utility Classes, Constructor Delegation и Singleton Design Pattern.

Protected vs Package-Private (Default) Access Modifiers в Java

В Java protected དང་ package-private (default) са два Access Modifiers, които определят достъпа до Classes, Fields, Constructors и Methods.

Основната разлика е, че protected позволява достъп и от наследяващи класове (Subclasses) в други Packages, докато package-private ограничава достъпа само до класове в същия Package.

1. Сравнение (Comparison)

Важно: package-private не е ключова дума в Java. Това е достъпът, който получаваме, когато не зададем Access Modifier.

2. Protected – Example

Класът Parent се намира в Package com.example.parent.

package com.example.parent;
public class Parent {
    protected String name = "John";
    protected void display() {
        System.out.println(name);
    }
}

Класът Child се намира в друг Package – com.example.child.

package com.example.child;
import com.example.parent.Parent;
public class Child extends Parent {
    public void show() {
        System.out.println(name);
        display();
    }
}

Това е позволено, защото Child наследява Parent и има достъп до неговите protected Members.

Важно уточнение: Когато protected Member се използва извън Package чрез наследяване, достъпът е ограничен до контекста на наследяването. Например Child не може просто да използва protected Member чрез произволен обект от тип Parent.

3. Package-Private (Default) – Example

Класът Parent се намира в Package com.example.parent.

package com.example.parent;
public class Parent {
    String name = "John";
    void display() {
        System.out.println(name);
    }
}

Ако създадем Child в друг Package:

package com.example.child;
import com.example.parent.Parent;
public class Child extends Parent {
    public void show() {
        System.out.println(name);
        display();
    }
}

Кодът няма да се компилира, защото name དང་ display() имат Package-Private достъп.

Дори Child да наследява Parent, той няма достъп до тези Members извън Package com.example.parent.

4. Key Difference – Основна разлика

Важно за Java Developer Interview

Запомнете:

1. Protected позволява достъп в същия Package и от Subclasses в други Packages.
2. Package-Private позволява достъп само в същия Package.
3. Наследяването само по себе си не дава достъп до Package-Private Members от друг Package.
4. package-private е Default Access Level, когато не е зададен Modifier.
5. При protected достъп извън Package има специално ограничение: достъпът през Reference трябва да бъде чрез самия Subclass или негов Subtype.

Основен извод: protected осигурява по-широк достъп от package-private, защото позволява на наследяващите класове да използват защитените Members дори когато се намират в различни Packages.

Java 21 – Sequenced Collections

Sequenced Collections са нова функционалност, въведена в Java 21 (JEP 431), която предоставя унифициран начин за работа с Collections, имащи дефиниран ред на елементите (Encounter Order).

Преди Java 21 различните Collections имаха различни методи за достъп до първия и последния елемент. Sequenced Collections въвеждат общ интерфейс и стандартизирани методи за работа с началото, края и обратния ред на колекцията.

1. Нови интерфейси (New Interfaces)

Java 21 въвежда три основни интерфейса:

Йерархията на интерфейсите:

Примери за класове, които имплементират новите интерфейси:

• ArrayList
• LinkedList
• LinkedHashSet
• TreeSet
• LinkedHashMap
• TreeMap

2. Основни Methods (SequencedCollection)

3. Methods при SequencedMap

Важно: getFirst() དང་ getLast() не са методи на SequencedMap. За Map се използват firstEntry() དང་ lastEntry(). Също така putFirst() དང་ putLast() са специфични за SequencedMap.

4. Java Code Examples

Example 1 – SequencedCollection

import java.util.ArrayList;
import java.util.List;
public class Main {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("John");
        names.add("Peter");
        names.add("Michael");
        System.out.println(names.getFirst());
        System.out.println(names.getLast());
        names.addFirst("Zara");
        names.addLast("Tom");
        System.out.println(names);
        names.removeFirst();
        names.removeLast();
        System.out.println(names);
    }
}

Резултат:

John
Michael
[Zara, John, Peter, Michael, Tom]
[John, Peter, Michael]

Example 2 – SequencedMap

import java.util.LinkedHashMap;
import java.util.SequencedMap;
public class Main {
    public static void main(String[] args) {
        SequencedMap<String, Integer> map =
                new LinkedHashMap<>();
        map.put("John", 25);
        map.put("Peter", 30);
        map.put("Michael", 35);
        System.out.println(map.firstEntry());
        System.out.println(map.lastEntry());
        map.putFirst("Zara", 22);
        map.putLast("Tom", 40);
        System.out.println(map);
    }
}

Резултат:

John=25
Michael=35
{Zara=22, John=25, Peter=30, Michael=35, Tom=40}

Example 3 – Reversed View

Методът reversed() връща View на оригиналната колекция в обратен ред, а не създава независимо копие.

import java.util.ArrayList;
import java.util.List;
public class Main {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>(
                List.of("John", "Peter", "Michael")
        );
        List<String> reversedNames = names.reversed();
        System.out.println(reversedNames);
        reversedNames.add("Zara");
        System.out.println(names);
    }
}

Резултат:

[Michael, Peter, John]
[John, Peter, Michael, Zara]

Обяснение: Промените в reversedNames се отразяват върху оригиналната колекция names, защото това е Live View.

5. Какво е предимството на Sequenced Collections?

Преди Java 21 достъпът до първия и последния елемент зависеше от конкретната имплементация на Collection.

དཔེར་ན:

// Before Java 21
list.get(0);
list.get(list.size() - 1);

При LinkedHashSet и други Collections нямаше универсален начин за директен достъп до първия и последния елемент.

С Java 21:

// Java 21+
collection.getFirst();
collection.getLast();
collection.reversed();

Това прави кода по-унифициран, четим и независим от конкретната имплементация.

Важно за Java Developer Interview

Запомнете:

1. Sequenced Collections са въведени в Java 21 чрез JEP 431.
2. Новите интерфейси са SequencedCollection, SequencedSet དང་ SequencedMap.
3. getFirst() དང་ getLast() осигуряват достъп до първия и последния елемент.
4. reversed() връща Live View в обратен ред, а не независимо копие.
5. SequencedMap използва firstEntry(), lastEntry(), putFirst() དང་ putLast().
6. Не всички Collections поддържат промяна на реда – при неподдържани операции може да се получи UnsupportedOperationException.

Основен извод: Sequenced Collections в Java 21 стандартизират работата с Collections, които имат определен ред на елементите, като предоставят унифицирани Methods за достъп, добавяне, премахване и обръщане на реда.

Spring анотации (Spring Annotations)

Spring Framework използва анотации (Annotations), чрез които се конфигурират компонентите на приложението, управляват се зависимостите (Dependency Injection), обработват се HTTP заявки и се контролират транзакциите.

По-долу са представени най-често използваните Spring и Spring Boot анотации, с кратко обяснение и примери.

1. Основни анотации за Spring компоненти

Пример:

@Component
public class EmailValidator {
    public boolean isValid(String email) {
        return email != null && email.contains("@");
    }
}

Пример за Java-based Configuration:

@Configuration
public class AppConfig {
    @Bean
    public EmailValidator emailValidator() {
        return new EmailValidator();
    }
}

2. Анотации за Dependency Injection

Тези анотации управляват автоматичното инжектиране на зависимости между Spring Beans.

Пример:

public interface NotificationService {
    void send(String message);
}

@Service("emailService")
public class EmailService implements NotificationService {
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

@Service("smsService")
public class SmsService implements NotificationService {
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

Използване на @Qualifier:

@Service
public class NotificationManager {
    private final NotificationService service;
    public NotificationManager(
            @Qualifier("emailService")
            NotificationService service) {
        this.service = service;
    }
}

Важно: Ако има само един подходящ Bean, Spring обикновено може да го инжектира без @Autowired. При Constructor Injection, когато класът има само един конструктор, анотацията @Autowired не е необходима.

3. Анотации за Bean Lifecycle и Scope

Пример:

@Component
@Scope("prototype")
public class ReportGenerator {
    // New instance for each request from the container
}

@Component
@Lazy
public class HeavyService {
    // Initialized only when needed
}

Основни Bean Scopes:

• singleton – един екземпляр на Bean в рамките на Spring Container. Това е стандартният Scope.
• prototype – нов екземпляр при всяко поискване от Container.
• request – един екземпляр за всяка HTTP заявка.
• session – един екземпляр за всяка HTTP сесия.

request དང་ session са приложими в Web Application Context.

4. Анотации за Spring MVC и REST API

Тези анотации се използват за обработка на HTTP заявки и създаване на Web Services.

Пример за REST Controller:

@RestController
@RequestMapping("/api/users")
public class UserController {
    @GetMapping("/{id}")
    public String getUser(@PathVariable Long id) {
        return "User ID: " + id;
    }
    @PostMapping
    public String createUser(
            @RequestBody User user) {
        return "User created: " + user.getName();
    }
    @GetMapping("/search")
    public String searchUser(
            @RequestParam String name) {
        return "Searching for: " + name;
    }
    @PutMapping("/{id}")
    public String updateUser(
            @PathVariable Long id,
            @RequestBody User user) {
        return "Updated user: " + id;
    }
    @DeleteMapping("/{id}")
    public String deleteUser(
            @PathVariable Long id) {
        return "Deleted user: " + id;
    }
}

Пример за User клас:

public class User {
    private String name;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

Разлика между @PathVariable དང་ @RequestParam:

5. Анотации за транзакции

Пример:

@Service
public class BankService {
    @Transactional
    public void transferMoney(
            Account from,
            Account to,
            double amount) {
        from.withdraw(amount);
        to.deposit(amount);
    }
}

Ако възникне подходящо Runtime Exception, Spring по подразбиране ще извърши Rollback на транзакцията.

Важно: По подразбиране Spring извършва Rollback при RuntimeException དང་ Error, но не и при Checked Exceptions. За Checked Exceptions може да се използва rollbackFor.

6. Анотации за Spring Boot

Пример:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(
            Application.class, args);
    }
}

@SpringBootApplication обединява три основни функционалности:

• @Configuration – позволява дефиниране на Bean конфигурация.
• @EnableAutoConfiguration – конфигурира автоматично компоненти според наличните зависимости и настройки.
• @ComponentScan – сканира пакетите за Spring компоненти и ги регистрира като Beans.

Важно за Java Developer Interview

Често задавани въпроси по темата:

1. Каква е разликата между @Component, @Service དང་ @Repository?И трите регистрират Spring-managed Beans. Разликата е в предназначението им: общ компонент, Business Logic и Data Access Layer. @Repository осигурява и Exception Translation.
2. Каква е разликата между @Controller དང་ @RestController?@Controller обикновено връща View, докато @RestController връща директно данни в HTTP Response Body.
3. Каква е разликата между @Autowired, @Qualifier དང་ @Primary?
   • @Autowired – инжектира зависимост.
   • @Qualifier – избира конкретен Bean.
   • @Primary – определя предпочитан Bean при няколко кандидата.
4. Каква е разликата между @Bean དང་ @Component?
   • @Component се поставя върху клас и позволява автоматичното му откриване чрез Component Scanning.
   • @Bean се поставя върху метод, обикновено в @Configuration клас, и регистрира върнатия от него обект.
5. Какво представлява @Transactional?Анотация, която позволява управление на транзакциите чрез Spring Transaction Management.
6. Какво прави @SpringBootApplication?Активира основните механизми за конфигурация, Auto-Configuration и Component Scanning.