Hacker News Reader

Comment by thomasz | Hacker News Reader

I think beginners should be confronted with OOP very early, but not in the typical way:

- DO teach encapsulation of state.

- DO NEVER ever try to teach about objects as representations of real-world things. And for the love of god, do not give out modelling assignments where "Human inherits mammal" is an answer.

- DO start with collections: Vector, List, Stack etc. are easy to implement and showcase the virtues of encapsulating.

- DO teach polymorphism, but only in terms of interface inheritance. The collections you have taught before are a good starting point: ICollection, IRandomAccessable etc.

- DO NEVER EVER talk about class inheritance. Do not even use the word inheritance. Call it "is a relation" or something like that.

- When the time comes to teach inheritance, emphasize the Liskov substitution principle.

View on HN

- DO NEVER ever try to teach about objects as representations of real-world things. And for the love of god, do not give out modelling assignments where "Human inherits mammal" is an answer

I have to disagree with this. I think this is exactly how to think about this.

I once explained the shift to OO to an older gent who was familiar, not just with ancient scientific programming, but also with building a house. I told him that the idea was that code was so large and complicated that it was divided up among teams with each team getting specific parameters that their code had to fit. He said, well of course.

Then I said it was much like constructing a house. You had to put the frame up, and know where the windows and doors would be, but the details of the windows and doors could be decided later. Every door had to be able to respond to an "open" command and a "close" command, some may have a "lock" command, and so on, but the builder of the door worried about getting that stuff right. All you had to specify were the dimensions and the direction of the door.

Now this was a pretty technical person- and perhaps doesn't qualify as a beginner, but I find, in general, real world metaphors to be powerful for teaching.

"I told him that the idea was that code was so large and complicated that it was divided up among teams with each team getting specific parameters that their code had to fit."

IMO, this is the first mistake. Code should not be large and complicated; when it is, few things can save you, whether it be the language or paradigm you're programming in, or the structure of the team doing the programming. OOP is a solution to the wrong problem.

But how do you avoid it in today's world? How do you actually build an app without a large code base?

The important things for writing modular code in a big codebase is defining clear interfaces and making "black box" modules. An important thing for this is abstract data types but, unlike what many people seem to say, those are not exclusive to OOP - you can also have abstract datatypes in procedural or functional languages.

The core concept of OOP is adding dynamic method-based dispatching to your abstract data types but I would argue that while this is useful a lot of times, its not really fundamental. IN fact, there as many cases when dynamic dispatching will not be able to solve the problem on its oown: a good example is generics in Java and C# - parametric polymorphism helps enforce abstractions but isn't really object oriented.

What is it about "today's world" that makes software require a larger code base? If anything, we have much higher-level languages which require far less code than in the olden days. Anyway, my point was more about the unix nature of building small programs, that do one thing well, and using those progams in combination.

"What is it about "today's world" that makes software require a larger code base?"

The fact that we are still not using the high-level languages we have available to us. Vast amounts of new C, C++, and Java code are written each year. We are solving bigger problems, but we are using languages that are still catching up to the state-of-the-art of the 1970s.

* Anyway, my point was more about the unix nature of building small programs, that do one thing well, and using those programs in combination.*

That just uses different words to describe the same net result and the same net problem. You still have to find a way to make all of those pieces work together to do something complex.

You can start with realizing that your data (100k rows) does not require Oracle and can be stored in a flat file and loaded in memory, so you can ditch JPA. Then get rid of Spring and Jackson. Then you remove all Abstract Singleton Factories and leave just the code that does what user wants, not what developer wants. Then drop a couple of messaging frameworks that your using when you realize that now all the code fits in one app. Next thing you will see is that NanoHttpd will do just fine for your load level and therefore you can ditch WebLogic. After all that you can remove maven (blasphemy!!!) because your project shrunk to a few dozen files that can be compiled and packaged with 5 lines batch script.

But that wouldn't be glamorous, would it? Besides, this approach will make you hopelessly unemployable in today's world.

Depends what you include in "code"; your program might be a one-liner, but its language environment and operating system are the product of huge teams. It's a kind of modularisation that's so effective we don't think of it as a division of labour.

One person writing all the code for a system from the bare metal up is pretty much limited to embedded systems now.

That's using a metaphor to explain OOP, not teaching OOP modeling with examples from the physical world.

No, you can teach it that way.

thomasz's point was that nothing in your example was "Human inherits Mammal".

As kazagistar succinctly puts it, "Inheritance is not taxonomy." Your house analogy isn't taxonomy; that's why it's correct.

Right. And monads are burritos. (http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio...)

> The heart of the matter is that people begin with the concrete, and move to the abstract. Humans are very good at pattern recognition, so this is a natural progression. By examining concrete objects in detail, one begins to notice similarities and patterns, until one comes to understand on a more abstract, intuitive level. This is why it’s such good pedagogical practice to demonstrate examples of concepts you are trying to teach. It’s particularly important to note that this process doesn’t change even when one is presented with the abstraction up front! For example, when presented with a mathematical definition for the first time, most people (me included) don’t “get it” immediately: it is only after examining some specific instances of the definition, and working through the implications of the definition in detail, that one begins to appreciate the definition and gain an understanding of what it “really says.”

Inheritance is not taxonomy. If you want to teach inheritance, show a couple of realistic examples of code which, when you add inheritance, becomes clearly better. We can see the pattern; we can make our own intuitive, abstractive jumps.

"Never ever try to teach about objects as representations of real-world things"

I hear this from time to time—it seems bizarre. Representing real-world things as objects is a fine design approach for many problems and is well worth teaching. Where on earth did the idea that it isn't get started?

SICP, a classic of programming pedagogy if ever there was one, has this to say:

One powerful design strategy, which is particularly appropriate to the construction of programs for modeling physical systems, is to base the structure of our programs on the structure of the system being modeled. For each object in the system, we construct a corresponding computational object. For each system action, we define a symbolic operation in our computational model. (p. 217, 2nd ed.)

It's true that by "object" they mean something more general than OO. But that doesn't change the basic design approach.

It's also true that they are careful to teach more primitive concepts first, so what they do is compatible with the OP's point. But there's a reason why the above passage on real-world representations appears immediately after they mention modularity.

The key here is p. 217. Examples and Exercises that come before p. 217 are:

- Square Roots by Newton's Method - Testing for Primality - Arithmetic Operations for Rational Numbers - Extended Excercise: Interval Arithmetic - A Picture Language - Symbolic Differentiation - Representing Sets - Huffman Encoding Trees - Symbolic Algebra

SICP teaches algorithms and data structures before that quote. And goes on to teach more about data structures without doing any of that awful OO modeling exercises you typically do in a typical Java Programming 101.

>But there's a reason why the above passage on real-world representations appears immediately after they mention modularity.

After that quote, you return to data structures. Okay, after lists, queues and tables, there is a chapter about simulating digital circuits, which is both a fairly abstract and a well defined thing. Well, we can disagree on how abstract a digital circuit is, but at least we can agree that its no fucking dog that is_a animal and has_a head and has_a leg array and methods like

    bark(int howManyTimes) {
        for (int i = 0; i < howManyTimes; i++) 
            println("woof"); 
    }

Using OOP to model real world stuff wouldn't be so bad if it would happen in the context of real problems, like simulations where you can show how to use the state pattern to model behavior. What I want to see gone is that stuff like inheritance and composition is explained with examples taken from the physical world, completely detached from the programming practice. If you use File, Directory and FileSystemEntry as examples for a hierarchy, you can demonstrate it's usefulness with concrete examples. With Dog, Frog and Animal, not so much.

I think I get why some people rage against inheritance, but I don't understand one of your remarks here.

Human isa mammal (let's say). Human is a Liskov substitute in any context requiring a mammal. What's the problem here? Is it just the fact that Mammal brings to mind a classification system which happens to be hierarchical, and you're afraid people will become too accustomed to hierarchies?

The problem is the design paradigm where you enforce an arbitrary fixed hierarchy on real-world data.

This doesn't work for several reasons:

* In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

* Your hierarchy will almost certainly have to change (you'll be wrong, or new requirements will come along). Frequent major code breakage / refactoring is the likely result. If you also need to persist data across versions, you're in big trouble.

Property / prototype based methods are in general much more flexible for real world data.

> * In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.

There may well be overlapping hierarchies, and trying to capture taxonomy with an adequate analogy to explain the concepts of inheritance to somebody is perhaps not the best way. But to say that you must never enforce an arbitrary fixed hierarchy contradicts the very purpose of inheritance in a good design.

For your particular example the correct way is to have a separate interface called "ISentient" that captures whatever methods and fields are required for sentient communication.

Most OOP languages support that concept.

So you can have a Human that inherits from Mammal, but only Human introduces the ISentient interface. Your "Robot" can then inherit from "Machine" and also introduce ISentient.

A much better way is to use interfaces for most things: use IMammal then override "procreate" so you can account for specie extrema like the duck-billed platypus class, which is a mammal that lays eggs.

Could you elaborate on how prototype based OOP solves overlapping hierarchy and hierarchy modification? It is not clear to me, and it seems actually like multiple inheritance, mixins, interfaces, and/or type-classes would address multiple hierarchies reasonably well, while I am not sure how prototype inheritance does so at all.

Exactly. It fucks everything up: As soon as you teach OO with real world stuff as examples, all they see are inheritance relationships. It is really hard to make 'em stop creating extremely complicated hierarchies in order to solve simple problems.

That is absolutely NOT my experience. People look at the real world and see concrete types, not hierarchies of abstractions.

New programmers will only try to build deep inheritance trees if they are told that's what they're supposed to do.

DO teach encapsulation of state.

I agree, with the caveat that there should be good discussion about when it's important to encapsulate state, rather than a rather blanket "always encapsulate data and methods" which is how it's often presented.

Writing complex classes which require inheritance is never a necessity of a begginer. He can only know that objects encapsulate values and methods and that's all.

When he needs inheritance he will know about it.

Why should you never try to teach objects as representations of real world things? Just curious.

Let's put it this way: you are asked to write a program that simulates the behavior of an LCR circuit. Do you create objects to represent the components of the circuit?

That example isn't specified enough to show the problem. It's either too simple or too hard. Since we're talking about a beginner, I'll assume you meant it at too simple. But even then you're assigning it to a person with a reasonably technical background. In which case, the LCR circuit is the object and you are asking for a method.

"the LCR circuit is the object and you are asking for a method"

I think that you still have the wrong abstraction here. If you are looking for a general solution, it should be one that can handle LCR circuits, mass-spring systems, etc., though that is probably too much for an introductory course. My real point is that there is nothing to be gained by modeling circuit components or even circuits as objects -- you do not improve maintainability, you do not encourage code reuse, and you do increase the amount of code that does nothing to solve the problem.

My real point is that there is nothing to be gained by modeling circuit components or even circuits as objects

Then I still find your point unclear. Why would you choose them as an exercise to introduce classes, which is what we were talking about? I agree, it's odd. Mammals and dogs, however, are a concept people can understand. As are windows and doors.

We were? I thought the question was, "Why shouldn't we teach that objects model real-world things?" The answer is that in many cases, the real-world things should not be represented as objects; I gave an example of such a case. If a student is being told that objects model real-world things and has internalized that, then when they are presented with the problem of simulating an LCR circuit, it is very likely that they will do the wrong thing and create classes for circuit components, and a class for circuits as a whole.

Further, "dogs and mammals" or "windows and doors" are extremely contrived examples. The fact that you have to invoke an artificial problem just to illustrate this point should be an indication that you are doing something wrong. On the other hand, simulating an LCR circuit is a real-world problem and one that students will probably be asked to solve as a homework assignment (e.g. in a differential equations course).

Just because some things should not be represented as objects doesn't mean that nothing should.

And mammals and dogs as a concrete example- a metaphor, if you will- is an example of a powerful way to teach abstract ideas, not an indication that something is wrong.

What I would find enlightening is how the mammal-dog relationship fails, not how there is something out there for which the model may not fit.

The problem with 'dog is a mammal' is that there's basically no obvious scenario in which you'd actually be modeling things this way unless you're trying to build some kind of ecosystem simulation or whatever. If you want to teach people, not only what inheritance is but why it's useful, you need to use a situation where inheritance makes things easier.

Here's an example that's visual: You are putting interaction widgets on the screen- they display some text, perhaps some other visual indicator, and have a button or text area or slider or something on them (there are some of each). Your base class has the setup: the window/panel/whatever-your-language-calls it, the place where the text goes, and the place where the variable widget goes. All of these widgets inherit the base class, and only differ in the user response portion. This makes it very easy to change the interaction style.

"My real point is that there is nothing to be gained by modeling circuit components or even circuits as objects"

That directly contradicts how SICP teaches it:

Our computational model of a circuit will be composed of objects that correspond to the elementary components from which the circuit is constructed. (p. 273, 2nd ed.)

Elsewhere they say:

If we have been successful in our system organization, then to add a new feature or debug an old one we will have to work on only a localized part of the system. (p. 217)

... which sounds a lot like the benefits you deny. Do you really think SICP is wrong to teach this way? I don't.

I quoted a more general passage where they introduce object modeling here: https://news.ycombinator.com/item?id=6910292. But it seems striking that you would have brought up circuit simulation as when not to do object modeling, as it is the very domain they use to illustrate the strength of the approach.

I don't know. Do you?

No, because it clutters the code. An LCR circuit is a linear system and should be solved as such; the only objects that would be relevant are those that are related to solving linear systems, and at the beginner level we probably should not be asking people to write such a general purpose solution anyway. If you start representing circuit components as objects you will just create a pile of unnecessary code that does not improve maintainability at all.

Not the grandparent, but in my view it distracts from what the code actually needs to do. OOP is a tool to structure code and data. It gives us some useful ways to deal with responsibilities, namespaces, some kinds of polymorphism, etc. We should use it in a pragmatic way, and making a class hierarchy reflect the real world often puts aesthetics above practical considerations.

Isn't it tied together? If a new programmer can't structure their code they can't write it.

You'd be surprised what kids can achieve with little more than global variables, gotos and if statements. Structure speeds things up and prevents stupid mistakes once you understand the basics, but before that point it can be overwhelming. Far more important, in myexperience, is the "programming mindset".

I agree with that. I was just remembering the first OO stuff I was taught. I think it was a person object which we then had to use to create "Bill", "Jane", etc. Constructor set stuff like eye colour, height, etc.

Then we went on to create a dating app where it would retrieve things like "all the people with brown eyes"

Reply on news.ycombinator.com