You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by David Arno <da...@davidarno.org> on 2012/01/15 20:37:09 UTC
Overly large classes (was Flex incubation on Apache as Opensource)
> To: flex-dev@incubator.apache.org
> Subject: Re: Flex incubation on Apache as Opensource
> I think it should be clarified that a class or function with what we
> would determine is a high number of lines of code does not mean
> that its an indicator of crap code.
I disagree. From experience there is a strong correlation between class size
and the quality of the code.
> With those taken into account the line count might be ~ 8000 (just
guessing).
I again agree with Omar. If your class goes over 500 lines, then serious
alarm bells should be ringing. I work on the basis that any class over 200
lines (including braces and comments) needs serious justification as it's
got too big. So whether it is 16,000 lines or 8,000 lines makes no
difference: it's still between 40 and 80 times larger than a well designed
class should be.
David
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Doug McCune <do...@dougmccune.com>.
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.
Re: Overly large classes (was Flex incubation on Apache as
Opensource)
Posted by Alex Harui <ah...@adobe.com>.
On 1/15/12 6:07 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
> Disagree with you there. Spark is far from perfect but as someone who also
> develops components every day I much prefer to problems of Spark over the
> lets-do-everything-through-inheritance mx world.
And that is the conundrum. Composition is way more flexible and should save
on development time and runtime memory, but MXML uses an inheritance model
and in a completely composed architecture, the modification of the behavior
requires modifying the internal pieces (or choosing a different composition)
which is not a good workflow for MXML.
Me, I will be exploring composition and seeing if we can build out
tools/utilities and patterns to assist with the modification issues.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: Overly large classes (was Flex incubation on Apache as
Opensource)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
Sorry Jeffry,
Disagree with you there. Spark is far from perfect but as someone who also develops components every day I much prefer to problems of Spark over the lets-do-everything-through-inheritance mx world.
Mike
-----Original Message-----
From: Jeffry Houser [mailto:jeffry@dot-com-it.com]
Sent: Sunday, January 15, 2012 3:55 PM
To: flex-dev@incubator.apache.org
Subject: Re: Overly large classes (was Flex incubation on Apache as Opensource)
On 1/15/2012 4:01 PM, David Arno wrote:
> I'll
> comment on List.
>
> The class does many things: it's a container; it displays the contents
> of a data provider; it supports scrolling; it supports item renderers;
> it supports dragging& dropping; it supports single selections; it
> supports multiple selections; it supports item editing etc. Classes
> should be single purpose. Therefore the List class should be a
> compositional class that is composed of IDataProviderSupport,
> IScrollSupport, IDragAndDropSupport etc and the functionality that is
> currently in List should be in classes that implement those
> interfaces. That way, the currently overly-large, over-complex,
> unfocused class could be broken up into a large number of properly focused, smaller classes.
That is kind of what the Spark Architecture did. And the end result is that development is more complicated to extending and modifying things [from the perspective of a component developer] is a complete nightmare. It's much worse than the "too many private variables"
problem that existed in the Halo architecture.
For the sake of simplicity in development; wouldn't the MX approach of having a single class to represent the List be better?
In my view Spark favored flexibility over simplicity.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Notice: This transmission is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. Any dissemination, distribution or copying of this transmission by anyone other than the intended recipient is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail or telephone and delete the original transmission. Thank you.
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Tink <fl...@tink.ws>.
On 15 Jan 2012, at 21:54, Jeffry Houser wrote:
>> That is kind of what the Spark Architecture did. And the end
>> result is that development is more complicated to extending and
>> modifying things [from the perspective of a component developer] is
>> a complete nightmare. It's much worse than the "too many private
>> variables" problem that existed in the Halo architecture.
>
> For the sake of simplicity in development; wouldn't the MX approach
> of having a single class to represent the List be better?
>
> In my view Spark favored flexibility over simplicity.
>
> --
> Jeffry Houser
> Technical Entrepreneur
> 203-379-0773
> --
> http://www.flextras.com?c=104
> UI Flex Components: Tested! Supported! Ready!
> --
> http://www.theflexshow.com
> http://www.jeffryhouser.com
> http://www.asktheflexpert.com
> --
> Part of the DotComIt Brain Trust
>
I much prefer the code base of the Spark List as a user and component
dev.
Scroller, DataGroup and skinning opened up so many more possibilities.
Those privates still get in the way though!
Please lets not go back to the MX days!
Tink
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by jude <fl...@gmail.com>.
By all means do it and post it here. I'd rather have more interfaces with a
few more bytes and less dependences if I understand you correctly.
On Monday, January 16, 2012, David Arno <da...@davidarno.org> wrote:
>> From: Tink [mailto:flex@tink.ws ]
>> Sent: 16 January 2012 08:21
>> There is also a small amount of code the make sure the selected index or
> carat is
>> visible (as a Scroller doesn't have any logic for selected items).
>
>
> We clearly have very different ideas on "a small amount of code".
>
> David.
>
>
RE: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by David Arno <da...@davidarno.org>.
> From: Tink [mailto:flex@tink.ws ]
> Sent: 16 January 2012 08:21
> There is also a small amount of code the make sure the selected index or
carat is
> visible (as a Scroller doesn't have any logic for selected items).
We clearly have very different ideas on "a small amount of code".
David.
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Tink <fl...@tink.ws>.
On 15 Jan 2012, at 22:23, David Arno wrote:
> Tink, Jeffry,
>
> Maybe I've got confused, but I was describing spark.components.List,
> which I
> assume is a spark component. This class might be less monolithic
> than the
> halo version, but it is ridiculous to claim it implements composition.
>
> Take for example scrolling. In true composition, there would be a
> reference
> to a scroll handler into which salient data would be injected and
> that would
> be pretty much it. List though, has a scroller variable (of class type
> Scroller), which handles some aspects of scrolling, but there are
> still lots
> and lots of lines of code, many deeply embedded inside long, complex,
> methods of List, that handle some aspects of scrolling. This isn't
> composition, it's just a messy bodge to enable support for spark
> skinning.
>
> Fair point on editing though. That was a mistake on my part.
>
> David.
>
>
List exposes 2 styles, and 2 properties that is passes onto the
Scroller instance.
There is also a small amount of code the make sure the selected index
or carat is visible (as a Scroller doesn't have any logic for selected
items).
Tink
RE: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by David Arno <da...@davidarno.org>.
Tink, Jeffry,
Maybe I've got confused, but I was describing spark.components.List, which I
assume is a spark component. This class might be less monolithic than the
halo version, but it is ridiculous to claim it implements composition.
Take for example scrolling. In true composition, there would be a reference
to a scroll handler into which salient data would be injected and that would
be pretty much it. List though, has a scroller variable (of class type
Scroller), which handles some aspects of scrolling, but there are still lots
and lots of lines of code, many deeply embedded inside long, complex,
methods of List, that handle some aspects of scrolling. This isn't
composition, it's just a messy bodge to enable support for spark skinning.
Fair point on editing though. That was a mistake on my part.
David.
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 1/15/2012 4:01 PM, David Arno wrote:
> I'll
> comment on List.
>
> The class does many things: it's a container; it displays the contents of a
> data provider; it supports scrolling; it supports item renderers; it
> supports dragging& dropping; it supports single selections; it supports
> multiple selections; it supports item editing etc. Classes should be single
> purpose. Therefore the List class should be a compositional class that is
> composed of IDataProviderSupport, IScrollSupport, IDragAndDropSupport etc
> and the functionality that is currently in List should be in classes that
> implement those interfaces. That way, the currently overly-large,
> over-complex, unfocused class could be broken up into a large number of
> properly focused, smaller classes.
That is kind of what the Spark Architecture did. And the end result
is that development is more complicated to extending and modifying
things [from the perspective of a component developer] is a complete
nightmare. It's much worse than the "too many private variables"
problem that existed in the Halo architecture.
For the sake of simplicity in development; wouldn't the MX approach of
having a single class to represent the List be better?
In my view Spark favored flexibility over simplicity.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Tink <fl...@tink.ws>.
A Spark List is maybe a bit more compositional (if thats a word) than
you would think.
It is a container, but it isn't really used as one (i.e. the Spark
skinning issue previously discussed on this list), it doesn't really
support Scrolling, it hands that off to a composite skin part
Scroller, it does very little with renderers, as it hands that off to
a composite skin part DataGroup.
It does implement drag and drop, single selection is inherited, but
multiple selection is implement on top of this.
It doesn't support any form of item editing,
Tink
On 15 Jan 2012, at 21:01, David Arno wrote:
>> From: Jeffry Houser [mailto:jeffry@dot-com-it.com]
>> Sent: 15 January 2012 19:54
>> I'm curious as to what your suggestions would be simplifying
>> something
> like this?
>> [Or ignoring my commercial component, the Flex List class]
> I'd prefer not to comment on your commercial creations Jeffry, but
> I'll
> comment on List.
>
> The class does many things: it's a container; it displays the
> contents of a
> data provider; it supports scrolling; it supports item renderers; it
> supports dragging & dropping; it supports single selections; it
> supports
> multiple selections; it supports item editing etc. Classes should be
> single
> purpose. Therefore the List class should be a compositional class
> that is
> composed of IDataProviderSupport, IScrollSupport,
> IDragAndDropSupport etc
> and the functionality that is currently in List should be in classes
> that
> implement those interfaces. That way, the currently overly-large,
> over-complex, unfocused class could be broken up into a large number
> of
> properly focused, smaller classes.
>
> David.
>
>
RE: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by David Arno <da...@davidarno.org>.
> From: Jeffry Houser [mailto:jeffry@dot-com-it.com]
> Sent: 15 January 2012 19:54
> I'm curious as to what your suggestions would be simplifying something
like this?
> [Or ignoring my commercial component, the Flex List class]
I'd prefer not to comment on your commercial creations Jeffry, but I'll
comment on List.
The class does many things: it's a container; it displays the contents of a
data provider; it supports scrolling; it supports item renderers; it
supports dragging & dropping; it supports single selections; it supports
multiple selections; it supports item editing etc. Classes should be single
purpose. Therefore the List class should be a compositional class that is
composed of IDataProviderSupport, IScrollSupport, IDragAndDropSupport etc
and the functionality that is currently in List should be in classes that
implement those interfaces. That way, the currently overly-large,
over-complex, unfocused class could be broken up into a large number of
properly focused, smaller classes.
David.
Re: Overly large classes (was Flex incubation on Apache as Opensource)
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 1/15/2012 2:37 PM, David Arno wrote:
>> To: flex-dev@incubator.apache.org
>> Subject: Re: Flex incubation on Apache as Opensource
>> I think it should be clarified that a class or function with what we
>> would determine is a high number of lines of code does not mean
>> that its an indicator of crap code.
> I disagree. From experience there is a strong correlation between class size
> and the quality of the code.
I'm w/ Jude on this one. Line count is not inherently an indicator of
bad code.
As one personal example; the most common feedback I hear about the
Flextras Calendar is how well it is documented. Not one person
complained about the length (~4K lines). More than half of those lines
do nothing but define the get/set properties of the API. I'm curious as
to what your suggestions would be simplifying something like this? [Or
ignoring my commercial component, the Flex List class]
I think this "issue" may come down to a mind set difference between
component creators and application creators.
I do agree, however, that the UIComponent class is not a focused
class. It sometimes feels like a "Catch all" class for everything that
didn't fit somewhere else.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust