Reaction for: OO Software Development by Andrew Schulak

Since I had the privilege (along with Robert and Danah) of helping the author of this chapter lead a workshop using these techniques I will focus on what I observed.

This technique was used to train adult teachers about object oriented thinking and programming. The people in the group I was "facilitating" had not had much to any exposure of object oriented programming though it was clear they had heard of it before. Since the jukebox example had been covered in "class" we used a new one, the bank transaction example.

The first thing we did was to break down the program into objects that we thought might be useful to model. Once we had done this and agreed upon our objects we wrote them down on note cards (which would become CRC cards). One class per card was the designation. After this was done we started to talk about how the objects would interact with each other. To do this each person in the group assumed the role of an object. Then we started a scenario, a scenario where the user would deposit some money to their account.

At this point, trying to walk through the interactions, I noticed that the people in my group grew hazier about their idea of objects. Still wanting to think about actions and procedures they tended to not focus on the objects themselves. Or, when they did focus on the objects, they would decouple the capabilities of objects from the objects themselves. For example, they would want to commit some action but would not know who should act it out. One thing that was common was for all of us to argue about what object should have what capabilities. Many people wanted to have a top-level object essentially be a manipulator of all the objects: objects had no real capabilities themselves, they were just fancy data structures (i.e. a transaction object would become a holder for a string). With a few well placed questions I eventually got them to start assigning (or delegating I should say) some responsibilities to the objects. Suddenly transactions were capable of committing their own actions, etc.

My review of this process is a good one. Being able to hold on to physical objects kept reinforcing in their minds that they actually had real constructs which could do real things. Objects were things which could be manipulated and manipulate -- they weren't abstract ideas that only attached some notion of ownership to otherwise free-floating actions.

I think a technique like this could most definitely work in a CS1 type environment. Either in groups or as something taught to students to help them design by themselves. I would be very interested in trying to put this to practice.


Reactions


Amanda:

Yeah, pretty cool...I kinda remember something like this from some time ago...maybe I dreamt about it when I was in the midst of learning OOP...but I kinda remember my teacher for C++ learnin' me CRC cards good...


[BACK]