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

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

Легкий.

1. не соединяют усилие по разработке платформы MVC с шаблонами.

2. Распознают, что каждая вещь, которую Вы делаете, была сделана прежде (Вами или кем-то еще).

3. при повторении чего-то - чего-либо - Вы следуете за шаблоном.

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

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

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

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

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

Большинство - часть языка и имеет очевидные собственные имена языка. "ЕСЛИ", "ОТКРЫТЫЙ", и т.д.

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

не запускаются с MVC. Запустите с ЧЕГО-ЛИБО ЕЩЕ.

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

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

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

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

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

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

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

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

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

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

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

Разъединяющийся слой данных и уровень UI от Вашей бизнес-логики до меня - что-то, что необходимо сделать так же, как хороший дизайн. Снова, слабая связь, DRY и удобный в сопровождении код должна быть целью, не шаблонами.

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

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

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

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

По моему скромному мнению, нужно иметь:

1. А хорошее понимание профессионалов & недостатки различных шаблонов разработки, которые Вы могли использовать
2. Ясность в том, что Ваше приложение разработано, чтобы сделать и удостовериться профессионалы шаблона, используются в ваших интересах.

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

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