When it comes to overly large classes there are a few issues: 1. overall swf file size bloat 2. performance 3. complexity when extending/modifying functionality
For me, the first point about swf file size is the least important. That would be a great side effect if we could get the total size down substantially, but it's not going to make or break a project (unless you're using Flex to serve banner ads, which I'd simply argue is a bad use case). Points #2 and #3 are the important ones, and I'd argue that with the current mobile landscape, the point about performance is the most important. UIComponent isn't bad because it has a lot of code, it's bad because it's impossible to write super performant Flex components because they all have the performance overhead of UIComponent. Spark tried to get around some of this with the introduction of the non-UIComponent graphics display objects. But in the end, the problem is that if you want to extend UIComponent you get way more stuff than you really need. I wouldn't necessarily care if UIComponent was 10,000 lines of code if none of those lines ran unless I explicitly used that functionality (and if it was easy to NOT use any of the functionality I wanted). I guess my only point is that reduction in LoC is unimportant. The important thing is making sure only the absolute minimum amount of code needed is being executed. Breaking things up and focusing on composition instead of inheritance is one way to do that, but it's not good because we have smaller classes, it's good because it allows you to leave out a whole bunch of code from executing if you don't need it. So while LoC is an easy measure to try to dictate rules around (ie don't create any classes over X lines!), really the only thing that matters to me is being able to write super-fast code and having the flexibility to remove/modify the functionality I want/don't want. And yes, I realize there are other reasons to focus on LoC; some people will argue that # of bugs is directly correlated with LoC. In the end though, all these things (swf size, bugginess of code, etc) are nice byproducts, but are not (my) #1 goal for a good framework.
