\documentclass[12pt]{article}
\usepackage{fullpage}

\newcommand{\tm}{\mbox{\sc tm}}

\begin{document}

\title{Computer Science 272 \\
Software II}

\author{Dr. Stephen Bloch \\
office 112 Alumn\ae\ Hall \\
phone 877-4483 \\
email \texttt{sbloch@boethius.adelphi.edu} \\
office hours ???}

\maketitle

\section{Subject Matter}
This course, in a few words, is about \emph{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, \emph{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.  \emph{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
\emph{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 \emph{thousands},
perhaps even \emph{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.

I assume you're familiar with the most basic techniques for program
readability: naming, indentation and white space, symbolic constants and
enumerated types, comments, and factoring out duplicate code.
In this course 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 \emph{sequence of actions}, we think
primarily about a \emph{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
\texttt{C++} looks like \texttt{C} with some extra features, 
\texttt{Object Pascal} looks like \texttt{Pascal} with extra features,
and \texttt{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 forebears:
the \texttt{Java} language descends from \texttt{C++}, but has significant
differences, while \texttt{Eiffel}, \texttt{Smalltalk}, and \texttt{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 \texttt{Pascal}, you can learn
\texttt{C}, \texttt{PL/I}, \texttt{Modula}, \texttt{Ada}, \emph{etc.}
in a few weeks with a good manual.  
But OOP is new enough that agreement has not been reached on its
underlying principles.  \texttt{C++} and \texttt{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: \texttt{Smalltalk}, \texttt{C++},
\texttt{Java}, \texttt{Objective C}, \texttt{Object Pascal}, and \texttt{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.

\section{Prerequisites}
I assume that everyone in the class is already familiar with the
\texttt{C}, \texttt{Pascal}, and Scheme languages,
and capable of writing small, working programs in each.  
I also assume you can use the Unix utilities
\texttt{gdb}, \texttt{make}, \texttt{rcs}, \texttt{lex},
and a text editor such as
\texttt{vi} or \texttt{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).

\section{Texts}
I've finally found a textbook that takes a language-independent approach to OOP:
\emph{An Introduction to Object-Oriented Programming}, by Timothy Budd.  This book
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.  \emph{Please keep up on the reading!}

The definitive book on \texttt{C++} is
\emph{The \texttt{C++} Programming Language}, by Bjarne Stroustrup, who invented
the \texttt{C++} language, and some students may want a copy of this book.
Since we'll use the GNU \texttt{C++} compiler, we also have extensive
documentation on \texttt{C++} and \texttt{Objective C} available through
the \texttt{info gcc} command.
Those interested in \texttt{Java} may want a copy of the book by Deitel and Deitel,
which I plan to use in a \texttt{Java} course over the summer.
 
\textbf{You are responsible for everything
in the reading assignments, whether or not I discuss it in a lecture.}

\section{Grading}
As I write this (a week before classes start), I envision five
homework assignments, each worth 10\% of the semester grade,
a midterm worth 20\%, and a final exam worth 30\%.
The number and dates of homework assignments may change;
I'll try to keep an up-to-date schedule on my Web page.

% These numeric grades will be converted to letter grades as follows:
% I'll draw a curve showing the distribution of numeric grades, and look
% for naturally-occurring ``clumps''.  For each clump, especially the
% top and bottom ones, I'll examine some exam and
% homework papers to decide what letter grade seems appropriate.  This
% method corrects for excessively hard or excessively easy assignments
% while not penalizing anybody for having genius classmates.

Exams 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.
% (and I'd
% prefer it if you let me know earlier --- you should know within the
% first week of class when all your exams are).
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, \emph{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.

\section{Ethics}
Most of the assignments in this class are to be done individually.  You
may \emph{discuss general approaches} to a problem with classmates, but
you \emph{may not copy} large pieces of programs or homework solutions.
If you do, \emph{all} the students involved will be penalized.

However, programming in the Real World is often done in teams, so I may
give an assignment or two to be done in teams.  I'll make clear which
assignments these are, and who is on your team, at the time I give the
assignment.

All work on an 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, \emph{both} students will be
penalized; see above.

\section{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 {\em vice versa},
the schedule will shift.

% In no case will an assignment be due earlier than indicated in the
% following schedule, but some may be due later; this will be announced
% in class a reasonable time in advance.  I'll try to keep an updated
% version of this schedule available online.  

I expect you to have read the reading assignments (usually one chapter per
lecture)
\emph{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.  \textbf{Please read ahead!}

\pagebreak

\begin{tabbing}
{\bf Date(s) \hskip10pt} \=
{\bf Assignment} \=
{\bf Reading \hskip10pt} \=
{\bf Subject} \kill
{\bf Date(s)} \>
{\hskip-15pt \bf Assignment} \>
{\bf Reading} \>
{\hskip40pt \bf Lecture Subject} \\
%
23 Jan \> \> \> Administrivia, ``what is this course about?'' \\
28 Jan \> \> \> Names, indentation, constants, and types \\
30 Jan \> \> \> ``Chunking'', abstraction, and information-hiding \\
4 Feb \> \> 1 \> Objects \emph{vs.} sequence; responsibility \\
6 Feb \> HW1 \> 2 \> Designing with Responsibilities \\
7 Feb \> \> \> Last day to add courses \\
11 Feb \> \> 3 \> Classes and methods \\
13 Feb \> HW1 due\> \> Classes, Objects, and Methods in Various Languages \\
18 Feb \> HW2 \> 4 \> Messages and Class Instances \\
20 Feb \> \> \> Messages and Instances in Various Languages \\
21 Feb \> \> \> Last day to drop courses \\
25 Feb \> \> 5 \> An example \\
27 Feb \> \> 6 \> Another example \\
4 Mar \> HW2 due \> 7 \> Inheritance \\
6 Mar \> HW3 \> 8 \> An example with inheritance \\
11 Mar \> \> 9 \> Subclasses and subtypes \\
13 Mar \> \> \> Catch up and review for midterm \\
18 Mar \> \> \> Midterm exam \\
20 Mar \> \> 10 \> Subclasses and subtypes \\
21 Mar \> \> \> Last day to withdraw from classes \\
25--27 Mar \> \> \> Spring break --- no classes \\
1 Apr \> \> \> Discuss midterm and project \\
3 Apr \> HW3 due \> 11 \> Why inheritance is your friend \\
8 Apr \> HW4 \> 12 \> Problems with inheritance \\
10 Apr \> \> 13 \> More problems with inheritance \\
15 Apr \> \> 14 \> Polymorphism \\
17 Apr \> HW4 due \> 15 \> An example with polymorphism \\
22 Apr \> \> \> Passover --- no classes \\
24 Apr \> HW5 \> 16 \> Templates \\
29 Apr \> \> 17 \> Visibility and Dependency \\
1 May \> \> 18 \> Application Frameworks \\
6 May \> \> \> I may be at a conference \\
8 May \> HW5 due \> \> Catch up and review for final \\
13 May \> \> \> 1:00--3:00, Final Exam \\
18 May \> \> \> Commencement \\

\end{tabbing}

\end{document}