The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,364 other followers

Design Patterns aren’t the goal, especially if you can cover the pattern with a language feature

Posted by jpluimers on 2019/10/15

Interesting read: [Archive.is] Are Design Patterns Missing Language Features.

On various places, it has been claimed that use of DesignPatterns, especially complex ones like VisitorPattern, are actually indicators that the language being used isn’t powerful enough. Many DesignPatterns are by convention rather than encapsulable in a library or component, and as such contain repetition and thus violate OnceAndOnlyOnce. If it didn’t contain at least some repetition, or something that could be Refactored out, then it wouldn’t be a pattern.

When applying design pattern, always remember that back then the Gang of Four wrote their book, languages were less powerful than now.

So always check if a design pattern cannot be applied by using a feature of the language you are using.

Examples from that page:

A list of DesignPatterns and a language feature that (largely) replaces them:

 VisitorPattern  .............. GenericFunctions (MultipleDispatch)
 FactoryPattern  .............. MetaClasses, closures
 SingletonPattern ............. MetaClasses
 IteratorPattern............... AnonymousFunctions 
              (used with HigherOrderFunctions, 
               MapFunction, FilterFunction, etc.)
 InterpreterPattern............ Macros (extending the language)
               EvalFunction, MetaCircularInterpreter
               Support for parser generation (for differing syntax)
 CommandPattern ............... Closures, LexicalScope, 
               AnonymousFunctions, FirstClassFunctions
 HandleBodyPattern............. Delegation, Macros, MetaClasses
 RunAndReturnSuccessor......... TailCallOptimization
 Abstract-Factory,
 Flyweight,
 Factory-Method,
 State, Proxy,
 Chain-of-Responsibility....... FirstClass types (Norvig)
 Mediator, Observer............ Method combination (Norvig)
 BuilderPattern................ Multi Methods (Norvig)
 FacadePattern................. Modules (Norvig)
 StrategyPattern............... higher order functions (Gene Michael Stover?), ControlTable
 AssociationList................Dictionaries, maps, HashTables
                    (these go by numerous names in different languages)

Food for thought…

–jeroen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: