Interview Two

The keyword 'private' was not seen by her as motivated by security, but maintaining object field values in valid states - the normative view. She said that her understanding of 'interface' was weak, and was reassured that several students had this problem and that a better understanding would come after seeing more examples.

Her understanding of the term, 'abstract' was normative, as was her understanding of static, and she quotes the Math class as an example of static, but something interesting arises. A class hierarchy, with an abstract base class and 3 non-abstract desendant classes is being discussed:

Suppose we programmed it, and we missed out the word abstract, would it still work, or what?

Umm, possibly umm .. the um would the methods in it have to be defined if it wasn't abstract, I'm not sure.

Would they have to be defined?

Well in the

Ah well OK would they have to be defined? Er what do you think?

Um if err if the sub-classes can still be an extension of the base class which isn't abstract, I'm not sure if that is possible

162

I'm not sure - is it possible that a super-class could not be abstract but still have sub-classes that extend it?

Oh OK the answer to that question is yes

OK

They can be

The interview then developed as a recap of the idea of inheritance, confirmation that base classes did not have to be abstract, and a discussion of what was gained by the use of the 'abstract' keyword.

Consideration of 'the Game' (see 8.2.2 and Appendix One) showed that for her, identifying classes and objects was difficult, and that the unassisted approach was procedural, but that given a suggestion of objects involved ( human player and robot) she was able to outline appropriate classes, including a hierarchy with an abstract base class.

Interview Summary

At this point the student:

 had some awareness of the ideas of inheritance and 'abstract'  knew they were related

 was unaware that inheritance does not depend on the base class being abstract - she thought base classes must be abstract

 was aware that she did not know

 could reason along the lines of ' if inheritance does not depend on abstract then .. but otherwise …'

Her belief that base classes had to be abstract is an over-generalization - she had seen an example where a base class was abstract, and had concluded from that that base classes had to be abstract.

163

She is able to apply logical reasoning to her understanding, in that she can say 'if .. then I think .. otherwise I think ..'

8.4.3 Interview Three

Jennifer had been ill before Christmas, and this interview was during the same week as Matthew's fourth interview, where the new topic area was starting GUI programming with Swing.

Previously her grasp of the interface idea had been weak, and so the line of questions pursued whether this was now clearer in the context of concrete use

Can you remember anything about ActionListener?

Well it um it um like takes note of what the user, how the user interacts with the program, and it does certain things based on what how they interact with it, like through um mouse clicks and things

OK so if you've got a button

Yeah

on there - this thing called ActionListener, do you know what kind of thing it is?

Is it a um can't think is it a (11 second pause) a err I can't think of the word, like there's a something there's a sub-class of it, I've just forgotten the word

Is it interface?

Um..

Or no? (laughs)

So interface is not the word you were thinking of?

No

Ah that's interesting. So what is the word you are thinking of?

I don't know.

Not class,

Its like something which some things can be a sub-class of, can't think of the word.

Well that would be a base class or a super-class or an ancestor class?

164 Yeah?

are sub-classes of that - I wasn't sure if it was a class or interface

OK

What is happening is that the hierarchy surrounding these interfaces (which has EventListener as a base, with sub-interfaces ActionListener, MouseListener, WindowListener and others) has been mistaken for the typical hierarchy of base and sub- classes, leading her to think of these as classes rather than interfaces.

The interface idea is pursued directly:

OK so if I ask you a question - what is an interface? what would you say?

Its um.. it’s a declaration of all the methods that the classes that implement it should um should write out

which is essentially a text-book answer. So although there is some confusion with specific cases, the general notion is well-grasped - the opposite of Matthew's situation. But she does describe the idea of ActionListener in human terms - it um like takes note of what the

user, how the user interacts with the program,

Also she shares Matthew's appreciation of the concrete visual nature of GUI programming:

How do you feel about graphics programming and Swing is it er

I think its slightly more interesting than what we were doing last year because you can see something that whereas with the other ones you could tell that it worked because it produced the output that you were expecting but you can't really um I think its more interesting to actually like see something visually than just..

OK

Her concept of an object involves the term instance:

What do you think an object is? What would you say?

It's an instance of a particular class. You create.. you can create a new object which has methods defined in the class of the object

165

Yeah.

Yeah? So what's a class then?

It's a series of methods that can be called when a new instance of the class is created.

OK so you have methods, you might also have fields, what are they all about?

They are variables that the object would need to use and work with.

This notion of a class bears some resemblance to that of Matthew's, as a library of functions which an object can call - rather than the object having those methods.