Они противоречат?
Развязка - это что-то большое и довольно трудное достижение. Однако в большинстве приложений нам это действительно не нужно, поэтому я могу разрабатывать приложения с высокой степенью связи и почти ничего не изменит, кроме очевидных побочных эффектов, таких как "вы не можете разделить компоненты", "модульное тестирование - это боль в задница" и т.д.
Как вы думаете? Вы всегда пытаетесь отделить и справиться с накладными расходами?
Мне кажется, что это развязка, и YAGNI - это очень много дополняющих достоинств. (Я просто заметил, что Роб отвечает, и похоже, что мы на одной странице здесь.) Вопрос в том, сколько развязки вы должны делать, а YAGNI - хороший принцип, чтобы помочь определить ответ. (Для тех, кто говорит об модульном тестировании, - если вам нужно отделить себя от unit test, то YAGNI, очевидно, не применяется.)
Я искренне сомневаюсь в людях, которые говорят, что они "всегда" отделяются. Может быть, они всегда делают каждый раз, когда думают об этом. Но я никогда не видел программы, где дополнительные слои абстракции не могли быть добавлены где-то, и я искренне сомневаюсь, что там нетривиальный пример такой программы. Все рисуют где-то.
По моему опыту, я отключил код, а затем никогда не использовал дополнительную гибкость так же часто, как я оставил код в сочетании, а затем пришлось вернуться и изменить его позже. Я не уверен, что это означает, что я хорошо сбалансирован или одинаково разбит в обоих направлениях.
YAGNI - это эмпирическое правило (а не религия). Развязка - это более или менее методика (также не религия). Поэтому они не связаны друг с другом и не противоречат друг другу.
YAGNI о прагматизме. Предположите, что вам что-то не нужно, пока не сделаете.
Обычно предполагается, что YAGNI приводит к развязыванию. Если вы вообще не применяете этот нож, вы в конечном итоге считаете, что вам нужно иметь классы, которые знают все о поведении друг друга, прежде чем продемонстрировать, что это правда.
"Разделение" (или "свободная пара" ) - это глагол, поэтому он требует работы. YAGNI - это презумпция, для которой вы настраиваете, когда обнаруживаете, что это уже не так.
I (почти) всегда отделяется. Каждый раз, когда я это делал, я считал это полезным, и (почти) каждый раз, когда я этого не делал, мне приходилось это делать позже. Я также нашел, что это хороший способ уменьшить количество ошибок.
Развязка ради развязки может быть плохим. Построение тестируемых компонентов очень важно.
Трудная часть истории - знать, когда и сколько развязки вам нужно.
Я бы сказал, что они этого не делают. Развязка заключается в сокращении ненужных зависимостей внутри кода и ужесточении доступа через чистые, четко определенные интерфейсы. "Это вам не понадобится" - это полезный принцип, который обычно рекомендует против чрезмерной расширяемости и чрезмерно широкой архитектуры решения, где нет очевидного и текущего варианта использования.
Практический результат состоит в том, что у вас есть система, в которой гораздо проще реорганизовать и поддерживать отдельные компоненты без непреднамеренного возникновения эффекта пульсации по всему приложению и где нет ненужных сложных аспектов для дизайна - это просто как это требуется для удовлетворения текущих требований.
Если "модульное тестирование - это боль в заднице", то я бы сказал, что вам это нужно. Большая часть времени развязки может быть достигнута и с нулевой стоимостью, так почему бы вам не хотеть это делать?
Кроме того, один из моих самых больших ошибок при работе над новой базой кода - это отделить код, прежде чем я начну писать модульные тесты, когда введение интерфейса или использование инъекции зависимостей может спасти много времени
Ну, YAGNI - это нечто большее, чем фальшивая упрощенная фраза, которую люди бросают. Развязка, однако, является довольно понятной концепцией. По-видимому, YAGNI подразумевает, что человек какой-то психический. Это просто программирование клише, которое никогда не является хорошей идеей. Честно говоря, есть случай, когда YAGNI, вероятно, вообще не связан с развязкой. Сцепление, как правило, "быстрее" и "кто знает, хотите ли вы, вам понадобится развязанное решение, вы все равно не собираетесь изменять X-компонент!"
Как говорит ваш тег, он очень субъективен. Это полностью зависит от вашей собственной инженерной мудрости, чтобы решить, что вам "не понадобится". Возможно, вам понадобится соединение в одном случае, но вы не будете в другом. Кто это должен сказать? Вы, конечно.
Для такого субъективного решения тогда не может быть указателя, предписывающего.
YAGNI беспорядок:)... действительно, нам не нужно, чтобы весь код смешался, чтобы идти "быстрее".
Единичные тесты действительно помогают чувствовать, когда они связаны (если вы хорошо понимаете, что такое unit test по сравнению с другими типами тестов). Если вы вместо этого сделаете это с мышлением "вы не можете разделить компоненты", вы можете легко добавить материал, который вам не понадобится:)
Я бы сказал, что YAGNI приходит, когда вы начинаете скручивать и изменять логику, выходящую за рамки реальных сценариев использования, к которым призывает текущая реализация. Допустим, у вас есть код, который использует пару внешних поставщиков платежей, которые работают с перенаправлением на внешний сайт. Это нормально, что дизайн, который держит все в чистоте, но я не думаю, что это нормально, чтобы начать думать о провайдерах, которые мы не знаем, будет ли когда-либо поддерживаться, которые имеют много разных способов обработки интеграции и связанных с ними рабочий процесс.