Pedagogical Pattern #13
Design-Do-Redo-Redo (DDRR) Pattern
(Version 1.0)
Marcelo Jenkins
Department of Computer and Information Sciences
University of Costa Rica
P.O. Box 025216
Miami, FL 33102 USA
mjenkins@cariari.ucr.ac.cr
Introduction
This short paper describes a pedagogical pattern to teach Object-Oriented
Programming (OOP) to senior students based on a multi-language approach.
The idea is to teach OOP concepts such as encapsulation, abstraction,
and polymorphism, independently of the OOP language used. To do that,
a in Design-Do-Redo-Redo (DDRR) pattern is used, in which students
design an OOP solution to a programming assignment and then implement
it in three different languages.
Intent:
Teach OOP concepts independently of any particular OOP language.
Motivation:
It has been long argued that OOP should be taught abstractly, that is, separately from the mechanisms and constructs some languages use to implement those programming concepts. However, Students often have a difficult time understanding OOP concepts such as encapsulation, abstraction and polymorphism independently of how particular languages implement them.
Applicability:
Use the DDRR pattern to introduce several OOP concepts at the same time.
Structure:
- Students are assigned a small programming assignment specially
designed to get them acquaintance with a small set of OOP concepts.
- They first turn in the OO design using CRC cards.
- The assignment is then implemented in one OOP language
(e.g.,Smalltalk).
- Students implement the same design in a sufficiently different
OOP language (e.g., C++).
- Students form groups of 2 or 3 and implement the same design but
this time using a third OOP language. Each group is assigned a
different language (e.g., Visual Basic, Delphi, Ada 95, SQLWindows,
Flavors, Java, etc.).
- Each group fills in a table showing how their assigend language
implements the OOP concepts covered in class. The table with the criteria
is provided by the instructor already filled with the features of
the first two languages they used. Appendix 1 contains the criteria
used in the table.
- Finally, each group presents their results and analysis to the rest
of the class.
Consequences:
- Allows the students to get hands-on experience with three different OOP languages and environments.
- They obtain a language-independent design of the problem using a simple design method.
- They learn how to learn a new OOP language by their own.
Implementation:
Issues to consider:
- This pattern is designed for senior-level students who are already
proficient in at least one programming language. Its use in
introductory programming courses might be counterproductive.
- The programming assignment must be carefully defined to assure
that the students will be implementing the OOP concepts we want
to teach them.
- Giving the students a quick feedback on their work is critical.
Assignments must be returned graded quickly so they can avoid making
the same mistakes in subsequent assignments.
Example Instances:
This pattern has been used to teach:
- OOP concepts
- OO design (CRC cards)
- Smalltalk programming
- C++ programming
Experience:
This pattern has been used twice during 1995 and 1996 with a total
of 38 senior students. The results have been satisfactory, although
further improvements can be done. We have to develop better and
more comprehensive programming assignments and update our textbook.
Appendix 1: Criteria to evaluate an OOP
The evaluation table contains the following criteria:
- Encapsulation (of variables and methods)
- Polymorphism (genericity vrs. inheritance or both)
- Abstraction (degree of reusability)
- Inheritance (simple vrs. multiple, dynamic vrs. static)
- Types (typing system, if any)
- Binding of variables and methods (static vrs. dynamic or both)
- Memory management (manual or automatic)
- Syntax complexity
- Programming environment (windows, design toolkit, debugger, etc.)
- Interface to RDBMS (ODBC or otherwise)
- Language uniformity (hybrid vrs. pure OOP)