Языковые интегрированные шаблоны проектирования

Question

Я заметил, что начинать с шаблонов дизайна довольно сложно для новичков. Для понимания структуры шаблонов проектирования требуется много времени. Применение шаблонов дизайна к вашей практике требует слишком много времени. Согласитесь, вы не можете увидеть различия между различными типами шаблонов проектирования в первый раз, если вы им не знакомы. Эта проблема частично решена, если ваши классы имеют подходящие имена. Кроме того, вы можете разбить структуру структуры с рисунком, которую вы внедряете, если вам не хватает некоторых правил, записывающих ваш код случайно, или вы не так опытны в шаблонах проектирования. Компиляторы могут защитить вас и помочь вам реализовать интерфейсы - если вы не реализуете интерфейс, вы не можете скомпилировать свое приложение. Это хороший и безопасный подход. И если компиляторы могут защитить вас при реализации классов шаблонов проектирования? Послушайте, много языков программирования поддерживает оператор foreach. И если языки программирования могут обеспечить поддержку для фабрик, мостов, прокси, сувениров и т. Д.? Если это может быть правдой, вы могли бы использовать что-то вроде следующего, чтобы применить абстрактную и конкретную картину фабрики (я предпочитаю C# в качестве базового языка для псевдокода, то предполагается, что используются контекстные ключевые слова):

public abstract factory class AF { 
    public product AP1 GetProduct1(); 
    public product AP2 GetProduct2(); 
}; 

public concrete factory class CF1 : AF { 
    public product CP1 GetProduct1() { ... } 
    public product CP2 GetProduct2() { ... } 
}; 

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

Answer 1

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

Это уже происходит, это ничего нового.

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

Это довольно много строк кода для концептуально очень простых.

В Scala вам не нужен шаблон, чтобы создать синглтон. В дополнении к class ключевому слову, Scala имеет object ключевое слово, которое декларирует одноэлементный объект:

object MainApp { 
    def main(args: Array[String]) { 
    println("Hello, world!") 
    } 
} 

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

Answer 2

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

Например, см. Peter Norvigs famous presentation о дизайне Шаблоны, невидимые в динамических языках.

На самом деле, легко придумать примеры этого процесса, которые уже происходят - как вы говорите, петли foreach - это, возможно, встроенные итераторы, Ruby имеет синглтон-миксин, чтобы наследовать, любой язык с помощью мультиметодов не нуждается в посетителе шаблон. У Groovy есть встроенные Builders.

Ваш конкретный пример фабрики немного напоминает интеграцию зависимостей Injection в спецификацию языка.

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

Ваш пример интересен, вы предлагаете добавить несколько ключевых слов и правил на язык, который (и я не знаком с C#) не добавляет явного преимущества. Что бы ключевое слово «factory» сообщило контролеру типа (или другому программисту), который не ясен из объявления «AF» как эквивалент интерфейса Java, и имея «продукт» в качестве возвращаемого типа для своих методов?

Answer 3

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

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

Дизайн спецификация:

single public Factory 
    methods: 
     T Get[T] 

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

Реализация:

public class ConcreteFactory : Factory { 
    public Product1 GetProduct1() { ... } 
    public Product2 GetProduct2() { ... } 
}; 

Здесь два подхода могут быть использованы:

1. компилятор может взять конструкцию как артефакт, а затем проверить, если код реализации сравнимый с ним.

2. компилятор или среда может обеспечить часть реализации, которая может быть автоматически генерируется (например, реализация одноэлементной), а сам код может взять на себя синглтон и не нужно повторно указать, например:

   класс ConcreteFactory: Фабрика {

   Product1 GetProduct1 { new ConcreteProduct1 } 
   
       Product2 GetProduct2 { new ConcreteProduct2 } 
   

   }

Обратите внимание, что реализация может игнорировать вещи более высокого уровня, как видимость класса и видимость методов, поскольку это уже указано на уровне разработки (DRY). Если вы спросите меня, этот тип языка должен будет поставляться со специализированной средой IDE, чтобы предоставить контекстную информацию о дизайне для типа. Как отметил Джефф Этвуд, любой новый язык должен поставляться со своей специализированной IDE.