Что происходит здесь? Как я могу назвать конструктора по умолчанию, когда нет ни одного?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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