Ответ: Это зависит. Если выпивание всегда одинаково, но есть много реализаций этого выпивания, то это либо наследование, либо декоратор, либо адаптер. Ифчики тоже никто не отменял. Семантически эти подходы почти не различаются, а какой из сахаров выбрать — зависит от контекста: языка, бизнеса и, пожалуй, фазы луны.
В любом случае — это не вопрос SRP. Это вопрос Open-Close принципа (OCP) и он требует отдельной проработки. Постараюсь найти время заняться и этим парнем ;)
Человеку нужны вызовы. То что происходит сейчас, когда в цивилизованной части света, единственная проблема это лайки и социальный статус — неестественно для психики человека. И жизнь в колонии, в скафандрах, холодильниках и тяжелых нагрузках, без пути назад — может оказаться ответом.
Если рассматривать жизнь как высокоуровневую химическую реакцию — то такая реакция очень подвержена эффекту бабочки. При это сложно придумать ситуацию, где изменение условий приведет к глобальному размножению. А вот глобальное вымирание вещь простая: у каждого вида есть своя ниша и набор необходимых для выживания и конкуренции параметров — температура, пища, свет итд.
Но есть один вид, который заселил все — от северного до южного полюса и остановился ибо «зачем?».
У этого вида есть механизм осознанного (или частично осознанного) влияния на внешние условия. Потому, в рамках научных ограничений, мы можем поселиться хоть на поверхности солнца (летая у поверхности в холодильнике со скоростью достаточной что бы внутри аппарата было 1g) Была бы мотивация и достаточный уровень развития науки.
Короче — центрифуги, радиационная защита, евгеника и прочее прочее — дело техники, ресурсов и мотивации. В конце концов, как сказали выше, может оказаться что низкая гравитация напротив будет полезна. Мы не знаем.
Причины вымирания — худшая приспособленности организма к резко ( в масштабах эволюции) изменяющейся среде. Пищевой и экологической. То есть вот плавал себе бульбульзавр. Плавал и ел жуков. Миллионы лет плавал и ел. А потом жуки стали крупнее и южнее. А там много акул. А акулы едят бульбозавров. И вымерли бульбозавры. Людям же это не опасно, так как мы можем воссоздавать каких хочешь жукозаменителей и где угодно (были бы финансы). И подошвы липкие можем напридумывать.
Куда опаснее — остановившаяся эволюция тут, у нас в естественной гравитации. Вот с этим точно надо что то делать иначе через сто лет вся современная Евразия на колясках будет рассекать.
Зато как круто там прыгать! Баскетбол, на стадионе размером с футбольныйс кольцами на высоте 5ти этажного дома. А нет, случаем такой компьютерной игры?
К программированию эта нагрузка имеет мало отношения.
Если же волею ТЗ требуется взять именно 4 игрока, то разбиение выпивохи на сабличности тем более пригодится.
Зависит от контекста задачи. В случае с оригинальной студенческой игрой эти ответственности определенно разделены ;)
Если же весь процесс действительно жестко сцеплен, то есть изменение одной его части повлечет изменение другой — то это разделение не только не нужно, но и вредно.
В терминах SRP — такое разделение противоречит идее «локализации изменений».
Исключением может быть объемный процес, допустим на 500 строк кода (цифра «зависит»). В таком случае нужно стараться изыскивать возможности разделения ответственности, из-за ограничений нашего с вами мозга. Разбить сложный процесс на взаимодействие нескольких более простых.
Эта фраза и была основной мотивацией написать эту статью, так как вторая ее часть еще более загадочна чем изначальное определение. На сайте у дядюшки Боба еще целую страницу он объясняет что значит «Пользователи и заинтересованные лица и есть та самая причина для изменений».
Я написал эту статью в т.ч. из опыта общения с начинающими разработчиками и в процессе общения открыл для себя много нового.
Для тех кто уже знаком с Srp — да, вопрос «что делает этот класс» — хороший критерий для самопроверки.
Но если вас еще не успели познакомить — то возникает много вопросов:
1) При наличие фасадов ответ может быть расплывчатым
«Выпивоха ответственнен за все что касается выпивания». А стакан — касается выпивания или за хранения жидкости? Он часть выпивохи или нет? Для новичка (да и не только) это может быть большим вопросом.
2) Формулировка «за что отвечает» является больше мотивацией дробить чем объединять, то есть накладывает ограничение сверху по размеру модуля, по крайней мере в понимание начинающих программистов (практика опять таки показывает, что не только)
Вы раскусили нас. Наш с манагерами заговор. Вы не могли бы скрыть или опровергнуть свой комментарий, так как нам еще деньги зарабатывать, а вы нас хлеба лишаете? С меня процент!
Более того, манагер просят поменьше SOLID-а. У них «сроки-сжаты» и ХХВП их методология. SOLID и тесты — зачастую единственный формализм защиты от KPI-хаоса
khim — да это же старый добрый Punks-not-dead--driven-development!
Есть спортивные машины, а есть гражданские. Произвести спортивную машину, в абсолютных деньгах и сложности намного дешевле и прощще чем гражданскую. И гражданских машин — 98% рынка.
К чему это я- вокруг дивный чудный мир, и львиная доля рынка занимается разработкой сложного ПО, не критичного к производительности, но критичного к функицональности. Одиночки и маленькие команды никогда не справятся с этим количеством нюансов, правок и этой динамикой рынка. И разрабатывать такое по — это искуство писать код для человека. Сделать себя взаимозаменяемым, и из этого стать дороже для рынка.
Другой пример, где читабельность выходит на первый план — Open source, где мэинтейнеру выгоден только тот реквест, который не усугубит энтропию. Максимально ясный, и покрытый тестами.
Вы приводите пример писателя и книг — но позвольте. Если вам нужно написать книгу в 10к страниц, а дополнять или изменять главы нужно раз в неделю — много вы книг издадите? Книга подобна алгоритму в программе — красивый, отточенный, согласованный. Но в программе таких алгоритмов тысячи. Современный софт, в основной своей массе нельзя сравнивать с книгами — он из них состоит.
Вы приводите пример авиаконструкторов — но их флоу обусловлен экономикой. Стоимость испытания великА а стоимость факапа — катастрофична. В софте эти стоимости почти бесплатны в сравнении. И сравните скорость развития самолоетостроения и софтвер отрасли. Софтвер отрасль развивается на порядки быстрее — в том числе из-за итеративного подхода. Иными словами — да, конструкторы делали бы итерациями если могли бы. И да — мои предки так же инженеры-конструкторы. Это имеет мало общего с современной разработкой ПО.
Безусловно есть крайние примеры легаси банкинга и физ базз интертеймент, но это точно такой же непрофессионализм как и методы по 10к строк. Две крайности.
Я вполне допускаю что конкретно вы делаете классные и специфичные вещи — это прекрасно! Мне классно что бы мы все были разными, и не греблись под одну гребенку.
Но основная масса занимается немного другими делами. Наше массовое исскуство — в читабельности и гибкости, и это отнюдь не проще чем создание алгоритма или тем более оптимизация. Не понимаете этого? Не практикуете это? Так зачем критикуете то в чем не разбираетесь?
И да, в моей практике тоже есть много кейсов, когда именно грамотное разбиение по модулям, и SOLID с unit-тестированием позволяли внедрять огромные фичи почти бесплатно, стал бы иначе я так защищать эти подходы? Я вступаю адвокатом дьявола по той причине что был по обе стороны барикад. И низко уровневой разработке втч алгоритмов и высокоуровневом процессинге высоконагруженных серверов.
Ну и в конце концов — уважьте людей. Брать в заложники заказчика своей уникальностью, это некрасиво, не профессионально и как то… низко что ли?
Поправьте меня, если я вас не понял:
— Вы — считаете что командная работа над одной задачей это плохо
— Считаете что UI-код в сетевом стеке это норм, пока его можно докостылить
— Считаете что выделение компонентов это плохой ход при котором скачком растет сложность
— Вы предпочитаете переписывание рефаторингу
— Считаете что оптимизацию нужно делать как можно раньше.
Позвольте уточнить — что именно вы делаете и на каком языке?
В любом случае — это не вопрос SRP. Это вопрос Open-Close принципа (OCP) и он требует отдельной проработки. Постараюсь найти время заняться и этим парнем ;)
Но есть один вид, который заселил все — от северного до южного полюса и остановился ибо «зачем?».
У этого вида есть механизм осознанного (или частично осознанного) влияния на внешние условия. Потому, в рамках научных ограничений, мы можем поселиться хоть на поверхности солнца (летая у поверхности в холодильнике со скоростью достаточной что бы внутри аппарата было 1g) Была бы мотивация и достаточный уровень развития науки.
Короче — центрифуги, радиационная защита, евгеника и прочее прочее — дело техники, ресурсов и мотивации. В конце концов, как сказали выше, может оказаться что низкая гравитация напротив будет полезна. Мы не знаем.
Куда опаснее — остановившаяся эволюция тут, у нас в естественной гравитации. Вот с этим точно надо что то делать иначе через сто лет вся современная Евразия на колясках будет рассекать.
Если же волею ТЗ требуется взять именно 4 игрока, то разбиение выпивохи на сабличности тем более пригодится.
Если же весь процесс действительно жестко сцеплен, то есть изменение одной его части повлечет изменение другой — то это разделение не только не нужно, но и вредно.
В терминах SRP — такое разделение противоречит идее «локализации изменений».
Исключением может быть объемный процес, допустим на 500 строк кода (цифра «зависит»). В таком случае нужно стараться изыскивать возможности разделения ответственности, из-за ограничений нашего с вами мозга. Разбить сложный процесс на взаимодействие нескольких более простых.
Я написал эту статью в т.ч. из опыта общения с начинающими разработчиками и в процессе общения открыл для себя много нового.
Для тех кто уже знаком с Srp — да, вопрос «что делает этот класс» — хороший критерий для самопроверки.
Но если вас еще не успели познакомить — то возникает много вопросов:
1) При наличие фасадов ответ может быть расплывчатым
«Выпивоха ответственнен за все что касается выпивания». А стакан — касается выпивания или за хранения жидкости? Он часть выпивохи или нет? Для новичка (да и не только) это может быть большим вопросом.
2) Формулировка «за что отвечает» является больше мотивацией дробить чем объединять, то есть накладывает ограничение сверху по размеру модуля, по крайней мере в понимание начинающих программистов (практика опять таки показывает, что не только)
Embeded (24%):
C 14.243%
C++ 8.095%
asm 1.816%
Enterprise (30%):
Java 16.005%
Visual Basic .NET 5.193%
C# 3.984%
SQL 2.555%
PHP 2.489%
Действительно больше чем я ожидал. Впрочем это не касается особенно дискурса ибо Solid, безусловно не про низкоуровневую разработку
Есть спортивные машины, а есть гражданские. Произвести спортивную машину, в абсолютных деньгах и сложности намного дешевле и прощще чем гражданскую. И гражданских машин — 98% рынка.
К чему это я- вокруг дивный чудный мир, и львиная доля рынка занимается разработкой сложного ПО, не критичного к производительности, но критичного к функицональности. Одиночки и маленькие команды никогда не справятся с этим количеством нюансов, правок и этой динамикой рынка. И разрабатывать такое по — это искуство писать код для человека. Сделать себя взаимозаменяемым, и из этого стать дороже для рынка.
Другой пример, где читабельность выходит на первый план — Open source, где мэинтейнеру выгоден только тот реквест, который не усугубит энтропию. Максимально ясный, и покрытый тестами.
Вы приводите пример писателя и книг — но позвольте. Если вам нужно написать книгу в 10к страниц, а дополнять или изменять главы нужно раз в неделю — много вы книг издадите? Книга подобна алгоритму в программе — красивый, отточенный, согласованный. Но в программе таких алгоритмов тысячи. Современный софт, в основной своей массе нельзя сравнивать с книгами — он из них состоит.
Вы приводите пример авиаконструкторов — но их флоу обусловлен экономикой. Стоимость испытания великА а стоимость факапа — катастрофична. В софте эти стоимости почти бесплатны в сравнении. И сравните скорость развития самолоетостроения и софтвер отрасли. Софтвер отрасль развивается на порядки быстрее — в том числе из-за итеративного подхода. Иными словами — да, конструкторы делали бы итерациями если могли бы. И да — мои предки так же инженеры-конструкторы. Это имеет мало общего с современной разработкой ПО.
Безусловно есть крайние примеры легаси банкинга и физ базз интертеймент, но это точно такой же непрофессионализм как и методы по 10к строк. Две крайности.
Я вполне допускаю что конкретно вы делаете классные и специфичные вещи — это прекрасно! Мне классно что бы мы все были разными, и не греблись под одну гребенку.
Но основная масса занимается немного другими делами. Наше массовое исскуство — в читабельности и гибкости, и это отнюдь не проще чем создание алгоритма или тем более оптимизация. Не понимаете этого? Не практикуете это? Так зачем критикуете то в чем не разбираетесь?
И да, в моей практике тоже есть много кейсов, когда именно грамотное разбиение по модулям, и SOLID с unit-тестированием позволяли внедрять огромные фичи почти бесплатно, стал бы иначе я так защищать эти подходы? Я вступаю адвокатом дьявола по той причине что был по обе стороны барикад. И низко уровневой разработке втч алгоритмов и высокоуровневом процессинге высоконагруженных серверов.
Ну и в конце концов — уважьте людей. Брать в заложники заказчика своей уникальностью, это некрасиво, не профессионально и как то… низко что ли?
Доброго дня вам, и отличных задач!
Поправьте меня, если я вас не понял:
— Вы — считаете что командная работа над одной задачей это плохо
— Считаете что UI-код в сетевом стеке это норм, пока его можно докостылить
— Считаете что выделение компонентов это плохой ход при котором скачком растет сложность
— Вы предпочитаете переписывание рефаторингу
— Считаете что оптимизацию нужно делать как можно раньше.
Позвольте уточнить — что именно вы делаете и на каком языке?