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 1,789 other followers

Archive for the ‘Design Patterns’ Category

Every programmer should read this at their own pace: From design patterns to category theory

Posted by jpluimers on 2019/12/12

Slowly but steadily, I’m now ready to continue reading [WayBackFrom design patterns to category theory.

I found it two years ago after stumbling into [WayBack] Semigroups accumulate and [WayBack] Monoids accumulate. Both articles indicate they are part of two distinct series: [WayBack] Semigroups and [WayBack] Monoids which both in turn indicate the same super-series: [WayBack] Monoids, semigroups, and friends.

That intrigued me, as from a casual interest in Semigroups I got into a really structured coverage of many related topics leading all the way to design patterns. How cool is that!

Back than, I lacked some of the vocabulary I needed to fully grasp this, as part of the posts use the functional programming perspective which – for geeks like me that grew up in the procedural, object-oriented, and interface-polymorphism eras – takes some time to wrap their head around.

I did learn a thing or two back then, for instance the series taught me that some semigroups are not monoids. The diagram on the right shows how the various groups are related. But I could not replicate that knowledge, clearly lacking the words to explain it to myself.

What I really liked is the humble way in which the author – Mark Seeman – indicated that when he first thought about these topics himself, he too had still a lot of things to learn, including acquiring the vocabulary:

My first attempt at answering these questions was in 2010, but while I had the experience that certain abstractions composed better than others, I lacked the vocabulary. I’ve been wanting to write a better treatment of the topic ever since, but I’ve been constantly learning as I’ve grappled with the concepts.

Like me, he is on a life long quest in learning new things every day.

Now that I’ve done more functional programming (mainly from object-oriented code bases), I think I’m more equipped to digest his writings, better understand them and maybe even explain them.

By now there also should be more topics than these ones:

Time to do some reading over the next weeks…

–jeroen

Posted in Design Patterns, Development, Software Development | Leave a Comment »

If you have a gripe with nested if-then-else statements in any language, then usually it’s time to refactor some code…

Posted by jpluimers on 2019/12/10

Every time I run into complex nested if/then/else statement in any language with truckloads of code blocks, it usually means it is time to refactor in two steps:

  1. the code blocks into separate methods
  2. the decisions and methods into a polymorphic structure

Of course this adds some overhead, but usually you end up with code that is easier to unit-test and understand both the overall structure and detailed implementations of.

I’m all for language enhancements that allow deeply nested logic to be more manageable (for instance by enhancing a case construct), but usually refactoring makes that less of a need and more of a nice to have.

Via: [WayBackAnybody else have a gripe with nested if-then-else statements in Pascal? What if we had the following statement/syntax available in Pascal? … – Gerhard Venter – Google+

–jeroen

Posted in .NET, C#, Design Patterns, Development, Software Development | Leave a Comment »

Antipatterns in software development, architecture and management

Posted by jpluimers on 2019/10/30

If you develop software, be sure you recognise Antipatterns just as well as Patterns.

Luckily [WayBack] SourceMaking has a full sub-site covering software development, -architecture and management AntiPatterns: [WayBackAntiPatterns.

Of course it isn’t complete, so be sure to read [WayBack] The Majestic Monolith – Signal v. Noise as well.

via: [WayBackMartin Fowler on Twitter: “It’s an old anti-pattern, and sadly is still going strong: The Entity Service Antipattern.”

–jeroen

Posted in Design Patterns, Development, Software Development | Leave a Comment »

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

Posted in Design Patterns, Development, Software Development | Leave a Comment »

Many Computer Science concepts do not apply to Enterprise Applications

Posted by jpluimers on 2019/10/08

Old long read: [WayBackEnterpriseApplication; Martin Fowler 24 March 2014

Via: [WayBackWeekend Reader 2017.46 – reality-loop:

Characteristics of Enterprise Applications

It’s an old article but I like to come back to it from time to time: Martin Fowler describes the term “Enterprise Applications” and explains why some concepts from classical “Computer Science” are not applicable.

–jeroen

Posted in Design Patterns, Development, Software Development | Leave a Comment »

 
%d bloggers like this: