Шаблоны дизайна - Архитектура Астронавт

Возможно, мой вопрос похож по своему характеру на этот: Используете ли вы шаблоны дизайна?

Программы, которые я пишу, - это небольшие программные линии 50-75 К, в основном используя Windows Forms и ASP.NET. Эти программы являются мощными графическими интерфейсами, позволяющими создавать и компоновать различные графические и графические обработки.

Я считаю себя хорошим в ООП и практикуется при балансировании ООП и традиционных процедурных методах для создания поддерживаемого кода.

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

Возьмем шаблон MVC в качестве примера. Если я хочу реализовать этот шаблон с помощью Windows Forms или ASP.NET(Visual Studio 2005), тогда мне нужно написать "Framework", и для создания фреймворков, похоже, будет больше проблем, чем того стоит размер приложения.

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

Кто-нибудь еще испытывает чувство "зодиакального астронавта"?

Как вы намеренно используете шаблоны проектирования, не переходя "за борт?"

ОТВЕТЫ

Ответ 1

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

Ответ 2

'Как вы намеренно используете шаблоны проектирования, не переходя "за борт?"

Легко.

  • Не сочетайте усилия по разработке структуры MVC с шаблонами.

  • Признайте, что все, что вы делаете, было сделано раньше (кем или кем-то другим).

  • Когда вы повторяете что-то - что угодно - вы следуете шаблону.

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

  • Когда вы замечаете, что повторяете что-то, назначьте имя той вещи, которую вы повторяете. Послушай, ты открыл и назвал свой первый шаблон дизайна. Независимо от того, насколько малы.

  • Когда вы назвали шаблон дизайна, вы можете подумать о том, когда вы его используете, почему вы используете его, что он решает и каковы последствия его использования. Независимо от того, насколько малы.

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

Каждый цикл. Каждый оператор if. Каждое диалоговое окно. Каждый файл открыт. Это все шаблоны проектирования.

Большинство из них являются частью языка и имеют явные языковые имена. "IF", ​​ "OPEN" и т.д.

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

Не начинайте с MVC. Начните с НИЧЕГО еще.

Ответ 3

"Архитектурные астронавты" - это те, кто тратит много времени на обсуждение дизайна, но на самом деле этого не делает.

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

Ответ 4

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

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

Я настоятельно рекомендую вам прочитать Fowler покрытие архитектур UI.

Ответ 5

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

Ответ 6

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

Ответ 7

Очень немногие проекты требуют или выигрывают от гипер-архитектуры. Большинство проектов, которые начинаются таким образом, никогда не завершаются. Многие из тех, которые, как правило, очень трудно продлить или поддерживать (несмотря на их требования об обратном). И помните, как быстро развиваются языки и технологии. Самая новая, самая крутая вещь сегодня может быть устаревшей к тому времени, когда вы закончите очень большой проект. Шаблоны интересны и могут дать вам некоторое представление о том, как решить проблему элегантно, но большую часть времени, в реальном мире, нет элегантного решения. Всюду, где я когда-либо работал, был суперзвезда-астронавт, впечатляющий всех, извергая бесконечный жаргон при написании кода нежелательной почты, который мне придется исправить позже. Конечным результатом является то, что является самым важным. Ваша компания нуждается в рабочем приложении, а не в бесконечной работе, даже если они сами этого не осознают.

Ответ 8

Шаблоны здесь как абстрактные решения общих проблем. Если кто-то знает шаблоны, то они имеют большую вероятность применения известного решения, быстрее и не сидят вокруг мышления: "Господи, интересно, как это сделать".

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

Ответ 9

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

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

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

Ответ 10

Для меня это зависит от:

  • Размер приложения,
  • Используемый шаблон дизайна
  • Время, которое я должен инвестировать авансом в архитектуру.

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

Ответ 11

Вы работаете в среде, где шаблоны настроены для вас крупной компанией, и я думаю, что это объясняет ваши чувства. И ты, наверное, прав. Те из нас, кто использует языки FOSS в открытых средах для более широких проблем, имеют бесконечный выбор, а чтение по шаблонам проектирования помогает нам принимать обоснованные решения об архитектуре. Обычно это означает выбор правильных библиотек. Ваш выбор для узкого домена, в котором вы работаете, был сделан для вас.

Ответ 12

IMHO нужно:

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

Возьмем шаблон MVC в качестве примера. Если Я хочу реализовать этот шаблон, используя WinForms или ASP.NET(VS 2005), затем я должны написать "Рамки" и письменные рамки, похоже, больше проблема, чем это стоит для размера приложения.

Требуется ли вашему веб-приложению эффективный SEO? Шаблон MVC, реализованный для ASP.NET, может помочь в этом отношении. Возьмите SO URL, например. Они настолько хорошо оптимизированы для поисковых систем, прежде всего потому, что реализация шаблона MVC для ASP.NET поддерживала его и эффективно использовалась в SO design/development.