Today I had my fifth live stream. The topic was interfaces, and this time I took a different angle at it: patterns. When I polled about live stream topics you’d like to hear about, most of you said “patterns”. So today’s stream covers several patterns and puts them in perspective of interfaces, or the opposite way around, however you like it.
The stream is available on my new http://vjeko.live/ page, and here it is if you hate clicking.
Today I’ve streamed the Fun with Interfaces video blog at https://www.youtube.com/watch?v=QSMHL32c5mg and the recording is now published online.
This was the first session I ever delivered about interfaces, and I actually planned delivering this a lot earlier (I made a suggestion to run this at Directions ASIA before corona crisis hit), but never had a chance. I now polished the demos a bit and delivered it as-is (no slides, really, so – no theory, just practice).
I will have more to say on interfaces, definitely. Stuff like dependency injection, inversion of control, testability, etc. is all very interesting to discuss and very useful in our daily life with AL.
My today’s session not only shows what you can do with interfaces, but also what you cannot, and why. Maybe, who knows, at some point we get some improvements to address some of pain points from my video.
Thanks to everyone who joined me today, and I am looking forward to see all you next week in “Making InvokeExtensibilityMethod work” session.
Whoa! This has been quite an event, the Directions EMEA 2016 in Prague. There has never been this many people (1.700+) and it was quite a pleasure connecting again with old friends, and meeting new friends. Also, it has been quite a pleasure listening to many good sessions, and an even bigger pleasure delivering four of them.
And this is why I am blogging now – to follow up on my promise during my Polymorphic Event Patterns for C/AL. I promised you that I’d post my pattern proposal online, and here I am doing it.
Let’s get started.
I’ve delved deep into design patterns story with my last two blog posts, but I am far from over. The patterns I discussed are the ones we could use up until NAV 2015 (we can still use them, of course!) but some more robust loose coupling (excuse the near-oxymoron) can be achieved with what NAV 2016 brought along: events.
It’s the “Handled” pattern. This pattern comes from Thomas Hejlsberg, a chief architect and CTO of Microsoft Dynamics NAV, and was first described by Mark Brummel on his blog. It’s a powerful loose-coupling pattern that successfully addresses the shortcomings of all design patterns I discussed earlier. I would prefer calling this pattern Event Façade rather than “Handled”, but it’s not my baby to christen.
Let’s take a look.
Achieving some kind of polymorphism in C/AL has always been a problem. The fact that true polymorphism with pure C/AL is outright impossible has not stopped the more stubborn of us to at least give it a try. That’s how some cool patterns emerged.
The façade pattern has been evangelized by Gary Winter so eagerly that he couldn’t find time to formally describe it. The other pattern that comes close is the variant façade pattern. It was formally described at the patterns Wiki page, but – to the best of my knowledge – was first figured out by Arend-Jan Kauffmann.
These two patterns can go a long way. No, they are not coming anywhere near true polymorphism, but will achieve some cool loose binding when you need it.
In my practice, I took a step further, and I think it’s about time I share it. Let’s see if it works for you as well as it did for me.
The purpose of events is to simplify business logic customization while not impeding upgradeability and general extensibility. However, there is one particular class of events that may cause troubles: OnAfter* table events. There are four of them: OnAfterInsert, OnAfterModify, OnAfterDelete, and OnAfterRename.
If you need them, you must be careful.
When I was writing my last post I had a distinct feeling that I was trampling over some boundaries of good NAV design. After all, you should not do stuff like that, NAV isn’t meant to do things like that, or at least that was how I felt.
And then two things happened.
First, I asked myself: what the heck, why not? What exactly is NAV meant to do, and why not things like that? If folks at Vedbæk didn’t provide an out-of-the-box solution for the problem, why should the problem stay unsolved?
Second, my dear friend and a fellow MVP, Hrvoje of Hudo’s Vibe, identified the thing as the mediator pattern. So, the thing I’ve done to NAV, civilized world has been doing to their programming environments for a long time.
And then I decided to take it all to a different level altogether, and expand the simple class which didn’t do much but raise events on itself when its method was called, into a full-scale framework. And here it is, the mediator pattern incarnated into a brand new Dispatcher class, adapted to NAV, and with features that make it truly flexible. I do not dare starting to think what are all the situations where you could put this thing to use in NAV.
Read on.
Four months ago I attended a conference, where I had a chance to listen to Miha Kralj, an architect at Microsoft, talk about architectures. It was one of the best presentations I ever attended, and ever since I had this topic in queue, but never really had chance to write about it. Most of the stuff he talked about reminded me of some bad experiences about architectures on projects I’ve worked on. Most of stuff here is also not my original contribution to the universal pool of knowledge, and I reuse it with the permission of the author, so Miha, thanks! What I did, however, is that I applied general principles to specific Microsoft Dynamics NAV situations.