Комментарии 18
всегда следует отдавать предпочтение private перед protected полями. Однако, по какой-то причине, он не распространяет этот принцип на выбор между final и не-final классами.
не монимаю откуда эта шизофрения пошла, но делать нужно с точностью до наоборот.
надо дизайнить так, чтобы оставлять возможность расширения и наследования.
если вы пишете на ооп языке, и ваш дизайн ограничивает типовые механизмы ооп по умолчанию, а не в каких-то исключительных случаях - вам требуется переобучение.
"а что если кто то отнаследуется и все сломает?" - это не причина связывать руки тем, кто не сломает.
мы хотим переиспользовать так много кода, как можем.
это какой то всратый коммунизм с уравниловкой по низу (я не смог отнаследовать не сломав, и мой сосед не смог - значит все вокруг не могут и мы для всх это запретим ради общего блага). я сам, черт возьми, беру на себя риск, переиспользуя твой код, и сам несу за это ответственность.
и что теперь, целый форк заводить чтобы твой чертов final убрать?
Если вы не уверены, стоит ли включать ту или иную функцию в API, то лучше её не включать
ну и не включайте, причем здесь ограничение наследования? то шутка какая-то, эти вещи вообще не связаны
приходит очередной тимлид и начинается заново возня final vs не final, protected vs private, господи, как же достало
Коммунизм-то тут причём? 🤨
Поддерживаю. Какой то "сервер шизофрения" с этими sealed-ами в шарпе
надо дизайнить так, чтобы оставлять возможность расширения и наследования
Это сложно, мало кто умеет. Поэтому ограничения в виде приватных классов и тому подобного можно встретить во многих популярных фреймворках. Вот с Спринге например
"Composition over Inheritance" (c)
Переиспользование кода - это замечательно, но делать это путем наследования - это так себе практика
Нравится вам или нет, но наследование является неотъемлимым и одним из ключевых свойств ООП.
Если же вас это не устраивает, возможно просто ООП вам не подходит, и вам надо писать код в другой парадигме.
Специально для фанатиков final классов выпустили котлин, рекомендую автору перейти на него и не вызывать холивар на пустом месте.
Как правило то, что нельзя так просто расширить имеет private методы и final поля.
Но всё равно есть возможность отнаследоваться.
Значит всё же расширение возможно.
С моей точки зрения абсолютизм это вредно.
Нужно принимать решение исходя из каждого конкретного кейса. В большинстве случаев ты как разработчик можешь прийти в код и снять final, т.к код скорее our, чем yours. В договоре на трудоустройство это чётко прописано.
В остальных случаях ты автор библиотеки, и да мнение пользователей важно, но я уверен каждый комментатор здесь в своей библиотеке сделает так, как он считает нужным, а не то как хотели бы большинство юзеров пользоваться либой.
Вспоминаем все те шутки разработчик планировал использование так, а юзер в т.ч другой разработчик использует иначе.jpeg
И тут нет места ненависти ни к первым, ни ко вторым. Тут есть место лишь пониманию. Если его у тебя нет я могу дать:
К первым потому что библиотека бесплатная, и опен сорсная, не нравится подход? Ну иди форкни сделай свою версию.
К вторым ну ты сам опубликовал библиотеку со свободой т.е они могут юзать её, как они хотят. Да это может быть неправильно, а может быть правильно по итогу, кто его знает как оно по итогу получится. Да и не плевать ли тебе? Выкладывая либу в опен сорс ты же хотел помочь людям с проблемами.
Ну и вот холивары не нужны. Ничего полезного кроме поднятия своего ЧСВ оно не даёт и то только тому кто якобы победил.
Что мешает вторую (условно проигравшему) просто забить на мнение победителя и вообще забыть о том что холивар существовал? Да ничего. Оно кому-то надо портить день из-за одного человека?
Я уже не говорю о том что холивары чаще всего об этом и том же, но разными словами. Что скорее говорит о недостатке эмоционального интеллекта и эмпатии, нежели ___________. (Подставьте желаемое, мне лень придумывать)
Итого: final нужно тогда когда нужно.
Не final нужно тогда когда нужно.
А ещё напомню существует функциональное ии реактивное программирование. Одно из самых любимых свойств final, точнее на нём большая часть всего строится.
Если нужно больше по теме что где когда и при каких обстоятельствах читайте чистая архитектура.
Ну и вот холивары не нужны. Ничего полезного кроме поднятия своего ЧСВ оно не даёт и то только тому кто якобы победил.
В холиваре же нельзя победить, на то он и холивар. Можно только лучше ознакомиться с чужой точкой зрения и лучше выразить свою. За это мы их и любим ))
Итого: final нужно тогда когда нужно.
Не final нужно тогда когда нужно.
Если так, то перед каждым классом или переменной нужно либо поставить модификатор non-final, либо final. Без модификатора код компилироваться не должен.
Со стороны читабельности, качества кода и главное - реализации бизнес процессов это зарезервированное слово имеет столь бесконечно малое значение, что не то что бы эта статья и тепло, выделенное на ее написание, никогда не окупится, но и даже мой комментарий абсолютно иррационален.
Наследование, если только наследование не используется автором исходного класса, имхо - зло. Spring, SOLID и Дядя Боб говорят то-же самое.
Если ты автор библиотеки или апи, то да, не хочется сюрпризов и хочется пользователей ограничить, в то же время, часто приходится наследоваться для обхода проблем в библиотеках и тогда открытость здорово выручает.
Final должен быть значением по умолчанию для Java-классов