CSC323 2010S, Class 09: Design and More Design

Overview:
* Beautiful Code: Emacsspeak.
* Thinking About Object-Oriented Design.
* Preliminary Project Discussions.

Admin:
* Incomplete submission of questions on readings.  Reasons?
* For next class (optional): Come up with a possible project, and think
  about how it can use inheritance, polymorphism, and encapsulation.
* Readings for Thursday: Python Unit Testing Framework & Beautiful Code 7: Beautiful Tests.
* There is a discussion on next year's non-offering of networks today at 4:15.
* EC for Wednesday's panel on Open Information Culture.
* EC for Thursday's convo.
* EC for Thursday's CS extra: Tony Pan on his internship at Microsoft.
* EC for Friday's CS Table: No Silver Bullet

EmacsSpeak
* Beauty?
  * Scripting languages like TCL
  * Pipes
  * Bushiness can be beautiful - possible to add features w/o breaking 
    program.
  * Auditory icons.  (Beautiful design/neat concept.)
  * RSS feeds
  * The Emacs LISP extension framework.
  * Emacs calendar as auditory
  * "Painless" access to online information
* Ugliness?
  * To the untrained eye, even to the Scheme-trained eye, EmacsLISP
    can be hard to read.
  * Fragility is dangerous if you rely on the program you're writing
    to do your work.
  * Having to parse changing HTML pages.
* Lessons for you?
  * Eat your own dog food.
  * Different domains may require a very different approach to the
    same information.  Try to design interfaces (such as RSS) that
    make it easy to use your code or data in different contexts.
  * Pipes are still a great interface. -- Write your programs to
    accept and send simple sequences of character data.
  * Start with something small and build upon it gradually.
  * KISS - simple architectures and interfaces break less

* Other comments
  * What's this with interfacing between multiple languages?
    * Scripting languages are your friend: It's easy to write EmacsSpeak
      servers in TCL and make them adapt to different speech synthesis
      systems
    * If your programs are talking over a pipe, it doesn't matter
      what language they are written in
    * TCL and Python are glue languages, so we expect them to be
      easier to interface

Fun with Emacs LISP
  (defadvice next-line (after emacsspeak)
    "Speak line after moving."
    (when (interactive-p) (emacsspeak-speak-line)))

The "Speak line after moving." is simply a comment (documentation) for
what the procedure does.

There's a weird "get the current line from the environemnt" thing happening
here.

(defadvice put-text-property (after emacspeak-personality pre act)
  "Used by emacspeak to augment font lock."
  (let ((start (ad-get-arg 0)) ;; Bind arguments
        (end (ad-get-arg 1 ))
        (prop (ad-get-arg 2)) ;; name of property being added
        (value (ad-get-arg 3 ))
        (object (ad-get-arg 4))
        (voice nil))                    ;; voice it maps to
(when (and (eq prop 'face)      ;; avoid infinite recursion
           (not (= start end)) ;; non-nil text range
           emacspeak-personality-voiceify-faces)
  (condition-case nil ;; safely look up face mapping
      (progn
        (cond
         ((symbolp value)
          (setq voice (voice-setup-get-voice-for-face value)))
         ((ems-plain-cons-p value)) ;;pass on plain cons
         ( (listp value)
           (setq voice
                 (delq nil
                       (mapcar   #'voice-setup-get-voice-for-face value))))
         (t (message "Got %s" value)))
        (when voice ;; voice holds list of personalities
          (funcall emacspeak-personality-voiceify-faces start end voice object)))
    (error nil)))))

* Yeah, the code is hard to read if you're not an experienced speaker.
Detour: Some fun with Scheme
  (define f 
    (lambda (x)
      (display x)
      (newline)
      (+ x 2)))

  (define f
    (lambda (x)
      "Hello"
      (+ x 2)))

--------
HF OOD
* Why do we start with what many of us would identify as a bad design?
  (i.e., having a Guitar class and no Instrument class)
  * Sometimes we have to start with other people's designs.
  * Sometimes it's good to write something that just solves the
    problem at hand.  [General code takes us more time to write.]
  * Sometimes that basic answer is all that makes sense to us at the time.
  * "The customer is always right."
  * The book is trying to explain a process one bit at a time.
  * Having to change your code makes you more money. [Not a pedagogical
    reason.]
  * While we might agree that the design is not general enough, we might
    have very different ways to generalize it.
  * The authors believe that the first design is what many people would
    come up with.
* What did you see as the key OO design principles or processes presented 
  in the narrative?
  * Encapsulate, Inherit, and Polymorphisate
  * Ask yourself "How hard will it be to extend this code to do something similar?"
    * Techniques for making extension easier:
      * Try to predict where the code will go.  (Think about what the customer may need later.)
      * Design interfaces and code to interfaces rather than to concrete classes.
  * Try to make classes do one thing, and one thing only.
  * Encapsulate what varies - What does this mean?
    * Pull out the things that vary between subclasses and put them into a separate class
    * Pull out the parts of your program that you expect to change
* Random critiques that don't answer my question
  * The "make it work first" style leads to bad initial code
  * The book is self-contradictory

Question sequence (to help check the depth of your reading):
* What does an association link from class A to class B mean?
  * Class A has a field of type B
* What does an aggregation link from class A to class B mean?
  * Class A has a field of type B
* What's the difference between association and aggregation?  Why
  is it such an important difference that we have different symbols
  for the two concepts?

Code reading: What does match look like for 
* The one-class-per-instrument model of the system
* The "let's use a Map" model of the system

* First one
public class Instrument
  InstrumentSpec spec
  ...
public class InstrumentSpec
  matches(InstrumentSpec): boolean

public class GuitarSpec extends InstrumentSpec
  ...

  Each extension of InstrumentSpec provides its own search procedure

  Lots of overriding of the matches method.

* Second one
public class InstrumentSpec
* Iterates through the map.

--------------------------------------------------------------------------------

Projects
* Sam's model: One project, done multiple times
  * Why?  Lets us talk in common terms.  
  * Easier to ensure that all the projects are of appropriate difficulty.
  * Code sharing and team member swapping!

Possible projects