Matthias Felleisen & Daniel Jackson NDIST · December 5, 2001

1. patterns incs education Matthias Felleisen & Daniel JacksonNDIST · December 5, 2001

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

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 3

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 4

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 -> solution • transformation patterns? 5

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 6

7. ! Subject subj obs Observer example: observer D D Observer C all o: Observer | o in o.subj.obs all s: Subject | s ! in s.^obs C dependency diagram object model 7

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 8

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 they’re obvious • architectural patterns (MVC, kernel) • harder, but more valuable 9

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 aren’t very many patterns • only GoF plus a few relevant to code • of these, the architectural ones matter 10