Что бы знать, что делает приложение, в 90% случаях достаточно посмотреть на точки входа, разве нет? Оставшиеся 10% это какие нибудь бекграунд джобы.
Имхо, не важно как вы называете это, но это просто добавление 4 слоя к стандартной трехслойной архитектуре. И имхо в идеале добавлять это только для части сценариев, где наблюдается сложная бизнес логика, связанная с множеством сервисов и репозиториев. Таких сценариев часто не очень много, подавляющее большинство вполне укладываются в три слоя.
Как мне кажется выделить какой либо сценарий в 4 слой можно на любом этапе разработки, когда в этом появится необходимость (каждый сам проведет границу).
Джуновское, но удивлен что в этот вопрос они не подняли тему пула строк
Имхо, 2 вопрос не так плох - проверка знания того, что дженерики инвариантны
Согласен
Этот вопрос отвратителен. Может быть я чего-то не понимаю, но во-первых, почему вопрос поставлен во множественном числе, а во-вторых, тут в целом нет правильного ответа, так как TreeSet можно использовать с объектами, которые не реализуют Comparable, если передать в конструктор реализацию компаратора
Нуууу окей, хотя в чем была проблема взять что-то похожее из OCP с примерами кода
Второй по отвратительности вопрос, ответ на который получается только методом исключения остальных вариантов. Причем тут в целом дефрагментация, она же не является именно источником проблемы.
Прям дежавю какое-то, буквально на этой неделе с лидом обсуждали такой же вопрос.
Отвечая на вопрос: в юнит тестах мы мокаем зависимости, тот же Mockito успешно позволяет получить мок от реализации с возможностью указать любой ответ на любой публичный метод.
Хоть убей, но я не могу представить ситуации, когда этого будет недостаточно, и вариант с интерфейсом и тестовой реализацией будет предпочтительнее.
Все вышеперечисленное правдиво, если мы исходим из того, что юнит тест должен проверять логику только тестируемого класса и не должен иметь никаких дел с зависимостями
Много лет назад Евгений Борисов в своем спринг потрошителе проводил перфоманс тест по использованию Spring AOP и ручному созданию динамических прокси через BeanPostProcessor + Proxy.newProxyInstance. По его результатам Spring AOP был сильно медленнее именно при вызове методов. Может кто-нибудь знает какие-то новые исследования на эту тему, поменялось ли что-то спустя время?
Comparator.comparing(String::toLowerCase) - не компилируется "Reference to 'toLowerCase' is ambiguous, both 'toLowerCase(Locale)' and 'toLowerCase()' match";
Что бы знать, что делает приложение, в 90% случаях достаточно посмотреть на точки входа, разве нет? Оставшиеся 10% это какие нибудь бекграунд джобы.
Имхо, не важно как вы называете это, но это просто добавление 4 слоя к стандартной трехслойной архитектуре. И имхо в идеале добавлять это только для части сценариев, где наблюдается сложная бизнес логика, связанная с множеством сервисов и репозиториев. Таких сценариев часто не очень много, подавляющее большинство вполне укладываются в три слоя.
Как мне кажется выделить какой либо сценарий в 4 слой можно на любом этапе разработки, когда в этом появится необходимость (каждый сам проведет границу).
Джуновское, но удивлен что в этот вопрос они не подняли тему пула строк
Имхо, 2 вопрос не так плох - проверка знания того, что дженерики инвариантны
Согласен
Этот вопрос отвратителен. Может быть я чего-то не понимаю, но во-первых, почему вопрос поставлен во множественном числе, а во-вторых, тут в целом нет правильного ответа, так как TreeSet можно использовать с объектами, которые не реализуют Comparable, если передать в конструктор реализацию компаратора
Нуууу окей, хотя в чем была проблема взять что-то похожее из OCP с примерами кода
Второй по отвратительности вопрос, ответ на который получается только методом исключения остальных вариантов. Причем тут в целом дефрагментация, она же не является именно источником проблемы.
Прям дежавю какое-то, буквально на этой неделе с лидом обсуждали такой же вопрос.
Отвечая на вопрос: в юнит тестах мы мокаем зависимости, тот же Mockito успешно позволяет получить мок от реализации с возможностью указать любой ответ на любой публичный метод.
Хоть убей, но я не могу представить ситуации, когда этого будет недостаточно, и вариант с интерфейсом и тестовой реализацией будет предпочтительнее.
Все вышеперечисленное правдиво, если мы исходим из того, что юнит тест должен проверять логику только тестируемого класса и не должен иметь никаких дел с зависимостями
Много лет назад Евгений Борисов в своем спринг потрошителе проводил перфоманс тест по использованию Spring AOP и ручному созданию динамических прокси через BeanPostProcessor + Proxy.newProxyInstance. По его результатам Spring AOP был сильно медленнее именно при вызове методов. Может кто-нибудь знает какие-то новые исследования на эту тему, поменялось ли что-то спустя время?
Поясните, пожалуйста, что имеется в виду под "квалификатором" ?
Comparator.comparing(String::toLowerCase) - не компилируется "Reference to 'toLowerCase' is ambiguous, both 'toLowerCase(Locale)' and 'toLowerCase()' match";
Comparator<String> cmp = Comparator.comparing(String::toLowerCase) - компилируется;
Comparator<String> cmp = Comparator.comparing(String::toLowerCase).reversed() - не компилируется, причина как в 1 пункте
А вы с какой jdk пробуете скомпилировать этот пример?