Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Принцип единственной ответственности — Класс должен делать что-то одно
И только этот класс должен делать это.
В заголовке есть KISS, а в списке его нет. Плюс вы там советуете интерфейсы использовать в качестве параметров конструктора, дык это вроде как нужно делать, только если это нужно делать, не раньше. Там еще полно подобных принципов: YAGNI, DRY…
Скорее всего озаглавить нужно было SOLID, раз уж Барбара в списке, но тогда труселя придется менять…
Непонятно про дефолты. Ссылка на вики ничего не прояснила, какие-то json, принцип наименьшего удивления… может в таблице нужен третий столбец с маленьким «плохим» примером и «как надо»?
Вы несколько раз пишете «класс должен делать что-то одно» или «меньше завязаны», а потом идет объяснение, но не для всех случаев, в результате некоторые принципы становятся не раскрытыми.
А так вообще идея неплохая, намного проще держать в голове содержимое второго столбца, чем «сферическо-вакуумные» наименования, но не все у вас получилось. Когда именно я перестаю управлять собакой и начинаю управлять лапами?
Скорее всего озаглавить нужно было SOLID, раз уж Барбара в списке, но тогда труселя придется менять…
Непонятно про дефолты. Ссылка на вики ничего не прояснила, какие-то json, принцип наименьшего удивления… может в таблице нужен третий столбец с маленьким «плохим» примером и «как надо»?
Вы несколько раз пишете «класс должен делать что-то одно» или «меньше завязаны», а потом идет объяснение, но не для всех случаев, в результате некоторые принципы становятся не раскрытыми.
А так вообще идея неплохая, намного проще держать в голове содержимое второго столбца, чем «сферическо-вакуумные» наименования, но не все у вас получилось. Когда именно я перестаю управлять собакой и начинаю управлять лапами?
dry и kiss слишком простые, чтобы их описывать ). Расшифровка их аббревиатур является их сутью.
Разве что про yagni можно рассказать дополнительно пару слов
Разве что про yagni можно рассказать дополнительно пару слов
В заголовке есть KISS, а в списке его нет.Да, было бы неплохо добавить. Вроде «Не усложняй». DRY, YAGNI сюда же.
труселя придется менятьДля чего этот пик в технической статье кто-нибудь может объяснить?
Про KISS хорошо объяснено в Луркоморе: lurkmore.to/KISS
добавил KISS
Мне кажется что классические законы будут в тему:
Законы машинного программирования
1. Любая действующая программа устарела.
2. Любая программа обходится дороже и требует больших затрат времени, чем предполагалось.
3. Если программа полностью отлажена, ее нужно будет скорректировать.
4. Любая программа стремится занять всю доступную память.
5. Ценность программы прямо пропорциональна весу ее «выдачи».
6. Сложность программы растет до тех пор, пока не превысит способности программиста.
Постулаты Трумэна по программированию
1. Самая грубая ошибка будет выявлена, лишь когда программа пробудет в производстве по крайней мере полгода.
2. Контрольные перфокарты, которые решительно не могут стоять в неправильном порядке, будут перепутаны.
3. Если назначен специальный человек для контроля за чистотой исходной информации, то найдется изобретательный идиот, который придумает способ, чтобы неправильная информация прошла через этот контроль.
4. Непечатный жаргон – это тот язык, которым решительно все программисты владеют в совершенстве.
Законы ненадежности Джилба
1. Компьютеры ненадежны, но люди еще ненадежнее.
2. Любая система, зависящая от человеческой надежности, ненадежна.
3. Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,– оно конечно по определению.
4. В поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.
Закон Брука. Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс.
Законы машинного программирования
1. Любая действующая программа устарела.
2. Любая программа обходится дороже и требует больших затрат времени, чем предполагалось.
3. Если программа полностью отлажена, ее нужно будет скорректировать.
4. Любая программа стремится занять всю доступную память.
5. Ценность программы прямо пропорциональна весу ее «выдачи».
6. Сложность программы растет до тех пор, пока не превысит способности программиста.
Постулаты Трумэна по программированию
1. Самая грубая ошибка будет выявлена, лишь когда программа пробудет в производстве по крайней мере полгода.
2. Контрольные перфокарты, которые решительно не могут стоять в неправильном порядке, будут перепутаны.
3. Если назначен специальный человек для контроля за чистотой исходной информации, то найдется изобретательный идиот, который придумает способ, чтобы неправильная информация прошла через этот контроль.
4. Непечатный жаргон – это тот язык, которым решительно все программисты владеют в совершенстве.
Законы ненадежности Джилба
1. Компьютеры ненадежны, но люди еще ненадежнее.
2. Любая система, зависящая от человеческой надежности, ненадежна.
3. Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,– оно конечно по определению.
4. В поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.
Закон Брука. Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс.
Заменил пик
И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче.
Это справедливо для любой области знаний. Помнится был у меня один начальник, который требовал чтобы даже описание сложных вещей было написано понятным языком даже для уборщицы.
И он мог объяснить причины таких требований уборщице? (Это старая шутка.) К сожалению некоторые вещи не удаётся обьяснить и своему начальнику, проще уже уборщице. :)
Смог фразой старшины Гуськова из «А зори здесь тихие» о гениальности Уставов. Ведь действительно написаны таким языком, что обязанности и права часового может понять и неграмотный. :)
Впрочем не раз замечал в реале то, что кратко, просто и понятно о сложных вещах может рассказать только действительно специалист «от Бога».
Впрочем не раз замечал в реале то, что кратко, просто и понятно о сложных вещах может рассказать только действительно специалист «от Бога».
Имхо, тут как с паттернами, можно пытаться каждый раз объяснять просто (не факт что конкретный человек это сумеет, и не введет в заблуждение), а можно использовать общепринятую терминологию вроде тех же названий принципов в статье описанных, или ранее упомянутых мной паттернов. Общий словарь все же коммуникацию упрощает (меньше ошибок, неоднозначностей, слов, абстракция содержит больше полезных идей и меньше мусора, ну, в идеале).
Помнится мне один начальник в Росстандарте дал совет никогда не участвовать в разработке терминологических стандартов (то есть самых-самых общих словарей) потому что практически невозможно привести определения, удовлетворяющие все заинтересованные стороны и потому это очень вредно для нервов. В качестве примера эта статья. 99% того, что большинство заявленных аббревиатур уже определено в различных стандартах, как международных, так и национальных. Но изобретение велосипеда будет продолжаться вечно. :))
Эти принципы сформировались на опыте программистов наступающих на известные грабли. По моему опыту принцип KISS тут главный и с высоким приоритетом. Все остальные можно и нужно нарушать если они противоречат этому принципу, правда лучше не торопиться и подумать ещё раз, возможно можно сделать ещё проще. Впрочем нет правил без исключений включая это. К сожалению даже умные учатся на своих ошибках, а на чужих не учится никто, впрочем возможно и в этом правиле есть исключения, но я не встречал (:…
добавил kiss
По сути, всё перечисленное — это и есть один и тот же KISS, только применённый к разным программным объектам:
* инкапсуляция, SRP, low coupling, high cohesion — к функциям, классам и модулям (не выноси мусор из избы, во многих знаниях многия печали, общайся только через публичный интерфейс)
* ISP и LSP — собственно к самим публичным интерфейсам (не усложняй контракт и не меняй его)
* CoC и IoC — к программным конфигурациям (уменьшай число параметров и зависимостей)
* YAGNI — к процессу разработки (не делай лишнего)
* OCP — ко всему вышеперечисленному
* инкапсуляция, SRP, low coupling, high cohesion — к функциям, классам и модулям (не выноси мусор из избы, во многих знаниях многия печали, общайся только через публичный интерфейс)
* ISP и LSP — собственно к самим публичным интерфейсам (не усложняй контракт и не меняй его)
* CoC и IoC — к программным конфигурациям (уменьшай число параметров и зависимостей)
* YAGNI — к процессу разработки (не делай лишнего)
* OCP — ко всему вышеперечисленному
Вместо конфига, описывающего всё, лучше использовать дефолты, которые при желании можно переопределять в конфиге.
Я боюсь это как минимум не точно.
Дело не в дефолтах, а в подходе с созданием конвенций и спецификаций которые впринципе делают конфигурацию ненужной. В этом сила брат.
Коаны — лучший ключ к развитию понимания. Давать абстрактное понятие без конкретных объектов, разрешающих абстракцию до привычных мыслительных цепочек то же самое, что запускать регулярный поиск на данных, которые не содержат структур, удовлетворяющих искомому паттерну. Попробуйте дать точное определение тривиальности в любом контексте, к вам придет понимание, что упрощение в контексте ваших знаний может привести к обратному результату. На Хабре уже столько подобных статей, что мем про «еще один протокол» (another one standard xkcd) никогда не перестанет быть актуальным.
> Давать абстрактное понятие без конкретных объектов, разрешающих абстракцию до привычных мыслительных цепочек то же самое, что запускать регулярный поиск на данных, которые не содержат структур, удовлетворяющих искомому паттерну.
Не совсем понял вашу мысль в контектсте данной статьи. Вы считаете, что надо начинать с примера, а потом подводить пример к абстрактному принципу?
Не совсем понял вашу мысль в контектсте данной статьи. Вы считаете, что надо начинать с примера, а потом подводить пример к абстрактному принципу?
Для того, чтобы прямо ответить на ваш вопрос, мне пришлось бы написать очень длинный текс. Поэтому я постараюсь написать короче, но через аллегорию.
Представьте, что вам необходимо объяснить человеку как получить стакан горячей воды. Вы могли бы просто рассказать ему как это сделать, реализация сказанного вами может занять много времени или вообще не сработать, если условия его быта сильно отличаются от ваших. Поэтому вы идете с человеком в его кухню и объясняете все императивно, здесь и сейчас. Вы отдаете ему команды, он их выполняет и в конце концов получает стакан горячей воды. Теперь он знает как в этой кухне, используя теже самые предметы, получить стакан воды.
Вы дали человеку алгоритм для удовлетворения определенной потребности в определенных условиях.
Теперь представьте, что вам необходимо постоянно производить подобную процедуру для большого круга людей. Вы могли бы писать книги, чтобы обучать людей принципам физики, электромеханики и др., чтобы люди могли в различных условиях находить различные способы получения стакана воды. Но подобный подход не гарантирует время выполнения процедуры и качество её результата. Поэтому вы принимаете решение производить чайники, проводить людям водопровод и раздавать брошюрки с наглядным описанием того, как при наличии водопровода, чайника и стакана можно получить стакан с горячей водой. Теперь, при условии выполнения необходимых условий, как наличие чайника, брошюрки и доступа к водопроводу, любой человек может получить стакан горячей воды.
Первое представление содержит объяснение, почему предложенные вами, в статье и вопросе, подходы не дадут ожидаемых результатов. Оба представления, при правильном построении аналогии позволят лучше понять изначальную суть принципа KISS. А форма ответа отражает форму предложенного вами метода объяснения принципов в утрированной форме.
Представьте, что вам необходимо объяснить человеку как получить стакан горячей воды. Вы могли бы просто рассказать ему как это сделать, реализация сказанного вами может занять много времени или вообще не сработать, если условия его быта сильно отличаются от ваших. Поэтому вы идете с человеком в его кухню и объясняете все императивно, здесь и сейчас. Вы отдаете ему команды, он их выполняет и в конце концов получает стакан горячей воды. Теперь он знает как в этой кухне, используя теже самые предметы, получить стакан воды.
Вы дали человеку алгоритм для удовлетворения определенной потребности в определенных условиях.
Теперь представьте, что вам необходимо постоянно производить подобную процедуру для большого круга людей. Вы могли бы писать книги, чтобы обучать людей принципам физики, электромеханики и др., чтобы люди могли в различных условиях находить различные способы получения стакана воды. Но подобный подход не гарантирует время выполнения процедуры и качество её результата. Поэтому вы принимаете решение производить чайники, проводить людям водопровод и раздавать брошюрки с наглядным описанием того, как при наличии водопровода, чайника и стакана можно получить стакан с горячей водой. Теперь, при условии выполнения необходимых условий, как наличие чайника, брошюрки и доступа к водопроводу, любой человек может получить стакан горячей воды.
Первое представление содержит объяснение, почему предложенные вами, в статье и вопросе, подходы не дадут ожидаемых результатов. Оба представления, при правильном построении аналогии позволят лучше понять изначальную суть принципа KISS. А форма ответа отражает форму предложенного вами метода объяснения принципов в утрированной форме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применяем принцип KISS к самим принципам проектирования