Seems like a bad idea to me. I guess it depends on what circles you run in. I think If I proposed this, most if not all of my dev peeps they would shun the idea immediately. Unless there was some extreme circumstance.

Like everything useful it’s a double-edged sword. I personally feel that Flex would never have succeeded if Monkey Patching were not possible. It’s an “Escape Hatch” (as Bruce Eckel would say). And without that you are just stuck and have to build things from scratch. Which is certainly less fun than having to dealing with diff’ing things when you rev the version of the SDK you use. I personally believe that the whole Monkey Patching thing could be improved if the Flex framework were more modular. Some of the programming constructs like Mixins, Traits, and IOC could certainly be used to build a more modular architecture. But it would be a enormous effort to rebuild the Flex framework using a more modular approach. That is why I’m hoping that Flight adopts a more modular approach and becomes a foundation for something new and modular.

-James

James, The historical perspective is interesting, and I do believe it is worthwhile to have the “escape hatch.” I would thank (not criticize) Adobe for giving us the freedom to do this. However, just because we have the freedom as developers doesn’t mean that is good for us to exercise it. Also, I would ask if you think this option is still key to Flex being successful in the years to come?

For me, I am primarily thinking about enterprise development, where systems are expected to be in production for many years to come. In those cases, avoiding this sort of technical debt is key to the long-term success of the system (and cost). So, I would tend to invest the time and cost up-front to find a solution that didn’t include monkey patching. In most cases, I think it can be done without having to start from scratch.

I think that we will continue to have to Monkey Patch in Flex until it (or something else) provides a more modular architecture. When you hit the wall there is just no other way. That is why it’s an escape hatch. All successful frameworks have them. But I would much prefer that the escape hatch were part of the framework instead of being the brute force method.

The only time that monkey patching has an impact on technical debt is when you upgrade versions of the Flex SDK. In large, production, long-lived applications this is rarely done. So I don’t think there is as much debt as you suggest. Also the new Marshall plan (SubApplications) can help to significantly reduce some of the technical debt incurred by this.

-James

My personal experience is that applications often do have to upgrade, and with agile projects development tends to go on long after the first production release (often years). That said, I would love to see more sophisticated methods for overriding and extending the framework added to Flex. Depending on how it was done it could open up some really interesting possibilities.

Applying a Monkey Patch means other developers who wish to set up a project using your code must understand the patch. In my experience, it just doesn’t work in the long term.

This is a very complex subject, you can’t just make it black and white. For example, it depends on what you define as Monkey Patching. If modify a private or protected method, or utilize mx_internal, I’m theoretically not affecting the public API. Thus, unit tests will still work, and upgrading from 3.1 to 3.2, etc. will still work. If you’re really concerned, if you are the one who wrote it, you’ll probably be doing diff’s to see what changes are in the new code. Most mp’s I’ve seen are small to get around small issues.

There are a lot of issues, but the big ones are visual design issues. For example, if the client wants a modified cursor… what do I say, ”No”? Ask the designer to design within the Flex SDK constraints? Both are perfectly valid responses… and a lot of times don’t work. So you have no choice. Besides, not all Flex projects use the Flex SDK in the same ways. Many of the Enterprise Flex projects I’ve seen have next to no custom components. They are just amalgamations of controls put in custom forms… that’s about it. Others are like Flash projects, where custom components are everywhere, and the Flex underpinnings (UIComponent and CSS styles) are used as a basis… and that’s where the SDK part ends. A lot of your code will be built atop the SDK, while other parts are completely unique.

It also depends on target company. Many of the Enterprises I’ve seen in consulting have strict rules that apply to their Java development, so they just assume they are appropriate for Flex too (which they aren’t always). Examples include, “Must use Cairngorm 2.2″, or “Do not utilize the mx_internal namespace”. The first is easy; you explain the benefits of using the UM extensions. For the latter… I usually ask them how they expect to draw custom Panels with custom buttons when extending the Flex panel. You HAVE to use mx_internal; all the stuff you need to access is in there. No mx_internal, no use of existing Panel and instead we write our own, thus negating all that wonderful work that went into Panel by the Flex SDK team.

The startups… they don’t care. Just get it working so we can get to market. Monkey patching and custom components abound there. The pattern though, is that a lot of the consumer apps tend to have more custom designs, and thus have more of a need to patch Flex whereas a lot of the behind the firewall, B2B apps are very simple. This’ll change over time as designers get up to speed on Flex’ capabilities, but for now, if you don’t do consumer apps, custom designs, or custom components, you probably are confused as to why in the hell you’d ever modify the Flex framework since it works so well.

Like James said, I’ve yet to see many Enterprise Flex apps drastically upgraded once in production. If you update the SDK for bug fixes, the whole point of using only public and protected, in my experience, pays off and most updates in SDK’s go smoothly. As for Agile… um, yeah, if you have an issue, fix it, that’s the point of getting crap done. If purism gets in the way, then to hell with purism. It’s not that black and white… nothing is when comparing YAGNI, architecture, and everything in between. Again though, I’ve seen these arguments before and chalk them up to Enterprise apps with standard designs vs. consumer/costumed designed Flex apps.

Evil: A rare (in my world) but very necessary evil. At technique that isn’t limited to the flex SDK classes either. I’m not against it at all, but its use should be judicious and the risk should be carefully managed on any projects that are not throw-away applications. Usually it is a good sign that you need to ask the vendor to sort it out, or possibly that your solution uses the wrong approach, because of course no one makes design errors do they?