Шаблони дизайну, які не є OOP? [зачинено]

Я чув лише, що термін "модель дизайну" використовується для об'єктно-орієнтованого коду, а шаблони GoF включають лише схеми дизайну OOP, але шаблони дизайну - це елегантні рішення для часто виникаючих проблем з програмуванням, правда? Ніщо там не говорить про те, що вони повинні бути обмежені OOP, чи не так?

Я хотів би побачити кілька прикладів моделей дизайну поза сферою об'єктно-орієнтованого програмування. Чи є у вас? Чи такі існують (жодна книга, як, наприклад, книга GoF, не обов’язково повинна бути написана, їх просто слід використовувати; цього достатньо)?

Вони можуть бути специфічними для деяких мов програмування, але загальні (на рівні парадигми) переважні інші парадигми, ніж орієнтована на об'єкт.

Погляньте в серію шаблонів дизайну ядра Linux. Статті пов'язані з не об’єктно-орієнтованою мовою (С), і я вважаю, що вони добре написані:

• Шаблони дизайну ядра Linux - Частина 1
• Шаблони дизайну ядра Linux - Частина 2
• Шаблони дизайну ядра Linux - Частина 3
• Привиди Unix Past: історичний пошук моделей дизайну
• Привиди минулого Unix, частина 2: Сплутані конструкції
• Привиди минулого Unix, частина 3: Несправні конструкції
• Привиди минулого Unix, частина 4: Конструкції з високим обслуговуванням

Насправді це парадокс - однією з найпопулярніших моделей, що не належать до OO, є ... "Клас".

Оскільки OO був винайдений мовами, що не належать до ОО, розробникам довелося моделювати його (і вони це роблять навіть зараз) - так закономірність народилася. Приклади цього є LISP та C.

Але прийміть мою пораду: не робіть поширених помилок - не використовуйте шаблони тільки тому, що це круто , вам потрібні серйозні причини, щоб виправдати використання шаблону (принаймні, OO).

Візьмемо для прикладу командний зразок - хоча це приємно & він знімає абонента від приймача, він не повинен використовуватися, якщо вам це справді не потрібно - оскільки операції повинні бути виражені за допомогою дієслів - що означає методи. І використовуючи команди на всіх місцях, ви б закінчилися з купою повністю децентралізованих OO-лямбда -> те ж саме було б справедливо і для багатьох стратегій.

"Шаблон дизайну" - це насправді евфемізм для "вирішення проблеми". Шаблони дизайну були винайдені для усунення недоліків та недоліків в мовах ОО . Для прикладу візьмемо шаблон ітератора, який врешті-решт призвів до введення колекцій на Java. Groovy позбувся багатьох інших шаблонів, перетворивши їх на мовні особливості: Вам більше не потрібен шаблон декоратора, оскільки ви можете додавати методи до існуючих класів у Groovy.

Це означає, що ви можете знайти шаблони дизайну скрізь. Насправді кожну "найкращу практику" можна вважати простою формою дизайну.

LtU згадує, що Джеремі Гіббонс пише книгу про закономірності функціонального програмування. Ознайомтесь із блогом « Шаблони містера Гіббона» у функціональному програмуванні для кількох тизерів. Зауважте, він рекомендує читати свої повідомлення від найдавніших до найновіших.

Його статті " Шаблони дизайну" як програми для вищого порядку даних (pdf) функціонально моделює банду з чотирьох візерунків: композит, ітератор, відвідувач та будівельник. Він описує закономірності програмування з рекурсивними рівняннями в програмуванні Орігамі (складки та розгортання).

Існують шаблони дизайну SQL .

І деякі функціональні моделі дизайну також існують - дивіться тут для Scala.

Замість того, щоб називати шаблони дизайну, що не входять у виробництво, я хотів би навести кілька прикладів книг, у яких багато моделей дизайну (в них деякі візерунки все ще будуть специфічними для OO):

• Подивіться у книжках POSA для прикладів архітектури програм
  • Розподілені обчислення
  • Шаблони для паралельних та мережевих об'єктів
  • Закономірності управління ресурсами
• Шаблони фоулерів архітектури підприємства за допомогою он-лайн каталогу
• xUnit Тестові зразки з веб-сайтом
• І звичайно, звідки зародилися візерунки: позачасовий спосіб побудови Крістофера Олександра

Сподіваюсь, це допомагає

У функціональному програмуванні (особливо в Haskell) є багато моделей і ідіом, які не дуже добре відображають OOP. Типи Phantom - це добре відомий приклад, і ви можете знайти багато іншого на сторінці вікі haskell на Idioms .

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

Хороший приклад моделей, що не належать до ООП, - це мій абсолютний улюблений каталог шаблонів: Організаційні патерни Agile Development Software, Джеймс О. Коплін . Ця книга не стосується програмних моделей, а про людей, каталог для створення успішних команд. Кожен керівник повинен прочитати цю книгу!

Мені подобається вважати структури структури даних, такі як черги, пов'язані списки, дерева, графіки тощо. Вони визначають певні шаблони для зберігання даних та їх обробки. Вони можуть здатися примітивними порівняно з більш високими кінцевими малюнками «Банди з чотирьох», але все ж вони є моделями. Я маю на увазі, що буде, якби хтось реалізував стек як FIFO замість LIFO і навпаки для черги та назвав їх інакше?