Leaderboard

(For those outside the US, you can see the original commercial .)

This is an excellent idea... I had not thought of that. I believe OOP in and of itself is not hard. Most people understand the concepts pretty quickly. What's hard is figuring how to design it correctly. As I review the OO mistakes I've made over the past several years what it almost always boils down to is that my api was wrong. (Usually by trying to make a class do more than it should.) OOP forces you to make api decisions that could have long term consequences. It's making good api decisions that is hard, not anything inherent in OOP. By wrapping all your AE's in their own libraries and only exposing certain methods (this is the 'encapsulation' part of OOP) you get practice developing api's without the stress/stigma of using OOP. You can present it to your coworkers simply as "bringing a little more structure and organization to our applications." Hopefully over time the thinking will shift from, "I need to do <something> and this AE has that data, so I'll just add another action to it." to "I need to do <something> and this AE has that data, but does this new action make sense in the context of it's api?" I wouldn't advise anyone to start learning OOP by designing a large reuse library. You certainly can (I did) and you'll learn a lot, but don't expect to be successful (I wasn't.) I wouldn't even advise anyone to start learning OOP by designing classes they expect to reuse in another application. Try it on a single application. Forget about inheritance, focus on encapsulation. If you are in an environment where you have multiple developers working on the same application, the most immediate payoff is more structured code that is easier to understand and easier to predict how it will react to changes. Don't get me wrong, inheritance is important and useful. Sometimes it can make an otherwise difficult change a piece of cake. I've seen programmers implement some really cool things using inheritance. For those who are venturing down the OOP path on their own, I think they'll get more bang for their buck by concentrating on encapsulation and good api development. On the other hand, if you have an experienced OOP developer handy who can help guide the design, jump on the bus and enjoy the ride. That's very cool. I hadn't seen it. I know FG's are very fast so if raw speed is a concern that might be a better route to go than holding the data in the class cluster. I do wonder what the performance change would be if the AE (but not the FG) were refactored into a class.