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,465 other followers

Archive for the ‘Design Patterns’ Category

Joe Groff on Twitter: “As programmers, we write parsers all the time, but handling parser errors well tends to fall by the wayside. Here’s a quick blog post with some high-level observations on how to deal with parse errors well”

Posted by jpluimers on 2020/04/30

From a while ago, but I archived and collected the links. Be sure to read the comments in the Twitter threads.


Read the rest of this entry »

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

Great quote destructors in Delphi development…

Posted by jpluimers on 2019/12/18

No destructor should ever throw an exception. If it does, there’s not really any way to recover from it anyway, so it doesn’t matter if anything leaks because of it.

Greate quote by [WayBackUser Rob Kennedy answering [WayBackinterface – Avoiding nested try…finally blocks in Delphi – Stack Overflow

It’s a basic development pattern for writing Delphi destructor code.


Posted in Delphi, Design Patterns, Development, Software Development | 6 Comments »

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…


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+


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.”


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

%d bloggers like this: