In Part 2 of this series we learned about a more flexible implementation of the Visitor Pattern than the traditional approach. But we can do better.
Continue reading “The Visitor Pattern – Part 3”
In Part 1 of this series we learned about the benefits of the Visitor Pattern and saw a basic approach according to the GoF description.
As clean and elegant the visitor pattern might look in the first place, it nonetheless has its disadvantages. Say, we want to add a new shape TShapeTriangle. We have to do it inside the same unit the other shapes are declared. As the shapes reference the visitor and the visitor references the shapes we have to put all shape classes together with the visitor into the same unit. Although this might work in some smaller scenarios, it definitely doesn’t in most of the real ones. Probably this is one of the reasons why the Visitor Pattern is not as famous as it should be.
Can we find a solution? Yes, we can!
Continue reading “The Visitor Pattern – Part 2”
Some of you might have already heard of the Visitor Pattern, especially if you have read the GoF book Design Patterns, but do you really use it? Do you use it often?
The common answer to this question is No. Once I was even confrontated with the question “Does anybody use it in real code at all?”.
Well, I do – and here I’m going to explain the why and the how. Actually there are different hows and at the end I will introduce a real elegant how…
Continue reading “The Visitor Pattern – Part 1”
It looks like the recent preview of RAD Studio XE didn’t met expectations of many developers resulting in a massive popular outrage.
Beleive it or not, but ranting and shouting will not change anything about the upcoming release. I suggest to calm down and start talking decently with each other.
Obviously the people at Embarcadero have something to explain and just missed the point to do it properly in advance. That might have been the wrong way, but honestly, we are all human and talking about bad news is nothing we are keen to do.
So be generous. Imagine you were in their position. Let DavidI and Mike Rozlog take a breath, wait what they have to say and then decide on the information you get.
Staying with Delphi or going away is no decision that has to be done today or tomorrow. It should neither be done during a heated situation like we have now.
After all we are still developers. We are used to tackle a problem with logic instead of speculating and ranting. I am not aware of any bug that has been fixed by shouting at it.
There is something going wrong, no question. Lets start a debugging session and find out what it is and how to fix it.
Thanks to this article by Raymond Chen we can read what garbage collection really is and (perhaps even more valuable) what it is not.
I don’t want to start a new flame war about garbage collection (and even when – hey, this is my blog!), but I for myself I’m glad that Delphi doesn’t offer such a feature. We are always tempted, aren’t we?
Not that I don’t have any memory leaks in my programs. Not that I don’t use memory already freed. But with the right tools you can actually spot those errors and solve them. Doing so I often find some other error lurking in my code, just waiting to pop up like a jack-in-the-box. If there were no more such leak hunting, I would know less about my code than I do now.
Delphi doesn’t lack garbage collection – Delphi doesn’t need one.