I recently looked at some code and had a lot of trouble figuring out how it works … until I found a lot of AddHandler spread through other parts of the code.
But there was really nothing that could not have been achieved with Senders and Receivers (Observer pattern).
Now I know that sometimes using AddHandler is the only way to go (timers declared in code come to mind), but most of the time it seems to me to be the modern equivalent of GoTo.
In my opinion the use of AddHandler should be discouraged as it’s a lazy way of producing spaghetti code.
Could you explain how the “observer pattern” contributes to spaghetti code? I found it very straightforward once I realised that it is just very badly named and is a simple sender receiver pattern (which is much easier to comprehend, and in some other programming languages it is actually called Sender Receiver pattern. ObjC and Swift seem to be a lot about sending and receiving messages). Because with the Sender Receiver pattern you know a control is registered as a receiver of messages and implements the receiving events. With AddHandler however the calls come from “nowhere” and can be to any event.
I have a generic solution for sending notifications with the observer pattern. There are only only about a dozen or so different notifications but these are used widely through my app. But even these are too many.
At the end of adding data to my app there is a complex set of notifications. I had to change something because of a change with the Valentina database. As result I to hunt through the mess of notifications because in some instances the progress window didn’t hide.
I have to say that the Observer pattern is excellent and I’m guilty of not using it enough. It’s one of the original “Gang of Four” design patterns. For the unenligntened, I decided to write a short explanation using Xojo code in this topic.
In response to your initial question Markus - I don’t think it’s the modern equivalent of GoTo because I believe it can be used effectively and clearly if you adhere to some naming conventions. I tend to prefix all methods that are acting as a handler as such: HandleTimerAction or HandleTextChanged which I think makes their intent clearer although I agree that, like anything, if you don’t document your code well then it’ll soon resemble a bowl of bolognese!
Yup, the cascade of messages is the problem. After adding data to the database I need to do a diagnosis of the database, which needs to be treated extra carefully these days. Then the app log needs to be shown, but now always. An email can be sent or not. And the app can be quit or not. The code is too old and needs a redesign. In the meantime I got a tiny bit of spaghetti code.
I must confess myself guilty of the same sin.
In my main project, I use a lot of external devices and their APIS, and in order to facilitate their handling I created classes for each. I chose an event scheme to handle their changes.
This is really nice as long as I use the classes as general objects on a windows layout. I can fill the event handlers with code and have everything nicely bundled to the object.
When I have to use a device in code only, things become messy because I find myself attaching a lot of handlers, and so the window or whatever container I am working on becomes cluttered with methods.
One way the IDE could help here would be the possibility to sort your methods in folders inside a class.
But of course, a much better way is to subclass the device and have one custom made for the usage. Of course, that means some communication between subclass and the parent object, and it is this tiny effort that often spoils easy understandable code.
Needless to say, an object full of methods tends to slow the IDE down, so additionally I spend a lot of time waiting for navigator to stop scrolling …
tl;dr: Agreed. There are usually better ways to handle class communication AND keep the code easy to follow.
One of the reasons that I think the Xojo IDE is easier to pick up for newcomers compared to many of its competitors is the fact that you have to add methods, properties, etc via the IDE and they end up in the navigator. This is great for custom controls that you drag on to a window but less good in the situation we’re talking about here where we are instantiating classes in code. It seems to be the topic of the day but the Observer pattern can help again here.