3 ms·

You can't add code to ducks any more than you can add code to sockets. Let's assume for a moment the hypothetical student in this scenario is bright enough to

You can't add code to ducks any more than you can add code to sockets. Let's assume for a moment the hypothetical student in this scenario is bright enough to tell the difference between literally describing a thing, and expressing an abstraction of it. So basically then, the thing we're all supposedly getting in a kerfluffle about is that the example program in a hypothetical textbook that introduces the concept of inheritance is a cheap duck simulator. Ducks are a corny example, so I think it's fair to dismiss it as bland. But talking about physical objects is a great way to introduce inheritance to a novice because inheritance is fundamentally about hierarchical abstraction (code simplicity and reuse, incidentally, are side benefits enjoyed by all methods of abstraction). And what easier way to talk about hierarchical abstraction than the most accessible mental model already possessed by anyone who made it out of elementary school – the animal kingdom. The easiest pedagogical metaphors to grasp for students without special knowledge are those that draw similarities to what they already know. OO is about a lot of other things too. But concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design than a topic so fundamental to objects and classes that they need to be discussed when you're still talking about fundamentals like these. Are they good things to know about? Definitely. Will a student's mind be warped by basic inheritance example that imitates a taxonomy he already understands? As long as the whole book isn't about duck modeling, probably not, and even then I'm not sure you couldn't teach <IQuackable> FactoryFactories with a little imagination.

kragen 15y ago
If someone is actually writing about a bird-flock simulator or something, I think Duck is a perfectly fine example. My beef is with Duck being presented in the abstract, disembodied. > concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design... I don't think so. The inflexibility you can loosen with DI exists in all kinds of non-OO and even non-imperative programs as well. In a sense, the whole point of object-orientation is that it gives you a handle on that kind of thing: the thing you depend on is an object reified at run-time, which you can arrange to have passed in to you instead of extracted from a global namespace, and which can be replaced with some other object with different behavior, not an address you are jumping to that's hard-coded into your compiled jump instruction as an immediate argument.
- sassafras 15y ago
  Interesting. I suppose when I think of DI I usually think of Java. Do you know of a good example of the DI pattern being used in functional languages?
  - fleitz 15y ago
    map and reduce. DI is so prevalent in functional programming that it's pretty much taken for granted.
    - sassafras 15y ago
      Well, take this Clojure tutorial, for instance, comparing a simple DI implementation in Java with a single function in Clojure. The latter bears almost no resemblance to the former, other than achieving the desired effect. Is it fair to say that the user of a closure is implementing the Dependency Injection pattern, or is it a positive side effect of the fundamental properties of first class functions and lexical scope? http://vimeo.com/10368175 http://vimeo.com/10368175
      - fleitz 15y ago
        IMHO it's largely a side effect of first class functions. In Java in order to pass a function you need to pass an object that has the function, or an interface with the function, so it leads to a lot of line noise and thus people don't do it much. DI doesn't look impressive in a functional language because it's so well supported, but if you look at something like a global accumulator in a functional language you'll need a monad because you need state. eg in Java it's easier to write: int accum = 0; for(int i : collection){ accum +=i; } rather than collection.reduce(new IReduce<int> { int reduce(int accum, int i){ return i + accum; } }) I'm a bit rusty on Java so the syntax may be off but you get the idea, where as in a functional language (F#) that code is reduced to: collection |> Seq.reduce + Or in an imperative language that supports function passing (C#) collection.sum((a,b) => a+b)

kragen 15y ago

If someone is actually writing about a bird-flock simulator or something, I think Duck is a perfectly fine example. My beef is with Duck being presented in the abstract, disembodied. > concepts such as Dependency Injection, which was the meat of the grandfather rant, are IMHO more an outgrowth of dealing with the limitations of OO design... I don't think so. The inflexibility you can loosen with DI exists in all kinds of non-OO and even non-imperative programs as well. In a sense, the whole point of object-orientation is that it gives you a handle on that kind of thing: the thing you depend on is an object reified at run-time, which you can arrange to have passed in to you instead of extracted from a global namespace, and which can be replaced with some other object with different behavior, not an address you are jumping to that's hard-coded into your compiled jump instruction as an immediate argument.

sassafras 15y ago
Interesting. I suppose when I think of DI I usually think of Java. Do you know of a good example of the DI pattern being used in functional languages?
- fleitz 15y ago
  map and reduce. DI is so prevalent in functional programming that it's pretty much taken for granted.
  - sassafras 15y ago
    Well, take this Clojure tutorial, for instance, comparing a simple DI implementation in Java with a single function in Clojure. The latter bears almost no resemblance to the former, other than achieving the desired effect. Is it fair to say that the user of a closure is implementing the Dependency Injection pattern, or is it a positive side effect of the fundamental properties of first class functions and lexical scope? http://vimeo.com/10368175 http://vimeo.com/10368175
    - fleitz 15y ago
      IMHO it's largely a side effect of first class functions. In Java in order to pass a function you need to pass an object that has the function, or an interface with the function, so it leads to a lot of line noise and thus people don't do it much. DI doesn't look impressive in a functional language because it's so well supported, but if you look at something like a global accumulator in a functional language you'll need a monad because you need state. eg in Java it's easier to write: int accum = 0; for(int i : collection){ accum +=i; } rather than collection.reduce(new IReduce<int> { int reduce(int accum, int i){ return i + accum; } }) I'm a bit rusty on Java so the syntax may be off but you get the idea, where as in a functional language (F#) that code is reduced to: collection |> Seq.reduce + Or in an imperative language that supports function passing (C#) collection.sum((a,b) => a+b)