pro.jvm

04 Dec 2024 09:51

Возможно, просто еще одна из причин использовать интерфейсы

pro.jvm

04 Dec 2024 09:49

экономия на спичках, не?

спринг не компилирует -> разница будет для раздутых приложений как оптимизация скорости старта и, может быть, перегруженных сценариев, но и только

pro.jvm

04 Dec 2024 08:57

Это практика для начинающих разработчиков в основном, так проще выделить контракт. Если ты можешь сразу писать сервис, понимая, что нужно минимизировать связность в приложении, такой подход не нужен

pro.jvm

04 Dec 2024 08:51

объект какого типа вернёт Mockito.mock?

pro.jvm

04 Dec 2024 08:50

Ну а как ещё воссоздавать конкретные ответы от зависимости, кроме как через when then?

pro.jvm

04 Dec 2024 08:46

че реакции понаставили. Интересно услышать вашу точку зрения

pro.jvm

04 Dec 2024 08:14

Не лезь 🤷
Ты сейчас у себя в голове какие-то аргументы придумал, никого в них не посвятил
И пытаешься общаться

pro.jvm

04 Dec 2024 08:13

Зачем мне лезть в апи для написания тестов?

pro.jvm

04 Dec 2024 08:12

A -> B -> C, где циклы?

pro.jvm

04 Dec 2024 08:11

И как это помешает? Рефакторинг с выделением интерфейса идея сама прекрасно сделает

pro.jvm

04 Dec 2024 07:59

надо реализацию не?, смысла в Mockito.when(<service>.<method>).thenReturn() нет

pro.jvm

04 Dec 2024 07:50

ну появится вторая, тогда можно рефакторнуть, сильно работы не увеличится

pro.jvm

04 Dec 2024 07:49

наверн в компании просто платят за количество интерфейсов в коде🤷‍♂️

pro.jvm

04 Dec 2024 07:25

Вы что тестируете: контракт или каждую отдельную его реализацию?

pro.jvm

04 Dec 2024 07:19

Создайте свой абстрактный класс, который будет передавать в предка уже заготовленные параметры, при наследовании от него передавать их снова уже не потребуется

pro.jvm

04 Dec 2024 09:50

Так, условно, если у тебя зависимость UsersService, то ты ему можешь этот мок присвоить? Или тип всё же другой?

pro.jvm

04 Dec 2024 09:45

Кроме того, что выше написали про контракты и тестирование:

- если использовать интерфейсы, Spring для создания прокси сможет применять Dynamic Proxy, встроенную в Java, тогда код будет легче и производительнее.

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

Так что использование интерфейсов помогает Spring работать более оптимально.

pro.jvm

04 Dec 2024 08:57

public static <T> T mock(Class<T> classToMock)

pro.jvm

04 Dec 2024 08:51

Есть понятие "Testability", оно подразумевает что когда пишем код нужно думать о том как его будем тестировать.

pro.jvm

04 Dec 2024 08:50

Если вы это мокаете, значит это вы не тестируете, значит это заменяется заглушкой. А раз оно не являетя объектом тестирования - то откуда взялся вопрос про реализации? Странно.

pro.jvm

04 Dec 2024 08:16

@UnknownNightElf

pro.jvm

04 Dec 2024 08:14

Что если это апи внешнее?

pro.jvm

04 Dec 2024 08:13

От кого в твоем случае зависит C

pro.jvm

04 Dec 2024 08:12

А это уже циклические зависимости

pro.jvm

04 Dec 2024 08:11

Если только стопицот зависимых друг от друга сервисов к тому моменту не появятся...

pro.jvm

04 Dec 2024 07:51

а в тестах замокать сервис можно используя Mockito

pro.jvm

04 Dec 2024 07:50

не понимаю зачем сразу выделять интерфейс, если имплементация будет скорее всего одна

pro.jvm

04 Dec 2024 07:33

Это базовые знания ООП. Неважно, это ваш код или Minecraft, или другой библиотеки. Вы просто создайте абстрактную реализацию самого Block.

public abstract class DefaultBlock extends Block {
    public DefaultBlock() {
        super(...);
    }

    // TODO: ...
}

pro.jvm

04 Dec 2024 07:25

Если речь идёт о том, чтобы Block реализовывал абстрактный класс AbstractBlock, то такой вариант недопустим, так как класс Block является частью кода библиотеки, на основе которой я пишу свой проект.

pro.jvm

04 Dec 2024 07:16

Если интерфейс нужен для тестирования, то получается , что это размазывание тестовой инфраструктуры по всему приложению 🧐