Matthias%20Felleisen%20

1
Matthias Felleisen Daniel JacksonNDIST
December 5, 2001
patterns incs education
2
content

• experience reports (30 mins)
• Rice
• 2 freshman year courses
• MIT
• sophomore/junior software eng.
• shared (10 mins)
• conclusions
• provocations
• discussion (20 mins)

3
6.170 lab in software engineering

• context
• required of all CS majors
• follows 6.001 (Sussman/Abelson)
• our only programming course?
• 8 weeks lectures problem sets, 6-week team
  project
• content
• data abstraction
• specification
• conceptual models of problem
• component specifications
• medium-level design
• module dependences
• object models
• design patterns

4
talking about design

• to talk about design
• need succinct, precise language
• must escape from code ASAP
• strategy
• 2 design notations
• module dependence diagram
• object model (invariant)
• introduce notations right at start use
  pervasively
• gradually drop code from lectures
• documentation
• less textual, more graphical
• less uniform, more focused

5
relating problems solutions

• hardest part of design?
• underlying conceptual model
• how to teach?
• simple notation for conceptual models
• same object modelling notation
• interpret as invariants about problem domain
• in early problem sets, have students write spec
• harder to do (good), harder to evaluate (bad)
• discuss strategies for problem -gt solution
• transformation patterns?

6
using design patterns

• why teach design patterns?
• students ( teachers!) must know idioms
• writing style is exemplary
• inspire raising level of discourse
• books are great resource
• GoF, Design Patterns
• Joshua Bloch, Effective Java
• what happened?
• in course evals, students say they want more
• fit nicely with our design notations
• students need substantial examples of use
• this term, added 3 case studies
• JUnit, Java API, Tagger

7
example observer
D
D
C
Observer
all o Observer o in o.subj.obs all s Subject
s ! in s.obs
C
dependency diagram
object model
8
conclusions

• why are patterns good for teaching?
• because they concretize abstract ideas
• are all patterns good?
• no, must be conveyed in a formal language
• how do patterns help?
• to communicate understand
• do they help design code?
• no key abstractions more vital
• do they never help with coding?
• yes, primarily in refactoring

9
conclusions, ctd

• do they understand why patterns are useful?
• yes, when they modify code (their own or others)
• which patterns do students find useful?
• not small patterns (interpreter, composite,
  command)
• they think theyre obvious
• architectural patterns (MVC, kernel)
• harder, but more valuable

10
provocations

• patterns are the icing, not the cake
• principles are more essential
• teachers researchers must know patterns
• they embody modern practice
• methods tools must handle them work at their
  level
• there arent very many patterns
• only GoF plus a few relevant to code
• of these, the architectural ones matter