incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug McCune <>
Subject Re: Overly large classes (was Flex incubation on Apache as Opensource)
Date Sun, 15 Jan 2012 20:06:41 GMT
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message