» Tue Jun 18, 2013 7:03 am
I get your point but that kinda depends. Some of my interface class definitions are really short. They are intended to work as a sort of code injection mechanism into a bigger class. They can have just the constructor, virtual destructor and a single action function. It's pure abstract, so there's no implementation in it and can really only consists of 5 lines. Not even the implementations that inherit from it are much more complex than that. Sometimes they need to be. The benefit is that I don't need to check some input mode variable within a tight loop, and instead I can inject the piece of code outside the loop.
When you add factories, multiple inheritance, managed c++ and all into this, yes, the resulting code can be a pain to read. You can only figure it out by debugging when not even the IDE can't help you out. It would just point you to the pure abstract interface class and you'd have to search for the references. At least I haven't found a proper way to interpret this kind of code in Visual Studio 2008.
I bet I could use a function pointer to plug in some changing functionality into a class too, but in my opinion that would be more difficult than taking advantage of some class with the implementation and instantiating that inside a smart pointer.. Note to self, document your code better.
Most of UI related functions can also consist of a single line as far as I've seen. You click a button, and it sets a local variable. Then you click OK and it runs some action function with possibly a few more lines. However, that's mostly because of how the programming interface connects the entities like buttons to functions through some event mechanism.
Can we agree on that the target length for a function would be something between 5 to 50 code lines to keep it maintainable? Longer functions are again less readable in my opinion.