Object-Oriented Programming

Lecture: Tuesdays, 16.15, room not yet known. Lab: Tuesdays, 18.15, room 137.

Prerequisites

One of the standard programming languages C, C++, Java, C#, and some programming experience. The course will be based mostly on C++.

Tentative Schedule

(Probably first two lectures) General Introduction. Advantage of Access Control. Discussion of relevant language constructs: Objects, Message Passing, Runtime Method Selection. Inheritance (I view this as an abbreviation for Interface Sharing). Templates versus Object inheritance. Multiple Inheritance versus Interfaces (as they occur in Java and C#) Dangers of Inheritance. Garbage Collection. Discussion of Implementation of OO languages.
We move on to C++. References, Objects and Pointers. Difference between const and non const. Allocation/Deallocation. Memory leaks. How to find them.
Structure of a big C++ program. Namespaces, Operator Definitions, Use of Include Guards, Separate Compilation. (I think these constructs must be introduced very early) Problems with static member initialization in different files. (static initialization order fiasco)
Objects in C++. The main operations on an object: Construction, Copying, Destruction. Exchange, Printing. Operator Definitions.
Inheritance in C++. Virtual Functions. Constructors, desctructors in combination with inheritance.
Use of the STL. Iterators.
Developing Templates. Developing you own Containers. Templates and Friendship. Templates produce unreadable error messages.
Smart Pointers. Boost Library.
Singleton Objects. Static Members, Static Initialization in C++.
Object Factories.
The content of the last 3-4 lectures will be chosen in coordination with the students. Possible topics are:
- Another Programming language (C#, Java, SmallTalk)
- A concrete Project: Students can do projects on their own, or all participants work on one big project.
- Design Patterns.

Slides

Classes are tuesday, 16.15, room 103. Exercises are tuesday, 18.15, room 137.

03.03.2009. Why I will insist on use of linux in the exercises. A short guide about how to use Linux. Introduction to object-oriented programming, and programming in general. A short essay by somebody who does not like Object-Oriented Programming. Note that there will be no exercise, because it makes no sense to have exercise before the lecture.
10.03.2009. Slides about the three types of variables.
23.03.2009. Structure of a C++ program. How to build classes in C++. slides .
31.03.2009. date.h , date.cpp , testdate.cpp and the Makefile . It is only a small example, but you should read it very carefully, and make sure that you understand it. It contains the main constructions of C++ . Store all files in one directory and type make. Make small changes in the program and see what error messages you get. The comments dicusss a lot of alternative choices and you should try out some of these alternatives.
We will have a long break. Next lecture is on April 21nd, 16.15. Slides about the doubly linked lists, and the implementation: dllist.h and dllist.cpp .
Slides about containers in the STL. Example of the use of maps. Script that compiles the example.

Exercises

Exercises are on tuesday, 16.15, room 107.

This is the first exercise.
This is the second exercise. This is the program that you need for the exercise.
Number 3 . I added some advice, so please download it again. The final date for these exercises is April 21. This is a partial solution. If you manage to complete it, you will still get some points for this task. If you handed in a solution, you also have look at it, because all solutions that I saw were too complicated.
Number 4 is a continuation of number 3, this time using the class mechanism and information hiding.
Number 5 is an easy exercise about STL.

Connect Four Game

You need to understand how this game works! I discussed it in the lectures in enough detail. You need to understand the C++ constructions that were used in it. I hope that it teaches you how to write good code that has a good class design and that makes use of what the STL has to offer. When you present your final project, we will speak 30 minutes about your project, and 30 minutes about this connect four game. In your project, I want also to see high-quality, maintainable code with a well-chosen class structure. The final project is not a hacking exercise!

Final Mark

Your mark will be based on three things:

Exercises.
Understanding of the material that was covered in the lectures.
Your final project.

The marks for points 2 and 3 will be determined when you present your project.

Some Remarks about Programming Style

Programming is Communicating

Most students seem to think that the main task of the programmer is to explain to a computer how to solve a problem. This is wrong. Nearly every program is going to be updated some day. Your task is to make the work of the person who comes after you as easy as possible. This person is not going to make you compliments for your smart tricks, he does not enjoy figuring out what f1, f2, f3 mean, and he does not like to trace your clever break statements.

What should be in a class?

This is a hard but important question. Finding the right classes requires talent and experience. There are the following type of classes:

Classes originating from the problem that you are solving. You have to understand the problem that you solve. Speak with experts (or become one by yourself) and see which concepts they use.
Classes corresponding to mathematical objects, or objects from computer science. Such objects are numbers, arrays, containers, file readers, graphical objects, etc.

What's in a Name?

As a general rule: Class names must be nouns (not: readinput, but inputreader). Fields of classes must be nouns. For a method that returns a boolean, it must be possible to read the name as question. (open, isinteger, greater than) Methods that return some other object should be nouns. (Not int getrandomint( ), but int random( ). Not double computesine( ), but double sine( )) Methods that have side effects must have imperative names.

What should be in a comment?

There is no need to write obvious things in a comment, only because your teacher tells you that code has to be commented. In a comment, you write what is important but not obvious. For class comments, comments about the external interface should be separated from comments about the internal implementation. Class invariants must be listed in comments. (I think most of them are internal) Preconditions of methods must be commented. Invariants of loops must be commented, when they are not obvious.