Computer Science 272 Software II

Dr. Stephen Bloch office 112 Alumnæ Hall phone 877-4483

                email sbloch@boethius.adelphi.edu
             Web page http://www.adelphi.edu/~sbloch/
     Class Web page http://www.adelphi.edu/~sbloch/class/272/

office hours TTh 4:20–5:00 PM, and most of the day Monday and Wednesday

January 26, 1998

1 Subject Matter

This course, in a few words, is about how to organize a computer program. The skill of organizing a computer program well has several benefits. First, you’ll understand your own program better if it’s organized in a way that “makes sense”. Second, you can find and repair bugs, and make enhancements, in your program more easily if it’s organized in a way that makes it easy to modify. Third, other programmers can read, understand, repair, and enhance your program more easily if it’s organized according to these same principles.

Up to this point in your computer science career, you’ve typically been given a programming assignment, written it by yourself, turned it in, and gone on to the next assignment. This is not what happens in the real world! In the real world, most computer programmers spend most of their time, not writing new programs, but debugging and modifying old ones, including old programs written by other people. This places an additional burden on both programmers: the new programmer must be able to understand and modify somebody else’s program, and the original programmer must write in a way that can be understood and modified easily.

The programs you’ve written up to this point are typically a few dozen lines long. In the real world, most programs are thousands, perhaps even millions, of lines long. You may be able to write a twenty-line program without planning, keeping the whole thing in your mind at once. But that seat-of-the-pants approach doesn’t work for large programs. No human being can keep a thousand-line program in mind all at once without organizing and breaking down the program into manageably small, coherent pieces.

The course will start with some of the most basic techniques for program readability: naming, indentation and white space, symbolic constants and enumerated types, comments, and factoring out duplicate code. We’ll go on to the more advanced techniques needed for problems of realistic size: abstraction, encapsulation, information-hiding, and modularity.

In particular, we’ll discuss a strategy, currently very fashionable in computer-programming circles, called “Object Oriented Programming”, or OOP. To get a first impression of OOP, compare the programs you’ve written so far to English sentences. Each statement performs a particular action, corresponding to an English verb, and your main interest is what actions are performed (what “functions” are “called”) in what order. In the English analogy, you’re concentrating on verbs. The OOP approach can be thought of as concentrating on nouns instead: rather than thinking primarily about a sequence of actions, we think primarily about a collection of objects, the properties and responsibilities of each, and what can be done with each one. The experience of many professional programmers shows that this approach usually works better for organizing large programs.

OOP usually requires that the programming language contain special object-oriented features. Object-oriented languages are often invented by adding such features to an existing language: for example, the object-oriented language C++ looks like C with some extra features, Object Pascal looks like Pascal with extra features, and CLOS (an acronym for “Common Lisp Object System”) is a collection of object-oriented features added to Lisp. Other languages are less closely tied to specific non-object-oriented forebears: the Java language descends from C++, but has significant differences, while Eiffel, Smalltalk, and Logo, despite some resemblances to other languages, are essentially new.

All this would be of little importance if object-oriented languages were as similar to one another as procedural languages: if you know Pascal, you can learn C, PL/I, Modula, Ada, etc. in a few weeks with a good manual. But OOP is new enough that agreement has not been reached on its underlying principles. C++ and CLOS, to name two, differ not only in their base language, but in their whole philosophy of object-oriented programming. Each provides support for certain kinds of object-oriented programming that would be unthinkable in the other. So in this course we’ll compare several different object-oriented languages, particularly C++, Java, and CLOS (actually, we’ll use a package of OOP extensions to Scheme called “tiny CLOS”). Each approach has advantages and disadvantages, and by the end of the semester you should be able to decide which approach is most suitable to any given programming task.

2 Prerequisites

I assume that everyone in the class is already familiar with the C and Scheme languages, and capable of writing small, working programs in each. I also assume you can use the Unix utilities gdb, make, rcs, and a text editor such as vi or emacs. (These are for your benefit, not mine: I sha’n’t grade your use of Unix utilities, but I doubt you can survive the course without using them.) Finally, I assume you are capable of learning the syntax of a new language on your own. I’m willing to answer language questions in class when necessary, but I’d prefer to spend that time on more fundamental issues.

The official prerequisites for the course are CSC 270 (Survey of Programming Languages) and CSC 271 (Software I).

3 Texts

The textbook for this course, An Introduction to Object-Oriented Programming, by Timothy Budd, takes a language-independent approach to OOP. This book, the same one we used last year for this course, discusses the fundamental ideas of OOP, with examples in half a dozen different languages, without (like some textbooks) getting bogged down in notational arguments about whether to use a double arrow or a rounded rectangle in diagramming some object-oriented system. Unfortunately, Budd omits CLOS from his list of example languages, a glaring omission in my opinion, so we’ll discuss the CLOS approach in class.

We’ll work through the first 15–20 chapters of the Budd textbook, reading approximately one chapter (c. 20 pages) per lecture. Please keep up on the reading!

The definitive book on C++ is The C++ Programming Language, by Bjarne Stroustrup, who invented the C++ language, and some students may want a copy of this book. Since we’ll use the GNU C++ compiler, we also have extensive documentation on C++ and Objective C available through the info gcc command. As for Java, I’ve been quite happy with the book by Deitel and Deitel, which although primarily written for beginning programmers will still provide plenty of material for students at this level. I don’t know of a book on Tiny CLOS, but we have the on-line documentation provided with the package, and I’ve placed some on-line tutorial material about Scheme and Tiny CLOS on my Web page.

You are responsible for everything in the reading assignments, whether or not I discuss it in a lecture. You are also responsible for checking my class Web page at least once a week or so; I often post assignments, corrections to assignments, solutions to assignments, etc. there.

4 Grading

We’ll work on two significant projects, one before Spring Break and the other after. Each project will be divided into a “design phase” and an “implementation phase”, not necessarily done by the same people. When you turn in a design phase, it’ll be worth 15% of your semester grade; then you’ll switch teams and projects and do the implementation phase of another project, which is worth 20% of your semester grade. Meanwhile, somebody else will be implementing the project you designed; how well this turns out is worth 5% of your semester grade. (Some communication between designer and implementer is acceptable, but try to keep it to a minimum, as though the designer had been transferred to another department of the company and brought back for a one-day consultation.) Doing this for two projects adds up to 80%; the remaining 20% of your semester grade will be determined by a final exam.

The exam must be taken at the scheduled time, unless arranged in advance or prevented by a documented medical or family emergency. If you have three or more exams scheduled on the same date, or a religious holiday that conflicts with an exam or assignment due date, please notify me in writing within the first two weeks of the semester in order to receive due consideration. Exams not taken without one of the above excuses will be recorded with a grade of 0.

Homework and programming assignments will be accepted late, with a penalty of 1/5 per 24 hours or portion thereof after they’re due. An hour late is 20% off, 25 hours late is 40% off, etc. No matter how late you are, however, it’s better (both for your education and for your grade) to do the assignment than not to do it at all.

Programs are not abstract works of art, they are supposed to run and solve real problems. So if I get a program that doesn’t compile or run, or a program that has little or nothing to do with the problem I assigned, I will give it a zero, no matter how much time you put into it. Don’t bother turning in a program you haven’t tested yourself.

5 Ethics

The homework assignments in this class will be done in teams, to better reflect the way programming is done in the Real World. You will work with different teammates on each project.

All work on the exam must be entirely the work of the one person whose name is at the top of the page. If I have evidence that one student copied from another on an exam, both students will be penalized; see above.

6 Schedule

This class meets every Tuesday and Thursday from 12:15 to 1:30 PM, except on University holidays or if I cancel class. All dates in the following schedule are tentative, except those fixed by the University; if some topic listed here as taking one lecture in fact takes two lectures to cover adequately, or vice versa, the schedule will shift.

I expect you to have read the reading assignments (usually one chapter per lecture) before the lecture that deals with that topic; this way I can concentrate my time on answering questions and clarifying subtle or difficult points in the textbook, rather than on reading the textbook to you, which will bore both of us. Please read ahead!

Date(s) Assignment Reading Lecture Subject 27 Jan Administrivia, “what is this course about?” 29 Jan Names, indentation, constants, and types 3 Feb “Chunking”, abstraction, and information-hiding 5 Feb HW1 1 Objects vs. sequence; responsibility 6 Feb Last day to add courses

10 Feb  2  Designing with Responsibilities
12 Feb  3  Classes and methods

17 Feb Classes, Objects, and Methods in Various Languages 19 Feb HW1 due; HW2 Group presentations 20 Feb Last day to drop courses 24 Feb 4 Messages and Class Instances 26 Feb Messages and Instances in Various Languages

3 Mar  5  An example
5 Mar  6  Another example
10 Mar  HW2 due  Group presentations

12 Mar Group presentations; discuss projects 16–22 Mar Spring break — no classes

24 Mar  HW3  7  Inheritance
26 Mar  8  An example with inheritance
31 Mar  9  Subclasses and subtypes
2 Apr  10  Subclasses and subtypes

3 Apr Last day to withdraw from classes

7 Apr  HW3 due; HW4  Group presentations; discuss projects
9 Apr  11  Why inheritance is your friend
14 Apr  12  Problems with inheritance
16 Apr  13  More problems with inheritance
21 Apr  14  Polymorphism
23 Apr  15  An example with polymorphism

28 Apr Catch up 30 Apr HW4 due Discuss and present projects 5 May Discuss and present projects 7 May catch up and review for final 12 May 1:00–3:00, Final Exam