Frequently asked questions (Object-Oriented Programming)

What is this course about?

The course is about ways of organising medium to large programs that makes them easier to understand, and specifically the techniques for doing this that are called Object-Oriented Programming and supported by programming languages such as Java.

So what are the main ideas?

There are three main ideas: encapsulation, that programs should be built from objects that satisfy a coherent specification and hide the details of how that specification is implemented; object identity, that each object has a distinct identity, so that multiple objects can co-exist and interact with each other; and polymorphism, that objects that implement the same interface can be used interchangeably to give a variety of behaviours.

What will we learn to do?

Well, as a sideline, you'll learn to work with programs written in Java. But the main focus will be on learning to design, discuss and think about the design of larger programs. That's a more important skill, because it transcends any particular programming language.

So it's a course about Java really?

Weren't you listening to the previous answer? No, far from it. We'll spend little time on details of Java syntax, and ignore some parts of the language and almost all of the (very extensive) libraries, unless using them fits with our immediate purpose. Actually, I think it's a waste of time to go over programming language syntax in lectures, because people pick up the detailed rules of a language faster by copying small examples than by being told the rules explicitly.

What are the prerequisites for the course?

This is a second-level course in programming, so I will be assuming that participants are fluent at programming in a high-level language such as C, Pascal or Oberon or perhaps Java, to the level where they are comfortable with defining and using subroutines or functions or procedures. The course will not be suitable for those who do not have at least this level of programming experience.

We'll also be using some notation from Functional Programming in specifying the behaviour of objects, but that will be easy enough to pick up without prior experience.

I thought OOP was all about building programs with a GUI. Why are we starting with a dumb editor?

There's always been a close link between OOP and GUI programming, right from the early days when GUI's were first developed for SmallTalk. But building a GUI necessarily involves using a pretty complicated library, and I didn't want that complication at the start of the course. The editor provides us with an example of a non-trivial program that we can see and understand all of.

Why Java? Why not C#?

The lessons we learn in the course can be applied in any object-oriented language – and most of them can be applied even in programming languages that have no object-oriented features at all. So in one sense, the choice of language doesn't matter.

In another sense, Java is just right: it is widely portable right now, and the language and (just as important) the libraries are not tied to a particular operating system. That makes it possible for me to develop the course materials on Linux, then upload them onto the Lab machines running Solaris, and for you to use them on a Windows machine at home.

Why Java? Why not C++?

See the answer above. But C++ is also a very complicated language – more complicated than we need – which a peculiar emphasis on manual management of storage allocation. Experience shows that this is not the way to go unless it is unavoidable.

I thought OOP was all about design patterns. Why are you leaving them until next term?

It's important not to underestimate the importance of the simple things, like Abstract Data Types. Having supervised and marked a lot of undergraduate projects over the years, I'd say the vital things to learn are Control Abstraction – that is, how to structure a program using judiciously-chosen subroutines – and Data Abstraction – how to use families of subroutines to hide the details of data representations the rest of a program. Learning to do these things well takes time.

Why the emphasis on proving that programs are right? Nobody does that in industry.

We'll spend much more effort in specifying what Abstract Data Types do than in actually proving that the implementation is correct. For my part, I think that ADT's need precise specifications, because that is what allows us to understand the rest of the program without having to think all the time about how the ADT is implemented. A bit of maths is a big help in making the specifications precise. As for how much these things are used in industry, I think you'd be surprised.

What is the difference between the two versions of Ewoks?

In terms of function, the difference is that the second version Ewoks1 that is used in Lab 2 adds an undo facility. In terms of the source code,

• The basic classes Text, PlaneText, and Display are unchanged in Ewoks1, partly because the methods needed to support Undo are already present in the earlier version.
• The class Command<T> has been made generic in the type <T> on which the command acts, and the class Keymap<T> is also generic in the same way. This has been exploited by making the MiniBuffer class use an instance of Keymap to implement the mapping from keys to the actions they perform while the minibuffer is being displayed.
• In order to implement Undo, the Editor class that represents a state of the editing session has been separated from the main application class, now called Ewoks, which is responsible for maintaining the Undo history.
• Editor commands, created in the EdCommands class, now act on Ewoks; the majority are in fact commands that act on Editor, and these are wrapped in an adaptor that provides a uniform protocol for recording Undo information.