Physical Activity for Objects

Question

I have a vague notion that I could create some sort of introductory activity for Objects. There would be worksheets ("programs") to get kids (high school, in this case) to physically go through the process of isolating behavioral groupings into different people, and using message passing to solve a problem or accomplish an algorithm, but I don't have a great idea for one to actually implement.

It would be a bonus if it wasn't immediately apparent what problem the students were solving at first, but the final output created a nice "A-ha!" moment. This would allow us to talk about the benefits of dividing a problem into component/machines instead of merely into sub-functions.

Has anyone done something like this? Or does anyone have an idea for a fun, physical activity to introduce some core OOP notions?

Answer 1

If the objects are something like robots or other things that "move", like froggies, or such, then you can do things like maze solving and other interesting things. If they can move some sort of other objects by picking them up and putting them down in piles, then you can sort and such. Of course they need some sensory behavior to sense boundaries.

There are a number of scenarios available for Greenfoot for example that permit this sort of thing, either with a Java program or with student "actors".

The left hand rule for walking a connected maze is kind of fun. And there are actually sorting routines for physical objects that are unlike the usual algorithms.

But it is moving under some constraint that makes it work.

Find the resources at the Greenroom for ideas. I think the first scenario in Greenfoot involved Wombats, but the developers were then in Australia.

Alternatively, you can have the students simulate a cpu that executes the program, moving some objects on a game board. The hard part of this, however, is capturing the message passing idea of OO. That is a bit easier if the students are, themselves, objects, since speaking/asking is a lot like message passing.

Answer 2

The guy who taught me object-oriented used three very simple examples.

The thing about objects that many students find hard is that the main thing about an object is its interface. You have an interface with a contract for behavior. Any object that can satisfy the contract can, in principle, get hooked up through that interface.

So the first example he used was electrical wall sockets. You can't see the stuff behind the wall, it's information hiding. It's a type, since you can plug any electrical device in there. Even devices that are created after the socket is installed. And you can plug your device into any socket, even sockets that are installed after you got your device. And you can even do things like inheritance using things like extension cords or power bars. And you can do testing by using a circuit checker. And even limited behavior since the socket's circuit breaker may have been tripped.

The second example he used was salt dispensing at a theme restaurant. This table had a simple little salt shaker. This one had a little train that came out and dispensed salt. This one had a Ferris wheel. This one had a little cuckoo clock that popped out and gave you salt. He used this to push the idea of interface and contract for behavior. For example, he had a "my reservoir is empty" message that the dispenser would give out. You can easily make this example more complicated. So each dispenser had a "dispense" command, and a "how much in my reservoir" data getting function, and a "refill my reservoir" function.

The third example he used was the weather report produced by the local weather forecaster. This would get put in the paper and read by various people around town. The salt miner wanted to know if it would rain so he could cover the salt. The ice cream truck wanted to know the temperature to predict sales. The log flume ride wanted to know about wind because they could not operate if it was too windy. The artist at 12th and Main wanted to know when there would be a pretty sunset. And so on. So the weather forecaster accessed one part of the news paper interface to load up the weather report. Then each of the clients of the newspaper accessed a different line of the data reporting part of the paper to get the data they wanted.