Teaching Constructors: A Difficult Multiple Choice Noa Ragonis and Mordechai Ben-Ari Department of Science Teaching Weizmann Institute of Science Rehovot 76100 Israel
[email protected],
[email protected]
Abstract. We carried out research on teaching OOP to high-school students; the understanding of constructors turned out to be a major issue. This paper surveys different structures of declarations for constructors, their semantic context and their influence on programming and students’ comprehension. We found that the professional style of declaring a constructor to initialize attributes from parameters is to be preferred even though it seems difficult to learn. Other “simplerÔ styles caused serious misconceptions.
1
Introduction
A constructor is a special method which creates an object; executing a constructor creates an instance of a type (instantiation). Instantiation is a central concept because it parallels creation of an object in the real world, a metaphor that is often used in teaching. Constructors and instantiation are complex concepts which are difficult to learn and teach, but they can’t be avoided. A further complication arises in the instantiation of a class that includes attributes of another class. In this paper we focus on students’ understanding of different paradigms for constructors, though obviously other aspects such as memory allocation and syntactic differences can also influence understanding. This research was conducting using Java, though we believe that the results would be similar for other OOP languages. The different paradigms of constructor declaration will be demonstrated using a simple example, which is built using the main concepts of OOP in a way so as to avoid misconceptions identified in [1]. Then, we describe their semantic context, their influence on programming and students’ comprehension. Finally, we give our recommendations for teaching.
2
Related Work
Corradi and Leonardi [2] discuss static vs. dynamic object creation. Object creation is static before program execution, but dynamic during program execution.
2
Fleury [3], in her research on how beginners’ students understand the construction and use of objects in Java, found that students construct a rule: “The only purpose of invoking a constructor is to initialize the instance variable of an object.” El-Qawasmeh and Mahafzah [4] point out that some of the effect of the execution of a constructor is hidden even when the constructor is defined by the programmer. Textbook writers teach constructors at different stages. In Koffman and Wolz [5], the first examples do not declare constructors. Subsequently, they describe the default constructor and only much later they explain how to define constructors. Bishop [6], on the other hand, refers to constructors at the very outset.
3
The Research
The experimental course was taught to tenth-grade students with no background in computer science. The approach of the course is objects-first, and our main interest is in evaluating the possibility of replacing a procedural-programming course. The population included 19 students during the first year the course was taught and 30 students during the second year. The data about students comprehension, and their difficulties and misunderstandings was collected according to qualitative research methods by observations on all the lessons, worksheets and homework, and interviews with the students who submitted this work. The lab exercises are carried out using the BlueJ environment for teaching OOP [7]. BlueJ supports visualization of classes and objects, and execution of individual methods on objects without writing a test harness.
4
The Multiple Choice
In this section, we present one of the first examples in our course and the various constructor paradigms that we have used during the past two years. The source code of the examples is available on our web site. Class Pepper represents the vegetable pepper whose attributes (fields in Java) are: the weight, the number of pieces and its color (for which we use String type for simplicity). The methods of Pepper include mutators and accessors for each attribute, and two simple methods: cutIntoTwoPieces() which cuts each piece of the pepper into two pieces, and cutIntoNumPieces(int n) which cuts each piece of the pepper into n pieces. Class PepperSalad represents a pepper salad containing three attributes of type Pepper, each of which is intended to be of a different color: green, red and yellow. The methods of PepperSalad include mutators and accessors, and two simple methods corresponding to those in the Pepper class: cutIntoTwoPieces which cuts each piece of the pepper salad into two pieces, and cutIntoNumPieces(int n) which cuts each piece of the pepper salad into n pieces. We will describe four paradigms in each of two contexts, simple and composed classes. A class whose attribute types are primitive is called a simple class, and a class whose attribute types include user-defined types is called a composed class. The different paradigms relate to the constructor method definition and to
3
the initialization of attributes: (1) An empty constructor; attributes get default values. (2) An empty constructor; attribute values are initialized by values in their declaration. (3) A constructor method that initializes the attributes with constant values. (4) A constructor method that includes parameters for each of the class attributes; attributes are initialized by the corresponding parameters. The following table describes the four main paradigms for each of the two categories of classes. Each version is denoted by a three-letter acronym: class category (S = Simple class, C = Composed class), whether attributes are initialized in their declarations or not (V = attributes initialized by Value, N = No values in declaration), and the form of the constructor (E = Empty constructor, V = initialize attributes Values, P = initialize attributes by Parameters values). Version 1 2 3 4 5 6 7 8
-
5
S/N/E S/V/E S/N/V S/N/P C/N/E C/V/E C/N/V C/N/P
Class category Attributes initialized in the declaration Simple No values Simple Values Simple No values Simple No values Composed No values Composed Values Composed No values Composed No values
Constructor form Empty Empty Constant values Parameters Empty Empty Constant values Parameters
Comparing Paradigms
We will analyze the paradigms according to the semantic context, the operational consequences which appear when you instantiate an object and assigns values to attributes, and how students analyze and understand the application.
5.1
The semantic context
For each paradigm you can associate a semantic context based on how the application relates to a real-world problem. The creation of an “empty” object with default values (1-S/N/E, 5-C/S/E) does not correspond with the real world, nor does the creation of all objects with the same values for all the attributes (2-S/V/E, 3-S/N/V, 6-C/V/E, 7-C/N/V). Similarly, there is no real-world correspondence in the creation of simple objects in the process of creation the composed class object (6-C/V/E, 7-C/N/V). The professional paradigm (4-S/N/P, 8-C/N/P) closely corresponds with the real world, in which each attribute gets a relevant value. In the composed class it is also better to previously create its components from the simple class and only later associate them with the corresponding attributes using parameters.
4
5.2
Influence On Programming
OO programs almost invariably begin by creating objects. If we choose one of the paradigms, except for the professional paradigm, we have to execute mutator methods in order to specify a value for each of the attributes, or in order to change the constant values for specific objects. In the professional paradigm, no further actions are needed. Another issue is the constraints on the possible combination of the paradigms in a project that contains both simple classes and composed classes. Some combinations are not possible, for example, if the composed class invokes constructors with parameters, the constructor for the simple class must also have parameters. 5.3
Students’ Comprehension
In this section, we summarize aspects of students comprehension, based upon our research results, obtaining from teaching different paradigms. Some difficulties were paradigm-specific, while others were common to some or all of the paradigms. – For all paradigms: Students have difficulty understanding instantiation. Some of them thought that the declaration of the constructor method is sufficient to instantiate an object. – For all paradigms: It is difficult to understand the new statement, because it causes both object allocation as well as constructor invocation. – For all paradigms: Students had difficulty understanding the meaning of the constructor method and its place within the class. For example students said: “The attributes belong to the class, the constructor method belongs to the object because it creates an object.” There is confusion between the static class declaration which includes the constructor declaration, and the dynamic object creation in executing the constructor method. – 1-S/N/E paradigm: Students had difficulty in understanding an “empty” instantiation, they asked: “What is an empty value?” or “What is an empty creation; is there an object or not?”. – 1-S/N/E paradigm: Students forgot to invoke the mutator methods after the creation of an empty object, and before using it. – 2-S/V/E paradigm: The distinction between a class and an object is difficult for novice OOP-students. From the sentence: “Attributes are declared in the class, and attributes values describe a specific object of the class,” some students drew a wrong conclusion about constructors: “[The constructor] is an object because attributes have values, and values belong to objects and not to classes.” – 2-S/V/E paradigm: Students thought that if attributes have already been initialized with values, then there is no need to instantiate the object. One comment was: “If you are saying that attributes belong to classes and values belong to specific objects, then why doesn’t the assignment of values to attributes mean that there is an object already?”
5
– 2-S/V/E and 3-S/N/V paradigms: Students saw a false correlation between reality and the created objects. They asked: “Do all the objects have the same attribute values?” – 4-S/N/P paradigm: The complexity of the parameter mechanism makes this paradigm difficult to understand by novice students. – For composed paradigms (5–8): It is difficult to understand that the type of an attribute can be a user-defined class. They said: “The attributes of the PepperSalad are weight, number of pieces and color,” when in fact there are three attributes of used-defined type Pepper. – 8-C/N/P paradigm: Students assumed that if the component objects have already been created, there is no need to create the object of the composed class.
6
Discussion
When we combined all these criteria, we came to the conclusion that the 4S/N/P and 8-C/N/P paradigms are preferable. This preference is justified as follows: – Constructors should be taught at an early stage because they are always used, even if implicitly, so there is no advantage to avoiding explicit teaching of this concept. – The reasons to reject the 1-S/N/E paradigm are: (a) Default values are usually irrelevant to a given problem. (b) Initialization by invoking mutators is complicated, because they also require the introduction of parameters. (c) This paradigm is not consistent with the concept of instantiation. – The reasons to reject the 2-S/V/E and 3-S/N/V paradigms are: (a) Initialization of all objects with the same values rarely corresponds to the real word. (b) Assigning constant values in the class declaration confuses students. However, there are some advantages to these paradigms: They prevent accessing an uninitialized attribute, and there is no need to invoke large numbers of mutators. Between the two paradigms, we prefer 3-S/N/V, because it concentrates the initialization within the constructor method. – We prefer the 4-S/N/P and 8-C/N/P paradigms because they allow us to emphasize good OOP principles: • The constructor is very important, so it is better to expose it than to conceal it. • Initializing an object with values for its attributes is more in accordance with the real world. • Creation of simple objects before creation of composed class object is also more in accordance with the real world. • Initializing values to attributes in the constructor method avoids access to default values. • Parameters are needed anyway at an early stage for mutators, so they are not an extra burden in constructors.
6
• Assigning values to parameters in each instantiation emphasizes the creation of different objects with possibly different values. • Learning this paradigm in simple classes makes it easier to understand the property of composed classes where attributes are the objects themselves and not the attributes of the objects.
7
Conclusion
From our experience in teaching OOP to novices, we found that one of the major difficulties is to understand the creation of object by the constructor. We believe constructors should be taught from the beginning and in the common professional paradigm. This is not trivial but not impossible. The key to success is to devote sufficient time to learning basic concepts such as classes, objects, attributes and methods with parameters, and only then to study their implementation in Java. We use verbal and graphic representations of classes and objects, and the students practice instantiation and method invocation within the BlueJ learning environment. When students begin programming in Java, they continue to use the paradigm which becomes familiar. The teaching process must emphasize the instantiation process. Each object has its own set of attribute values, and we have to instantiate it accordingly, maintaining a correspondence with the real world. We believe that these principles will enable successful teaching to novice students of the constructor concept as it is used in professional programming.
References [1] Holland, S., Griffiths, R., Woodman, M.: Avoiding object misconceptions. SIGCSE Bulletin 29 (1997) 131–134 [2] Corradi, A., Leonardi, L.: Static vs. dynamic issues in object oriented programming languages. Journal of Object-Oriented Programming (October 2000) [3] Fleury, A.E.: Programming in java - students-construct rules. SIGCSE Bulletin 32 (2000) 197–201 [4] El-Qawasmeh, E., Mahafzah, B.: Poorly designed features of c++ constructors. Journal of Object-Oriented Programming (March 2001) [5] Koffman, E., Wolz, U.: Problem solving with Java. Addison-Wesley (1999) [6] Bishop, J.: Java Gently. Addison-Wesley (2001) [7] K¨ olling, M.: Teaching object orientation with the BlueJ environment. Journal of Object-Oriented Programming 12 (1999) 14–23
