Твердые принципы против ЯГНИ

43

Когда твердые принципы становятся ЯГНИ?

Как программисты, мы постоянно идем на компромиссы между сложностью, ремонтопригодностью, временем сборки и так далее. Среди прочего, два из самых умных руководящих принципов для выбора - это, на мой взгляд, принципы SOLID и YAGNI. Если вам это не нужно; не строить его, и держать его в чистоте.

Теперь, например, когда я смотрю серию dimecast на SOLID , я вижу, что она начинается как довольно простая программа и заканчивается как довольно сложная (конец да сложность также в глазах смотрящего), но она все еще делает меня интересует: когда твердые принципы превращаются в то, что вам не нужно? Все твердые принципы - это способы работы, позволяющие использовать изменения на более позднем этапе. Но что, если проблема, которую нужно решить, довольно проста, и это одноразовое приложение, то что? Или принципы SOLID всегда применимы?

Как спросили в комментариях:

KeesDijk
источник
Не должно ли название быть SOLID principle vs YAGNI?
Волк
2
@Wolf: это множественное число «SOLID (единая ответственность, открытая-закрытая, подстановка Лискова, сегрегация интерфейса и инверсия зависимостей) - это мнемоническая аббревиатура, введенная Майклом Фезерсом для« первых пяти принципов », названных Робертом К. Мартином в начале 2000-е годы - это пять основных принципов объектно-ориентированного программирования и дизайна ».
Журнал

Ответы:

55

Всегда трудно судить о подходе, основанном на скринкасте, поскольку проблемы, выбранные для демонстраций, как правило, настолько малы, что применение таких принципов, как SOLID, быстро создает впечатление, что решение полностью перегружено.

Я бы сказал, что твердые принципы почти всегда полезны. Как только вы станете опытным с ними, их использование не будет похоже на то, о чем вы должны сознательно думать. Это просто становится естественным. Я видел, как много одноразовых одноразовых приложений становятся чем-то большим, так что теперь я боюсь сказать, что я собираюсь что-то выбросить, потому что вы просто никогда не узнаете.

Подход, который я обычно использую, заключается в том, что если я пишу простое приложение для конкретной задачи, я иногда отказываюсь от принципов громкого имени в пользу нескольких строк кода, которые работают. Если я обнаружу, что возвращаюсь к этому приложению для внесения дальнейших изменений, я найду время, чтобы сделать его ТВЕРДЫМ (по крайней мере, в некоторой степени, поскольку 100% -ное применение принципов редко выполнимо).

В больших приложениях я начинаю с малого, и по мере развития программы я применяю принципы SOLID, где это возможно. Таким образом, я не пытаюсь спроектировать всё заранее, до последнего перечисления. Для меня это сладкое место, где сосуществуют YAGNI и SOLID.

Адам Лир
источник
Это в значительной степени то, что я думаю также. В качестве замечания я не сужу по скринкасту, я просто думаю, что это хороший пример того, как программное обеспечение может расти при применении SOLID.
KeesDijk
Хорошая точка зрения. Любая демонстрация будет искажена, чтобы продемонстрировать или усугубить проблему под рукой. По сути, вся идея довести идею до ее полного завершения, чтобы доказать, что это заблуждение. Предпосылка, которая сама по себе может быть злоупотреблена.
Берин Лорич
YAGNI and SOLID coexistхороший вывод. Хотя это может быть хорошей отправной точкой
Вольф
Кажется, что иногда может понадобиться догадка. Вы должны знать, где вы можете начать видеть множество изменений, чтобы знать, где ваши уровни абстракции и остановки останавливаются и начинаются.
джонни
19

Подумайте о проблеме в первую очередь. Если вы слепо применяете принципы YAGNI или SOLID, вы можете навредить себе позже. Надеюсь, мы все сможем понять, что не существует единого подхода к проектированию, который бы подходил всем проблемам. Вы можете увидеть доказательства этого, когда магазин продает шляпу, рекламируемую как «один размер подходит всем», но она не подходит вашей голове. Он либо слишком большой, либо слишком маленький.

Вместо этого лучше понять принципы и проблемы, которые SOLID пытается решить; а также принципы и проблемы, которые YAGNI пытается решить. Вы обнаружите, что один связан с архитектурой вашего приложения, а другой - с процессом разработки в целом. Хотя в некоторых случаях возможны совпадения, они представляют собой совершенно разные проблемы.

YAGNI («Вам это не нужно» [причудливая американская аббревиатура]) посвящен экономии времени застройщика, добавлению железобетонных фундаментов со стальным восстановленным мостом к мосту, который предназначен только для охвата ручья шириной 3 фута, когда более простой деревянный мост подойдет просто хорошо. Если мы пересекаем реку шириной в милю и нуждаемся в поддержке нескольких тракторных прицепов, конечно, нам понадобятся дополнительные фундаментные работы. По сути, YAGNI предлагает вам взглянуть на более широкую картину и дизайн для текущих потребностей. Он решает проблему создания чего-то слишком сложного, потому что мы предвидим ряд потенциальных потребностей, которые клиент еще не определил.

SOLID заботится о том, чтобы убедиться, что части моста правильно совмещаются и могут поддерживаться в течение долгого времени. Вы можете применять ТВЕРДЫЕ принципы к деревянному мосту, а также к стальному железобетонному мосту.

Короче говоря, эти два понятия не обязательно противоречат друг другу. Когда вы сталкиваетесь с ситуацией, когда вы верите в это, самое время взглянуть на общую картину. В зависимости от вашего заключения, вы можете решить отказаться от части принципов SOLID или решить, что вам это действительно нужно.

Берин Лорич
источник
Да, согласен .. не существует подхода «серебряной пули», подходящего для любого сценария.
Е.Л. Юсубов
Ваш make sure the pieces of the bridge fit togetherдалеко не так очевиден, как can be maintained over time.
Волк
По сути, SOLID - это то, что позволит вам превратить этот деревянный мост в стальной стальной мост длиной 1 милю, способный поддерживать бронированный взвод, не переписывая полностью или просто вставляя взломать за взломом.
Сара
@ Кай, это ложная предпосылка. Если вам нужен мост, который охватывает 1 милю, то вы проектируете мост, который охватывает 1 милю. Если вам нужен мост длиной 5 футов, вы должны построить мост длиной 5 футов. Не поймите меня неправильно, принципы SOLID очень полезны, но требуется больше понимания их, чтобы понять, какие принципы не нужны для рассматриваемой проблемы. 9 раз из 10 эта лишняя миля никогда не нужна.
Берин Лорич
@BerinLoritsch, поэтому я согласен, что если вам нужно 5 футов, вы строите 5 футов, но вы НЕ БУДЕТЕ строить 5 футов, приставив пару 2х4 к земле. Вы делаете то, что вам нужно, и вы делаете это хорошо. (хотя аналогия рода разваливалась)
сара
9

Принципы SOLID не нужны, когда это одноразовое приложение; в противном случае они всегда нужны.

SOLID и YAGNI не имеют разногласий: хороший дизайн класса облегчает обслуживание приложения. YAGNI просто заявляет, что вы не должны добавлять в ваше приложение возможность настраивать это чудовище, которое может делать все под солнцем - если только оно ему действительно не нужно.

Это разница между классом автомобилей с четко определенными границами (SOLID) и классом автомобилей, который обладает способностью к самовосстановлению (YAGNI) до того, как клиент об этом попросит.

Джордж Стокер
источник
1
Разве это не перепутано? Как насчет этого: Правильно применяйте принципы SOLID, чтобы справиться со сложностью самовосстанавливающихся автомобилей, или применяйте YAGNI, пока ваши машины все еще настолько просты, что никогда не сломаются (или - альтернативно - настолько дешевы, что их можно просто выбросить) ,
Волк
2
@ Волчьи твердые принципы не говорят, ЧТО вы должны делать, только КАК. если вы уже решили, что вам нужны самовосстанавливающиеся автомобили, вы можете применить принципы SOLID к этому коду. SOLID не говорит, является ли самовосстанавливающаяся машина хорошей идеей. Вот где приходит YAGNI.
Сара
Часто одноразовые приложения не являются.
Тулин Кордова
«Самовосстановление» это хорошо. «До того, как покупатель попросит об этом», также хорошо, потому что я думаю, что вся идея, если вы слушаете дядю Боба, касается мест, которые приносят прибыль и предвосхищают потребности клиента и имеют жизнеспособный бизнес, который может реагировать на потребности потому что они меняются. Многих людей раздражает дядя Боб, потому что он не имеет права на программирование, но в большинстве случаев он говорит вам, почему важно использовать SOLID, а не просто как.
джонни
«Твердые принципы не нужны, когда это одноразовое приложение» . Я думаю, что принципы SOLID - хорошая привычка, поэтому, даже если это одноразовое приложение, вы готовитесь к тому, когда вам нужно написать большое приложение, поэтому может быть полезно следовать принципам SOLID.
icc97
4

Ничто не всегда относится! Не позволяйте астронавтам архитектуры пугать вас! Важно постараться понять, какие проблемы пытаются решить эти принципы, чтобы вы могли принять обоснованное решение о их применении.

Недавно я пытался понять, когда мне следует использовать принцип единой ответственности ( вот что я придумал).

Надеюсь это поможет!

Brandon
источник
2

Есть цитата, приписываемая Эйнштейну (возможно, вариация реальной ):

«Все должно быть сделано как можно проще, но не проще».

И это более или менее подход, который я использую, когда сталкиваюсь с компромиссом SOLID и YAGNI: применяйте их альтернативно, потому что вы никогда не знаете, является ли программа «одноразовым» кодом или нет. Итак, просто добавьте слой грязи, который работает, затем отполируйте его до более чистого интерфейса ... и повторяйте, пока не дойдете до нужного уровня энтропии. С надеждой.

logc
источник
Хорошая мысль: you never know if a program is 'throw-away' code- ну, я думаю, что альтернативная идея не так хороша.
Волк
@Wolf: да, я расширил порядок шагов, которые я считаю наилучшим (кратко изложенный в лозунге «Сначала сделай это возможным, затем сделай его красивым, а затем сделай его быстрым»), но потом я подумал ... ЯГНИ :)
Журнал
1

Есть много способов разработать программу для данной проблемы; SOLID - это попытка определить свойства хорошего дизайна. Правильное использование SOLID должно привести к созданию программы, которую легче рассуждать и изменять.

YAGNI и KISS занимаются широким спектром возможностей. Программа, которая решает больше видов проблем, является более сложной и абстрактной. Если вам не нужна эта универсальность, вы потратили время и силы на создание кода, который сложнее понять и поддерживать, но не приносит никакой дополнительной выгоды.

Хорошо продуманная программа не обязательно ориентирована только на те функции, которые ей необходимы. Программа, ориентированная только на те функции, которые ей необходимы, не обязательно хорошо разработана. Здесь нет компромисса, только две ортогональные оси в пространстве принятия решений. Идеальная программа является модульной и имеет только основные функции.

Doval
источник
0

Я думаю, что вы должны начать YAGNI, и когда есть необходимость, решите это.

Я имею в виду, что SOLID существует, поэтому, когда вы добавляете новый класс, вам не нужно будет проводить рефакторинг, просто переключите реализацию (например), ну, на мой взгляд, просто напишите свой код, и когда вы увидите, что вы меняете вещи - измените это с помощью SOLID (то есть опасный рефакторинг, от которого SOLID должен вас спасти - это не так уж плохо, когда вы только начинаете).

Вы не тратите время впустую, потому что вам все равно придется выполнять работу (в начале), и там, где это необходимо, ваш код хорош и аккуратен.

Я думаю, вы могли бы назвать это ленивой оценкой SOLID.

Биньямин
источник
Хм, я вижу ваше мнение о том, что сообщение является избыточным, я бы удалил его, но, похоже, у меня нет прав для этого (или я не вижу кнопку). В любом случае я отредактирую это, чтобы быть более ясным.
Биньямин