diff --git a/README.md b/README.md
index 661f81b..ce1294a 100644
--- a/README.md
+++ b/README.md
@@ -4,119 +4,6 @@
# Тут могут быть ошибки/неточности - используйте на свой страх и риск. Но буду благодарен, если укажете на косяки)
-# Вопросы для разбора
-
-1. Java Core: С какой проблемой можно столкнуться при увеличении размера heap памяти. Почему программисты стараются излишне не расширять ее
-2. Java Core: Ускоряет ли вычисление программы использование parallelStream() в Stream ? В каких случаях да, а в каких нет
-3. Java Core: какой размер у String Pool?
-4. Java Core: какой GC используется по дефолту в Java 8/11
-5. Java Core: что такое Stop The World
-6. Java Core: чем лямбда отличается от анонимного класса
-7. Java Core: какие методы можно вызвать у Throwable
-8. Java Core: назови классы, которые наследуются не от Object
-9. Maven: как передавать стартовые параметры через мавен
-10. Java Core: назовите Immutable коллекции
-11. Java Core: как сделать иммутабельным класс, у которого в полях находятся ссылочные неиммутабельные типы (final не поможет, потому что финализируется ссылка, а не объект, и сам объект можно будет изменить)
-12. Java Core: Максимальное кол-во элементов в массиве? Максимальный размер ArrayList? Максимальный размер LinkedList? Почему в LinkedList лучше не использовать size() при итеррировании, и как лучше итеррироваться?
-13. SQL: что такое Explain и чем Explain отличается от Explain Analyse
-14. Spring: @Value отрабатывает до вызова конструктора или после?
-15. Spring: На каком этапе происходит внедрение зависимостей при использовании @Autowired над конструктором?
-16. Spring: как выбрать профиль
-17. Spring: Какой из трех способов автовайринга рекомендуется использовать разработчиками спринга и по каким причинам.
-18. Spring: можно ли создать два бина со скоупом сингтон одного класса
-19. Spring: мы создали контроллер и инжектим бин со скоупом Session. Как спринг будет подставлять каждой сессии новый бин, если контекс инициализируется со стартом приложения
-20. Spring: какие исключения может обрабатывать @Transactional по дефолту. Может ли он обработать пробрасываемое исключение
-
-# Микросервисная архитектура. Основные принципы. Отличия от Монолита и SOA
-1. 12-ти факторная модель создания облачных приложений
-2. IaaS, PaaS, SaaS https://gigacloud.ua/ru/blog/navchannja/hmarna-piramida-iaas-paas-i-saas
-3. CAP теорема
-4. Паттерны микросервисной архитектуры. https://mcs.mail.ru/blog/26-osnovnyh-patternov-mikroservisnoj-razrabotki
-5. Паттерны интеграции микросервисов https://www.enterpriseintegrationpatterns.com/patterns/messaging/
-
-# Apache Kafka
-https://www.youtube.com/watch?v=-AZOi3kP9Js Основы кафки
-
-https://www.youtube.com/watch?v=c_mkpVg5rlg Обзор брокеров сообщений
-
-https://www.youtube.com/watch?v=Y1eSeEJDses вебинар по обзору некоторых фишек в кафке
-
-1. Что такое очередь сообщений.
-2. Основные концепции очередей
-3. ? Kafka vs Rabbit MQ
-4. Основные сущности Kafka
-
-# Kafka Cluster. Zookeaper
-5. Zookeper. Хранение метаданных кластера
-6. Kafka кластер. Устройство
-7. Партиционирование. Leader партиция.
-8. Репликация
-9. Настройка Kafka кластера для корректной работы партиционирования и репликации
-10. Устройство файлового хранилища Kafka
-11. TTL
-
-# Producer
-13. Producer. Из каких шагов состоит инцициализация
-14. Стратегии коммитинга. Гарантия доставки
-15. Сериализация, Десериализация
-16. Стратегии выбора партиции продюссером
-17. Можно ли из топика (распределен по 3 партициям) прочитать сообщения в том же порядке, в котором они были записаны? Почему?
-18. Как сделать так, чтобы все сообщения по одному клиенту попали в одну партицию?
-19. Timestamp
-20. Headers
-21. Batch size. Linger time
-22. Retry
-# Consumer
-
-# Docker, Kubernetes, OpenShift.
-1. Контейнеризация
-
-# Реактивщина
-https://projectreactor.io/docs/core/release/api/ - список классов и методов по Project Reator
-
-https://habr.com/ru/post/565000/ - основной источник материалов
-
-1. Реактивное программирование. Основные принципы. Преимущество реактивного программирование над блокирующим.
-2. Перечислите основные виды потерь на блокирующем типе программирования в web
-3. Объясните понятие backpressure. Что оно дает. https://habr.com/ru/post/512724/
-4. При каком количестве запросов и нагрузке имеет реактивно построенное приложение начинает выигровать у приложения с блокироющим типом запросов. Приведите оценки
-5. Основные библиотеки
-
-# Rector Core
-1. Cтандарт спецификации Reactive Streams.
-2. Reactive Streams: Основные интефейсы
-3. Reactive Streams: Publisher
-4. Reactive Streams: Subscriber
-5. Основные модули Project Reactor
-6. Reactor Core: основные интерфейсы
-7. Flux Api. Основные методы https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html
-8. Mono Api. Основные методы
-9. Обработка ошибок
-10. Тестирование
-11. Параллельное выполнение. Scheduler
-12. Backpressure: оператор request
-13. Горячий и холодный паблишер. Что это. Как создать
-14. Контекст: локальные переменные для контекста
-15. Sinks. События
-16. Отладка/Debug реактивной программы
-
-# Spring WebFlux (Расширить)
-22. Реактивные Application Servers: Netty, Jetty, Tomcat, Servlet 3.1, HTTP 2.0
-23. Spring WebFlux. Для чего используется
-24. Обработка запроса. Аннотационная модель: контроллеры на базе WebFlux
-25. Обработка запроса. Функциональная модель: HandlerFunctions, RouterFunctions,
-26. Spring Security WebFlux.
-27. Отправка запросов. WebClient. Основные методы
-28. WebSocket, RSocket
-29. Тестирование WebFlux
-
-# R2DBC (Расширить)
-30. Что такое R2DBC, Программы, реализующие драверы для R2DBC
-31. SPRING DATA R2DBC
-32. ReactiveCrudRepository
-33. DatabaseClient. Оптравка SQL запросов напрямую в БД
-34. Транзакции
-
+ [ООП](#ООП)
+ [Java Core](#java-core)
+ [Java Collections Framework](#java-collections)
diff --git a/core.md b/core.md
index 42cd20d..84a1e6a 100644
--- a/core.md
+++ b/core.md
@@ -182,6 +182,11 @@ float x = 8.5F;
+ char: хранит одиночный символ в кодировке UTF-16 и занимает 2 байта, поэтому диапазон хранимых значений от 0 до 65535
+Классы обертки (Integer, Float, Long и тд) хранят внутри примитив, расширяя его дополнительными методами (наприер .equals()), возможностью хранить null и использоваться в коллекциях
+
+Метод valueOf() реализован во всех классах-обёртках в Java:
+Метод Integer.valueOf(int) использует кеширование значений от –128 до 127 из внутреннего пула. Это оптимизация для часто используемых чисел. Объекты в пуле — это объекты в heap-памяти (куче), как и любые другие Java-объекты. Как и String pool
+
## Какими значениями инициализируются переменные по умолчанию?
+ Числа инициализируются `0` или `0.0`;
+ `char` — `\u0000`;
@@ -279,6 +284,119 @@ short s = 7; // 0000 0000 0000 0111
[к оглавлению](#java-core)
+## Как применяют побитовые операции?
+
++ Маски (битовые флаги)
++
+Маска — это число, в котором каждый бит используется как отдельный флаг (true/false). Это позволяет хранить несколько булевых значений в одной переменной int или long.
+
+`
+final int READ = 1 << 0; // 0001 = 1
+final int WRITE = 1 << 1; // 0010 = 2
+final int EXECUTE = 1 << 2; // 0100 = 4
+
+int rights = READ | WRITE; // 0011 = 3 (чтение + запись)
+
+// Проверка
+boolean canRead = (rights & READ) != 0; // true
+boolean canExecute = (rights & EXECUTE) != 0; // false
+
+// Добавим EXECUTE
+rights |= EXECUTE; // теперь 0111 = 7
+
+// Уберём WRITE
+rights &= ~WRITE; // теперь 0101 = 5 (READ + EXECUTE)
+`
+
+Здесь | используется для добавления флага,
+& для проверки,
+~ для обнуления конкретного бита.
+
+В Java часто вместо масок используют EnumSet, но маски полезны, если надо хранить очень много флагов компактно (например, при работе с сетью или драйверами).
+
+`
+enum Permission {
+ READ(1 << 0),
+ WRITE(1 << 1),
+ EXECUTE(1 << 2);
+
+ final int mask;
+ Permission(int mask) { this.mask = mask; }
+}
+
+`
++ Быстрое умножение/деление на степени двойки
+
+Сдвиги влево и вправо работают быстрее, чем умножение/деление.
+
+`
+int x = 5 << 1; // 10 (5 * 2)
+int y = 20 >> 2; // 5 (20 / 4)
+
+int z = 7;
+
+int mul = z << 1; // 14 (7 * 2)
+int div = z >> 1; // 3 (7 / 2)
+`
+
++ Оптимизация в алгоритмах
+__Проверка чётности__
+`
+int n = 10;
+if ((n & 1) == 0) {
+ System.out.println("Чётное");
+} else {
+ System.out.println("Нечётное");
+}
+`
+__Быстрый модуль по степени двойки__
+`
+int n = 77;
+int mod = n & (8 - 1); // 77 % 8 = 5
+System.out.println(mod); // 5
+`
+
+__Переключение флага (toggle)__
+`
+int flags = 0;
+
+// переключаем WRITE
+flags ^= WRITE; // включили WRITE
+flags ^= WRITE; // снова выключили WRITE
+
+`
+__Очистка всех флагов, кроме одного__
+`
+int flags = READ | WRITE | EXECUTE;
+flags &= READ; // оставляем только READ
+`
+
+__Интересные применения__
+
+Хранение состояний: например, в графике (VISIBLE, ENABLED, SELECTED).
+
+Комбинация параметров: настройки работы функции (FULLSCREEN | VSYNC).
+
+Быстрая работа с большими массивами булевых значений (экономия памяти).
+
+[к оглавлению](#java-core)
+
+## Разница >> и >>>
+
+>>> и <<< сдвиги без учета знака
+`
+int x = -8; // 11111111111111111111111111111000
+
+System.out.println(x >> 2); // -2 (111111...1110) — арифметический сдвиг
+System.out.println(x >>> 2); // 1073741822 (001111...1110) — логический сдвиг
+
+`
+Зачем нужен >>>, если есть >>?
+
+Ответ: для работы с int/long как беззнаковыми числами (например, при работе с сетевыми протоколами или бинарными файлами).
+
+[к оглавлению](#java-core)
+
## Autoboxing и unboxing?
__Автоупаковка__ - автоматическая инкапсуляция примитивного типа в эквивалентную ему класс-обёртку всякий раз, когда требуется объект данного типа.
diff --git a/oop.md b/oop.md
index 5cdb287..6c48481 100644
--- a/oop.md
+++ b/oop.md
@@ -15,6 +15,7 @@
+ [Что такое _статическое_ и _динамическое связывание_?](#Что-такое-статическое-и-динамическое-связывание)
+ [Принцип SOLID?](#Принцип-SOLID)
+ [Что такое Монолит, Микросервис?](#Что-такое-Монолит,-Микросервис)
++ [Что такое Continuous Integration, Continuous Delivery/Deployment?](#Что-такое-Continuous-Integration,-Continuous-Delivery/Deployment)
+ [Что выбрать Монолит или Микросервис?](#Что-выбрать-Монолит-или-Микросервис)
+ [Взаимодействие между микросервисами](#Взаимодействие-между-микросервисами)
+ [OpenAPI](#OpenAPI)
@@ -39,7 +40,7 @@ __Объектно-ориентированное программировани
+ _Наследование_ - создание новой сущности на базе уже существующей.
+ _Полиморфизм_ - возможность иметь разные формы для одной и той же сущности.
+ _Абстракция_ - набор общих характеристик.
-+ _Посылка сообщений_ - форма связи, взаимодействия между сущностями.
++ _Пересылка сообщений_ - форма связи, взаимодействия между сущностями.
+ _Переиспользование_- все что перечислено выше работает на повторное использование кода.
Это единственно верный порядок парадигм ООП, так как каждая последующая использует предыдущие.
@@ -61,11 +62,13 @@ __Наследование__ – это свойство системы, поз
[к оглавлению](#ООП)
## Что такое _«полиморфизм»_?
-__Полиморфизм__ – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
+__Полиморфизм__ – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. Т.е. использовать разные объекты одинаково, через общий интерфейс.
+
+Пример: у нас есть метод draw(). Для круга он рисует окружность, для квадрата — квадрат. Но мы обращаемся к ним одинаково: figure.draw().
Преимуществом полиморфизма является то, что он помогает снижать сложность программ, разрешая использование одного и того же интерфейса для задания единого набора действий. Выбор же конкретного действия, в зависимости от ситуации, возлагается на компилятор языка программирования. Отсюда следует ключевая особенность полиморфизма - использование объекта производного класса, вместо объекта базового (потомки могут изменять родительское поведение, даже если обращение к ним будет производиться по ссылке родительского типа).
-Полиморфизм бывает _динамическим_ (переопределение) и _статическим_ (перегрузка).
+Полиморфизм бывает _динамическим_ (переопределение методов в потомках) и _статическим_ (перегрузка методов -одинаковое имя, разные параметры).
_Полиморфная переменная_, это переменная, которая может принимать значения разных типов, а _полиморфная функция_, это функция у которой хотя бы один аргумент является полиморфной переменной.
Выделяют два вида полиморфных функций:
@@ -78,15 +81,19 @@ _Полиморфная переменная_, это переменная, ко
## Что такое _«абстракция»_?
_Абстрагирование_ – это способ выделить набор общих характеристик объекта, исключая из рассмотрения частные и незначимые. Соответственно, __абстракция__ – это набор всех таких характеристик.
+Пример: когда мы говорим «машина», нам важно, что у неё есть двигатель и колёса, а цвет ковриков внутри — неважно.
+
[к оглавлению](#ООП)
## Что представляет собой _«обмен сообщениями»_?
-Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. В ООП посылка сообщения (вызов метода) — это единственный путь передать управление объекту. Если объект должен «отвечать» на это сообщение, то у него должна иметься соответствующий данному сообщению метод. Так же объекты, используя свои методы, могут и сами посылать сообщения другим объектам. Обмен сообщениями реализуется с помощью динамических вызовов, что приводит к чрезвычайно позднему связыванию (extreme late binding).
+Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия + данные.
+
+В ООП посылка сообщения (вызов метода) — это единственный путь передать управление объекту. Если объект должен «отвечать» на это сообщение, то у него должна иметься соответствующий данному сообщению метод. Так же объекты, используя свои методы, могут и сами посылать сообщения другим объектам.
[к оглавлению](#ООП)
## Расскажите про основные понятия ООП: _«класс»_, _«объект»_, _«интерфейс»_.
-__Класс__ – это способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
+__Класс__ – шаблон описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).
@@ -99,69 +106,63 @@ __Интерфейс__ – это набор методов класса, дос
[к оглавлению](#ООП)
## В чем заключаются преимущества и недостатки объектно-ориентированного подхода в программировании?
-Преимущества:
-
-+ Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.
-+ Классы позволяют проводить конструирование из полезных компонентов, обладающих простыми инструментами, что позволяет абстрагироваться от деталей реализации.
-+ Данные и операции над ними образуют определенную сущность, и они не разносятся по всей программе, как нередко бывает в случае процедурного программирования, а описываются вместе. Локализация кода и данных улучшает наглядность и удобство сопровождения программного обеспечения.
-+ Инкапсуляция позволяет привнести свойство модульности, что облегчает распараллеливание выполнения задачи между несколькими исполнителями и обновление версий отдельных компонентов.
-+ Возможность создавать расширяемые системы.
-+ Использование полиморфизма оказывается полезным при:
- + Обработке разнородных структур данных. Программы могут работать, не различая вида объектов, что существенно упрощает код. Новые виды могут быть добавлены в любой момент.
- + Изменении поведения во время исполнения. На этапе исполнения один объект может быть заменен другим, что позволяет легко, без изменения кода, адаптировать алгоритм в зависимости от того, какой используется объект.
- + Реализации работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.
- + Возможности описать независимые от приложения части предметной области в виде набора универсальных классов, или фреймворка, который в дальнейшем будет расширен за счет добавления частей, специфичных для конкретного приложения.
-+ Повторное использование кода:
- + Сокращается время на разработку, которое может быть отдано другим задачам.
- + Компоненты многоразового использования обычно содержат гораздо меньше ошибок, чем вновь разработанные, ведь они уже не раз подвергались проверке.
- + Когда некий компонент используется сразу несколькими клиентами, улучшения, вносимые в его код, одновременно оказывают положительное влияние и на множество работающих с ним программ.
- + Если программа опирается на стандартные компоненты, ее структура и пользовательский интерфейс становятся более унифицированными, что облегчает ее понимание и упрощает использование.
-
-Недостатки:
-
-+ В сложных иерархиях классов поля и методы обычно наследуются с разных уровней. И не всегда легко определить, какие поля и методы фактически относятся к данному классу.
-+ Код для обработки сообщения иногда «размазан» по многим методам (иначе говоря, обработка сообщения требует не одного, а многих методов, которые могут быть описаны в разных классах).
-+ Документирование классов - задача более трудная, чем это было в случае процедур и модулей. Поскольку любой метод может быть переопределен, в документации должно говориться не только о том, что делает данный метод, но и о том, в каком контексте он вызывается.
-+ Неэффективность и неэкономное распределения памяти на этапе выполнения (по причине издержек на динамическое связывание и проверки типов на этапе выполнения).
-+ Излишняя универсальность. Часто содержится больше методов, чем это реально необходимо текущей программе. А поскольку лишние методы не могут быть удалены, они становятся мертвым грузом.
+
+✅ Ближе к человеческому восприятию мира.
+
+✅ Код разбивается на логичные части.
+
+✅ Удобнее поддерживать и расширять.
+
+✅ Код можно переиспользовать.
+
+✅ Легко добавлять новые объекты и изменять поведение программы.
+
+❌ Иногда сложно понять, где что наследуется.
+
+❌ Методы могут быть «размазаны» по разным классам.
+
+❌ Документировать сложнее. Поскольку любой метод может быть переопределен, в документации должно говориться не только о том, что делает данный метод, но и о том, в каком контексте он вызывается.
+
+❌ Дополнительные расходы памяти и производительности.
+
+❌ Избыточность. Часто содержится больше методов, чем это реально необходимо текущей программе. А поскольку лишние методы не могут быть удалены, они становятся мертвым грузом.
[к оглавлению](#ООП)
## Что подразумевают в плане принципов ООП выражения _«является»_ и _«имеет»_?
-__«является»__ подразумевает наследование.
-__«имеет»__ подразумевает ассоциацию (агрегацию или композицию).
+__«является»__ подразумевает наследование. Класс _cat_ является потомком класса _animal_
+__«имеет»__ агрегация или композиция. Класс _car_ имеет класс _engine_
+
+
[к оглавлению](#ООП)
## В чем разница между _композицией_ и _агрегацией_?
-Ассоциация обозначает связь между объектами. Композиция и агрегация — частные случаи ассоциации «часть-целое».
+Ассоциация обозначает связь между объектами.
-Агрегация предполагает, что объекты связаны взаимоотношением «part-of» (часть). Композиция более строгий вариант агрегации. Дополнительно к требованию «part-of» накладывается условие, что экземпляр «части» может входить только в одно целое (или никуда не входить), в то время как в случае агрегации экземпляр «части» может входить в несколько целых.
+Агрегация — «часть» может существовать отдельно и принадлежать нескольким «целым». (Книга находится в библиотеке, её можно перенести в другую).
->Например, книга состоит из страниц и мы не можем вырвать страницу из книги и вложить в другую книгу. Страницы четко привязаны к конкретной книге, поэтому это композиция.
-В тоже время мы можем взять и перенести книгу из одной библиотеки в другую - это уже агрегация.
+Композиция — «часть» жёстко привязана к «целому». (Страница принадлежит конкретной книге).
[к оглавлению](#ООП)
## Что такое _статическое_ и _динамическое связывание_?
-Связывание означает наличие связи между ссылкой и кодом. Например, переменная, на которую вы ссылаетесь, привязана к коду, в котором она определена. Аналогично, вызываемый метод привязан к месту в коде, где он определен. Присоединение вызова метода к телу метода. Если связывание проводится компилятором (компоновщиком) перед запуском программы, то оно называется _статическим_ или _ранним связыванием (early binding)_.
+Связывание означает наличие связи между ссылкой и кодом. Например, переменная, на которую вы ссылаетесь, привязана к коду, в котором она определена. Аналогично, вызываемый метод привязан к месту в коде, где он определен.
-В свою очередь, _позднее связывание (late binding)_ это связывание, проводимое непосредственно во время выполнения программы, в зависимости от типа объекта. Позднее связывание также называют _динамическим (dynamic)_ или _связыванием на стадии выполнения (runtime binding)_. В языках, реализующих позднее связывание, должен существовать механизм определения фактического типа объекта во время работы программы, для вызова подходящего метода. Иначе говоря, компилятор не знает тип объекта, но механизм вызова методов определяет его и вызывает соответствующее тело метода. Механизм позднего связывания зависит от конкретного языка, но нетрудно предположить, что для его реализации в объекты должна включаться какая-то дополнительная информация.
+_Статическим_ или _ранним связыванием (early binding)_ — компилятор заранее знает, какой метод будет вызван. (Напр. перегрузка методов).
+
+_Позднее связывание (late binding) или динамическое_ проводимое непосредственно во время выполнения программы, в зависимости от типа объекта (Напр. переопределение методов в наследниках). Механизм позднего связывания зависит от конкретного языка
Итак, фундаментальное различие между статическим и динамическим связыванием в Java состоит в том, что первое происходит рано, во время компиляции на основе типа ссылочной переменной, а второе – позднее, во время выполнения, с использованием конкретных объектов.
-Для всех методов Java используется механизм позднего (динамического) связывания, если только метод не был объявлен как `static` или `final` (приватные методы являются `final` по умолчанию).
+В Java почти все методы — динамические, кроме `static`, `final` и `private`.
Ключевые различия между ранним и поздним связыванием в языке Java:
-1) Статическое связывание происходит во время компиляции, а динамическое – во время выполнения.
-
-2) Поскольку статическое связывание происходит на ранней стадии жизненного цикла программы, его называют ранним связыванием. Аналогично, динамическое связывание называют также поздним связыванием, поскольку оно происходит позже, во время работы программы.
+1) Статическое связывание используется в языке Java для разрешения перегруженных методов, в то время как динамическое связывание используется в языке Java для разрешения переопределенных методов.
-3) Статическое связывание используется в языке Java для разрешения перегруженных методов, в то время как динамическое связывание используется в языке Java для разрешения переопределенных методов.
+2) Аналогично, приватные, статические и терминальные методы разрешаются при помощи статического связывания, поскольку их нельзя переопределять, а все виртуальные методы разрешаются при помощи динамического связывания.
-4) Аналогично, приватные, статические и терминальные методы разрешаются при помощи статического связывания, поскольку их нельзя переопределять, а все виртуальные методы разрешаются при помощи динамического связывания.
-
-5) В случае статического связывания используются не конкретные объекты, а информация о типе, то есть для обнаружения нужного метода используется тип ссылочной переменной. С другой стороны, при динамическом связывании для нахождения нужного метода в Java используется конкретный объект.
+3) В случае статического связывания используются не конкретные объекты, а информация о типе, то есть для обнаружения нужного метода используется тип ссылочной переменной. С другой стороны, при динамическом связывании для нахождения нужного метода в Java используется конкретный объект.
[к оглавлению](#ООП)
@@ -208,58 +209,65 @@ __Принцип инверсии зависимостей (DIP)__
Монолитная архитектура - система с одним сервисом, который отвечает за работу со всей предметной областью бизнеса (приложения)
При начале работы над монолитным проектом Достоинства:
-+ Быстрая разработка
-+ Возможность внесения радикальных изменений (например изменить архитетуру, класс-дизайн, схему бд)
-+ Безболезненое тестирование
-+ Легкое развертывание
-+ Простое hardware масштабирование
+
+✅ Быстрая разработка
+
+✅ Возможность внесения радикальных изменений (например изменить архитетуру, класс-дизайн, схему бд)
+
+✅ Безболезненое тестирование
+
+✅ Легкое развертывание
+
+✅ Простое hardware масштабирование
С увеличением размера проекта и команды разработки появляются Минусы:
-+ Медленное внесение изменений
+
+❌ Медленное внесение изменений
+
Команды А и Б работают не пересекаясь. Выкатывается новая версия проекта с багами в коде команды Б. Откатывается на предыдущуюю версию весь код и команды Б и команды А.
-+ Уязвимая надежность - если падает часть кода, то не работает все приложение.
-+ Трудности в hardware масштабировании.
+
+❌ Уязвимая надежность - если падает часть кода, то не работает все приложение.
+
+❌ Трудности в hardware масштабировании.
+
Одна часть требует оперативу, другая ядра. Приходится апгрейдить "вертикально" - покупать больше оперативных планок и процессоры с большим кол-вом ядер для всех сервисов. А не по потребностям
-+ Дороговизна обновления технологического стека
-Например переход на новую версию Java. Чтобы проверить эффективность, нужно переписывать весь проект
+
+❌ Дороговизна обновления технологического стека. Например переход на новую версию Java. Чтобы проверить эффективность, нужно переписывать весь проект
Микросервисная архитектура — система, которая содержит больше одного обособленнго сервиса. Размер значения не имеет.
Обособленный сервис — является независимой единицей развертывания, имеет своё хранилище, свою БД (?), отвечает за свою часть предметной области
Достоинства:
-+ Возможность масштабирования разработки
-+ Дешевизна эксперементов с новым стеком
-+ Инкрементальное обновление технолошического стека
-+ Повышенная надежность и отказоустойчивость
+
+✅ Возможность масштабирования разработки
+
+✅ Дешевизна эксперементов с новым стеком
+
+✅ Инкрементальное обновление технолошического стека
+
+✅ Повышенная надежность и отказоустойчивость
Минусы:
-+ Сложность проектирования архитектуры
-+ Долгое внесение радикальных изменений
-+ Нетривиальное тестирование
-+ Повышенные требования к Continuous Integration/Continuous Delivery (деплою)
+❌ Сложность проектирования архитектуры
-Непрерывная интеграция (CI) — процесс автоматического принятия изменений. Первичный процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
-+ Возможность локальной сборки проекта
-+ На каждый коммит в кдаленный репо запускаем сборки проекта в системе (Jenkins, TravisCI)
-+ Сломанная сборка запрещает слияние
+❌ Долгое внесение радикальных изменений
-Непрерывная доставка (CD) — CI + CD. Автоматизированый процесс доставки изменений до продакшена. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
-+ Поддерживаем артефакты стабильными
-+ Развертываем по кнопке
+❌ Нетривиальное тестирование
+
+❌ Повышенные требования к Continuous Integration/Continuous Delivery (деплою)
Сложности проектирования Микросервисов
+ Сложно разделить предметную область на части
-Не стоит делить монолит на микросервисы по функциональным возможностям. Это приведет к распределенному монолиту - архитектура, включающая недостатки и того и другого. Монолит нужно разбивать по пренадлежности к какой-то области бизнеса. Отличить одно от другого довольно сложно. Т.е. по принципу единой ответственности.
+Не стоит делить монолит на микросервисы по функциональным возможностям. Это приведет к распределенному монолиту - архитектура, включающая недостатки и того и другого. Монолит нужно разбивать по пренадлежности к какой-то области бизнеса. Отличить одно от другого довольно сложно. Т.е. по принципу единой ответственности.
Соответствие принципам Low coupling, high cohesion способствует быстрому внесению изменений и легкому тетсированию.
Сильная связанность high cohesion - части системы, которые изменяются вместе, должны находиться ближе друг к другу
-Слабая связанность low coupling - части системы, которые изменяются параллельно, должны иметь как можно меньше зависимостей друг на друга
+Слабая связанность low coupling - части системы, которые изменяются параллельно, должны иметь как можно меньше зависимостей друг на друга b внутри сервиса и между сервисами
-И внутри сервиса и между сервисами
+ Задержки при межсервисном взаимодействии влияют на производительность + сеть ненадежна
+ Межсервисное взаимодействие влияет на доступность
@@ -267,6 +275,19 @@ __Принцип инверсии зависимостей (DIP)__
[к оглавлению](#ООП)
+## Что такое Continuous Integration, Continuous Delivery/Deployment?
+
+Непрерывная интеграция (CI) — процесс автоматического принятия изменений. Первичный процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
++ Возможность локальной сборки проекта
++ На каждый коммит в кдаленный репо запускаем сборки проекта в системе (Jenkins, TravisCI)
++ Сломанная сборка запрещает слияние
+
+Непрерывная доставка (CD) — CI + CD. Автоматизированый процесс доставки изменений до продакшена. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
++ Поддерживаем артефакты стабильными
++ Развертываем по кнопке
+
+[к оглавлению](#ООП)
+
## Что выбрать Монолит или Микросервис?
Микро если:
+ Предметная область хорошо делится на части
@@ -292,9 +313,8 @@ https://martinfowler.com/
+ Доступность и отказоустойчивость
+ Архитектура
-_Транспорт_
-+ стандарт JSON внутри HTTP
-HTTP - простой, множество инструментов, человекочитаемость. Из-за текстового формата большие объемы и нужно оптимизировать
+__Транспорт__
++ стандарт JSON внутри HTTP (REST, RPC, GraphQL). Простой, множество инструментов, человекочитаемость. Из-за текстового формата большие объемы и нужно оптимизировать
+ бинарные протоколы: gRPC, Thrift, Avro и т.д.
Выше производительность, оптимизированно представление данных, можно определить схему сообщения из коробки, но меньше инструментов и не читаемы человеком
@@ -302,32 +322,38 @@ HTTP - простой, множество инструментов, челове
Что выбрать?
+ Начинать с HTTP
+ Бинарные не бесплатные
-+ Большинство проблем не из-за протокола
++ Большинство проблем не из-за протокола!
+ Для публичных API всегда HTTP либо несколько реализаций одна из которых HTTP
-_API_
+__API__
+
Application Programming Interface - интерфейс, определяющий способ и схему взаимодействия с сервисом
+ Remote Procedure Call (RPC)
+
Только POST метод. Все параметры в теле запроса. Любой статус !=200, считается ошибкой
Выбирают: Простая реализация, Внутренние API, HTTP только как транспорт
+ Representational State Transfer (REST)
+
Архитектурный стиль, в основе которого лежат ресурсы и их идентификация, изменение их состояния через представление. REST != HTTP
Выбирают: Своего рода стандарт, Внутренние API, Публичные API, HTTP как протокол
+ GraphQL
+
Язык запросов для API. Например можно задать конкретный набор полей, которые хотим получить в ответе на запрос
Выбирают: Типо-безопасность, API для Web и мобильных клиентов, тут свой инструментарий
-Проектирвоание
+__Проектирвоание__
+ Клиент-сервер
+ Stateless - сервис не должен хранить состояние в памяти, это важно для масштабирования
+ Кеширование
__Типы сообщений__
+ Команды
++
Императивное управление (звучит как "сделать что-то"), вызывают сильную связанность, зато понятны - названия обычно отражают логику
+ События
++
Декларативное управление (звучит как "что-то произошло"), снижают связанность, менее понятны - не знаем что скрыто в notifyOrderCreated
@@ -423,15 +449,16 @@ Database Schema as a Code - текущая схема должна быть пр
[к оглавлению](#ООП)
## Тестирование микросервисов
-+ Компонентные для тестирования логики приложения
-+ Модульные для тестирования вычислений
-+ Компонентных должно быть больше, чем модульных, т.к. изменяемая среда, много зависимочти между классами
++ Компонентные тесты проверяют работу сервисов и их взаимодействие
++ Модульные тесты для тестирования отдельных функций
+
+Компонентных должно быть больше, чем модульных, т.к. изменяемая среда, много зависимочти между классами
-Тесты должны быть независимыми и уметь работать параллельно. Тесты не должны очищать БД или буффер брокера сообщений перед/после своего запуска/завершения
+Тесты должны быть независимыми и уметь работать параллельно.
Для тестирования API лучше делать реальные HTTP вызовы, валидировать ответ согласно схеме (JSON). RESTAssured как пример инструмента.
-При тестирование взаимодействия с БД на каждый запуск тестов локально поднимается БД. Embedded или TestContainers
+При тестирование взаимодействия с БД на каждый запуск тестов локально поднимается БД. Embedded или TestContainers. Тесты не должны очищать БД или буффер брокера сообщений перед/после своего запуска/завершения
При тестировании взаимодействия микросервисов на каждый запуск тестов локально HTTP-сервер, создаем моки операций сервисов, выполняем, моки валидируем. WireMock, MockServer
diff --git a/spring.md b/spring.md
index 1f4d03d..dba386c 100644
--- a/spring.md
+++ b/spring.md
@@ -164,7 +164,7 @@ https://habr.com/ru/post/222579/
- __prototype__ - контейнер Spring IoC создаёт новый экземпляр бина на каждый полученный запрос т.е. иметь любое количество экземпляров бина;
- __request__ - Создаётся один экземпляр бина на каждый HTTP запрос. Касается исключительно ApplicationContext;
- __session__ - Создаётся один экземпляр бина на каждую HTTP сессию. Касается исключительно ApplicationContext;
-- __web soccet__ - Создаётся один экземпляр бина для определенного сокета.
+- __web socket__ - Создаётся один экземпляр бина для определенного сокета.
- __application__ - Создаётся один экземпляр бина для жизненного цикла бина. Похоже на синглтон, но когда бобы ограничены областью приложения, значения, однажды установленное в applicationScopedBean, будет сохранено для всех последующих запросов, сеансов и даже для другого приложения сервлета, которое будет обращаться к этому Бобу, при условии, что оно выполняется в том же ServletContext. В то время как одноэлементные бобы ограничены только одним контекстом приложения.
+ constructor-arg - Определяет конструктор, использующийся для внедрения зависимости. Более подробно – далее.
diff --git a/toResolve.md b/toResolve.md
new file mode 100644
index 0000000..dafdaa4
--- /dev/null
+++ b/toResolve.md
@@ -0,0 +1,118 @@
+[Вопросы для собеседования](README.md)
+
+# Вопросы для разбора
+
+1. Java Core: С какой проблемой можно столкнуться при увеличении размера heap памяти. Почему программисты стараются излишне не расширять ее
+2. Java Core: Ускоряет ли вычисление программы использование parallelStream() в Stream ? В каких случаях да, а в каких нет
+3. Java Core: какой размер у String Pool?
+4. Java Core: какой GC используется по дефолту в Java 8/11
+5. Java Core: что такое Stop The World
+6. Java Core: чем лямбда отличается от анонимного класса
+7. Java Core: какие методы можно вызвать у Throwable
+8. Java Core: назови классы, которые наследуются не от Object
+9. Maven: как передавать стартовые параметры через мавен
+10. Java Core: назовите Immutable коллекции
+11. Java Core: как сделать иммутабельным класс, у которого в полях находятся ссылочные неиммутабельные типы (final не поможет, потому что финализируется ссылка, а не объект, и сам объект можно будет изменить)
+12. Java Core: Максимальное кол-во элементов в массиве? Максимальный размер ArrayList? Максимальный размер LinkedList? Почему в LinkedList лучше не использовать size() при итеррировании, и как лучше итеррироваться?
+13. SQL: что такое Explain и чем Explain отличается от Explain Analyse
+14. Spring: @Value отрабатывает до вызова конструктора или после?
+15. Spring: На каком этапе происходит внедрение зависимостей при использовании @Autowired над конструктором?
+16. Spring: как выбрать профиль
+17. Spring: Какой из трех способов автовайринга рекомендуется использовать разработчиками спринга и по каким причинам.
+18. Spring: можно ли создать два бина со скоупом сингтон одного класса
+19. Spring: мы создали контроллер и инжектим бин со скоупом Session. Как спринг будет подставлять каждой сессии новый бин, если контекс инициализируется со стартом приложения
+20. Spring: какие исключения может обрабатывать @Transactional по дефолту. Может ли он обработать пробрасываемое исключение
+
+# Микросервисная архитектура. Основные принципы. Отличия от Монолита и SOA
+1. 12-ти факторная модель создания облачных приложений
+2. IaaS, PaaS, SaaS https://gigacloud.ua/ru/blog/navchannja/hmarna-piramida-iaas-paas-i-saas
+3. CAP теорема
+4. Паттерны микросервисной архитектуры. https://mcs.mail.ru/blog/26-osnovnyh-patternov-mikroservisnoj-razrabotki
+5. Паттерны интеграции микросервисов https://www.enterpriseintegrationpatterns.com/patterns/messaging/
+
+# Apache Kafka
+https://www.youtube.com/watch?v=-AZOi3kP9Js Основы кафки
+
+https://www.youtube.com/watch?v=c_mkpVg5rlg Обзор брокеров сообщений
+
+https://www.youtube.com/watch?v=Y1eSeEJDses вебинар по обзору некоторых фишек в кафке
+
+1. Что такое очередь сообщений.
+2. Основные концепции очередей
+3. ? Kafka vs Rabbit MQ
+4. Основные сущности Kafka
+
+# Kafka Cluster. Zookeaper
+5. Zookeper. Хранение метаданных кластера
+6. Kafka кластер. Устройство
+7. Партиционирование. Leader партиция.
+8. Репликация
+9. Настройка Kafka кластера для корректной работы партиционирования и репликации
+10. Устройство файлового хранилища Kafka
+11. TTL
+
+# Producer
+13. Producer. Из каких шагов состоит инцициализация
+14. Стратегии коммитинга. Гарантия доставки
+15. Сериализация, Десериализация
+16. Стратегии выбора партиции продюссером
+17. Можно ли из топика (распределен по 3 партициям) прочитать сообщения в том же порядке, в котором они были записаны? Почему?
+18. Как сделать так, чтобы все сообщения по одному клиенту попали в одну партицию?
+19. Timestamp
+20. Headers
+21. Batch size. Linger time
+22. Retry
+# Consumer
+
+# Docker, Kubernetes, OpenShift.
+1. Контейнеризация
+
+# Реактивщина
+https://projectreactor.io/docs/core/release/api/ - список классов и методов по Project Reator
+
+https://habr.com/ru/post/565000/ - основной источник материалов
+
+1. Реактивное программирование. Основные принципы. Преимущество реактивного программирование над блокирующим.
+2. Перечислите основные виды потерь на блокирующем типе программирования в web
+3. Объясните понятие backpressure. Что оно дает. https://habr.com/ru/post/512724/
+4. При каком количестве запросов и нагрузке имеет реактивно построенное приложение начинает выигровать у приложения с блокироющим типом запросов. Приведите оценки
+5. Основные библиотеки
+
+# Rector Core
+1. Cтандарт спецификации Reactive Streams.
+2. Reactive Streams: Основные интефейсы
+3. Reactive Streams: Publisher
+4. Reactive Streams: Subscriber
+5. Основные модули Project Reactor
+6. Reactor Core: основные интерфейсы
+7. Flux Api. Основные методы https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html
+8. Mono Api. Основные методы
+9. Обработка ошибок
+10. Тестирование
+11. Параллельное выполнение. Scheduler
+12. Backpressure: оператор request
+13. Горячий и холодный паблишер. Что это. Как создать
+14. Контекст: локальные переменные для контекста
+15. Sinks. События
+16. Отладка/Debug реактивной программы
+
+# Spring WebFlux (Расширить)
+22. Реактивные Application Servers: Netty, Jetty, Tomcat, Servlet 3.1, HTTP 2.0
+23. Spring WebFlux. Для чего используется
+24. Обработка запроса. Аннотационная модель: контроллеры на базе WebFlux
+25. Обработка запроса. Функциональная модель: HandlerFunctions, RouterFunctions,
+26. Spring Security WebFlux.
+27. Отправка запросов. WebClient. Основные методы
+28. WebSocket, RSocket
+29. Тестирование WebFlux
+
+# R2DBC (Расширить)
+30. Что такое R2DBC, Программы, реализующие драверы для R2DBC
+31. SPRING DATA R2DBC
+32. ReactiveCrudRepository
+33. DatabaseClient. Оптравка SQL запросов напрямую в БД
+34. Транзакции
+
+[к оглавлению](#Вопросы-для-разбора)
+
+[Вопросы для собеседования](README.md)