Insanely Complex Event Handling
Author
In creating a level editor, I've come across the problem of having gigantic event handling functions (my MouseButtonDown function is over two pages long). I've considered breaking it down into two functions, such as MouseButtonDownVertexList() and MouseButtonDownOtherThing(), thereby cutting the function sizes in half. However, this doesn't make it much more readable, and it introduces a small amount of redundant code.
After looking at the two event handling functions, I realized that a lot of their code is almost exactly the same. So, I was thinking of possibly combining them under a single base class, and let polymorphism make my job easier. Problem is, one of the classes doesn't implement all of the features of another. So, that class would have to implement an empty function that essentially has nothing to do with that class at all. Is that a common practice though? It doesn't seem like very good design to me.
What are your suggestions? Is splitting the code enough, or would abstracting the functionality make my life easier in the long run? I hate having to make decisions like this...
Thank you for your time.
As long as the event handling function does everything it needs to do, there is no fatal problem here. When I have blocks of code that I deem to be too long, I don't just cut them in half and put them in different functions. Instead I try to identify redundant code and separate that. Also, it sounds obvious by keep in mind that certain chunks of code may look quite different but be doing the same thing on different sets of data. Such chucks should, of course, be separated into a separate function with parameters that describe the specific data.
Personally, when I start having very large code blocks, it indicates to me that I am unhappy with the overall organization of my code. At that point I start trying to understand what about the length of the code dissatisfies me, and I begin enumerating classes that can encapsulate some of that functionality so I don't have to see it, especially in simple event handling where I want to be able to glance at the code and understand what it's doing.
Personally, when I start having very large code blocks, it indicates to me that I am unhappy with the overall organization of my code. At that point I start trying to understand what about the length of the code dissatisfies me, and I begin enumerating classes that can encapsulate some of that functionality so I don't have to see it, especially in simple event handling where I want to be able to glance at the code and understand what it's doing.
What I would do is create a message register/list, and in the message handling function, look up the message and pass it on to a corresponding function. Then in my classes I would require an implementation of this callback function, probably using polymorphism. Basically, those things you click on, like the Vertex List, are wigits in your GUI, and should be encapsulated as such. The event handler function itself should be only a relay, imho.
Personally I don't mind so much having a 'nothing' function. It's generally far more clear, and easy to work with than duplicate code, or conditionals. I though am not exactly a seasoned professional or CS scholar.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
