One thing that I've noticed a lot when trying to extend components (both in Flex and in .NET) is that a lot of base class methods simply do too much. If the base class methods are split up so they can be more selectively overridden, then extensions would be easier. For example, today I was trying to put a Button component inside a DataGrid as an item renderer directly within ActionScript (not creating a separate item renderer which contains a button). The button class has special code in it's "data" setter to set it's selected property when it's inside a datagrid. This code actually causes a null reference exception 'cause I'm using the button to launch commands and I don't want it to reflect a selected value. In my subclass I had to override both the "data" setter and getter because it's the only way to work-around this particular part of the data setter even though it's only part of what the setter does. If instead the setter was broken up into the setter, a protected dataSelected setter and a protected dataValue setter, then I could have just overridden the selected setter and not have had to duplicate code. This is only one small example which required duplicating only a dozen or so lines to work around. But often you find functions that are hundreds of lines long that have to be duplicated changing only a few lines which wouldn't be necessary if the function was broken up. Other time its literally impossible to override functionality because base class functions do too much in one function. IMO there is never a reason to have huge functions, breaking them up makes it easier to maintain, more self documenting (assuming you use good names), and makes extension easier (assuming the parts are protected and not private). My $0.02. Sam
------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building Flex based products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon Smith Sent: Thursday, June 14, 2007 10:03 PM To: [email protected] Subject: RE: [flexcomponents] Re: Private vs Protected Object-oriented languages support private access because hiding implemention details is essential to producing evolvable code. We try to figure out what the "interface" of a class should be, and we expose that and no more. Otherwise the class becomes so brittle that we can't change it without breaking compatibility... "Somebody might be calling foo() and it still has to do exactly what it did in 2.0.1 or their code will break." An alarmingly large percentage of our time is already spent on that kind of compatibility issue. If you can find a book on OO design that says "Make everything public unless you have a great reason for it to be private", I'd like to know about it. IMHO, we've done a good job of exposing the right APIs for application developers, but a poor job of exposing the right ones for component developers. We need to understand much more about how and why developers are extending our components in order to get the balance right. Making the framework brittle and unevolvable is one the quickest ways I can think of to kill Flex. - Gordon
