On 13 dec, 21:19, Richard Newman <holyg...@gmail.com> wrote: > At the risk of going off on a bit of a tangent: > > My experience with teaching OO to university students (and watching my > own class learn it) suggests that polymorphism -- at least, as > presented by C++ and Java -- is the hardest concept for beginners to > grasp.
I would probably say that that is because it is the most powerful aspect of OO. Power is hard to wield effectively. > Encapsulation and some (usually erroneous) notion of 'modeling the > world' would seem to be the most obvious improvements over structured > programming, and beginners pick those up easily. When you present a > scenario of some object representing a bank account, "owning" its > balance and providing an interface to access it, OO seems a natural > fit to the problem. Polymorphism builds on that, yes, but one could > have a useful OO system without it (e.g., the various approaches to OO > in C, such as putting function pointers in structs, or prototype-based > OO systems). Oh yes, OO demands a kind of view of the problem that helps in breaking it down into manageble items, but it's not easy. In fact, I think it's actually hard to design an object-based system that models a problem well - in the general case - and the main reason we as programmers feel comfortable with OO is that we're so used to it. In the same way we tend to feel comfortable with relational databases - they're both a help in that they give you a pretty clear way of deciding what "works" and what doesn't, but at the same time, they can force all kinds of restrictions and work-arounds that are completely artificial. Encapsulation as in access control is really quite incidental and only marginally helps you in making sure the program works as expected - but neophytes to OO seem to think that that is the main benefit - while you can do encapsulation and API "contracts" in any language that has functions. I've commented in the past that whoever thought up "protected" should be publicly shamed. That's not to say that "pure functional" programming is better. As a general design principle, I would say it is, but you'll still run into problems where maybe OO has the better tools or the more straight- forward means of mapping a problem to code. > I suspect that students' difficulty with "traditional" OO polymorphism > has something to do with having to hold the inheritance hierarchy in > their heads while also looking at the instance, and figuring out what > will happen. At that larval stage it's a lost cause to dive into > virtual function tables :) Inheritance is at the same time too powerful and too weak. Look at any large Java project's API docs and try to figure out what the hell is happening. It just doesn't work for anything that isn't fundamental or clearly restricted. It's just not a good way of handling the larger problems. See the number of Java classes named XXXworker/actor/factory/ builder etc. Those things aren't objects; they really are just a bunch of functions. I think it's actually harmful when the language forces OO upon you because that kind of thinking can cloud the intent of whatever it is you're trying to build. > I'd be interested to see how Clojure's multimethods -- which pull out > the dispatch function into a concrete thing -- fare by comparison. As > with a lot of things, having a REPL there and being able to call the > dispatch function on various inputs would be a massive aid to > understanding. At the very least, explicit dispatch functions force you to think about what you're doing. That's probably a good thing. In my experience, you really don't need them much at all though. As with "standard" polymorphism, it's a great tool when it fits - especially when designing general libraries - but it's not something you need much in day-to-day programming, except - maybe - as a way to deal with name clashes. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
