Это признак какой-то проблемы: либо ты должен мокать интерфейс, либо в случае всяких value object'ов типа DateTime ты должен создавать инстанс класса напрямую.
В юнит-тестах - разумеется. Я ж говорю - иногда.
Бывает, скажем, надо по-быстрому написать тест на баг, прям по репродюс кейсу.Да просто я уже по 100 раз слышу одни и те же аргументы: мокать нельзя, якобы нарушает OCP, нельзя перекрыть баг во внешней библиотеке и т.д. У меня уже есть запасённые контраргументы.
Не нужно.
Не нарушает.
Копируй весь класс с багом, фикси и используй его, как реализацию.
Я правильно понял, ты предлагаешь создать новую физическую копию класса вместе со всеми его выявленными и невыявленными недостатками и называешь это более корректным подходом чем расширение на базе наследования?Копируй весь класс с багом, фикси и используй его, как реализацию.
А я бы наоборот посоветовал с практики заниматься. Только не методом тыка, а методом работы с хорошим кодом.
Нет. И то, и другое — это вынужденный хак до фикса на стороне vendor'а. Мой пойнт в том, что отказываться от final с мотивацией «чтобы можно было перекрыть баг, если он есть» не стоит того, т.е. и без наследования есть аж 2 варианта:
Понятно. Просто я бы не стал так категорично заявлять насчет final. Как минимум часто protected фабричный метод.
Точка расширения через интерфейс фабрики в конструкторе будет куда лучше.
Все это круто. Я надеюсь ты про бритву Оккама не забыл. Пока программы пишут люди, все эти тепломягкие споры упираютсяв некий предел. Предел когда идеальный код оправдан, а когда нет, с практической точки зрения в случае написания и последующего сопровождения человеками. При экстремальной степени декомпозиции (которая определенно возникнет при твоем подходе - это только вопрос сложности проекта) возникают совсем другие проблемы. По этому final, а особенно при работе в команде, его как бы на практике часто проще убрать, чем другими способами проблему решить.
Физическая копия в виде форка репозитория - вполне корректный подход.
Проще убрать final, чем добавить новый аргумент в конструктор или, на крайняк, сделать сеттер? Возможно в ближайшей перспективе это проще, но как и с прочими «простыми» решениями это может создать проблемы в будущем.
Куда добавить, какие простые решения и какие проблемы? Ты хочешь изменить поведение используя внутренний полиморфизм типа - путем подмены реализации одного метода, который используется внутри этого же класса. С файналом тебе всю реализацию заново переписывать придется, потенциально добавляя туда косяков и глюков. Файнал действительно нарушает OCP, как тут было подмечено.
Файнал как и статика убивает полиморфизм (в данном случае внутренний). Нет полиморфизма, нет возможности изменить поведение. Отсутствие этой возможности и есть закрытость класса для расширения. Никто же не говорит что в принципе изменения недоступны. Этот принцип относится именно к классу.
Это заблуждение. http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html
Тащемта, в каком-то смысле это «истина в последней инстанции».
