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

Они действительно используются большинством программистов?

Говоря об опыте, у меня были некоторые проблемы при программировании, вещи, которые я не мог решить некоторое время, но Google и несколько часов исследований решили мою проблему. Если где-то в сети я найду способ решить мою проблему, это шаблон проектирования? Я использую это?

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

ОБНОВЛЕНИЕ: Я думаю, что когда я спрашиваю, используют ли их программисты, я спрашиваю: «О, мне следует использовать этот шаблон».

Когда я был начинающим программистом, я любил шаблоны проектирования. Я не просто использовал шаблоны дизайна. Я их нанёс. Где бы и когда бы я ни мог. Я был беспощаден. Ага! Наблюдатель шаблон! Возьми это! Используйте слушателя! Proxy! AbstractFactory! Зачем использовать один слой абстракции, когда подойдет пять? Я говорил со многими опытными программистами и обнаружил, что почти каждый, кто читает Книгу GoF, проходит этот этап.

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

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

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

Если один признает их или нет, большинство программистов делают использование шаблонов.

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

Некоторые из общих шаблонов встроены в некоторые языки - например, шаблон итератора встроен в C # с foreachключевым словом.

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

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

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

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

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

Вообщем нет. Бывают случаи, когда из моего кода появляются шаблоны, но в целом я их не ищу и, конечно, не говорю: «О, шаблон моста решит мою проблему!».

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

да, большинство программистов, с которыми я когда-либо сталкивался, используют самый распространенный шаблон, Big Ball of Mud . Обычно они начинаются с хорошо спроектированных архитектур, но обычно заканчиваются здесь, особенно если они начинают думать, что «мы должны использовать шаблоны проектирования» повсеместно, и беспощадно проводить рефакторинг.

ты их используешь?

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

Если где-то в сети я найду способ решить мою проблему, это шаблон проектирования?

Не обязательно. Шаблон проектирования относится к определенному способу проектирования классов, их поведения и взаимодействий для достижения конкретной цели (или избежания конкретной проблемы). То, с чем вы, возможно, столкнулись, может быть не проблемой проектирования, а определенной последовательностью шагов для программирования определенного API. Например: существует определенная последовательность установки сокетов. Сделайте это неправильно, и ваша розетка не будет общаться. Эта последовательность шагов не является образцом.

Вы (программисты) ищите модели

Да. Конструктивные схемы воплощают аксиому «профилактика лучше лечения». Если вы можете заранее определить конкретную предстоящую проблему дизайна, вы можете предотвратить массовые изменения дизайна, чтобы они могли быть внесены позже. Так что стоит заранее знать шаблоны проектирования и искать места, где вам нужно их использовать при создании приложения.

где я должен посмотреть, кстати?

Поскольку вы студент, вы, вероятно, не видели типичных проблем, которые вдохновляют шаблоны проектирования. Я настоятельно рекомендую вам взглянуть на Head First Design Patterns . Сначала они представляют проблему проектирования, а затем показывают, как конкретный шаблон может решить / избежать ее.

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

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

Не ищите модность

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

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

Не пытайтесь использовать их, попробуйте думать в их терминах

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

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

Ищите их в дикой природе

Существует множество проектов с открытым исходным кодом, в которых вы найдете шаблоны применяемого дизайна. Один пример, который приходит на ум, - это Joomla: вы найдете синглтонов , наблюдателей . GUI библиотеки будут иметь шаблон декоратора , команда реализована, и , возможно , даже мухи .

Существуют и другие шаблоны, такие как шаблоны данных, например, использованный только в Doctrine Project, шаблон активной записи (1.x), шаблон менеджера сущностей (2.x), единица работы , хранилище , объект запроса , отображение метаданных , данные отображение и другие более общие , как шаблон стратегии , и декоратор .

Есть так много интересных решений на выбор. См . Шаблоны корпоративной архитектуры Мартина Фаулера , есть также шаблоны моделей данных .

Просто изучите их, когда придет время

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

Стать архитектором

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

Я программировал около 7 лет на C ++ и изучал шаблоны около 2 лет назад. Большинство шаблонов, вероятно, имеют некоторые приложения, но в моем использовании некоторые лучше, чем другие. Вы должны подумать, почему вы их используете.

Шаблон итератора фактически сделал мой код более запутанным и добавил ненужную сложность. Я могу получить такую ​​же удобство обслуживания, используя typedefs для векторных типов STL. И любые изменения, которые я делаю в классе, который повторяется, я также должен сделать в классе итератора.

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

Я годами использовал шаблонный шаблон, даже не зная, что это «шаблон дизайна».

Шаблон Observer был полезен в некоторых случаях, иногда нет. Иногда необходимо предсказать сложность, чтобы определить, стоит ли сложность накладных расходов шаблона Observer. У нас есть программа, которая использует около 10 подписчиков, и их может быть гораздо больше, поэтому модель наблюдатель / подписчик оказалась полезной. Другая программа, однако, имеет два графических интерфейса. Я реализовал шаблон наблюдателя для этой программы, и он был по большей части ненужным, просто потому что он добавил сложность, и я не ожидаю добавления большего количества дисплеев.

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

Добавление к Lunivore. Я хотел бы процитировать это из головы первой книги

        ## **Three steps to great software** ##     

• Убедитесь, что программное обеспечение делает то, что хочет клиент
• Применять хорошие объектно-ориентированные принципы
• Стремитесь к ремонту, многоразовому дизайну

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

Они действительно используются большинством программистов?

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

Говоря об опыте, у меня были некоторые проблемы при программировании, вещи, которые я не мог решить некоторое время, но Google и несколько часов исследований решили мою проблему. Если где-то в сети я найду способ решить мою проблему, это шаблон проектирования? Я использую это?

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

Я бы предпочел думать о том, что ты там делал, как об обычной практике. Остерегайтесь копирования и вставки кода, хотя.

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

Иногда, когда я вижу один и тот же код снова и снова, я могу найти способ реорганизовать код в шаблон или, если я вспоминаю решение аналогичной проблемы, включающей шаблон, я его извлекаю и использую. Шаблоны Head First Design Patterns содержат более нескольких шаблонов, в то время как рефакторинг будет предложением для практики кодирования, которая может привести к поиску различных шаблонов. Если вы хотите другую возможную отправную точку, посмотрите на Шаблоны и Практики Microsoft .

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

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

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