vaskir's blog

The Decorator design pattern makes it possible to extend an abstraction's behavior without touching the implementing class at all. I didn't use to use it as often as I should in the past, but as I'm reading (for the second time, btw) the fresh edition of the excellent  Dependency Injection in .NET  book by  Mark Seemann , I'm getting to really understand how useful it could be. But the most amazing thing is that how elegantly Windsor Container  wires up Decorators. Everything you have to do is register the Decorators in outside-in order and resolve the abstraction. For example, if we have Abstraction interface and two implementations - Impl1 and Impl2: and we would like Impl1 be injected into Impl2 via its constructor, then all we have to do is register Impl2 as the implementation of Abstraction, then register Impl1 in the same way (no explicit names are required for both). As a result, when we resolve Abstraction from the container, we get instance of ...

A very interesting thought about another wonderful side effect of "Tell, Don't Ask" principle ( Nat Price wrote in his blog ): "On the other hand, if the object tells a collaborator to do something with the value, it can choose, when the value does not exist, to just not tell it's collaborator anything or to tell the collaborator to do something different. There's often no need to represent the "does not exist" case as a data structure because it never gets passed around."

The .NET events are so common that almost nobody even thinks to consider practical alternatives to them. And that's a mistake. I'm going to show how much interfaces are better in OO sense. Consider two simple implementations of a very common Listener scenario where one class is "listening" another for some useful events. First, .NET event-based version: And interface-based version: The pros of the interface-based version are: An instance of Worker always references to a not-null WorkListener, which is great point since the Listener is its Dependency. ...and Worker claims about that as clear as possible - via its constructor. It's not possible to create a Worker without a valid instance of a class implementing WorkListener. It's absolutely clear at a glance that AnotherClass plays WorkListener role. In the even-based version all we have is just a public method with a rather weird (in context of the rest class's public interface) name and seman...

"Unless I’m publishing an API for general use, I don’t worry about testing method parameters against null . It’s too much code and too many duplicate tests. Besides, I would be testing the wrong thing. When a method receives null as a parameter, the invoker—and not the receiver—is missing a test." - J. B. Rainsberger

Martin Fawler in his good "Domain Specific Languages" book  heavily uses  ANTLR  to describe topics related to external DSLs. So, I pick the thing up and got to use it. It can generate lexers and parsers in C# (as well as in some other languages - java, c, c++, python). ANTLRWorks is a IDE with syntax highlighting, grammars visualization and even graphic debugger! What's rather strange and annoying that the latest ANTLR (3.2) and ANTLRWorks (1.4.2) generate wrong C# code - some attribute classes are just not defined in any assemblies. However, as ANTLRWorks 1.4 (with ANTLR 3.2 integrated) generates proper sources, I quite happy with the tool :) I recommend the DSL book and ANTLR to every senior developer who needs introduce a DSL into his project instead of tedious XML files or handwritten parsers.

Yesterday the GOOS paper book was brought by FedEx! Although I've read the e-book three times, I felt necessity to say 'thanks' for the authors by buying a paper copy. Then, thanks Nat and Steve!

"...[existing code] rewrites should be avoided because the programmers will not have been able to understand from the code why the software does what it does and, when rewriting, will revisit all the same mistakes the original programmers made. The same can be said [...] about making big refactorings to code that is new to you when you are not adding any new functionality to the system. It's only by adding a new feature that you can get a feel for the structure that the code needs to have. Otherwise you're just noodling about aimlessly and your refactoring will very probably make it harder to add new features in the future." Nat Pryce