что такое позднее и раннее связывание java
Java: механизмы наследования, ссылочные типы данных, интерфейсы, вложенные классы
Механизмы наследования
Интерфейс может быть объявлен для расширения одного или нескольких интерфейсов.
Наследование позволяет определять новые классы в терминах существующих классов.
Наследование интерфейсов реализует некоторую замену множественному наследованию, когда вместо того чтобы один класс имел несколько непосредственных суперклассов, этот класс наследует несколько интерфейсов. Интерфейс позволяет определить некоторый шаблон класса: описание методов без их реализации.
При создании подкласса на основе одного или нескольких суперклассов возможны следующие способы изменения поведения и структуры класса:
Объявление класса
Объявление класса вводит новый ссылочный тип и определяет или часть, или всю его реализацию.
Объявление класса может иметь следующее формальное описание:
Вложенный класс описывается так же, как и внешний.
В описании каждого класса указывается имя класса и тело класса, содержащее объявления полей класса. Дополнительно для класса могут быть заданы модификаторы класса и указан непосредственный суперкласс и реализуемые классом интерфейсы. Полями класса в Java называются переменные и методы, определяемые в теле класса.
Класс может иметь более одного модификатора класса.
В языке программирования Java существуют следующие модификаторы класса:
Для указания модификаторов класса применяются следующие правила:
Раннее и позднее связывание
Раннее и позднее связывание является одним из проявлений полиморфизма, позволяя выполнять одним оператором вызов различных методов в зависимости от типа объекта.
Русские Блоги
Раннее (статическое) связывание Java и позднее (динамическое) связывание
Концепция привязки программы:
Связывание относится к связыванию вызова метода с классом (телом метода), в котором расположен метод. Для java привязка делится на статическую привязку и динамическую привязку; или называется ранней привязкой и поздней привязкой.
Динамическое связывание:
Поздняя привязка: привязка в соответствии с типом конкретного объекта во время выполнения.
Если язык реализует позднее связывание, он также должен предоставлять некоторый механизм для определения типа объекта во время выполнения и вызова соответствующего метода соответственно. Другими словами, компилятор все еще не знает тип объекта в это время, но механизм вызова метода может исследовать самостоятельно и найти правильное тело метода. Различные языки имеют разные методы реализации позднего связывания. Но мы, по крайней мере, можем думать об этом так: все они должны вставить в объект какой-то особый тип информации.
Процесс динамической привязки:
Таблица методов для виртуальной машины для извлечения фактического типа объекта;
Подпись метода поиска виртуальной машины;
Вызвать метод.
Я уже сказал, что для методов в java помимо final, static, private
и метод построения являются предварительно привязанными, все остальные методы являются динамическими.
Типичная динамическая привязка происходит при объявлении преобразования родительского класса и подкласса:
Например: Parent p = new Children ();
Подробная информация о конкретном процессе:
1: компилятор проверяет объявленный тип и имя метода объекта.
Предположим, мы вызываем метод xf (args) и x был объявлен как объект класса C, тогда компилятор перечислит все методы с именем f в классе C и методы из класса C. Метод f унаследован от суперкласса.
2: затем компилятор проверяет типы параметров, указанные в вызове метода.
Если существует тип параметра, который наиболее точно соответствует типу параметра, предоставленному вызовом во всех методах с именем f, то вызывается этот метод. Этот процесс называется «разрешением перегрузки».
3: Когда программа запущена и метод вызывается с использованием динамической привязки, виртуальная машина должна вызвать версию метода, которая соответствует фактическому типу объекта, на который указывает x.
Предполагая, что фактическим типом является D (подкласс C), если класс D определяет f (String), тогда вызывается метод, в противном случае метод f (String) ищется в суперклассе D и так далее.
Когда виртуальная машина JAVA вызывает метод класса (статический метод), она выбирает метод для вызова на основе типа ссылки на объект (обычно известного во время компиляции). Напротив, когда виртуальная машина вызывает метод экземпляра, она выбирает метод для вызова на основе фактического типа объекта (который может быть известен только во время выполнения). Это динамическое связывание, которое является своего рода полиморфизмом. Динамическое связывание обеспечивает большую гибкость для решения актуальных бизнес-задач и представляет собой очень красивый механизм.
В отличие от методов, при работе с переменными-членами (переменными экземпляра и переменными класса) в классе java не используется привязка времени выполнения, а статическая привязка в общем смысле. Следовательно, в случае восходящего преобразования метод объекта может найти подкласс, а свойства объекта (переменные-члены) являются свойствами родительского класса (подкласс скрывает переменные-члены родительского класса).
Код Java
[java] view plaincopyprint? Просмотрите фрагмент кода на CODE, чтобы получить фрагмент кода
public class Father <
protected String name = «Атрибут отца»;
>
public class Son extends Father <
protected String name = «Атрибут сына»;
[java] view plaincopyprint? Просмотрите фрагмент кода на CODE, чтобы получить фрагмент кода
public class Father <
protected String name = «Атрибут отца»;
public class Son extends Father <
protected String name = «Атрибут сына»;
Результат: Признак сына называется
Java должна использовать метод статической привязки для атрибутов. Это связано с тем, что статическая привязка имеет много преимуществ: она позволяет нам находить ошибки в программе во время компиляции, а не во время выполнения. Это может повысить эффективность программы! Динамическое связывание методов предназначено для достижения полиморфизма, который является важной особенностью Java. Полиморфизм также является одной из ключевых объектно-ориентированных технологий, поэтому Java имеет смысл реализовать полиморфизм за счет повышения эффективности.
Pro Java
Страницы
6 июл. 2015 г.
Полиморфизм – позднее связывание.
В первой статье по полиморфизму мы кратко познакомились с тем что это такое. По существу это просто переопределение методов суперкласса в подклассах. Но наверное вся мощь и красота этого еще не совсем понятна. И может не совсем ясно для чего все это нужно. Теперь попробуем разобраться более глубже. Приготовились к глубокой медитации. Оммммм…. Ну и погнали! 🙂
Возьмем затертый до дыр пример с фигурами. Не будем отклонятся от классиков жанра 🙂
И так общим суперклассом у нас будет класс Shape, и у него будут наследники царь, царевич, король, королевич, Circle, Square, Triangle. Но мы пойдем чуть дальше заезженного примера 🙂 и образуем еще парочку наследников. Oval у нас будет наследником Circle, а Rect наследником Square.
На диаграмме все можно изобразить примерно так:
Методы drow() в каждом классе будут переопределены, а метод erase() будет просто наследоваться от Shape. Теперь осталось всю эту красоту забабахать в коде 🙂
Код у нас вышел очень красивый 🙂 Буквочка к буквочке 🙂 и вывод у него такой же 🙂
Теперь внимательно посмотрим на код. У нас есть одномерный массив shape классов Shape размером 6. И первому элементу массива мы присвоили ссылку на объект Shape (созадется new Shape()). А вот далее начинается магия, которую вы уже видели и должны понимать. Это называется восходящее преобразование. Я уже про это говорил, что ссылка суперкласса может указывать на объекты подклассов. И так далее мы присваиваем следующим элементам массива shape ссылки на подклассы. Но затем в выводе работает вообще сумасшедшая магия полиморфизма – вызываются методы подклассов, хотя ссылка имеет тип суперкласса.
Теперь вопрос от куда компилятор знает метод какого объекта должен быть вызван?
А компилятор то и не знает… 🙂 Ну а кто же тогда знает?
Кто, кто? Дракон в пальто!
Хотя в приведенной программе это не очень очевидно, что компилятор не знает, так как мы присваиваем элементам массива ссылки на конкретные объекты.
Но я это сделал для простоты понимания и наглядности того что происходит.
Чтобы все было по честному и было видно кто компилятор точно не может знать на какой объект будут ссылаться элементы массива, эту программу можно модифицировать так, чтобы массив заполнялся случайным образом.
Слева как раз и приведен пример измененного отрывка этой же программы, но массив уже заполняется случайным образом, что видно из вывода программы:
Встает все тот же вопрос – кто знает метод какого объекта надо вызывать в каждом конкретном случае? А знает это JVM. Но как она узнает? И тут начинается серьезная магия виртуальной машины Java вкупе с компилятором Java.
Сам компилятор не знает, но может подсказать JVM как надо обрабатывать инструкции вызова методов.
Чтобы в полной мере разобраться в сути происходящего, необходимо рассмотреть понятие связывания (binding).
Проблема определения метод какого объекта вызывать в нашей программе решается благодаря позднему связыванию (late binding), то есть связыванию, проводимому во время выполнения программы, в зависимости от типа объекта. Позднее связывание также называют динамическим (dynamic binding) или связыванием на стадии выполнения (runtime binding).
В языках, реализующих позднее связывание, должен существовать механизм определения фактического типа объекта во время работы программы, для вызова подходящего метода. Иначе говоря, компилятор не знает тип объекта, но механизм вызова методов определяет его и вызывает соответствующее тело метода. Механизм позднего связывания зависит от конкретного языка, но нетрудно предположить, что для его реализации в объекты должна включаться какая-то дополнительная информация. Теперь мы попытаемся выяснить, что же это за информация.
В прошлом посте, мы уже вкратце коснулись этого вопроса. Теперь постараемся понять более глубоко.
В инструкцию байт-кода invokespesial компилируются:
Есть конечно еще несколько других инструкций байт-кода для вызова методов: invokedynamic, invokeinterface и invokestatic. Но хотя об их использовании и говорят их названия, пока мы их обсуждать не будем. Если кому-то сильно хочется то можно почитать эту статью на враждебном каждому правоверному программисту буржуйском языке 🙂 Чтиво полезное, но для понимания того о чём сейчас речь, достаточно того, что я тут уже написал. Так же можно почитать эту статью на родном языке.
И так, надо уже переходить к практике. Модифицируем программу из этого поста, следующим образом:
Я подсветил private и final модификаторы чтобы вы обратили на них внимание и затем на то, какой байт-код для них создаст компилятор. Вывод у нашей программы сейчас следующий:
Заострю внимание на том, что ссылка root имеет тип Root, но указывает на объект типа Branch. И как я уже не однократно писал, обычные методы вызываются по версии объекта на который указывает ссылка. Именно через это свойство и реализуется полиморфизм.
Но в нашем случае, не смотря на это, первая команда вывела на консоль Root, а не Branch.
Эта команда сгенерирует достаточно длинный вывод, но нам нужна только эта часть:
Как видно из вывода команда root.prt() была преобразована в вызов типа invokespecial, а команда branch.prt() в invokevirtual.
Вот мы и раскрыли магию всего этого действа. Надеюсь вам понравилось представление 🙂 и теперь вы стали чуть больше понимать как работают полиморфные методы в Java.
Java: механизмы наследования, ссылочные типы данных, интерфейсы, вложенные классы
Механизмы наследования
Интерфейс может быть объявлен для расширения одного или нескольких интерфейсов.
Наследование позволяет определять новые классы в терминах существующих классов.
Наследование интерфейсов реализует некоторую замену множественному наследованию, когда вместо того чтобы один класс имел несколько непосредственных суперклассов, этот класс наследует несколько интерфейсов. Интерфейс позволяет определить некоторый шаблон класса: описание методов без их реализации.
При создании подкласса на основе одного или нескольких суперклассов возможны следующие способы изменения поведения и структуры класса:
Объявление класса
Объявление класса вводит новый ссылочный тип и определяет или часть, или всю его реализацию.
Объявление класса может иметь следующее формальное описание:
Вложенный класс описывается так же, как и внешний.
В описании каждого класса указывается имя класса и тело класса, содержащее объявления полей класса. Дополнительно для класса могут быть заданы модификаторы класса и указан непосредственный суперкласс и реализуемые классом интерфейсы. Полями класса в Java называются переменные и методы, определяемые в теле класса.
Класс может иметь более одного модификатора класса.
В языке программирования Java существуют следующие модификаторы класса:
Для указания модификаторов класса применяются следующие правила:
Раннее и позднее связывание
Раннее и позднее связывание является одним из проявлений полиморфизма, позволяя выполнять одним оператором вызов различных методов в зависимости от типа объекта.
Что такое позднее и раннее связывание java
Объектно-ориентированное программирование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.
Программа считается объектно-ориентированной, только если выполнены все три указанных требования. В частности, программирование, не использующее наследование, называется не объектно-ориентированным, а программированием с помощью абстрактных типов данных.
Назовите основные принципы ООП.
Это единственно верный порядок парадигм ООП, так как каждая последующая использует предыдущие.
Что такое «инкапсуляция»?
Инкапсуляция – это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя, открыв только то, что необходимо при последующем использовании.
Цель инкапсуляции — уйти от зависимости внешнего интерфейса класса (то, что могут использовать другие классы) от реализации. Чтобы малейшее изменение в классе не влекло за собой изменение внешнего поведения класса.
Что такое «наследование»?
Наследование – это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью.
Класс, от которого производится наследование, называется предком, базовым или родительским. Новый класс – потомком, наследником или производным классом.
Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
Полиморфизм бывает динамическим (переопределение) и статическим (перегрузка).
Полиморфная переменная, это переменная, которая может принимать значения разных типов, а полиморфная функция, это функция у которой хотя бы один аргумент является полиморфной переменной. Выделяют два вида полиморфных функций:
Абстрагирование – это способ выделить набор общих характеристик объекта, исключая из рассмотрения частные и незначимые. Соответственно, абстракция – это набор всех таких характеристик.
Что представляет собой «обмен сообщениями»?
Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия. В ООП посылка сообщения (вызов метода) — это единственный путь передать управление объекту. Если объект должен «отвечать» на это сообщение, то у него должна иметься соответствующий данному сообщению метод. Так же объекты, используя свои методы, могут и сами посылать сообщения другим объектам. Обмен сообщениями реализуется с помощью динамических вызовов, что приводит к чрезвычайно позднему связыванию (extreme late binding).
Расскажите про основные понятия ООП: «класс», «объект», «интерфейс».
Класс – это способ описания сущности, определяющий состояние и поведение, зависящее от этого состояния, а также правила для взаимодействия с данной сущностью (контракт).
С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов).
С точки зрения структуры программы, класс является сложным типом данных.
Объект (экземпляр) – это отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом. Каждый объект имеет конкретные значения атрибутов и методы, работающие с этими значениями на основе правил, заданных в классе.
Интерфейс – это набор методов класса, доступных для использования. Интерфейсом класса будет являться набор всех его публичных методов в совокупности с набором публичных атрибутов. По сути, интерфейс специфицирует класс, чётко определяя все возможные действия над ним.
В чем заключаются преимущества и недостатки объектно-ориентированного подхода в программировании?
Что подразумевают в плане принципов ООП выражения «является» и «имеет»?
«является» подразумевает наследование. «имеет» подразумевает ассоциацию (агрегацию или композицию).
В чем разница между композицией и агрегацией?
Ассоциация обозначает связь между объектами. Композиция и агрегация — частные случаи ассоциации «часть-целое».
Агрегация предполагает, что объекты связаны взаимоотношением «part-of» (часть). Композиция более строгий вариант агрегации. Дополнительно к требованию «part-of» накладывается условие, что экземпляр «части» может входить только в одно целое (или никуда не входить), в то время как в случае агрегации экземпляр «части» может входить в несколько целых.
Что такое статическое и динамическое связывание?
Связывание означает наличие связи между ссылкой и кодом. Например, переменная, на которую вы ссылаетесь, привязана к коду, в котором она определена. Аналогично, вызываемый метод привязан к месту в коде, где он определен. Присоединение вызова метода к телу метода. Если связывание проводится компилятором (компоновщиком) перед запуском программы, то оно называется статическим или ранним связыванием (early binding).
В свою очередь, позднее связывание (late binding) это связывание, проводимое непосредственно во время выполнения программы, в зависимости от типа объекта. Позднее связывание также называют динамическим (dynamic) или связыванием на стадии выполнения (runtime binding). В языках, реализующих позднее связывание, должен существовать механизм определения фактического типа объекта во время работы программы, для вызова подходящего метода. Иначе говоря, компилятор не знает тип объекта, но механизм вызова методов определяет его и вызывает соответствующее тело метода. Механизм позднего связывания зависит от конкретного языка, но нетрудно предположить, что для его реализации в объекты должна включаться какая-то дополнительная информация.
Итак, фундаментальное различие между статическим и динамическим связыванием в Java состоит в том, что первое происходит рано, во время компиляции на основе типа ссылочной переменной, а второе – позднее, во время выполнения, с использованием конкретных объектов.
Для всех методов Java используется механизм позднего (динамического) связывания, если только метод не был объявлен как static или final (приватные методы являются final по умолчанию).
Ключевые различия между ранним и поздним связыванием в языке Java:
Статическое связывание происходит во время компиляции, а динамическое – во время выполнения.
Поскольку статическое связывание происходит на ранней стадии жизненного цикла программы, его называют ранним связыванием. Аналогично, динамическое связывание называют также поздним связыванием, поскольку оно происходит позже, во время работы программы.
Статическое связывание используется в языке Java для разрешения перегруженных методов, в то время как динамическое связывание используется в языке Java для разрешения переопределенных методов.
Аналогично, приватные, статические и терминальные методы разрешаются при помощи статического связывания, поскольку их нельзя переопределять, а все виртуальные методы разрешаются при помощи динамического связывания.
В случае статического связывания используются не конкретные объекты, а информация о типе, то есть для обнаружения нужного метода используется тип ссылочной переменной. С другой стороны, при динамическом связывании для нахождения нужного метода в Java используется конкретный объект.
Пять основных принципов дизайна классов:
Принцип единственной ответственности (SRP)
Никогда не должно быть больше одной причины изменить класс.
Класс должен быть ответственен лишь за что-то одно. Если класс отвечает за решение нескольких задач, его подсистемы, реализующие решение этих задач, оказываются связанными друг с другом. Изменения в одной такой подсистеме ведут к изменениям в другой.
Представьте себе модуль, который обрабатывает заказы. Если заказ верно сформирован, он сохраняет его в базу данных и высылает письмо для подтверждения заказа. Принцип единственной обязанности подразумевает, что три аспекта этой проблемы на самом деле — три разные обязанности. А значит, должны находиться в разных классах или модулях. Объединение нескольких сущностей, которые могут меняться в разное время и по разным причинам, считается плохим проектным решением. Гораздо лучше разделить модуль на три отдельных, каждый из которых будет выполнять одну единственную функцию.
Принцип открытости/закрытости (OCP)
Программные сущности (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения.
Это означает, что должна быть возможность изменять внешнее поведение класса, не внося физические изменения в сам класс. Следуя этому принципу, классы разрабатываются так, чтобы для подстройки класса к конкретным условиям применения было достаточно расширить его и переопределить некоторые функции. Поэтому система должна быть гибкой, с возможностью работы в переменных условиях без изменения исходного кода. Используются интерфейсы
Принцип подстановки Барбары Лисков (LSP)
Объекты в программе можно заменить их наследниками без изменения свойств программы.
Это означает, что класс, разработанный путем расширения на основании базового класса, должен переопределять его методы так, чтобы не нарушалась функциональность с точки зрения клиента. То есть, если разработчик расширяет ваш класс и использует его в приложении, он не должен изменять ожидаемое поведение переопределенных методов. Если оказывается, что в коде проверяется тип класса, значит принцип подстановки нарушается.
Принцип разделения интерфейса (ISP)
Клиенты не должны быть вынуждены реализовывать методы, которые они не будут использовать.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более мелкие и специфические, чтобы клиенты мелких интерфейсов знали только о методах, необходимых в работе.
Рассмотрим пример. Разработчик Алекс создал интерфейс «отчет» и добавил два метода: generateExcel() и generatedPdf(). Теперь клиент А хочет использовать этот интерфейс, но он намерен использовать отчеты только в PDF-формате, а не в Excel. Он должен будет реализовать два метода, один из которых по большому счету не нужен и существует только благодаря Алексу — дизайнеру программного обеспечения. Клиент воспользуется либо другим интерфейсом, либо оставит поле для Excel пустым. Так в чем же решение? Оно состоит в разделении существующего интерфейса на два более мелких. Один — отчет в формате PDF, второй — отчет в формате Excel. Это даст пользователю возможность использовать только необходимый для него функционал.
Принцип инверсии зависимостей (DIP)
Зависимости внутри системы строятся на основе абстракций. Объектом зависимости должна быть абстракция, а не что-то конкретное. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Программное обеспечение нужно разрабатывать так, чтобы различные модули были автономными и соединялись друг с другом с помощью абстракции.
Классическое применение этого принципа — Spring framework. В рамках Spring framework все модули выполнены в виде отдельных компонентов, которые могут работать вместе. Они настолько автономны, что могут быть быть с такой же легкостью задействованы в других программных модулях помимо Spring framework. Это достигнуто за счет зависимости закрытых и открытых принципов. Все модули предоставляют доступ только к абстракции, которая может использоваться в другом модуле.
Что такое Монолит, Микросервис?
При начале работы над монолитным проектом Достоинства:
С увеличением размера проекта и команды разработки появляются Минусы:
Микросервисная архитектура — система, которая содержит больше одного обособленнго сервиса. Размер значения не имеет. Обособленный сервис — является независимой единицей развертывания, имеет своё хранилище, свою БД (?), отвечает за свою часть предметной области
Непрерывная интеграция (CI) — процесс автоматического принятия изменений. Первичный процесс обновления ПО, в рамках которого все изменения на уровне кода вносятся в единый центральный репозиторий. Такое внесение принято называть слиянием. После каждого слияния (которое проходит по несколько раз в день) в изменяемой системе происходит автоматическая сборка (часто приложение упаковывается в Docker) и тестирование (проверка конкретных модулей кода, UI, производительности, надёжности API). Таким образом разработчики страхуются от слишком поздних обнаружений проблем в обновлениях.
Непрерывная доставка (CD) — CI + CD. Автоматизированый процесс доставки изменений до продакшена. Теперь новая версия не только создаётся и тестируется при каждом изменении кода, регистрируемом в репозитории, но и может быть оперативно запущена по одному нажатию кнопки развёртывания. Однако запуск развёртывания всё ещё происходит вручную — ту самую кнопку всё же надо кому-то нажать. Этот метод позволяет выпускать изменения небольшими партиями, которые легко изменить или устранить в случае необходимости.
Сложности проектирования Микросервисов
Соответствие принципам Low coupling, high cohesion способствует быстрому внесению изменений и легкому тетсированию.
И внутри сервиса и между сервисами
Что выбрать Монолит или Микросервис?
https://microservices.io/ https://martinfowler.com/ «microservices patterns» chris richardson «clean architecture» robert martin
Взаимодействие между микросервисами
Межсервисное взаимодействие = сетевое взаимодействие, т.е. система управляется сообщениями
бинарные протоколы: gRPC, Thrift, Avro и т.д. Выше производительность, оптимизированно представление данных, можно определить схему сообщения из коробки, но меньше инструментов и не читаемы человеком
Типы сообщений
Виды взаимодействия
Пользователь должен ждать как можно меньше, и нужно выполнять как можно меньше запросов на опрос
Способы взаимодействия
На основе polling: Kafka 
Микросервисы могут работать одновеременно с разными диалектами БД. При этом есть сильная согласованность, когда изменения сразу видны всем, с момента их применения и конечная согласованность когда изменения будут видно, но не сразу, а доставляются асинхронно
В таких случаях используются Распределенные транзакции. Но это сложно, дорого и есть не везде. Можно эмулировать распределенную транзакцию с помощью вложенных локальных транзакций 
При этом возврат ошибки не гарантирует, что запись не была вставленна в БД. А откат первой транзакции не приводит к откату второй.
Saga паттерн: Для решения нужно разбивать одну большую распределенную транзакцию на последовательность локальных транзакций и предоставить возможность отката всех локальных транзакций. 
Особенности: нужно уметь восстанавливаться после сбоев любого участка и повторять сагу с определенного шага + отличать финальные ошибки от нефинальных Хореография 
Взаимоисключения
Тесты должны быть независимыми и уметь работать параллельно. Тесты не должны очищать БД или буффер брокера сообщений перед/после своего запуска/завершения
Для тестирования API лучше делать реальные HTTP вызовы, валидировать ответ согласно схеме (JSON). RESTAssured как пример инструмента.
При тестирование взаимодействия с БД на каждый запуск тестов локально поднимается БД. Embedded или TestContainers
При тестировании взаимодействия микросервисов на каждый запуск тестов локально HTTP-сервер, создаем моки операций сервисов, выполняем, моки валидируем. WireMock, MockServer
При тестировании аинхронных процессов стараемся приблизить тестовый сценарий к реальному, запускаем операцию и ждем завершения выполнения. Awaitility
При межсервисном взаимодействии сложно отследить весь путь запроса по системе
Визуализация трасс помогает построить схему взаимодействия между сервисами. Можно это делать атоматически и динамически. Zipkin, Jaeger