Должны ли сегодня шаблоны рассматриваться как недостатки или отсутствующие функции в Java и С++?
Посетители, Абстрактные фабрики, Декораторы и Фасады - это шаблоны проектирования для Java и С++ сегодня.
Как будут выглядеть языки завтрашнего дня? Какие шаблоны у них будут?
Некоторые канонизированные шаблоны проектирования - Adapter, Factory, Command, Visitor и т.д. - это аппроксимации функций, которые запекаются на других языках. Сверху моей головы:
Обработчики событий в С# являются запеченными версиями шаблона наблюдателя. Подумайте о том, как вы подключаете события на С#, если вам приходилось каждый раз перематывать свой собственный наблюдатель.
Шаблон посетителя представляет собой подробное приближение многоточия, пересылка сообщения или действительно слабая форма соответствия шаблонов.
Командный шаблон завершает конкретное поведение, поэтому вы можете передать объект между методами, которые более или менее приближаются к первоклассным функциям.
Шаблон стратегии позволяет динамически вставлять поведение в объект, чтобы в любое время вы могли изменять объект, заменяя одно поведение другим. В мире функционального программирования мы называем эту композицию функций.
Абстрактный шаблон factory принимает аргумент и возвращает factory. В общем, вы можете думать о фабриках как обертки вокруг функции (точнее, обертки вокруг конструктора). Итак, вы передаете аргументы функции и получаете функцию в результате, делая этот шаблон довольно похожим на currying.
Рисунок декоратора позволяет прикрепить или удалить поведение объекта во время выполнения. В JavaScript вы можете добавлять или удалять функции без явного внедрения шаблона декоратора благодаря модели "prototype" OO.
Итак, у нас есть куча шаблонов проектирования, которые эмулируют функции, присущие другим языкам. Особенность зависти не обязательно указывает на слабость языка - это код шаблона, который вам нужно писать много раз, что указывает на слабость языка.
Я бы не назвал их дефектами.
Языки более высокого порядка связаны с понятиями на более высоком уровне, чем языки более низкого порядка. Подумайте об этом в строительном плане.
Вы могли бы построить здание на уровне нефтеперерабатывающего завода, фрезерный пиломатериал, плавильную сталь и таким образом собрать здание.
Вы можете приобрести доски и стальные балки и построить их в здании.
Вы можете приобрести готовые стены и фермы и построить их в здании.
Вы можете приобрести здание и начать с интерьера.
Строит ли здание с досками и балками пропущенную сборную функцию стены или каким-то образом является дефектной?
Каждая вещь, которую вы делаете три или более раз в разработке программного обеспечения, формирует шаблон.
Каждое повторение. Каждое повторение. Каждое повторение.
Некоторые получают канонизированные с классными именами. Они становятся образцами дизайна. Сознательное повторение.
Некоторые из них просто "лучшие практики" или "это сработало для меня". Это образцы дизайна без ясности.
Некоторые - это просто "вещи, которые вы обычно делаете". Это шаблоны проектирования без какого-либо осознанного осознания того, что вы повторяете себя.
Шаблоны проектирования имеют ничего для устранения слабости или неполноты языка. Они имеют все, чтобы делать с хорошими идеями, сознательно повторно используемыми.
Сегодня шаблоны дизайна - это не королевская дорога к завтрашним языкам. Языковая парадигма не продвигается через ряд "исправлений ошибок на предыдущие языки". Если бы это было так, мы бы никогда не создали Visual Basic.
И шаблоны проектирования - гораздо более широкий и более широкий интеллектуальный инструмент, чем простой набор функций языка программирования.
Нет, они не пропускают признаков или дефектов языков. Но языки должны предоставлять средства для написания кода для полезной модели проще, чем сложнее. То, что функции, предоставляемые языком, могут быть либо благом, либо препятствием.
Я думаю, что Эван поднимает увлекательный момент. Возьмите его пример подпрограммы. В ранних языках программирования идея передачи параметров в подпрограмму и возвращение результата была чем-то, что вам нужно было явно кодировать. В современных языках он встроен. Или взять другой пример: если /then/else встроен в большинство, если не все современные языки. Но в свои дни ассемблера мне пришлось написать код, чтобы это сделать. Не много, конечно, но все же, вы должны были написать инструкцию jump или goto, чтобы обойти блок else. И тот факт, что вам приходилось писать эти вещи сами, означало, что разные программисты сделали бы это по-разному, и было бесконечное соблазн быть умным и сделать это несколько иначе в этой программе, чтобы сделать его более эффективным или получить некоторые другие предполагаемое преимущество.
Самый последний пример, который приходит на ум, - итераторы. Вам нужно вручную написать их на С++ и в ранних версиях Java, но они встроены в Java 5. Это, возможно, синтаксический сахар, вам просто нужно просто создавать функции итератора. Лично я считаю это приятной особенностью. Радикально ли это улучшает мою производительность? Нет.
Есть ли что-то, что мы делаем все время, которое должно логически быть встроено в язык, чтобы стандартизировать и упростить его? Увлекательный вопрос. Я не думаю, что кто-то всерьез утвердит, что даже их любимый язык совершенен и абсолютно невозможно улучшить. Но каково будет направление следующего языка?
Конечно, некоторые функции, которые были добавлены в языки, являются бесполезным дополнительным багажом. По моему скромному мнению, Java enum делает гораздо больше, чем это необходимо, они добавляют кучу багажа без уважительной причины. Я уверен, что другие не согласятся и скажут, что они считают их невероятно полезными.
У меня нет вывода. Я просто согласен, что это увлекательный вопрос.
Я где-то читал что-то вроде "чем больше у вас шаблонов, тем менее мощный ваш язык", и я считаю это определение очень приятным.
Причина ясна ИМО: если вы видите повторяющийся шаблон (или вы должны его использовать), это означает, что это своего рода копия вставить на логическом уровне. Конечно, это не так плохо, как copy'n paste заявлений, но это все еще избыточность. Я все еще повторяюсь снова и снова.
Чем больше язык является выразительным, тем больше вы сможете улавливать и блокировать эту избыточность, преобразовывая его в повторное использование вместо повторной реализации, а повторное использование будет легче читать и понимать в исходном коде.
Каждый раз, когда вы снова делаете то же самое (включая, например, "ok... пусть реализует абстрактный factory здесь" ), это означает, что что-то должно было быть выражено на более высоком уровне.
Конечно, иногда вы можете попытаться понять суть чего-то, но повторное использование может быть более уродливым для чтения, чем повторная реализация (я думаю, например, для некоторых частей "высокого уровня" С++ в <algorithm>)., Это ИМО - явный признак того, что язык недостаточно выразителен.
Я думаю, что некоторые шаблоны дизайна представляют языковые недостатки, а новые языки включают существующие шаблоны в граждан первого класса. Примером нового языка, использующего существующие шаблоны проектирования на других языках (инъекция зависимостей, неизменность и т.д.) И включение их в качестве функций уровня первого класса, является NOOP от Google.
Мне интересно, сколько вы можете втиснуть в язык, прежде чем он станет слишком "большим".
Мне нравится язык, с которым я работаю, чтобы быть достаточно маленьким, чтобы держать его в голове все сразу. Такие шаблоны, как DI, связаны со структурными проблемами; должен ли он быть частью языка?
Насколько нужно владеть языком на языке, который действительно нужен разработчику?
В случае Code Contracts (требует, гарантирует), приятно, когда это первоклассная часть языка, но это не требуется. Он все еще может быть частью библиотеки.
Рамки, которые облегчают использование определенных шаблонов на языках, действительно существуют, поэтому они скорее являются скорее выбором, чем обязательным. Существуют шаблоны, которые для определенного проекта могут вам просто не нужны, поэтому включение многих из них в качестве основных функций языка будет только налагать ограничения, а не облегчать продуктивную работу.
каждый язык представляет собой произвольный набор шаблонов проектирования с синтаксисом как обозначение для выбранных шаблонов. для неубранных шаблонов вам необходимо вмешаться в ограничения синтаксиса, чтобы выразить их. большинство языков не позволяют его синтаксису сильно измениться, чтобы ассимилировать шаблоны более высокого уровня.
язык, который может сделать это безгранично, будет одним без жесткого синтаксиса. (или по-другому, который позволяет легко усвоить любой шаблон высокого уровня). см. металингвистическая абстракция
тот, который приходит мне на ум, - это схема/ lisp.
Шаблоны проектирования не являются слабыми на языках. Они предоставляют дизайнерские решения для повторяющихся проблем.
Поскольку со временем многие вещи эволюционировали, я думаю, что "Шаблоны интеграции предприятия" будут популярны.
Если разные корпоративные приложения должны общаться, эти шаблоны предоставляют наилучшие решения.
Integration Styles документировать различные способы применения приложений, предоставляя историческую информацию об интеграционных технологиях. Все последующие шаблоны соответствуют стилю Messaging.Channel Patterns описывают, как сообщения переносятся по каналу сообщений. Эти шаблоны реализованы большинством коммерческих и открытых систем обмена сообщениями.Message Construction Patterns описывают намерение, форму и содержание сообщений, которые перемещаются по системе обмена сообщениями. Базовым шаблоном для этого раздела является шаблон сообщения.Routing Patterns обсуждают, как сообщения направляются от отправителя к правильному получателю. Шаблоны маршрутизации сообщений потребляют сообщение с одного канала и повторно публикуют его, как правило, без изменений, другому каналу на основе набора условий. Шаблоны, представленные в этом разделе, являются специализациями шаблона Message Router.Transformation Patterns изменить содержимое сообщения, например, для размещения различных форматов данных, используемых системой отправки и получения. Данные, возможно, придется добавлять, отбирать или существующие данные могут быть перегруппированы. Базовым шаблоном для этого раздела является Message Translator.Endpoint Patterns описывают, как клиенты системы обмена сообщениями производят или потребляют сообщения.System Management Patterns описывают инструменты, позволяющие поддерживать сложную систему на основе сообщений, включая работу с условиями ошибок, узкие места производительности и изменения в участвующих системах.