Не-ООП Шаблоны проектирования? [закрыто]


70

Я только слышал, как термин «шаблон проектирования» используется для объектно-ориентированного кода, и шаблоны GoF включают только шаблоны проектирования ООП, но шаблоны проектирования - это элегантные решения для часто возникающих проблем программирования, верно? Там нет ничего, что говорит, что они должны быть ограничены ООП, не так ли?

Я хотел бы увидеть некоторые примеры шаблонов проектирования вне сферы объектно-ориентированного программирования. У тебя есть? Существуют ли они вообще (не должно быть написано ни одной книги, такой как книга GoF, ее просто нужно использовать; этого достаточно)?

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


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

14
Ну, объекты - это шаблон проектирования на языках, не относящихся к OO :)
back2dos

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

Ответы:


25

12

На самом деле это парадокс - один из самых популярных паттернов Non-OO - это ... «Класс».

Поскольку ОО был изобретен не на ОО-языках, разработчикам приходилось имитировать его (и они делают это даже сейчас) - так и появилась модель. LISP и C являются примерами этого.

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

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


11

«Шаблон дизайна» на самом деле является эвфемизмом для «обходного пути». Шаблоны проектирования были изобретены для устранения недостатков и недостатков в ОО-языках . Например, возьмем шаблон итератора, который в конечном итоге привел к появлению коллекций в Java. Groovy избавился от многих других шаблонов, преобразовав их в языковые функции: вам больше не нужен шаблон декоратора, поскольку вы можете добавлять методы к существующим классам в Groovy.

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


9
Согласовано! От Пола Грэма : «Например, в ОО-мире вы много слышите о« шаблонах ». [...] Когда я вижу шаблоны в своих программах, я считаю это признаком проблем. Форма программы должна отражать только проблема, которую нужно решить. Любая другая закономерность в коде является признаком, по крайней мере для меня, того, что я использую абстракции, которые недостаточно мощны - часто я вручную генерирую расширения некоторого макроса что мне нужно написать ".
Андрес Ф.

7
Я не согласен с тем, что шаблон дизайна - это обходной путь. Эти две противоположности. Обходной путь - это краткосрочный патч, собранный вместе, чтобы обойти определенное препятствие. Шаблоны проектирования - это долгосрочные решения для многократного использования. Целью шаблона декоратора является функциональное добавление «без» модификации класса. Вы можете разместить разные декораторы на объекте, не узнавая об этом объект.
Despertar

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

@AaronDigulla Я не понимаю, почему вы думаете, что шаблон, такой как декоратор, является такой тяжелой реализацией; Вы говорите о нескольких строках кода. Класс содержит другой класс и перенаправляет запросы к нему с некоторыми дополнительными функциями. Он использует наследование и композицию таким образом, что делает вызов декорированного объекта эквивалентным вызову самого объекта. Я считаю эту прозрачность сильной стороной. Это позволяет вам менять декораторы во время выполнения. Когда вы говорите, что groovy не нужен декоратор, потому что он может добавлять методы к классу, это звучит так, как будто вы упускаете суть.
Despertar

2
Шаблон Iterator не был заменен какой-либо новой языковой функцией в современных языках. Это просто идет с реализацией по умолчанию для общих коллекций. Тот факт, что он имеет реализацию по умолчанию, не означает, что шаблон не используется. Если вы напишите свою собственную коллекцию, вам придется реализовать ее самостоятельно.
Despertar

10

LtU упоминает, что Джереми Гиббонс пишет книгу о шаблонах в функциональном программировании. Посмотрите паттерны Мистера Гиббона в блоге по функциональному программированию, чтобы найти несколько тизеров. Обратите внимание, что он рекомендует читать свои посты от самых старых до новых.

Его статья « Шаблоны проектирования как общие программы типов данных высшего порядка» (pdf) функционально моделирует шаблоны «банды четырех»: составной, итератор, посетитель и построитель. Он описывает шаблоны программирования с помощью рекурсивных уравнений в программировании оригами (складывает и разворачивает).



7

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

Надеюсь это поможет


Это те, которые я бы порекомендовал, а также шаблоны корпоративной интеграции Hohpe & Woolf .
TMN

Паттерны Фаулера очень хороши :)
Дэвид Конд

@David Conde :) Большинство из них являются чисто ОО, все они записаны ОО-способом, но некоторые из них также применимы к не ОО: посмотрите на «Шаблоны веб-презентации», «Шаблоны состояния сеанса», «Шаблоны распределения "
KeesDijk


1

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


Используется в JS & "pure C": en.wikipedia.org/wiki/Module_pattern
umlcat

1

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


0

Мне нравится думать о Data Strucutres, таких как очереди, связанные списки, деревья, графики и т. Д. Как шаблоны. Они определяют определенные шаблоны для хранения данных и их обработки. Они могут показаться примитивными по сравнению с более высококлассными моделями Gang of Four, но, тем не менее, они являются шаблонами. Я имею в виду, что произошло бы, если бы кто-то реализовал стек как FIFO вместо LIFO и наоборот для очереди и назвал их иначе?

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.