pazukdev

Вы можете безопасно обмениваться данными с кем-то только в том случае, если у Вас обоих есть общий ключ для их шифровки и расшифровки, о котором больше никто не знает. Проблема в том, как сделать так, чтобы он оказался у вас обоих, но при этом никто его не узнал. Т.е. как передать ключ по открытому каналу не скомпроментировав его. Ассиметричное шифрование как раз вот про это.

Алгоритм этой операции такой:

1. Сервер передает клиенту публичный ключ по незащищенному соединению.

2. На основе публичного ключа сервера клиент создает разделяемый (общий) ключ, сохраняет его у себя.

3. Клиент шифрует свой разделяемый ключ и в зашифрованном виде передает серверу.

4. Сервер расшифровывает зашифрованный разделяемый ключ c помощью своего приватного ключа и получает разделяемый ключ у себя.

Ассиметричное шифрование свою задачу выполнило - handshake состоялось. Далее клиент и сервер имея разделяемый ключ могут обмениваться уже симметрично зашифрованными данными.

Вы можете безопасно обмениваться данными с кем-то только в том случае, если у Вас обоих есть общий ключ для их шифровки и расшифровки, о котором больше никто не знает. Проблема в том, как сделать так, чтобы он оказался у вас обоих, но при этом никто не узнал. Т.е. как передать ключ по открытому каналу не скомпроментировав его. Ассиметричное шифрование как раз вот про это.

Алгоритм этой операции такой:

1. Сервер передает клиенту публичный ключ по незащищенному соединению.

2. На основе публичного ключа сервера клиент создает разделяемый (общий) ключ, сохраняет его у себя.

3. Клиент шифрует свой разделяемый ключ и в зашифрованном виде передает серверу.

4. Сервер расшифровывает зашифрованный разделяемый ключ c помощью своего приватного ключа и получает разделяемый ключ у себя.

Ассиметричное шифрование свою задачу выполнило - handshake состоялось. Далее клиент и сервер имея разделяемый ключ могут обмениваться уже симметрично зашифрованными данными.

Почему нельзя, когда можно?

public class SomeSubClass {
    
    void someMethod() throws CloneNotSupportedException {
        this.clone();
    }
    
}

Этот код компилируется.

Многопоточность vs асинхронность

Ресторан. Клиент заказал яичницу и гренки. 

1. Синхронное выполнение: даем задание 1 повару. Он сначала делает яичницу. После того как она готова он приступает к гренкам.

2. Асинхронное выполнение (многопоточность): даем задание 2 поварам. Они приступают условно одновременно. Один делает яичницу, второй гренки и оба конфликтуют из-за доступа к общим ресурсам (перцу, соли, сковородке).

3. Асинхронное выполнение (1 поток): даем задание 1 повару. Он ставит на плиту яичницу и ставит таймер. Ставит гренки и тоже ставит таймер. Пока таймеры не сработали, чтобы не терять время, прибирает кухню. После того как сработают оба таймера - отдает заказ.

Как уже тут было сказано в комменте выше:

с одной целью - снизить сложность сопровождения и развития большой кодовой базы

Я бы добавил, что ООП пытается повысить "человекопонятность" кода за счет переноса свойств реального мира на процесс написания и структуру кода.

Требование 2НФ - отсутствие зависимости неключевых атрибутов от части составного ключа. Дата рождения ребенка зависит только от его имени. Т.е. только от части ключа "Сотрудник, имя ребенка". Поэтому для приведение к 2НФ надо декомпозировать отношение, вынеся отдельную таблицу "Имя ребенка, дата рождения ребенка".
PS Замена вашего составного первичного ключа на id, кстати, тоже формально приведет к 2НФ. Но это такое.

Суть я понимаю, что они позволяют получать доступ к переменным других классов с уровнем доступа private

Они позволяют получать контролируемый доступ. Любая сущность должна быть доступна для внешней среды только через интерфейс. Public методы - это интерфейс любго класса. Setter'ы и Getter'ы - часть этого интерфейса.
Хотя аксессоры действительно в какой-то мере могут казаться формализмом.

Интерфейсы в Java не наследуются от Object.

1, Абстракция нужна везде, где будет проходить ось изменений системы. А интерфейс - основное средство достижения абстракции в Java. Из этого следует п.2.
2. Всегда, когда нужна абстракция (за исключением случаев, когда абстракция должна обладать состоянием. В таком случае вместо интерфейса придется использовать абстрактный класс т.к. интерфейс не может обладать состоянием).

Body могут (и обязательно должны) иметь static, default (Java 8) и private (Java 9) методы.

1. Класс - это всегда интерфейс + реализация (хотя бы частичная).
2. Интерфейс - это способ полностью отделить интерфейс от реализаци. Т.е. полностью абстрактный класс. Служит для описания котракта поведения класса для взаимодействия с внешним окружением.

1. Interface - это контракт системы с внешним окружением. Более Java-специфично: контракт для класса на определенное поведение реализованный в форме напоминающей полностью абстрактный класс.
Применять всегда. Это основной способ реализации абстракции.

2. Abstract class - это шаблон для группы классов кот. не может быть инстанциирован т.к. не содержит полного описания поведения (может содержать частичное).
Применять только в специфических случаях, когда нужно какое-то стостояние в абстракции.

Конкретные различия можно посмотреть тут: https://ru.stackoverflow.com/a/1229336/258227

Монада - это абстракция над цепочкой связанных вычислений. Контейнер, который принимает текущее состояние и функцию, которая принимает это состояние в качестве аргумента и возвращает новое состояние. Этот контейнер инкапсулирует среду (контекст) выполнения вычислений с учетом возможных исключений; на выходе только ожидаемые значения. Вобщем, just a monoid in the category of endofunctors (c).