Комментарии 13
Если не хотите палиться, что статья - просто копипаста с нейронки - удаляйте эмодзи.
Хочу сделать цикл статей
Тоже нейропаста?
Класс должен решать только одну проблему.
Пусть будет так. Для того чтобы это сделать нужно правило - как детерминировано определить какую единственную задачу должен решать класс. Где это правило?
Добавляй новую функциональность через новые классы/методы не меняя старые.
А если нужно поменять старые?
Дочерние классы должны соблюдать требования к родителю.
В оригинальном принципе нет ни слова про классы.
Дели большие интерфейсы на маленькие и специализированные.
Пусть будет так. А где правило согласно которого мы определяем что такое большие а что такое маленькие интерфейсы? Без этого правила принцип - это красивый и бесполезный набор слов.
Преждевременная оптимизация
→ Попытки «предусмотреть всё» ведут к переусложнению.
→ Пример: Создание интерфейса IReportExporter для единственной реализации PDFExporter.
→ Философия: «Не создавай абстракцию, пока нет реальной необходимости» (YAGNI+KISS > SOLID).
Причем здесь оптимизация? Оптимизация, в нашем контексте - это сокращение потребления ресурсов без потери функциональности, например процессора и памяти. Какое к этому имеют отношение создание каких то интерфейсов?
В сухом остатке так и не понятно из статьи. Есть абстрактный SOLID который непонятно как использовать а если использовать то еще и куча проблем может быть и нужно 10 раз подумать. А по итогу то нужно или нет? Если нужно то где обоснование что оно имеет больше плюсов чем минусов?
PS Статья написана нейронкой а ответы хотелось бы от автора получить.
Интересные вопросы. Предлагаю разделить их на отдельные треды, чтоб можно было точно понимать, что обсуждаем. Также сегодня уезжаю на неделю в горы, буду отвечать по мере возможностей.
Класс должен решать только одну проблему.
Пусть будет так. Для того чтобы это сделать нужно правило - как детерминировано определить какую единственную задачу должен решать класс. Где это правило?
→ Ваш вопрос за пределами Шпаргалки по SOLID. Он про объединения данных и кода работающего с этими данными в класс. Есть разные подходы:
1) Отражение объектов реального мира - классы имитируют (отражают) реальные объекты. Странно, когда человек имеет функцию распечатать, а вот секретарь может иметь такую функцию.
2) Договоренности команды, терминологический словарь.
3) Статистический - если данные и код встречаются вместе, то стоит их выделить в класс, скорей всего вы позже поймете что это за объект и назовете его (Рефакторинг, выделение граничного объекта Мартин Фаулер).
💡 Важно, чтобы меньше дискуссий возникало в команде опираться на знакомые определения и фиксировать их в документации. Слово "Клиент" в коде может значить разное: посетителя в офлайн магазине или покупателя на сайте. От этого иметь разные данные и код. Клиент может быть программа вызывающая API. Без ясности — путаница и ошибки.
Детерминированного критерия не существует. В команде можно спокойно договориться построить "Дом в верх дном". И команде будет понятно. Просто для новых участников и остального мира код будет странно и не понятно.
Детерминированного критерия не существует.
На этом можно и закончить.
Представьте себе уголовный кодекс в котором написано что преступление карается правосудием, но при этом сам кодекс не содержал бы полного определения понятия преступление. Был бы от такого кодекса толк? Вроде и написано все правильно - нельзя совершать преступления, вот только что такое преступление не очень понятно и у каждого гражданина, правоохранителя, прокурора, адвоката и судьи свое понимание что это. Очевидно что всех внешней правильности, практического смысла от такого полезного кодекса нет.
Ровно тоже самое и с SOLID. Буквы - красивые, призывы - пафосные, толку - ноль.
SRP - у класса должна быть одна ответственность. Какой смысл от принципа если нет методики определения этой самой ответственности? Если так то у каждого разработчика свои критерии что будет делать класс а следовательно, уберите SRP и ничего не поменяется - у каждого разработчика остануться свои критерии что будет делать класс.
ISP - тоже самое. Без методики как понять сколько много а сколько мало - толку нет. Каждый будет делать столько сколько посчитает нужным. Зачем тогда ISP?
OCP - напоминает очередное делай хорошо плохо не делай а что делать и как забыли подвести и все начинают трактовать как сами понимают.
Проблема SOLID что это просто мнение одного единственного человека 20 летней давности из которого сделали священную корову в придачу с религией, о котором уже 20 лет пишут статьи и шпаргалки и все никак не могут постигнуть. Причем мнение в стиле не делай плохо - делай хорошо, а как что такое хорошо я вам не скажу. Почему вроде бы инженерные принципы не могут постигнуть уже 20 лет? Да потому что они стали религиозными.
Для тех кто немного использует ИИ сразу бросается в глаза, что это тупо ответ от нейронки.
В следующий раз можно написать не статью,а пост:
"Вот вам промт для изучения SOLID" - так было бы честнее и каждый сам бы посмотрел ответ ИИ
Один класс — одна задача
Вот непонятно, где в оригинале "одна задача". Почему если в оригинале речь идет об "одной ответственности" и "одной причине для изменения", этот принцип так часто переводят как "одна задача"? Это же искажает смысл принципа для человека не читающего первоисточник.
Благодарю за предложение, действительно возможны разные трактовки. В определения что такое задача, что такое одна ответственность или зона ответственности для краткости не хочу идти. Замечание считаю важным, поправил.
Мало кто понимает srp правильно. Нет дело не в зоне ответственности и не в задаче, которую выполняет класс. Дело именно в причине изменений (акторе или заказчике функционала). Класс или модуль может делать, что угодно, совмещать разный функционал. Но если все это делается для одного бизнес-процесса и не аффектит другие, srp не нарушен.
1) До SOLID нужно дойти своим умом. Бесполезно читать эти принципы как мантру.
2) Этот текст написан ИИ.
Почему Хабр теперь пропускает статьи от DeepSeek, даже не редактированные? С таким успехом и я могу такую статью написать.
Ну статья свое дело делает, это просто шпаргалка. А про ИИ написано в конце так что нет смыла на человека накидываться, вот в соседних статьях 1 запрос к ИИ и тонна кода что выдал ИИ и это "контент"
"Лисков – это имя собственное, фамилия Барбары Лиско. Ученной из Америки. "
это фиаско братан. Ученый как и заведующий бывает только он. И пишется с одной "н". И Фамилия это не имя собственное. Имя собственное это Барбара. Надо было брать подсказку 50/50 ))) Лиско это какой то(абстрактный) восточный украинец. Фамилию надо ВСЕГДА писать правильно. Когда пишут с ошибками это ОЧЕНЬ обидно.
SOLID: Шпаргалка для собеседования и работы