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

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

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

Шаблоны являются проблемой, если они не решение. Этим я имею в виду: если шаблон будет представлен для пользы шаблона а не решить реальную, существующую проблему проектирования в приложении, то это, вероятно, вызовет проблемы, а не решит или предотвратит их.
я продолжаю говорить людям здесь на работе, которую заказывает Банда Четыре (Шаблоны разработки: Элементы Допускающего повторное использование Объектно-ориентированного программного обеспечения), ссылка, не руководство для хорошего дизайна.

Я вспоминаю интервью одному из GoF, где кто-то спросил об общем заявлении, что шаблоны разработки являются инструментами для замены функций, которые отсутствуют в языке. Автор утверждал что A) любой язык имеет шаблоны разработки (не те же), так как шаблоны разработки являются инструментами, созданными для работы вокруг языка idiosynchrasies и B) не выполнимо избавиться от их потребности путем добавления большего количества опций на язык.

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

Вот другая статья о предмете: http://blog.plover.com/prog/design-patterns.html

Существует много принципов, которые мы используем (и которые распространены вокруг ТАК), что, если Вы прослеживаете их до источника, первоначально утверждались с резервированием; как в "..., когда Вы разрабатываете использование..." Это - один из тех случаев. Шаблоны соответствуют хорошо при выполнении ООП. YMMV, когда Вы находитесь в другой парадигме.

"Рефакторинг" является другим подобным случаем.

, Когда я пишу SQL, часть "шаблонов" моего мозга выключает.

Примечание в Вашей цитате: "Я генерирую вручную расширения некоторого макроса, который я должен записать".. Таким образом, он распознает шаблоны и абстрагирует их в макрос - он не повторно кодирует его иначе. Просто хороший-ol' DRY. Это не шаблоны, этому не удается сделать правильную вещь с теми, мы находим. Я сказал бы, что его комментарий мог войти в любую запись Wiki, подробно останавливающуюся на достоинствах DRY, и как владеть ими. GoF согласился бы полностью - распознают шаблоны дизайна, затем используют то, что Вы знаете о них, чтобы реализовать (или осуществить рефакторинг) их соответственно.

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

Часто времена, когда шаблоны разработки применяются неправильно, это - потому что процесс происходит наоборот. Программист Joe (мои извинения тем из Вас назвали Joe) читает книгу по Шаблонам разработки и говорит "Хорошо, я понимаю Шаблон разработки X, теперь как я могу применить его к своему приложению?" Это неправильно.

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

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

шаблоны Diesign не представляют слишком мало abstraction— они - попытка увеличить уровень абстракции. Можно сказать, что "этот бит является Посетителем", а не "вот некоторый код, который рекурсивно пересекает дерево объектов, работающих на операции на них".

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

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

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

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

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

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

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

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

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

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

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

Обобщение что-то вроде этого будет логически испорченным, но если Вы перефразируете свой вопрос чему-то вроде, "могут там быть слишком много шаблонов в коде, который является симптоматическим для большей проблемы, то есть, недостаточных уровней абстракции" тогда, ответ был бы да. Это всегда имеет место? Нет.

форма программы должна отразить только проблему, которую она должна решить.

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

шаблоны разработки являются знаком недостаточной абстракции

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

, Что, если там 'чрезвычайно тяжелым' является объект, который не должен быть загружен? Шаблон "proxy" сохраняет пользователя от ожидания навсегда.

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

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

проблема состоит в том, что это не верно. Вы не можете записать код опытного качества только с "шаблонами разработки" больше, чем можно разработать собственную профессиональную одежду качества модельера с помощью [только 110] шьющие шаблоны .

[вздох], Сколько напыщенной речи против хороших методов мы должны разоблачить перед людьми, начинает использовать их собственное решение?

Короткий ответ: при выполнении реальной работы на объектно-ориентированном языке существует очень высокая вероятность, что Вы реализовали некоторые шаблоны разработки GoF, чтобы сделать задание. Понимаете ли Вы, что сделали это, или не вопрос образования, перспективы и самоанализа. Отклонение этого, Вы когда-либо делали это или это копирует, не существуют или не "необходимы" или "злоупотребляются", смешно - если Вы никогда не пишете ничего более сложного, чем 'привет мир';-)

Да ведь просто на днях я должен был реализовать фасад посетителя для одиночного элемента только для получения стратегии адаптера работать:-P

Я полагаю, что эта часть от кавычки Paul Graham важна:

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

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

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

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

Я полагаю, что требование Paul Graham состоит в том, что шаблоны разработки должны быть выражены на языке. Если существует X шаблонов, это означает, что люди вынуждены переписать последовательности кода, чтобы сделать это, и должен быть особенный метод языка выражения его. Это могло быть встроено в язык (хотя это является неловким, и может создать новые шаблоны разработки), или это могло быть automatable в языке (таком как макросы языка Common LISP; шаблоны C++, особенно, когда используется странными способами, могут сделать почти такой же иногда).

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

Точно так же при использовании Шаблона "фабрика", или язык мог включать функцию Factory, или могло быть возможно автоматизировать его в языке. А именно, Paul хочет быть в состоянии записать макрос Lisp, чтобы реализовать его, вместо того, чтобы записать Фабрики сам много раз.

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

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

Приезжайте в людей, считайте целую кавычку, считайте ее тщательно. Или еще лучше, прочитайте эссе.

Paul Graham критикует, среди прочего, подобный языкам C для того, чтобы не обеспечивать соответствующие средства абстракции. В рамках эссе его критика шаблонов является запоздалой мыслью, или скорее рассматриваемым вопросом для его основного аргумента. Его обоснование идет как это:

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

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

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

Термин Шаблоны разработки перегружается и сбивает с толку.

существует узкий способ думать о нем: в основном как коллективное название понятий OO, перечисленных в книге GoF, например, Singleton, Фасад, Стратегия. Вы, вероятно, используете это определение при помещении Шаблонов разработки как компетентности на CV.

Один проект может легко содержать десятки одноэлементных объектов. Этот шаблон, довольно очевидно, извлекает выгоду из того, чтобы быть кодированным как instantiable абстракция, например, как макро-или абстрактный класс. Аналогично для многих из других шаблонов в книге GoF.

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

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

В этом общем смысле, становится намного менее очевидно, что шаблоны разработки должны все быть кодированы как instantiable абстракции.

, Если Вы не считали Язык Шаблона, проверьте объем его здесь . Вообразите что-то как этот для мира программного обеспечения. Шаблоны GoF были бы путем вниз у основания ToC: они - детали реализации.

, Что другие шаблоны Вы могли найти выше их?

я предполагаю, что одна глава имела бы связанные с игрой шаблоны. Это могло включить и шаблоны игрового дизайна и методы реализации, —, и я утверждаю, что это не ясное различие —, как Игровой Цикл, Мировой Объект, Пространственный Хеш, Среда Карты Высоты, и так далее. Это все шаблоны разработки.

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

, Но то, что описывает шаблон, - то, как эта абстракция формируется: это содержит некоторое понятие положения, это renderable и так далее. Не очевидно, извлек ли этот Шаблон разработки выгоду из того, чтобы быть кодированным, поскольку макро-или абстрактный класс сам по себе — шаблон уже описывает абстракцию! Вы сделали бы метакласс для мировых реализаций объекта? Макрос для определения мировых классов объекта, со всеми видами безбожных параметров?

Взгляд далее мнимое Оглавление, мы видим, что эти шаблоны зависимы от более общего шаблона, этого Игры. Действительно ли это стоит кодировать как макро-или абстрактный класс? Возможно. Но не, очевидно. Мы говорим об игровой платформе, где Вы определяете компьютерную игру передающими параметрами, восполнением пробелы, и т.д. Это могло быть продуктивно и забавно, но это не единственный способ сделать вещи.

платформа Erlang имеет instantiable абстракции для шаблонов, столь же общих как Сервер, который является классным. И я предполагаю, что проект Erlang имеет столько Серверов, сколько проект Java имеет Одиночные элементы.

, Но в Ваших определенных целях, если Вы работаете в Lisp или Haskell, или что бы то ни было, и пишете сервер, иногда достаточно просто следовать за шаблоном Сервера, реализовывая его как старые добрые функции и объекты, не пытаясь сделать instantiable абстракцию из всего этого.

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

Шаблоны являются действительно просто способом описать, как работают вещи. Это - способ классифицировать их. Есть ли некоторые программы, которые злоупотребляют их? Уверенный. Самое большое преимущество наличия шаблонов состоит в том, что путем классификации чего-то как это или что, все находятся на той же странице (принимающий у них есть уровень знаний для знания то, о чем говорят.). Когда у Вас есть система с 10,000 из строк кода, становится необходимо быть в состоянии быстро определить, как что-то собирается работать.

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

Когда я запрограммировал в LISP, я не использовал шаблоны разработки GoF вообще, это просто не было применимо для программ, которые я писал. Теперь я программирую в C# и натыкаюсь на ситуации все время, где шаблон разработки на самом деле упрощает записанную программу.

Шаблоны разработки определяются как следующее (из Википедии, но я считал то же в некоторой книге также)

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

, Если Вы смотрите на применение шаблонов прямо от смещения, не входя в проблемную область экстенсивно, может привести к проблемам. Используйте шаблоны разработки в качестве руководства или больше в качестве подсказки/подсказки для решения проблемы. Сильно примененный шаблон разработки, конечно, не даст решение, это достаточно абстрактно. Часто замечается, что в Программном обеспечении предприятия вариант или комбинация нескольких шаблонов разработки используются.. вид гибридов. Если бы Вы говорите, что никогда не использовали шаблоны разработки тогда, Вы были бы рады знать, что что-то как цикл foreach - на самом деле interator шаблон, и можно искать для более очевидных реализаций около Вас!

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

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

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

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

Если вы позволите мне использовать метафору: Написание музыки - обычная «проблема», и музыка часто (очевидно, не всегда) сочиняется свободно как разновидность вариации на следующие темы:

стих хор стих хор стих хор chorus

Что, действительно, является «шаблоном». Тем не менее, вам все равно нужно написать песню, и не каждая написанная песня будет хорошо работать с использованием этого шаблона.

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

Это предложение не имеет смысла: шаблоны проектирования - признак недостаточной абстракции Поскольку образцы дизайна являются абстракцией! Следуя приведенным здесь ответам, я согласен с тем, что языки программирования должны иметь возможность выражать шаблоны проектирования. Однако очевидно, что это возможно не для каждой ситуации.