(Update: заменил картинку на более нейтральную)
Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.
Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".
И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче. Вообще, очень часто бывает такое, что объясняешь кому-то за минуту то, что сам изучал довольно долго. А какие-то детали прирастают уже потом, главное получить "ключ".
В итоге я попытался сделать такую табличку. Можно сказать, своего рода русско-китайский разговорник:
| Значение | Перевод |
|---|---|
| KISS «Keep it short and simple», «Keep it simple, stupid!» и т.д. |
Не усложняй код без веской причины |
| Инкапсуляция | Нам не надо знать, что там у объекта внутри, просто используем публичные методы. Так мы упрощаем для понимания сложные системы и уменьшаем связанность объектов друг с другом |
| Convention over configuration | Вместо конфига, описывающего всё, лучше использовать дефолты, которые при желании можно переопределять в конфиге. |
| Принцип подстановки Барбары Лисков Оригинальная формулировка: "… Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T...") |
Поведение класса-наследника не должно противоречить поведению, заданному классом-родителем. Чтобы можно было без проблем подставить объект класса Dog туда, где ожидается объект класса Animal |
| Принцип единственной ответственности | Класс должен делать что-то одно |
| Принцип разделения интерфейса "...Клиенты не должны зависеть от методов, которые они не используют..." |
В аргументах конструктора или метода не надо ожидать объект со множеством лишних деталей, если классу для работы нужен лишь маленький специфический объектик или вообще тупо один integer. И точно не надо пихать во все классы контейнер зависимостей. |
| High Cohesion | Класс должен делать что-то одно :). Если вы видите, что некоторые методы используются обособленно, отдельно от других, с какими-то своими данными, значит у вас не high cohesion. Возможно стоит разделить класс на части или перенести часть методов куда-то еще |
| Low coupling | Классы должны быть как можно меньше завязаны на другие классы, особенно на их содержимое. Не управляйте лапами собаки, управляйте собакой |
| Принцип инверсии зависимостей "… Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций..." |
Классы должны быть как можно меньше завязаны на другие классы :) Для гибкости кода в аргументах конструктора/метода нужно делать интерфейсы или абстрактные классы, а не конкретные классы. |
| Принцип открытости/закрытости "… Программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения..." |
Новая функциональность должна добавляться путём добавления нового класса, а не добавлением новой ветки if в существующий класс, который делает всё на свете. |
| YAGNI «You aren't gonna need it», ?«Вам это не понадобится» |
Не надо делать того, что не просили. Подход «возможно в будущем понадобится» сильно усложняет код и поддержку |
Если есть желание дополнить, исправить или поспорить — как обычно, пишите в комментариях
Комментарии (22)
Sinatr
23.01.2018 11:29В заголовке есть KISS, а в списке его нет. Плюс вы там советуете интерфейсы использовать в качестве параметров конструктора, дык это вроде как нужно делать, только если это нужно делать, не раньше. Там еще полно подобных принципов: YAGNI, DRY…
Скорее всего озаглавить нужно было SOLID, раз уж Барбара в списке, но тогда труселя придется менять…
Непонятно про дефолты. Ссылка на вики ничего не прояснила, какие-то json, принцип наименьшего удивления… может в таблице нужен третий столбец с маленьким «плохим» примером и «как надо»?
Вы несколько раз пишете «класс должен делать что-то одно» или «меньше завязаны», а потом идет объяснение, но не для всех случаев, в результате некоторые принципы становятся не раскрытыми.
А так вообще идея неплохая, намного проще держать в голове содержимое второго столбца, чем «сферическо-вакуумные» наименования, но не все у вас получилось. Когда именно я перестаю управлять собакой и начинаю управлять лапами?
ArVaganov
23.01.2018 11:42+1В заголовке есть KISS, а в списке его нет.
Да, было бы неплохо добавить. Вроде «Не усложняй». DRY, YAGNI сюда же.
труселя придется менять
Для чего этот пик в технической статье кто-нибудь может объяснить?
System12
23.01.2018 12:08Про KISS хорошо объяснено в Луркоморе: lurkmore.to/KISS
varanio Автор
23.01.2018 12:13добавил KISS
System12
23.01.2018 12:45Мне кажется что классические законы будут в тему:
Законы машинного программирования
1. Любая действующая программа устарела.
2. Любая программа обходится дороже и требует больших затрат времени, чем предполагалось.
3. Если программа полностью отлажена, ее нужно будет скорректировать.
4. Любая программа стремится занять всю доступную память.
5. Ценность программы прямо пропорциональна весу ее «выдачи».
6. Сложность программы растет до тех пор, пока не превысит способности программиста.
Постулаты Трумэна по программированию
1. Самая грубая ошибка будет выявлена, лишь когда программа пробудет в производстве по крайней мере полгода.
2. Контрольные перфокарты, которые решительно не могут стоять в неправильном порядке, будут перепутаны.
3. Если назначен специальный человек для контроля за чистотой исходной информации, то найдется изобретательный идиот, который придумает способ, чтобы неправильная информация прошла через этот контроль.
4. Непечатный жаргон – это тот язык, которым решительно все программисты владеют в совершенстве.
Законы ненадежности Джилба
1. Компьютеры ненадежны, но люди еще ненадежнее.
2. Любая система, зависящая от человеческой надежности, ненадежна.
3. Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,– оно конечно по определению.
4. В поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.
Закон Брука. Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс.
System12
23.01.2018 11:31+1И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче.
Это справедливо для любой области знаний. Помнится был у меня один начальник, который требовал чтобы даже описание сложных вещей было написано понятным языком даже для уборщицы.Sdima1357
23.01.2018 11:50+1И он мог объяснить причины таких требований уборщице? (Это старая шутка.) К сожалению некоторые вещи не удаётся обьяснить и своему начальнику, проще уже уборщице. :)
System12
23.01.2018 12:04Смог фразой старшины Гуськова из «А зори здесь тихие» о гениальности Уставов. Ведь действительно написаны таким языком, что обязанности и права часового может понять и неграмотный. :)
Впрочем не раз замечал в реале то, что кратко, просто и понятно о сложных вещах может рассказать только действительно специалист «от Бога».
Neikist
23.01.2018 13:25Имхо, тут как с паттернами, можно пытаться каждый раз объяснять просто (не факт что конкретный человек это сумеет, и не введет в заблуждение), а можно использовать общепринятую терминологию вроде тех же названий принципов в статье описанных, или ранее упомянутых мной паттернов. Общий словарь все же коммуникацию упрощает (меньше ошибок, неоднозначностей, слов, абстракция содержит больше полезных идей и меньше мусора, ну, в идеале).
System12
23.01.2018 13:51Помнится мне один начальник в Росстандарте дал совет никогда не участвовать в разработке терминологических стандартов (то есть самых-самых общих словарей) потому что практически невозможно привести определения, удовлетворяющие все заинтересованные стороны и потому это очень вредно для нервов. В качестве примера эта статья. 99% того, что большинство заявленных аббревиатур уже определено в различных стандартах, как международных, так и национальных. Но изобретение велосипеда будет продолжаться вечно. :))
Sdima1357
23.01.2018 11:35Эти принципы сформировались на опыте программистов наступающих на известные грабли. По моему опыту принцип KISS тут главный и с высоким приоритетом. Все остальные можно и нужно нарушать если они противоречат этому принципу, правда лучше не торопиться и подумать ещё раз, возможно можно сделать ещё проще. Впрочем нет правил без исключений включая это. К сожалению даже умные учатся на своих ошибках, а на чужих не учится никто, впрочем возможно и в этом правиле есть исключения, но я не встречал (:…
Bronx
23.01.2018 13:57+1По сути, всё перечисленное — это и есть один и тот же KISS, только применённый к разным программным объектам:
* инкапсуляция, SRP, low coupling, high cohesion — к функциям, классам и модулям (не выноси мусор из избы, во многих знаниях многия печали, общайся только через публичный интерфейс)
* ISP и LSP — собственно к самим публичным интерфейсам (не усложняй контракт и не меняй его)
* CoC и IoC — к программным конфигурациям (уменьшай число параметров и зависимостей)
* YAGNI — к процессу разработки (не делай лишнего)
* OCP — ко всему вышеперечисленномуSdima1357
23.01.2018 14:14Все верно, согласен, однако чтобы понять это нужен опыт, а тем кто уже понял — правилам и так следует, даже если их и не знает (в формальном виде). В этом то и проблема. А если без опыта, прочитал — то все равно не осознал… Поэтому KISS — наше всё.
shuron
23.01.2018 23:16Вместо конфига, описывающего всё, лучше использовать дефолты, которые при желании можно переопределять в конфиге.
Я боюсь это как минимум не точно.
Дело не в дефолтах, а в подходе с созданием конвенций и спецификаций которые впринципе делают конфигурацию ненужной. В этом сила брат.
WarKnife
24.01.2018 08:49Коаны — лучший ключ к развитию понимания. Давать абстрактное понятие без конкретных объектов, разрешающих абстракцию до привычных мыслительных цепочек то же самое, что запускать регулярный поиск на данных, которые не содержат структур, удовлетворяющих искомому паттерну. Попробуйте дать точное определение тривиальности в любом контексте, к вам придет понимание, что упрощение в контексте ваших знаний может привести к обратному результату. На Хабре уже столько подобных статей, что мем про «еще один протокол» (another one standard xkcd) никогда не перестанет быть актуальным.
varanio Автор
24.01.2018 08:54> Давать абстрактное понятие без конкретных объектов, разрешающих абстракцию до привычных мыслительных цепочек то же самое, что запускать регулярный поиск на данных, которые не содержат структур, удовлетворяющих искомому паттерну.
Не совсем понял вашу мысль в контектсте данной статьи. Вы считаете, что надо начинать с примера, а потом подводить пример к абстрактному принципу?WarKnife
24.01.2018 12:13Для того, чтобы прямо ответить на ваш вопрос, мне пришлось бы написать очень длинный текс. Поэтому я постараюсь написать короче, но через аллегорию.
Представьте, что вам необходимо объяснить человеку как получить стакан горячей воды. Вы могли бы просто рассказать ему как это сделать, реализация сказанного вами может занять много времени или вообще не сработать, если условия его быта сильно отличаются от ваших. Поэтому вы идете с человеком в его кухню и объясняете все императивно, здесь и сейчас. Вы отдаете ему команды, он их выполняет и в конце концов получает стакан горячей воды. Теперь он знает как в этой кухне, используя теже самые предметы, получить стакан воды.
Вы дали человеку алгоритм для удовлетворения определенной потребности в определенных условиях.
Теперь представьте, что вам необходимо постоянно производить подобную процедуру для большого круга людей. Вы могли бы писать книги, чтобы обучать людей принципам физики, электромеханики и др., чтобы люди могли в различных условиях находить различные способы получения стакана воды. Но подобный подход не гарантирует время выполнения процедуры и качество её результата. Поэтому вы принимаете решение производить чайники, проводить людям водопровод и раздавать брошюрки с наглядным описанием того, как при наличии водопровода, чайника и стакана можно получить стакан с горячей водой. Теперь, при условии выполнения необходимых условий, как наличие чайника, брошюрки и доступа к водопроводу, любой человек может получить стакан горячей воды.
Первое представление содержит объяснение, почему предложенные вами, в статье и вопросе, подходы не дадут ожидаемых результатов. Оба представления, при правильном построении аналогии позволят лучше понять изначальную суть принципа KISS. А форма ответа отражает форму предложенного вами метода объяснения принципов в утрированной форме.
sshmakov
И только этот класс должен делать это.