Нет, тут про то, что если ты с помощью утилиты java компилишь и запускаешь один конкретный файл, но при этом он юзает классы из других файлов, то до 22ой Java у тебя бы падала ошибка. Теперь такая ситуация будет резолвиться автоматически, утилитка сама найдёт и скомпилит нужные файлы.
Да, новые версии Kora продолжают публиковаться в мавеновском репозитории. Tinkoff в целом забанили на GitHub, поэтому пока думаем, как полноценно вернуть проект в open source.
Предположим у нас микросервисная архитектура, но мы хотим, чтобы все микросервисы отвечали единоообразным правилам архитектуры, которые мы выражаем через тесты. Это нужно будет дублировать набор тестов в каждом сервисе?
Замечательная статья) Узнал много интересных вещей. Пользуюсь тем же стеком. Было бы интересно узнать как пишите тесты. А ещё мне очень интересно узнать, как решаете проблему с десериализацией POST/PUT запросов. jackson требует (даже при десериализации через конструктор), чтобы все поля были nullable даже те, что определённо такими быть не должны, и я навесил на них соответствующую валидацию с помощью hibernate-validator. Сам решаю классом-обёрткой и оператором !!, но есть ощущение, что можно и лучше.
Пример выглядит очень надуманным. Мы ввели новую сущность, но тесты для неё используем от другой сущности и поэтому всё сломается. Ну да, а вы чего ожидали?
Это не просто другая сущность — это наследник, подкласс. И тесты, которые справедливы для родителя должны быть справедливы и для наследника как раз из-за Принципа подстановки.
Open-Close это вовсе не только наследование, лучше уже про композицию рассказывать, в большинстве случаев полезнее будет.
Да, это вовсе не только наследование, но LSP показывает нам как его соблюсти именно в контексте наследования.
Да и кому нужно реальный мир моделировать(соседа, кстати, надо или нет моделировать?) — не понятно.
Пожалуй я слишком упрощённо сформулировал. Речь идёт о том, что мы оперируем абстракциями, причём не столько непосредственно объектов реального мира сколько понятий. У каждого понятия есть набор признаков. При написании ООП-кода мы выбираем те из них, которые являются наиболее значимыми в конкретной предметной области, то есть формируем абстракцию.
OC это более глобальный принцип. И достигается он в том числе и за счёт того, что зависимости внедряются через интерфейсы или говоря более общим словом абстракции. Об этом как раз говорит DI. Но не только. Принцип Подстановки Лисков также обепечивает выполнение OC за счёт того, что мы правильно реализуем иерархии наследования и клиентам базовых классов не нужно подстраиваться под детали реализации наследников, а значит не не надо изменятся, когда появляется новый наследник.
Дословно из оригинала:
We have a name for this expectation, we call it: encapsulation.
Но возможно я не правильно понял термин в контексте. Но я всегда полагал, что инкапсуляция в частности предполагает именно это. В чём конкретно разница между сокрытием и инкапсуляцией?
Как было сказано в самой статье и на чём я сакцентировал внимание в предисловии: ни одно программа не может быть на 100% закрыта. Это нужно принять. Какую бы продуманную абстракцию мы не построили, в любом случае могут появиться требования, которые заставить нас её изменить. Потому что правильность абстракций в каждой программе определяется прежде всего бизнес-требованиями. Следование же принципу открытости-закрытости просто позволяет свести изменения к минимуму и производить правильный рефакторинг. В примере из статьи самолётов не закладывали, но постепенно, стратегически вводили закрытость. Задача изначально была: рисовать фигуры. Потом требования дополнились: рисуй фигуры в правильной последовательности. Вот дополнили интерфейс соответствующим методом. Пришлось и DrawAllShapes поменять. Но теперь она закрыта от изменений требований в порядке рисования фигур. Но при этом всё ещё не закрыта от того, что допустим линии фигур надо рисовать в форме котёнка. Ну тут опять же надо изменять. Например введением аргумента в функцию Draw класса Shape типа DrawStrategy, которая воздействует на способ рисования линий. Либо же не изменять эту функцию, а просто ввести для фигур декораторы. Но тут нужно будет менять код, который эту функцию вызывает, чтобы он эти самые декораторы инициализировал и закинул в множество. Зависит от конкретной ситуации. Самое главное — держать в голове сам принцип и понимать, когда он нарушается, а когда нет и какие могут быть последствия.
Кстати, на нашей конференции 31 августа про кору тоже будут рассказывать
Онлайн нет, но записи докладов будут
Да, буквально сегодня вышла новая версия :)
https://github.com/kora-projects/kora
Нет, тут про то, что если ты с помощью утилиты java компилишь и запускаешь один конкретный файл, но при этом он юзает классы из других файлов, то до 22ой Java у тебя бы падала ошибка. Теперь такая ситуация будет резолвиться автоматически, утилитка сама найдёт и скомпилит нужные файлы.
Да, новые версии Kora продолжают публиковаться в мавеновском репозитории. Tinkoff в целом забанили на GitHub, поэтому пока думаем, как полноценно вернуть проект в open source.
Это не просто другая сущность — это наследник, подкласс. И тесты, которые справедливы для родителя должны быть справедливы и для наследника как раз из-за Принципа подстановки.
Да, это вовсе не только наследование, но LSP показывает нам как его соблюсти именно в контексте наследования.
Пожалуй я слишком упрощённо сформулировал. Речь идёт о том, что мы оперируем абстракциями, причём не столько непосредственно объектов реального мира сколько понятий. У каждого понятия есть набор признаков. При написании ООП-кода мы выбираем те из них, которые являются наиболее значимыми в конкретной предметной области, то есть формируем абстракцию.
We have a name for this expectation, we call it: encapsulation.
Но возможно я не правильно понял термин в контексте. Но я всегда полагал, что инкапсуляция в частности предполагает именно это. В чём конкретно разница между сокрытием и инкапсуляцией?