AntFarm anti-pattern - стратегии, которых следует избегать, противоядия, чтобы помочь исцелить от

Question

Я работаю над 10-страничным веб-сайтом с базой данных. Существует более 500 объектов, которые пытаются реализовать шаблон MVP в ASP.Net. Я отслеживаю выполнение кода с одной страницы, мой палец был на F-11 в Visual Studio около 40 минут, кажется, нет конца, возможно, более 1000 вызовов методов для одной веб-страницы! Если бы это было всего лишь 50 объектов, это было бы одно, однако выполнение кода пронизывало все эти объекты, точно так же, как миллионы муравьев лихорадочно потревожили их гигантский дом грязной насыпи, пронизанный туннелями объектов. Следовательно, рождается новый анти-паттерн: AntFarm .

AntFarm также известен как "OO-Madnes", "OO-Fever", OO-ADD или просто наркоман с дизайнерским рисунком.

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

Я хотел бы ввести анти-шаблон в анти-шаблон: GST или "Get Stuff Done" AKA "Get Sh ** done" AKA GRD (GetRDone). Этот паттерн сфокусирован на том, что он говорит, делая вещи простым способом. Я могу попытаться обрисовать это подробнее в следующем посте, или, пожалуйста, поделитесь своими идеями по поводу этой схемы противоядия.

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

Answer 1

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

Answer 2

Если это действительно из-за чрезмерного дизайна (и звучит так), вот несколько синонимов для вас:

Газовый завод
Rube Goldberg machine
Хит хитон хитрость

Но мое личное имя для этого "слишком старательно F # $% 3n". Мои соболезнования.

Приветствие Адриан

Answer 3

Множество файлов, где можно было бы сделать. Насти. 500 объектов на 10 веб-страницах кажется сумасшедшим соотношением. Рассматривали ли вы выполнение анализа кода в решении? Могу дать вам некоторые интересные характеристики, чтобы сражаться с ними.

Также я бы назвал анти-анти-паттерн KISS.

Answer 4

Спасибо, Glomek, статья за интересную проблемную область, рассказывающую о сути ОО, то есть о том, как проектировать ваши объекты ... за успех или неудачу, спасибо за ссылку.

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

Answer 5

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

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

Answer 6

Проблема в том, что ваш шаблон проектирования сам по себе не OO. Начните с не OO-шаблона, попробуйте реализовать его как «объекты», в результате вы получите беспорядок.

То, что система записана в OOPL, не делает систему OO.