Комментарии 18
Оказывается, я всю жизнь говорил прозой писал код по принципам SOLID и не знал об этом.
А с базовыми принципами и паттернами так часто бывает: можно не знать об их существовании, но при этом прийти к ним самостоятельно. Но у самостоятельно изобретения паттернов и принципов есть ряд недостатков: 1. паттерны и принципы формируют язык, при помощи которого вы можете общаться с коллегами (с «самопальными» паттернами это не работает) 2. в книгах и сообществе с очень высокой вероятностью паттерны и принципы лучше проработы, выявлены их плюсы и минусы и т. д.
Поясню, откуда возник опрос. Пообщался с коллегами из непоследних компаний и обнаружил, что многие не следуют принципам SOLID. Это меня сильно удивило, потому что я придаю этим принципам очень серьезное значение. Стало интересно узнать статистику на более широкой выборке людей.
Особый интерес для меня представляет мнение людей, которые осознанно не используют SOLID. Но предлагаю оставить за пределами данного обсуждения ситуацию, когда SOLID (да и не только SOLID) не используется из-за убогого legacy-кода, рефакторить который нет ни ресурсов, ни желания: в таких ситуация зачастую выбирать не приходится.
Особый интерес для меня представляет мнение людей, которые осознанно не используют SOLID. Но предлагаю оставить за пределами данного обсуждения ситуацию, когда SOLID (да и не только SOLID) не используется из-за убогого legacy-кода, рефакторить который нет ни ресурсов, ни желания: в таких ситуация зачастую выбирать не приходится.
Впервые услышал про этот принцип из вашей статьи.
У меня возник вопрос — а статические методы вписываются в этот принцип?
У меня возник вопрос — а статические методы вписываются в этот принцип?
Скорее нет, чем да. С переходом на SOLID я не отказался от статических классов, но стал их использовать гораздо реже: статическими я делаю только не классы, которые мне не нужно будет стабить и/или мокить; в обратном же случае я делаю класс нестатическим и прокидываю как зависимость.
Большое количество статических классов в большинстве случаев говорит от функционально ориентированном подходе разработчика к решению проблемы (хотя исключения и возможны). SOLID же это своего рода правила решения ООП проблем.
А что вы имеете в виду под функциональным подходом в контексте статических классов? Отстутствие side-effect'ов? Или что-то еще?
Сущность в ООП определяется состоянием и поведением. Статические классы — есть вырожденный случай такой сущности.
Если изредка они встречаются, то это можно списать на необходимость: профилирование, низкоуровневые особенности свойств статических классов, наконец достаточность. Это такой полухак.
Если часто, то скорее всего в восприятии разработчика система представляется преобразователем входных данных в выходные.
Если изредка они встречаются, то это можно списать на необходимость: профилирование, низкоуровневые особенности свойств статических классов, наконец достаточность. Это такой полухак.
Если часто, то скорее всего в восприятии разработчика система представляется преобразователем входных данных в выходные.
Вопрос хороший, но сдя по реакции — вы не вставили пункт про «Не знаю что это / Не программирую»
C пунктом «Принцип изоляции интерфейса» периодически проблемы, а так тоже следовал, но не знал.
Сам следую, но это мелкие разработки, компании в которых работал, нет.
Мотивируют тем:
1. Многа кода
2. Непонятно
3. Путаница
и все в этом духе, когда-то спроектировал и запрограммил по принципам SOLID работу с пользователями, народ сходил с ума, они реально не могли понять как с этим работать, со временем привыкли, поняли, понравилось, но сами при этом все равно соблюдать принципы не хотят.
Но больше всего добивает момент, что студентам-программистам, которых знаю, это преподают в вузе, они сами называют это бредом и делают по принципам Флинстоунов)))
Мотивируют тем:
1. Многа кода
2. Непонятно
3. Путаница
и все в этом духе, когда-то спроектировал и запрограммил по принципам SOLID работу с пользователями, народ сходил с ума, они реально не могли понять как с этим работать, со временем привыкли, поняли, понравилось, но сами при этом все равно соблюдать принципы не хотят.
Но больше всего добивает момент, что студентам-программистам, которых знаю, это преподают в вузе, они сами называют это бредом и делают по принципам Флинстоунов)))
Я слышал примерно такую же «аргументацию», и она не укладывается у меня в голове. По-моему это детский лепет, а не аргументация.
Много кода? Так кода больше не становится. Сущностей (интерфейсов, классов) становится больше — да. Но это необходимое «зло».
Непонятно? Это вопрос профпригодности и компетентности
Путаница? Путаница — это когда все намешано в кучу. А когда система строится по принципам SOLID, у каждого класса и у каждого метода есть своя ответственность (причем одна).
Много кода? Так кода больше не становится. Сущностей (интерфейсов, классов) становится больше — да. Но это необходимое «зло».
Непонятно? Это вопрос профпригодности и компетентности
Путаница? Путаница — это когда все намешано в кучу. А когда система строится по принципам SOLID, у каждого класса и у каждого метода есть своя ответственность (причем одна).
Я и приводил аргументы, мучился, надоело, сделал по своей инициативе «как надо» и вот только тогда народ оценил силу.
А объем кода как обычно оценивают строчками и им как-то фиолетово, что в строче только символ { или }.
Просто видимо web диктует такой подход, часто ведь получается примерно так
А объем кода как обычно оценивают строчками и им как-то фиолетово, что в строче только символ { или }.
Просто видимо web диктует такой подход, часто ведь получается примерно так
… (случайно отправил, дописываю)
Мысли многих программистов:
— А давай я научусь делать сайты, сейчас книжку куплю и буду делать.
Приходит в магазин, выбирает книжку в стиле «как сделать сайт за 24 часа», «сайтостроение для чайников», учит
— Ура, я сделал клёвый сайт, а что, пойду ка я программистом работать.
Идет и устраивается на работу.
А дальше так и продолжается, научились делать как-то, «язык» подучили, а вот «грамматику» забыли, в итоге и получаем, что этот не понимает, этот не умеет и т.д. Могут выдавать быстро код, но сомнительного качества и невозможностью нормальной поддержки.
Мысли многих программистов:
— А давай я научусь делать сайты, сейчас книжку куплю и буду делать.
Приходит в магазин, выбирает книжку в стиле «как сделать сайт за 24 часа», «сайтостроение для чайников», учит
— Ура, я сделал клёвый сайт, а что, пойду ка я программистом работать.
Идет и устраивается на работу.
А дальше так и продолжается, научились делать как-то, «язык» подучили, а вот «грамматику» забыли, в итоге и получаем, что этот не понимает, этот не умеет и т.д. Могут выдавать быстро код, но сомнительного качества и невозможностью нормальной поддержки.
Аргументация может быть и проще.
Привыкли, «и так всё работает» с одной стороны, а с другой стороны то, что в обучение новой методике надо вкладывать деньги/время, и первое время эта самая новая методика только замедлит процесс выдачи результата (собственно, здесь SOLID от любой другой новинки не отличается — с любой технологией сначала идет замедление).
А с другой стороны — со стороны «профпригодности» — допустим, работает в фирме 20 человек из которых 5 очевидно эту новую методологию не потянут. Но в существующих реалиях эти пятеро работают, и нормально. Что делать? А искать новых людей сложно!
Есть еще и третья сторона — руководитель может в новой технологии не разбираться. А он привык, что все технические детали раньше тоже глубоко понимал. Как менеджеру ему это, может, и не надо, но он понимал. А сейчас пришел человек революцию делать. А вдруг он потом уйдет. И кроме него никто всех деталей просто и не знает. Риски? Риски.
А может быть и еще проще — коллектив «стабильный» и никто про это даже и не знает. И всем хорошо :)
P.S. Сам — «за», не поймите неправильно :)
Привыкли, «и так всё работает» с одной стороны, а с другой стороны то, что в обучение новой методике надо вкладывать деньги/время, и первое время эта самая новая методика только замедлит процесс выдачи результата (собственно, здесь SOLID от любой другой новинки не отличается — с любой технологией сначала идет замедление).
А с другой стороны — со стороны «профпригодности» — допустим, работает в фирме 20 человек из которых 5 очевидно эту новую методологию не потянут. Но в существующих реалиях эти пятеро работают, и нормально. Что делать? А искать новых людей сложно!
Есть еще и третья сторона — руководитель может в новой технологии не разбираться. А он привык, что все технические детали раньше тоже глубоко понимал. Как менеджеру ему это, может, и не надо, но он понимал. А сейчас пришел человек революцию делать. А вдруг он потом уйдет. И кроме него никто всех деталей просто и не знает. Риски? Риски.
А может быть и еще проще — коллектив «стабильный» и никто про это даже и не знает. И всем хорошо :)
P.S. Сам — «за», не поймите неправильно :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Следуете ли вы принципам SOLID при объектно-ориентированном дизайне и программировании?