As a former TA, I agree. Objects are not ways of solving problems. They are a metaphor, which gives you a handle into the problem space. OO design is building

As a former TA, I agree. Objects are not ways of solving problems. They are a metaphor, which gives you a handle into the problem space. OO design is building a metaphorical data storage mechanism for your system, and then you need to cross the data into the metaphor and back again. I wasted countless hours when learning programming trying to wrap my head around coding in an OO fashion. Eventually I integrated enough OO to make my programs better. But I never really got 'into' OO, although I tried real hard! I don't have good words yet to explain the problem in detail, but fundamentally, a metaphor is not the solution. Most discussions of object orientation badly confuse themselves with that. As an example - an interface (ala Java/C#) is not an interface as a hardware engineer would speak of it: an interface from the OO perspective is some sort of promised type or 'protocol'. Are you building a model of your problem? Or are you solving your problem. I'm willing make a small wager that building models of your problem doesn't pay off until you really start scaling your system in some direction. If we use the Pareto idea, only 20% of your systems actually need the heavyweight approach - the other 80% can be put together without the heavy object-oriented machinery. Anyway, I'd rather be given the opportunity to teach in Scheme or other functional untyped language, instead of Java or C++. :-)