14

I remember reading somewhere that the original concepts behind OO were to find a better architecture for handling the messaging of data between multiple systems in a way that protected the state of that data. Now that is probably a poor paraphrase, but it made me wonder if there is a way of teaching OO without the (Bike, Car, Person, etc.) object analogies, and that instead focuses on the messaging aspects. If you have articles, links, books, etc., that would be helpful.

Improve this question
14
  • 6
    I believe the origin of OO was in a language designed for simulations, which was very much grounded in real-world objects. That doesn't mean OO isn't useful for unreal objects, but you can't necessarily look to its history for illumination.
    – Tom Anderson
    Mar 17, 2011 at 17:06
  • 7
    Why would you want avoid familiar, understandable, real-world objects when teaching?
    – Adam Crossland
    Mar 17, 2011 at 17:19
  • 1
    It's an interesting question, though. Whether OO is rooted in the physical not, and whether it's a good idea to teach OO in terms of the physical world or not, it would be improving to know of a productive way to teach it without reference to the physical world.
    – Tom Anderson
    Mar 17, 2011 at 17:58
  • 3
    Frankly, I'd like to see a few more examples of using objects for GUI and web-apps (so, like data models and views) since these are, after all, the meat and potatoes of development. "Real-world" objects are the crust - useful, but not always needed for a good meal
    – HorusKol
    Mar 17, 2011 at 22:42
  • 1
    @HorusKol: You have that exactly backwards. The underlying domain model is the meal. That almost always focuses on real world objects. Otherwise, why write software? The GUI or web presentation is just the serving plate. Interestingly, the presentation takes so much effort. Perhaps that says something about the primitiveness of the tools.
    – S.Lott
    Mar 18, 2011 at 9:42

8 Answers 8

Reset to default
4

The original concept of OO doesn't have anything to do with what today's OO is. (See So what *did* Alan Kay really mean by the term "object-oriented"?). Today's object oriented programing IS about creating objects like the metaphors of bicycles and houses and people, etc. I would highly recommend sticking with these because the purpose of the metaphors is to help people understand by using a concept they already understand. Help them see the correlation then help them see the differences THEN dive in to deeper things about OO.

EDIT: Today's OO is about creating fully self-contained objects whose properties and abilities are fully/partially described using various methods (functions) and attributes (references AKA variables and constants).

Improve this answer
4

You can talk about concepts of coupling and cohesion. Objects should be composed of attributes and methods with high cohesion and implicitly high coupling. They should map to the least granular operations and attributes needed for the system to work. They should also satisfy the desire to keep code as small and straightforward as possible, ie coding with maintenance and extensibility in mind.

This also prevents "object explosion", over-generalization, and wrong metaphor choice which are all common mistakes.

Improve this answer
2
  • 1
    +1 for actually giving an answer to the question instead of replying the analogy is needed!
    – Steven Jeuris
    Mar 19, 2011 at 18:01
  • 1
    I also find this is the very essence of OO. This explains OO in a way of what its benefits are instead of what it looks like. Add reuseability to the list, and I'd want to upvote this answer again. ;p
    – Steven Jeuris
    Mar 19, 2011 at 18:08
2

I wouldn't focus on the real-world objects, and I wouldn't focus on the messaging either. Rather an example I've used is in graphics, where you want to have objects that "know how to draw themselves".

If you're working in C, for example, that doesn't have OO built in, you may find it convenient to store pointers to functions inside of data objects. If you do, then you're wedging your way into OOP.

I don't like to refer to Alan Kay as if he were Moses handing down the tablets. Rather, he was trained in math and bio, I believe. As a math guy, he probably had some familiarity with Lambda Calculus, which was pretty abstract, not related to hardware. In LC, you might say everything is an "object" - like the number 0 and the number 1 are objects that evaluate to different things when given an argument. That leads into Smalltalk pretty nicely. The idea of "message" is so we can avoid talking about hardware. You could say when you call a function (or a method of an object) you are sending it a message, and when it returns, it is sending a message to you (or to your continuation). That was latched onto as a way of describing ways to communicate between programs running asynchronously on separate hardware. That's fine, but for ordinary programming it's getting carried away. To get the value of the OOP idea, you don't need to deny the relevance of the concrete task you're trying to do, or deny the concreteness of the hardware you're running on. I think teaching about OOP in terms of contrived analogies leads people to think about software design too much in terms of data structure, leading to its over-design, leading to code bloat and massive performance issues, that I have to spend time cleaning up when it gets bad enough.

Improve this answer
6
  • If you read through the discussion I referenced you'll see that it's pointed out that what Alan Kay referred to as OO doesn't have anything to do with modern OO... that's why I referenced it.
    – Kenneth
    Mar 17, 2011 at 18:10
  • @Kenneth: Here's the link. What I don't hear AK saying is that he wanted his ideas to be anyone's bible. It was just a clever idea that, in his estimation, was a really good one. He specifically refers to Hewitt's PLANNER (on which I got thoroughly indoctrinated) as an improvement. Those are nice ideas had by smart people, not by any means to be regarded as holy grails to which other things should be considered imperfect by comparison.
    – Mike Dunlavey
    Mar 17, 2011 at 18:28
  • @Mike Perhaps you are still misunderstanding what I'm saying... I referenced the discussion I did to point out that what his original ideas were DON'T apply much to today's OO. I definitely don't worship his ideas or even study them.
    – Kenneth
    Mar 17, 2011 at 19:30
  • @Kenneth: I do get wrapped up in my "hot-buttons", like when I hear people talk about true OOP, or what did AK really mean. Sorry.
    – Mike Dunlavey
    Mar 17, 2011 at 19:52
  • @Mike Alan Kay does say that he takes a lot of inspiration from his training in microbiology. In particular, his conception of an object was (and I don't recall in which of his papers/talks he mentions this) based on the cell.
    – Frank Shearar
    Mar 19, 2011 at 17:35
1

I'd claim there is little difference in using a physical object for an example and using a non physical object as an example. In code they both have the exact same parts. If we use the graphics example and teach it with Sphere, cube, cylinder, its nearly the same as using ball, box, pole.

So to teach it without using physical examples I would suggest not using any examples at all, but I don't see why you wouldn't want physical examples so my stance on the topic is

No, you shouldn't teach it without physical real world objects

Improve this answer
1

I don't see how you can avoid starting out in real-world metaphors, but you don't want to stay there. If you're doing OOP right, it quickly becomes abstract, but at that next level of understanding, the learner should be understanding objects as objects.

Improve this answer
1

Interestingly some of my favourite examples are not physical objects. Take Bank Account for example. Everyone "gets" why deposit() and withdraw() should charge the service charge, rather than relying on calling code to change the value of balance and remember to take off the service charge. Shapes on a screen are doubly intangible, and Stroustrup told me the classic "Shapes" example is one of the two oldest OO examples he knows, dating back 40 years now (the other is vehicles, now 44 years old.)

What's important is that people understand your examples right away. Elevators make a good example only with people who are all familiar with elevators. Etc.

Improve this answer
1

If you are in a programming group get a few people together and start discussing how you would tell each other to do what you need the system to do. Literally take roles in the system (you can do this on your own by just playing each role, but it is easier with a group of people. Toys help if you are on your own). Focus on what each person is doing/will do, rather than on what data they have. Doing this with people helps this focus on messages and roles because people tend to remember what they are doing but not the data they have.

Take note of what you have to ask each other to do, and what information you need to do it. Be protective of your own data, if another programmer asks for your data for something say no and ask him why he needs it (helps data encapsulation).

Improve this answer
1
  • Would add as well that this is a good way to find out if you have objects that are just data collections, because you will end up with someone with literally nothing to do. Think then where is that objects data being used and would it make more sense for that data to simply be in those objects.
    – Cormac Mulhall
    Oct 15, 2013 at 9:23
0

I think a bottom-up/metal approach might be useful. First explain C-style structs and pointers, to show how data can be structured rather than just using primitives directly. Then explain late binding and function pointers. Then explain that you can use these to build objects, which are basically well-encapsulated piles of data and pointers to the functions that are needed to operate on said data.

This explanation contradicts the conventional math/comp sci way of teaching the concept independently of the implementation, but it's the perspective that made me (admittedly someone with an engineering, not a comp sci, background) finally get OO.

Improve this answer