RSS LinkedIn Twitter

Private Variables and Monkey Patching

July 12th, 2009 Categories: Actionscript, Architecture, Design, Flex 3, Frameworks, Scalability

I’ve been pretty busy the past two months finishing up a project for my client.  I may have mentioned it before, but their creative vision is pretty intense (especially considering this is an in-house app… in my limited experience I’ve never seen so many resources allocated toward getting the look and feel of an in-house app to be just right).

Anyway, I’ve had to monkey patch approximately 10 Flex framework classes (for various reasons) in order to realize their vision.  In each of these cases I’ve first tried to use inheritance or composition to achieve the desired functionality, mostly in terms of interaction.  And in each of these cases I was unable to do so, and had to resort to making changes directly in a framework class which I maintain in an mx.controls.etc, etc structure with the rest of my project.  I don’t think I need to point out the many evils that this exposes the project to, suffice it to say it’s not ideal.

I just wanted to make an observation as to why I was unable to use normal OOP techniques to achieve the desired functionality.  The most common reason I have been unable to extend classes to do what I need is because there are too many private variables being used in protected functions.  So if I need to tweak one line of a protected method, I can override it.  However, assuming I don’t want to call super.methodName(), there’s no way to recreate the lines that interact with the private variables.

This leaves me two alternatives: 1) monkey patch the file to make the variable protected, or 2) monkey patch the file and just make the change directly to the method.  I make that decision depending on whether I’m fixing a bug, or just adding functionality.  Either way, it’s still a pain in the butt; and will probably be a bigger pain down the road.

Tags: , , , ,
No comments yet.

Leave a Comment