Students' Understanding of Selected Aspects of Interface Class in Java

Published Online September 2013 in MECS

void setGestationPeriod (int days) { this.gestationPeriod = days;

} int getGestationPeriod (){ return this.gestationPeriod;

}

} class Shark extends Fish implements Pregnant { int gestationPeriod;

void setGestationPeriod (int days) { this.gestationPeriod = days;

} int getGestationPeriod (){ return this.gestationPeriod;

}

}

It should be stressed that since dogs and mice are the only descendants of the abstract class Mammal, the implementation of the Pregnant interface should be located at the Mammal class. However, since sharks do not inherit from mammals, a separate implementation of the Pregnant interface has to be added to the Shark class, although the implementation is identical.

Addressing properly the questions in this cluster requires one to understand the principles of class hierarchy in the context of interface classes. One has to be able to decide where to implement the interface class along the class hierarchy in a way that avoid redundant code duplications.

4)    Interface class and polymorphism

The two questions in this category address the students' ability to exchange views of an object from its interface type to its object type and vice versa as needed.

Question 8 addresses the ability of students to use a proper reference type to access specified methods. More specifically, one has to be able to perform a casting operation from a base class type to an interface type in order to invoke the interface's methods.

Question 8: Please provide an implementation of a method that takes a Flying object and displays its max flight height. The method will also display the animal's weight, in case object is an animal.

Expected solution to question 8:

void someMethod(Flying obj){

(obj.getMaxFlightHeight());

if (obj instanceof Animal)

System. out.println

(((Animal)obj.getWeight());

}

It should be notified that obj is accepted by its interface type and not by its class type. Therefore only the interface methods can be accessed via obj. Any other method of the object that has to be invoked must be preceded with a proper casting operation. However, it is not safe to perform a casting operation without first examine the type of obj. For example, one could implement a class representing planes, and choose to implement Flying interface within it. Obviously, Plane do not inherit from Animal, and casting obj to Animal without first examine its type may result in severe error.

Similarly to the previous question, question 9 addresses the ability of students to use a proper reference type to access specified methods. In this case, one has to be able to perform a casting operation from an interface type to a class type to in order to invoke the class methods.

Question 9: Please provide an implementation of a method that takes an Animal object as a parameter, and displays its weight. If the animal provided is a hunter, it also displays its favourite prey.

Expected solution to question 9 :

void someMethod(Animal obj){

System. out.println

(obj. getWeight());

(((Hunter) obj.getFavouritePrey()); }

It should be notified that obj is accepted by its base class type that already includes the weight attribute and related methods. Therefore, the weight-related methods can be accessed directly via obj. However, not all animals are hunters; therefore a proper casting to Hunter interface is required in order to invoke the methods related to it. As in the previous question, it is not safe to perform a casting operation without first examines the type of obj, and an examination if obj is a hunter precedes the casting operation.

Proper solution to question 9 requires one to be able to demonstrate mastery in the principle of polymorphism in the context of interface classes. It requires one to be able to properly handle an object based on its reference type. Namely, given that the reference used is of an interface type, only methods declared in the interface can be accessed. One has to perform a proper casting to another type of the object if he wishes to access other methods of it. Also, when the reference used is of a base class type that did not implement the interface, the methods defined in the interface cannot be accessed through it, and unsafe casting operation will fail.

The complete solution of the questionnaire, including all classes and interfaces involved are presented in figure 2. As shown, Endangered and Vegetarian are the solutions for questions 1 and 2 accordingly. Licensed is implemented by Dog class that adds one attribute to support the implementation of the methods involved. Flying and Hunter are implemented by Hawk class that adds two attributes to support the implementation of the methods of these two interfaces. PharmaExperimenter is implemented by Mouse and Salmon classes. Each of these classes defines different type of attribute to support the implementation of the interface's methods since each provides different implementation as required. Swimmer is implemented by Fish class, since swimming is ability common to all kinds of fish. For that matter Fish class adds one attribute to support the implementation of the methods involved. Pregnant is implemented by Mammal class and Shark classes. Since pregnancy is ability relevant to all mammals, it is implemented in the Mammal class. Since Shark is not a mammal, it must also implement the interface. Both classes add an attribute to support the implementation of the methods involved, and the implementation itself is identical.

• IV.    RESULTS AND DISCUSSION

In the following discussion we present: (a) informal definitions of interface class as provided by the study participants (the students' responses to part A question); (b) analysis of the students' solutions to the nine questions that were classified to various aspects of interface class (Table 1); (c) analysis of the students' reflections from the informal interviews regarding their perceptions of the interface class.

A.    Informal definition of interface

In the first question of part A the students were asked to provide an informal definition of an interface, and specify its possible uses. The results obtained concerning the informal definition of an interface and its possible uses were analysed and categorised into the following categories: correct, semi-correct and incorrect. In this section, we elaborate on these categories:

Licensed

Vegetarian

Endanger

Swimmer

Flying

getNumber() setNumber()

getAmountOfPlants()

setAmountOfPlants()

getMaxDepth() setMaxDepth()

Pregnant

getMaxFlightHeight() setMaxFlightHeight()

I I

I

P harmaExperi menter

Hunter

getMedicines() setMedicines()

getGestationPeriod) setGestationPeriod)

getFavoritePrey() setFavoritePrey()

T

Animal weight getWeight() setWeight()

Mammal

Fish

gestationPeriod

getGestationPeriod() setGestationPeriod()

Bird

maxDepth

getMaxDepth() setMaxDepth()

Dog

Mouse

Penguin

Hawk

Shark

Salmon

licenseNumber

medicineList

maxFlightHeight prey

gestationPeriod

medicine

getLicenseNumber() setLicenseNumber()

getMedicines() setMedicines()

getMaxFlightHeight() setMaxFlightHeight() getFavoritePrey() setFavoritePrey()

getGestationPeriod() setGestationPeriod()

getMedicines() setMedicines()

Figure 2: Class hierarchy and interfaces

1)    Correct definitions

Four students provided a definition that refers to the most significant aspects of an interface and it uses. The following definition is a variation of the answers provided: (1) “a special class that has no attributes (beside constants), and may contain abstract methods that other classes which implement this special class must provide an implementation for those methods. A class may apply as many interfaces as needed. Its main purpose is to enforce unity on the classes that apply it, and allow for them to be handled them in the same manner" .

2)    Semi-correct definitions

Forty-one students provided either a partial definition of the interface concept or a partial list of possible uses of it. Some definitions did not include the explicit specification that a class may implement multiple interfaces. Some others did not include the explicit specification that multiple classes may implement the same interface, each providing a different implementation. Others did not refer to the possibility of having constant variables as part of an interface.

As for the possible uses of interfaces, most students did not refer to the unity enforced by the interface method’s definitions on the classes that apply it. Many others ignored the possibility of handling different classes that implement an interface in the same manner (i.e. using a reference of the interface type). While some indicated that interface is a substitute to the multiple inheritance that was prohibited in Java, others ignored this aspect and did not provide any explanations regarding the need for this kind of construct.

3)    Incorrect definitions

Five students provided incorrect definitions. Some students omitted the requirement for the method declared within the interface to be abstract. Others enabled the definitions of variables within the interface. Another incorrect definition referred to an extra restriction concerning the ability of a class to implement one interface at most. These students did not provide any possible uses of interface.

To conclude, the large number of semi-correct and incorrect definitions demonstrates only partial understanding of the interface concept. We may state that the above partial and incorrect definitions stem from several reasons: (a) confusing prior knowledge regarding related concepts such as abstract classes with interfaces; (b) forgetting some of the definition's constituents due to the time that has passed since they were engaged with interfaces; (c) partial understanding and assimilation of the interface concept.

B.    Students' solutions and typical mistakes

In what follows we present analysis of the students' solutions according to the aspects specified in Table 1. In Table 2 we present the percentage of correct solutions and in the following subsections we discuss common mistakes provided by the students according to the examined aspects of interface class.

T ABLE II: DISTRIBUTION OF CORRECT ANSWERS

Examined aspect	Question no.	No. of correct solutions
Definition	1	50 (79%)
	2	58 (92%)
Implementation	3	57 (90%)
	4	52 (83%)
	5	48 (76%)
Hierarchy	6	45 (71%)
	7	40 (63%)
Polymorphism	8	25 (40%)
	9	26 (41%)

1)    Definition

50 out of 63 (79%) provided fully correct answer to the first question. As for the other 13 students, 2 students did not provide any solution, 7 provided a definition of the required interface class but added unnecessary methods. The following is a variation of this solution:

interface En dange red { boolean isEndangered(); }

The students who provided the latter solution were instructed to provide an interface and did so, but they felt obligated to add a method. They did not want to provide an interface with nothing inside it; hence they provided a declaration of a method that returns whether or not the animal is endangered. Obviously, such a method is redundant, as any class that implements

Endangered will return true. This may point towards the students’ difficulties in understanding that interface may not include methods and yet may be useful for tagging objects.

Four students ignored the explicit instruction to use interface to represent endangered animals, and suggested adding an abstract method to the Animal class that returns true or false regarding whether or not the class represents an endangered species. This method then must be overridden in Animal concrete successors.

58 out of 63 (92%) provided fully correct answer to the second question. As for the other 5 students, 3 of them provided a faulty definition of the required interface class including both methods and the amount attribute which is obviously not allowed in an interface class. Surprisingly, the methods declared remained unimplemented in these faulty solutions. One student provided a partial solution omitting the setAmountOfPlants() method. One student provided a definition of the interface and included a complete implementation of the methods inside the interface.

Obviously, implementing methods and declaring member variables are not feasible within an interface. We may infer that the above students did not understand the concept of interface at all.

According to the above results (questions 1 and 2) it can be concluded that most of the students were able to provide correct answers referring to the aspect of defining an interface class. However, minority of them demonstrated difficulties such as adding attributes to an interface, implementing the methods in the interface class, and partial declaration of the required methods.

2)    Implementation

57 out of 63 (90%) provided fully correct answer to the third question. As for the other 6 students, they provided a faulty implementation of the Dog class omitting the licenseNumber attribute. This omission did not prevent them from using such a variable in the implementation of the methods. Maybe if they were using a code editor they would be notified on the problem and correct it.

52 out of 63 (83%) provided fully correct answer to the fourth question. As for the other 11 students, 3 students did not provide any answer, 5 students provided a faulty solution in which the Hawk class declared on the implementation of only one interface of the two required as follows:

class Hawk extends Bird implements Flying or class Hawk extends Bird implements Hunter

These students also omitted the implementation of the interface which was not declared, and implemented only the methods of the declared one. Another student also provided similar solution in which only Flying interface was declared, however, he implemented also the methods required by the Hunter interface, although not declared in the class definition. The other 3 students provided another faulty solution in which they set

Hawk's base class to be of type Flying, instead of type Bird, and added the Hunter in the implements-clause as follows:

class Hawk extends Flying implements Hunter { ... }

These errors may point on the fact that these students do not realise that a class may implement multiple interfaces, and that an interface cannot serve as a base class for another class. These mistakes are not only syntactic since they require a high level of understanding of object oriented concepts, which presumably not all students possess. To be precise the students do not consider the importance of the class hierarchy. Omission of the Bird class from being Hawk's base class results in hawks that are not part of the birds' family (or of animals' family, implied).

48 out of 63 (76%) provided fully correct answer to the fifth question. As for the other 15 students: 3 students did not provide any answer; 2 students implemented the methods inside the interface class and added "implemets PharmaExperimenter" clause in the Mouse and Salmon classes; 10 students provided solutions which were erroneously implemented. Namely, they did not distinguish between the different implementations required in the two classes. They provided identical implementations to both.

According to the above results (questions 3-5) it can be concluded that many of the students were able to provide correct answer referring to the aspect of implementing an interface class. However, part of them demonstrated difficulties such as omitting required attributes in the classes that are necessary to support the implementation of the methods, implementing only one interface instead of two required, implementing identical behaviour of the same interface in two different classes although dissimilar implementation was expected. Some of these difficulties can be attributed to the students' habit of relying on the automatic correction of the development environment and hence not paying enough attention to these faults.

3)    Hierarchy

45 out of 63 (71%) provided fully correct answer to the sixth question. As for the other 18 students: 4 students did not provide any answer; 14 students implemented the interface in both classes Shark and Salmon.

40 out of 63 (63%) provided fully correct answer to the seventh question. As for the other 23 students: 4 students did not provide any answer; 19 students implemented the Pregnant interface only in the Mammal class. Among them 5 students changed the hierarchy in a way that Shark extends Mammal instead of Fish, while the other 14 students simply ignored the part of the question related to sharks.

According to the above results (questions 6 and 7) it can be concluded that approximately two-thirds of the students were able to provide correct answers referring to the aspect of implementing an interface class in the context of class hierarchy. However, approximately third of them demonstrated difficulties such as implementing the interface in an identical manner at the lowest level of the hierarchy (i.e., the concrete classes) instead of implementing it at a more abstract level (i.e., the common ancestor), changing the hierarchy in a way that classes that wishes to have abilities already implemented in a certain class must extends this class instead of extending their current base class. It should be stressed that in this case the class hierarchy was given to the students and they had to use their knowledge to properly implement interface class in the given context. However it is well known that in cases they had to construct the class hierarchy as well they encounter more difficulties [7].

4)    Polymorphism

25 out of 63 (40%) provided fully correct answer to the eighth question. As for the other 38 students: 10 students did not provide any answer, 15 students invoked the getWeight() method without proper casting, as follows:

void someMethod(Flying obj){

System. out.println

(obj. getMaxFlightHeight());

}

The obj parameter is of type Flying and therefore cannot be used to invoke the getWeight() method. However, the object pointed at by obj may include a getWeight() method, and a casting of obj to type Animal is required in order to access it. 13 students indeed performed a proper casting to type Animal as follows:

System. out.println

((Animal)obj.getWeight());

However they did not precede a testing operation using the instanceof operator to ensure that the object is of type Animal. Without the testing a runtime error of type ClassCastException can occur. For example, if obj is of type Airplane which implements the Flying interface but is not a successor of Animal, the casting will fail. Avoiding such an error requires a deep understanding of the polymorphism principle in the context of class hierarchies and interfaces. The above results are in line with [5] who found that students have difficulties in understanding polymorphism in general and casting between types in particular.

26 out of 63 (41%) provided fully correct answer to the ninth question. As for the other 39 students: 10 students did not provide any answer, and the other 29 students provided solutions with errors similar to those of question 8 concerning proper casting. 18 students failed to perform a proper casting to the parameter before invoking the getFavouritePrey() method, as follows:

void someMethod(Animal obj){

System. out.println

(obj. getWeight());

System. out.println

(obj. getFavouritePrey());

}

Unlike the previous question, the method's parameter is of type Animal, which is the base abstract class of the given hierarchy. Since not all animals are of type Hunter, the object must be checked as being of that type (using the instanceof operator) before one can invoke the getFavouritePrey() method. Accessing the later method also requires a proper casting to Hunter. 11 students performed proper casting to Hunter, however, they did not precede a testing operation using the instanceof operator to ensure that the object is of type Hunter. This is in line with [6] who found that students have difficulties in dynamic binding in the context of proper casting.

According to the above results (questions 8 and 9) it can be concluded that approximately one-third of the students were able to provide correct answers referring to the aspect of polymorphism in the context of interface class. Approximately two-thirds of them demonstrated difficulties such as accessing methods without performing a proper casting to the type that enables desired access, performing unsafe casting from interface to class and vice versa without examining first the type of the object at hand. This is in line with [10], and [6] who found that students have difficulties related to class inheritance and polymorphism.

To summarise, most students demonstrate good understanding concerning the definition and implementation of interface classes. This understanding is demonstrated by their ability to define interface according to the requirements, and implement given interfaces in one or more concrete classes. As a profound understanding of the infrastructure of interface and its relations to principles of polymorphism and class hierarchy is needed, the number of students who demonstrate such an understanding decreases. Specifically, in case that: (a) several interfaces are involved, or some classes need to implement an interface; (b) casting is needed to access methods belong to a specific type; (c) abstract classes are involved or an interface with no methods appears, the number of the correct solutions decreased significantly. These results strengthen the findings resulting from in part A of the questionnaire, in which many students failed to provide good definitions that encompass the various aspects of interfaces. The upshot of such misunderstandings is the students' unsatisfactory results when using, designing and implementing interfaces [1].

• C.    S 19B tudents’ reflections on the questionnaire

After the students had finished answering the questionnaire we conducted informal semi open interviews with twenty six of them, in which they were asked to provide reflections concerning their performances on the questionnaire. Using analytic induction [20] and content analysis [21] in reviewing the entire corpus of data to identify themes and patterns of the focal points of the study, the students’ reflections were classified into the following categories: the essence of interfaces; the complexity embedded in the interfaces versatility; and lack of experience with interface programming. In this section, we elaborate on the students’ reflections regarding each of these categories.

1)    The essence of interfaces

Some students provided reflections similar to the following, concerning the essence of interfaces:

Dafna: “I do not use interfaces in my programs, unless I'm specifically required to do so. I do not find it useful, and to tell the truth I never understood what it is good for. If one wants to implement some methods in a class you may do it without employing interfaces, so why bother?”

Gideon: “I totally misunderstand the concept of interface. If I want something to be abstract I use abstract classes. In what sense are interfaces better? They do not even allow defining data members!”

The students consider interfaces as not being useful. They confuse them with abstract classes and cannot understand the difference. They cannot think of a problem in which interfaces would be their best solution, and they avoid using it. The above excerpts point towards the students’ misunderstanding of the essence of interfaces. As a result of this misunderstanding, the students (a) do not find it useful; (b) do not use it unless forced; (c) bypass employing interfaces by using abstract classes instead. The students’ misunderstanding may stem from several reasons: (a) insufficient time dedicated to the learning of interfaces; (b) insufficient exposure to examples that demonstrate the unique advantages of interfaces over other object oriented mechanisms such as abstract classes. (c) lack of continual exposure to interfaces in various courses. The students’ misunderstanding concerning interfaces was reported by [1], who found that interfaces are among the most difficult concepts for students to understand when they study object oriented programming.

• 2)    21B The complexity embedded in the interfaces versatility

Some students provided reflections similar to the following, concerning the complexity embedded in the versatility of interfaces:

Alex: “The use of the 'instanceof' operator is not difficult to me in the context of a class hierarchy, but I did not remember that it works with interfaces.”

Ruth: “The casting operations are very difficult to me. The rules are not intuitive. I do not understand why one would use a reference to 'Animal' when you actually want to treat the parameter as 'Flying', or vice versa. The questions concerning the casting were artificial.”

David: “I couldn't solve the problem concerning the Hawk that is both 'Flying' and 'Hunter' since I did not recall that a class can implement more than one interface . ”

Gal: “The first question regarding the 'empty' interface confused me. I added a method to the interface not because they asked for it, but because I couldn't leave the interface empty. It seems odd to do so, and I even thought it was illegal. Isn't it?”

The above excerpts refer to the versatility of interfaces, which makes it difficult to apply it properly in various contexts. Alex refers to the polymorphism aspect of interfaces and his difficulties expressed by his inability to tie together the instanceof operator with the interface type. This difficulty may stem from his misunderstanding that implementing an interface is similar to extending a base class. Ruth refers to difficulties stemming from another aspect of working with interfaces. She finds it difficult to perform casting operations required to handle an object through different views. Namely, when an object is accessed by Animal reference she had difficulties in switching the view for that object to Flying (via casting operation) in order to access the getMaxHeightFlight() method. David raises an additional difficulty referring to a third aspect of interface which concerns the possibility of one class implementing multiple interfaces. This difficulty may stem from his faulty analogy to class inheritance in which only one base class is allowed. Gal refers to another aspect of the use of interfaces, which is concerned with tagging objects via interfaces. Tagging is used when one has to distinguish between objects based on some property. A known use for tagging in Java is the Serializable interface which does not contain any method declarations and is aimed at being implemented by classes which permit serialisation of their objects to/from input/output streams. These difficulties are in line with [6] who found that students have difficulties in understanding and applying various issues regarding inheritance and polymorphism.

3)    Lack of experience with interface programming

Some students provided reflections similar to the following, concerning their lack of experience with interface programming:

Dorit: “Interfaces are sophisticated. I think that professional programmers use them, but I'm just a beginner. I cannot think of a situation I would consider using it to solve a problem. Maybe after I gain more experience I'll find it useful".

Boris: “I do not remember that we paid much attention to interfaces when we learned object oriented programming. The lecturer explained its purpose, and we even practiced it, but we practiced the use of regular and abstract classes a lot more.”

Ron: “I do not feel I understand interfaces. I remember we studied it, but I do not remember much. It is probably not so important, otherwise we would use it more often, and I wouldn't forget how it works. I do not remember I ever used it again in successive courses.”

From the above excerpts we can learn about possible explanations why students face difficulties when using interfaces properly. Dorit attributes her difficulties to both the complexity of interfaces and her minor experiences as a programmer. Boris, on the other hand, attributes his difficulties to the small amount of time dedicated to the learning and practicing of interfaces compared to the time dedicated to the learning and practicing of class inheritance. Ron refers to the discontinuity of practicing interfaces in successive courses. As a consequence he forgot how to use it properly, and considers the issue to be less important than other object oriented constructs. No doubt intensive and continual practicing may raise the students' comprehension of the concept under study. It is desirable to practice interfaces as well as other important programming constructs in successive courses, and in stressing the possible interrelations among them. Loftus et al. [22] reached the conclusion that most graduating students cannot design systems properly. Therefore Hu [12] suggests rethinking the pedagogy used to teach object orientation. He raises the following questions: (a) Where, when, and how can inheritance and polymorphism be learned in a truly problem-solving environment? (b) Would it be advantageous for students to learn problem solving with object aggregation before they learn inheritance and polymorphism? (c) Should the interface construct be introduced before class inheritance (thus, students would be “forced” to think in terms of polymorphic implementations of an interface)?

• V.    CONCLUDING REMARKS AND IMPLICATIONS TO EDUCATION

In this paper, we have presented and analysed the understanding of college students’ concerning various aspects of the concept of interface class. The results obtained reveal that most of the study participants understand how to properly define and implement interface classes in concrete classes. Nevertheless, few of the students demonstrated difficulties in defining an interface class with no methods; in implementing multiple interface classes in one concrete method; and implementing a single interface class in different concrete classes. As to understanding of the use of interface classes in a given class hierarchy only two-thirds of them demonstrated a proper understanding. The other third had difficulties in implementing an interface within an abstract class together with separate implementation in additional concrete class. As for the polymorphism aspect, only one third of the student was able to change views of the object from one type to another. The other two-third were accessing methods without performing a proper casting from its 'class' type to its 'interface' type and vice versa. These results are consistent with previous research regarding the object-oriented design capabilities of novice programmers [6, 7, 23], and regarding the use of interfaces during object oriented design and implementation [10].

There is no doubt that the interface concept enables the programmer to design more flexible and modular computer programs. Nevertheless, the time devoted to it in the MIS curriculum is minor, and as a consequence the students have difficulties in understanding it profoundly, and in using it properly. Usually, this topic is studied towards the end of the second programming course (Object Oriented programming), after learning the concepts of class inheritance, abstract classes and polymorphism. Difficulties in understanding these issues result in difficulties in understanding the interface. Moreover, the students are not exposed enough to interfaces in other contexts other than the objected oriented programming course, and hence tend to underestimate its value. Therefore, to facilitate the students' understanding of the issues involved we suggest the following: (1) incorporate the issue of interface class together with abstract class, emphasizing the similarities and the difference between them; (2) dedicate more time to teach interface classes. The extra time will be devoted to the practice of advanced properties of interface classes in order to raise the students' awareness to their advantages; (3) emphasize the contribution of interface classes to the quality of the code in general and to modularity and flexibility in particular, by providing an example in which one interface (e.g., interface List) can be implemented by two concrete implementations (e.g., class ArrayList and class LinkedList) and can be used interchangeably without further modifications in other parts of the code; and (4) add tasks involving the use of interfaces in advanced programming courses, in order to demonstrate its importance and relevance in other contexts (e.g., data-structures, algorithms, distributed systems, etc).

Furthermore, we recommend on spiral learning [24] of the interface concept. At first, even before introducing the class concept, the interface concept cab be introduced as a general declaration of some capability, including only a collection of related methods without an implementation. Then, the course moves on to classes and their implementation. The next time interfaces can appear is when the polymorphism concept is presented. It can be used as a parameter type to some method, and the students are presented again with the interface concept and its uses. The course moves on to abstract methods and classes, and then the interface class should be represented with compare to the abstract class construct. It is now the time to specify the advantages of using interfaces, specifically their flexibility (i.e., any class can implement them) and their modularity (i.e., any concrete implementation of it will fit in). After that, combinations of interfaces and abstract classes should be presented, and a discussion of the contribution of each construct to the solution should take place. The use of an interface to label classes can be also presented and discussed in a separate lesson. In the following courses

(e.g., data structures, distributed systems) the educators should use interfaces in their examples, and require the use of them, this way the students would have a chance to revisit the concept, and to internalize the advantages of using it.

Finally, we believe that further research with a large number of participants should be conducted in order to substantiate our results.