Course Overview

The objective of this course is to teach modern Object-Oriented Design.  Yes, I know that the course title is "Object-Oriented Programming".  But object-oriented programming is not programming in an object-oriented language: it’s immersing yourself in objects and taking advantage of the object-oriented perspective to create code that is readable, maintainable, malleable, and reliable.  Object-oriented programs look the same as procedural-programs “in the small”: they use essentially the same control and data abstractions.  They differ “in the large”: in the way that the code is organized, that dependencies are managed, and code is re-used.

I'm going to start by assuming that you have some familiarity with objects, inheritance, test-driven development, and refactoring.   We are going to deepen those skills throughout the quarter by working on in-class programming, assignments, and projects.  I'm going to encourage you to pair-program with partners, because our goal is to reflect on programming and design, rather than to “just do it”.

Because I want you to reflect on what you are doing, I'm going to use some languages in this class with which you may not be familiar.  The primary language will be Grace, a new O-O language that I have been developing over the last 4 years with colleagues in California and New Zealand.  Grace is designed for teaching OOP to novices, and is very much simpler than most other languages that you have encountered.  It nevertheless allows the full range of expression of all the mainstream OO idioms.  Grace also contains a dialect mechanism that is intended to allow instructors to define their own extensions and restrictions on the language to make it more appropriate for their individual teaching style.   In addition to Grace, we will also use some Smalltalk, Ruby, and JavaScript.   

Once again, the point of using unconventional languages in general, and Grace in particular, is to help you move your focus away from the language syntax and the details of programming in the small, and towards the organization of programs in the large: the art of Object-Oriented Design.   Grace will also give us scope for some interesting student projects, because the minigrace compiler for Grace is written in Grace, and because Grace contains a dialect mechanism that can be used to extend and restrict the language.

Synopsis

  1. Overview and Background: state of the team with respect to:
    1. The goals of Object-Oriented Development
    2. Test-Driven development
    3. Responsibility-driven design
    4. Code smells and Refactoring
    5. Version Control Systems
    6. Collective Code Ownership
    7. The role of design
  2. Coding Patterns
  3. Designing Object with a Single Responsibility (Metz Ch. 2)
  4. Managing Dependencies (Metz Ch. 3)
  5. Designing Interfaces (Metz Ch. 4)
  6. Structural Typing (Metz Ch. 5)
  7. Inheritance (Metz Ch. 6)
  8. Sharing behaviour using Traits (Metz Ch. 7)
  9. Combining objects using Composition (Metz Ch. 8)
  10. Designing Cost-Effective Tests (Metz Ch. 9)

We will explore each topic with a mixture of readings, discussion, mob-programming, pair programming, and homeworks.

Project

A substantial team project will be required as part of the course.  It will involve contributing to the Grace open-source code base in some way.   Possibilities include:

  1. Implement a library to provide access for Grace programmers to some useful external functionality, for example, audio, or infinite-precision arithmetic.
  2. Implement a useful library module, such as balanced trees, or priority queues.
  3. Implement a Grace dialect for teaching in some particular domain.
  4. Improve the functionality of the minigrace implementation in some substantive way.
  5. Improve the performance of the minigrace implementation in some substantive way.
  6. Improve the Grace IDE in some substantive way, such as augmenting the debugger, or providing performance monitoring tools.
The advantage of the minigrace implementation being so primitive is that it leaves lots of room for improvement.  The advantage of the current code quality being, let us say, poor, is that it's easy to make significant improvements.


Most recently modified by Andrew P. Black at 0:11 on Tuesday 31st March