Recently released on pub:

Show more releases

Latest Blog Posts

Factory Method without Factory Subclasses

Chris Strom, on 05 Feb 2016
I am already bored by the factory method pattern. Time for Dart mirrors! I kid of course. About the bored, not the mirrors. I goes without saying that I'm going to add mirrors.The Gang of Four book mentions two major varieties of the pattern: one that uses an abstract class, forcing subclasses to define the factory implementations, and the other in which the creator class provides a default factory implementation. I tried the the former last night, so tonight I try with a default implementation. For this example, I adopt the Delphi example on the Wikipedia page, which describes a... read more

Factory Method Pattern (Take 2)

Chris Strom, on 04 Feb 2016
Crazy what happens when you start writing a book, take a break for a year and a half, then come back. I had completely forgotten that I have already researched the factory method pattern for Design Patterns in Dart. But research it I did.Crazy too is that the approach I was taking to design patterns back then is very different to the one that I have been doing on this recent chain of posts. My focus recently has been to understand the consequences of patterns and different approaches to the pattern. Back then I spent the entire time benchmarking. I... read more

Degenerate Abstractions

Chris Strom, on 03 Feb 2016
What do you get when you remove all but one refined abstraction from the bridge pattern? I already looked into what happens when you only need one implementor. The Gang of Four book even included a discussion about one implementor, terming it a "degenerate case." What about the opposite?The prime mover in the bridge pattern is given the seemingly vague name of "The Abstraction." There are two required characteristics for the abstraction. First, it needs to perform some action whose exact implementation can vary. Second, it needs to have subclasses—different specific types of the abstraction. These subclasses are called refined... read more

In Which I Quarrel with Bridge Names

Chris Strom, on 02 Feb 2016
I confess that I find the names in the bridge pattern awkward. Why are there "refined abstractions" instead of "concrete abstractions"? Why is it "concrete implementor" instead of "refined implementor"? Why did we settle on names like "abstraction" and "implementor" which closely mirror programming concepts like "abstract classes" and "interface implementation"? Also, why does the Gang of Four book describe the pattern as decoupling "an abstraction from its implementation so that the two can vary independently" instead of "decoupling an abstraction from part of its implementation"? The pattern does not have the implementor implement all of the abstraction's functionality, just... read more

Factory Bridges in Dart

Chris Strom, on 01 Feb 2016
I've constructed a bridge in a client. I've constructed a bridge in a constructor. So tonight, I construct a bridge in a factory. I must investigate the factory and abstract factory in Dart. Mostly because I am unsure how much value the standard structure of the pattern is needed in a language with factory constructors baked right in. Since they are baked in, that's what I opt for tonight.The abstraction in my bridge pattern example continues to be a Messenger:abstract class Messenger { Communication comm; Messenger(this.comm); void updateStatus();}The purpose of classes implementing this interface is to simply facilitate status updates.... read more