Object Design Lab

Question

When I have finished introducing my students to Objects (including Encapsulation, Inheritance, Polymorphism, and a healthy dose of philosophy), I would like to give them a lab with the following criteria:

1. They should be designing a set of Objects from the ground-up. That could include designing part of the project itself (such as choosing an ecosystem or a sport to simulate)

2. The requirements of the project should be rich enough to support the use of encapsulation, inheritance, and polymorphism.

Because I want the lab to involve design of a good system, and not merely utilization of a preexisting system, I have been getting myself stuck. I want this to be an Objects Design Lab, and I'm not sure how to get started.

My classes have 15-22 kids, and they are expected to do a substantial portion of the lab work during class (with me present).

Answer 1

The basic idea is for the students to build a Model for an application that might in some larger scenario be expanded to a complete Model-View Controller application.

The suggested application is a Dungeon Game[1]. There are three basic kinds of objects: Characters, Places, Things. The Characters can move through the Places and can acquire Things and leave them behind. They do interesting things in the places: fight Monsters (a kind of Character), etc. The places are connected in some sort of, possibly dynamic, graph (map). The Things have capabilities to enhance the Characters and they can be carried from Place to Place.

However, to be successful at this you need some sort of development process. I suggest an Agile process in which you serve as Customer (Product Owner) and give them little bits of a specification at a time so that they work in small chunks (Stories) to extend a growing base.

It is a minefield to let them both specify and build the thing. On the other hand, it is nearly impossible to give them a complete spec up front. Much better to make it an agile project with someone (you) as Customer, feeding in Stories as you go. On Monday you give the students a few stories to build. On Friday you measure progress and prepare for the following week. Iterations are one week and it is fine if the stories don't all get built successfully. The learning is more important than the code.

Your stories talk about behavior. Say you describe a new kind of Character and what it's goals are, or a new kind of Thing. Students create the classes for these, but you need some sort of overriding set of Interfaces for the three basic types. Perhaps a Character can moveTo(aPlace), and can obtain a list of things in that place.

If you want them to have a chance to actually specify the world a bit you could have a discussion (open ended) on Friday in which they throw out ideas for things that you might add to the spec on Monday.

The advantage of an agile approach is that the students can be a success even if very little actually gets built. They will work on small pieces (set of stories) and have frequent successes. Otherwise they are too likely to take on big chunks and fail at those leaving chaos behind.

But you will also need to be careful that they don't take over and decide themselves WHAT to build. That is the customer's job, not the developer's. Students often have too little knowledge of the difference as most student work is underspecified so they have to fill in the blanks and get used to doing that.

You can also get them used to the small scale practices of Agile development here, such as Pairing, Test First, Stand Up Meetings and a few others along with Story-Driven-Development driven by a Customer.

If they don't do all of their work in a lab, however, enforcing the pairing rule will be harder (No code written by individuals can be committed to the base). Projects can fail when "prima donnas" build something that is inconsistent with everyone else's code/ideas.

They will likely resist the testing rule (No code written unless you have a failing test for the story first) at first. When they come to you with any question, ask to see the test or ask them to write one.

---

Two more ideas about organization.

Your students should switch partners while pairing quite frequently. As students this helps them learn to work with a variety of people. As professionals it helps them learn the code base as they only work on a part of it themselves but a new partner has seen other parts. The driver-navigator idea is also good here as the navigator has some perspective on the whole thing that the driver does not.

Also, since a Story isn't a complete specification for even a part of the app, a pair with a new story needs to consult you for more information so that they are building your idea, not making things up as the go along. Likewise, when they finish they need to get your sign-off on the work. This is just standard agile practice, but in a classroom it gives them access to your expertise as well.

---

[1]This idea comes from Ward Cunningham in a private conversation.

Answer 2

One rich area is ecosystem simulation with multiple plants, herbivores, carnivores, and omnivores.

The card game "Evolution" can serve as a very good model, with every creature being assigned various defensive and offensive capabilities. Each defensive trait would receive an corresponding offensive one. Given a few examples (such as "tall" as a plant feature that protects a plant against creatures that don't possess the "long neck" trait), this provides students plenty of chances to design their own creative universes.

Additional aspects that would he required from the model include a requirements that individual creatures either eat every round or die, that creatures only reproduce when they obtain a certain amount of food, and that larger animals can only eat smaller animals. (Any of these requirements could be overridden with an offensive or defensive trait).

It is possible to add in diseases, reproduction rates, etc. If the students have designed a modelling engine with a certain number of available traits, they can then see if they can enact worlds that obtain certain outcomes, such as:

• No creatures go extinct within 500 turns.
• Every creature goes extinct except for 2, which create an equilibrium.
• Everything goes extinct.