CSC321.01 2016S, Class 19: Design Patterns for SaaS
===================================================

_Overview_

* Preliminaries.
    * Admin.
    * Upcoming Work.
    * Extra Credit.
    * Questions.
* Refactoring, revisited.
* Design patterns.
* The GoF list of patterns.

Preliminaries
-------------

### Admin

* What did you do/learn without me?

### Upcoming Work

* Readings for Wednesday: SaaSbook Chapter 11
* Reading Journal for Wednesday (due Tuesday at 8pm)
    * Subject: Reading Journal for Class 20 (Your Name)
    * What does the SOLID acronym stand for?
    * In your own words, what is a design pattern? What is an antipattern?
    * Which design principle or pattern did you find the most relevant to your CSC 322 project or other prior experience with object-oriented programming? Explain the pattern and why you chose it.
    * Which design principle or pattern did you find the most confusing? Explain it as best you can and say where you got confused.
    * As always, better questions were stolen from JLND.

### Good Things to Do

#### Academic

* Public Events Concert Tuesday Night

#### Peer

#### Other

### Questions

Things We Learned
-----------------

### UML

* Draw pretty pictures to illustrate software systems.
* Relationships between different components
    * Method calls
    * Data relationships (one:one, one:many, many:many)
    * Orders of actions
    * Inheritance
* Why pictures?  
    * Simple and easy to understand.
    * Maybe simple enough for pointy-haired managers
* Why one particular way to write the diagrams?
    * Uniformity helps with clarity.

### Ethics of Software Professionals

* No complete consensus.
* While we should care about the client, keep in mind what's best for 
  society as a whole.
* Compare to other professions, such as bridge engineers
    * Software is so broad that it's not clear that everyone needs to
      follow the same standards: Someone developing a game may not need
      to follow the same standards as someone developing the software
      to control breaks on a car.
   * Should we overbuild?
   * Whose responsibility is it when something breaks?  It's not as simple
     as you might think.

Where should ethics of computing professionals fit within the Grinnell CS
curriculum?

* Small case studies in CSC 321 and CSC 322 and then add the code of ethics
  somewhere later.
    * "Make us write essays so that we can better formulate ideas for
      what to do when we encounter ethical questions!"
* "In comic books"
* Don't worry about it; as liberal arts students we already know how to
  behave ethically.
* Add a two-credit course on ethics which includes some case studies and
  compares to other professions.  A serious enough issue that it shouldn't
  be crammed in among the gaps in other topics.  (Or is it serious enough
  that we should be talking about it in every class.)
    * Complicated enough that we need to focus deeply in order to apply it.
    * A relevant ethics course in Philosophy doesn't suffice; the problems
      feel somewhat different
* Introduce the code of ethics earlier, so that we can start to understand
  what it is before we get to here.  Deeper cases would be good.
* Big cases are easy.  What about smaller cases, which are often more
  complex?

Refactoring, revisited
----------------------

Refactoring is an approach to dealing with bad code smells.  For each
of the following, think about one or more examples and come up with 
aproaches to dealing with  the bad smells.

* Repeated code: Nearly identical procedures
* Repeated code: Within a procedure
* Magic numbers
* Too many parameters
* Too-long procedures
* Complex control structures, usually with nested ifs
* Code that is never executed

Repeated code: Nearly identical procedures

* Write a more general procedure that takes an additional parameter
  that handles the different part.
    * In a functional language, that might be a procedure.

Repeated code: Within a procedure

* Use a loop
* Turn into a separate procedure and do the stuff above
    * May be difficult if we are doing assignment
* Restructure the code to put the common code together (e.g., in a
  conditional).

Magic numbers

* #define in C.  More generally, use constants in whatever the model
  is for that language.

Too many parameters

* Maybe the function is trying to do too many things, so break it
  into separate functions.
* Combine things into structs or objects or something equivalent.

Too-long procedures

* Break it into separate functions.
* In some cases, the too-long-ness is repeated code, so we should
  use loops.
* Move behavior to objects.

Complex control structures, usually with nested ifs

* Use a case statement.
* It depends on the case.  Sometimes you need a nested if.
* Look for code that may not be executed.
* Break portions out into separate procedures.  
* For complex tests, write a separate procedure.
* Use goto! (Only if absolutely necessary and you're about to quit 
  your job anyway.)
* Diagram the control flow and see if there's a simpler description.
* Move the control to the objects.
    E.g., from
        case foo:
          x += 23;
          break;
        case bar:
          x += 11;
          break;
        case baz:
          x += 5;
          break;
    To
       foo, bar, and baz are subclasses of soemthing
        x += thing.importantValue()

Code that is never executed

* Be happy!  It's probably there only when errors occur and they haven't
  occurred.
* Think about why it's not getting executed.
    * Is it that it's not getting executed in your tests?
    * Is it that it can never be executed?  (Delete it.)
* Maybe it's obsolete.
* What should you do with a procedure that you know is never called?
    * Comment it out.
    * Use your version control system and just delete it.

Design patterns
---------------

The GoF list of patterns
------------------------