[Закрываются] новые шаблоны/стратегии проектирования дизайна

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

Многие другие паттерны, которые вы найдете в Интернете и в литературе, - это "просто" полезные приемы, а не язык, который вы можете использовать в разговоре с коллегами-программистами. Тем не менее, существует ряд паттернов, возникших за последние десять лет или около того, особенно в сфере веб-разработки. См. шаблоны, перечисленные в книге Мартина Фаулера patterns book.

Я заядлый последователь и сторонник PCMEF (теперь PCBMER)

Вот более простой обзор.

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

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

Я обнаружил, что это придало смысл принципам, которые мы все знали раньше, но были слишком ленивы, чтобы разобраться с ними - таким как принцип единой ответственности и разделение забот. Теперь я отношусь к этим двум принципам более серьезно".

Другим направлением совершенствования для меня стали TDD и Dependency Injection. Я обнаружил, что с большим количеством интерфейсов и классов, реализующих их, я смог избавиться от страха определить что-то только один раз. Это не значит, что это сильно противоречит DRY (Don't Repeat Yourself). Вполне нормально иметь два класса с одинаковыми свойствами, если их цели различны. Инкапсуляция и SRP гораздо важнее, чем определение свойства только один раз.

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

GOF был написан неявно с учетом Java. Он довольно хорошо исследовал это пространство. Однако как только вы переходите на другие языки, некоторые шаблоны больше не нужны (Observer редко используется в таких языках, как C #, который поддерживает события), и появляются новые. Возьмите себе книги Pro JavaScript Design Patterns или Design Patterns in Ruby и посмотрите, что происходит с резервными шаблонами в этих очень разных парадигмах.

Мои фавориты в последнее время основаны на функциональном дрейфе современных языков. Я большой поклонник вложенных замыканий и функциональных способов решения некоторых из тех же проблем, что и GoF (опять же, см. Прекрасные примеры в книге Ruby). Я также в настоящее время влюблен в идею внутренних предметно-ориентированных языков , которые открываются в целую серию собственных шаблонов проектирования (включая вложенные замыкания). Кроме того, агрегация событий, похоже, может сильно ударить по.Сетевой мир в ближайшем будущем.

Пара других крупных проектов, которые появились на сцене, но не обсуждаются так часто в GoF - вероятно, потому, что они более высокого уровня, чем те, к чему стремились эти ребята - это Inversion Of Control Containers, Message Bussing , Aspect-Oriented-Programming, Model-View-Controller, Model-View-Presenter, Model-View-ViewModel и им подобные.

Между прочим, это не шаблоны проектирования, но если вы хотите выйти за рамки TDD, обратите внимание на Behavior-Driven-Development и Context / Specification.

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

Mercurial (hg): https://www.mercurial-scm.org/
git : http://git-scm.com/

Они сделали довольно много для изменения рабочего процесса общей среды программирования. Это не совсем паттерн/дизайн, но я не думаю, что TDD или UML тоже являются техническими паттернами/дизайнами на каком-то уровне. Возможно, это больше похоже на общепринятую практику программирования.