Развязка против ЯГНИ - PullRequest
       13

Развязка против ЯГНИ

7 голосов
/ 02 марта 2009

Они противоречат?

Разделение - это что-то великое и довольно труднодостижимое. Однако в большинстве приложений нам это не нужно, поэтому я могу проектировать сильно связанные приложения, и это почти не изменит ничего, кроме очевидных побочных эффектов, таких как «нельзя разделять компоненты», задница "и т. д.

Что ты думаешь? Вы всегда пытаетесь отделить и справиться с накладными расходами?

Ответы [ 9 ]

7 голосов
/ 02 марта 2009

Мне кажется, что разъединение и Ягни - очень взаимодополняющие добродетели. (Я только что заметил ответ Роба, и кажется, что мы находимся на одной странице здесь.) Вопрос в том, какую степень развязки вы должны сделать, и YAGNI - хороший принцип, помогающий определить ответ. (Для тех, кто говорит о модульном тестировании - если вам нужно разъединить, чтобы выполнить ваш модульный тест, то YAGNI явно не применяется.)

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

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

4 голосов
/ 05 мая 2009

Ягни - это эмпирическое правило (не религия). Разделение - это более или менее техника (также не религия). Так что они на самом деле не связаны и не противоречат друг другу.

Ягни о прагматизме. Предположим, вам что-то не нужно, пока вы не сделаете.

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

«Развязка» (или «слабая пара») - это глагол, поэтому он требует работы. YAGNI - это презумпция, которую вы настраиваете, когда обнаруживаете, что она больше не соответствует действительности.

2 голосов
/ 02 марта 2009

Я бы сказал, что нет. Разделение - это уменьшение ненужных зависимостей в коде и усиление доступа через чистые, четко определенные интерфейсы. «Вам это не понадобится» - это полезный принцип, который обычно не допускает чрезмерной расширяемости и чрезмерно широкой архитектуры решения, где нет очевидного и актуального варианта использования.

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

2 голосов
/ 02 марта 2009

Развязка ради развязки может быть плохой. Хотя создание тестируемых компонентов очень важно.

Сложная часть истории - знать, когда и в какой степени вам нужна развязка.

2 голосов
/ 02 марта 2009

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

1 голос
/ 02 марта 2009

Если «юнит-тестирование - это боль в заднице», то я бы сказал, что вам нужно это нужно. В большинстве случаев развязка может быть достигнута практически с нулевыми затратами, так почему бы вам не захотеть сделать это?

Кроме того, одна из моих самых больших ошибок при работе с новой кодовой базой - это необходимость разъединять код, прежде чем я смогу начать писать модульные тесты, когда введение интерфейса где-либо или использование внедрения зависимости может сэкономить много времени

0 голосов
/ 02 марта 2009

YAGNI беспорядок :) ... действительно, нам не нужно смешивать весь код, чтобы идти "быстрее".

Модульные тесты действительно помогают чувствовать, когда они связаны (если хорошо понять, что такое модульный тест по сравнению с другими типами тестов). Если вместо этого вы сделаете это с мышлением «вы не можете разделить компоненты», вы легко сможете добавить вещи, которые вам не понадобятся:)

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

0 голосов
/ 02 марта 2009

Как говорит ваш тег, это очень субъективно. Решать, что вам «не нужно», полностью зависит от вашей собственной инженерной мудрости. В одном случае вам может понадобиться соединение, но в другом - нет. Кому рассказать? Вы , конечно.

Для такого субъективного решения не может быть указания для назначения.

0 голосов
/ 02 марта 2009

Что ж, YAGNI - это не более чем фальшивая упрощенная фраза, которую люди бросают вокруг. Разделение, однако, является довольно хорошо понятной концепцией. Кажется, Ягни подразумевает, что вы какой-то экстрасенс. Это просто программирование клише, что никогда не было хорошей идеей. Честно говоря, есть основания утверждать, что YAGNI, вероятно, вообще не связан с разделением. Как правило, соединение происходит «быстрее» и «кто знает, что если вам нужно, вам понадобится разъединенное решение; вы все равно не будете менять компонент X!»

...