Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »


Presenters: Simon Bates

An Infusion Pattern Language

Creative User Rights


  • Pattern language might be good to express design thinking
  • Pattern language for Infusion:
    • What could be pattern languages for Infusion?
    • Technical patterns?
    • More scope to do more there.
  • Today:
    • What pattern languages are in the broad sense.
      • Pattern languages are an approach to documenting design strategies/solutions in the 1960s.
      • Christopher Alexander 
        • book series:
          • The Timeless Way of Building (1979)
          • A Pattern Language (1977)
          • The Oregon Experiment (1975)
        • looks for patterns in time and space
          • cannot separate these - e.g. watching the world go by, sitting on the porch
        • Writing generative patterns – recording them in a way that they can be reused, not just documenting observations.
        • Only interested in patterns with "the quality without a name"
        • Language or structure for making something (e.g. making a porch)
          • Loop through the language and choose patterns useful to what you want to make
          • Construct a mini-language for that situation
      • Richard Gabriel, Patterns of Software
    • How they are applied to computer software.
      • Kent Beck (1987, "Using Pattern Languages for Object-Oriented Programs")
        • "Keep all of the operations in a method at the same level of abstraction"
          • what does this mean?
            • Depends on the context of what you are writing the code for. It's matching how you might break the problem down in your head, and having the code structured in a way that matches that.
            • Consistency of metaphor? How you understand how to break a task into smaller tasks.
      • 1994, "Design Patterns" by the Gang-of-4
        • Paul Graham wrote:

          When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

      • anti-pattern, a bad thing.
        • something could either be a pattern or an anti-pattern based on the context. (e.g. Data Transfer Object)
        • Requires too much ongoing work and maintenance over time
      • Computer users should write their own programs. Computer users as "inhabitants" of the space.
        • But, another view is that it is programmers that are the "users" here, and the patterns are for programmers.  Another type of "user" is the "end user" and they won't be using these programming patterns.  It is these "end users" that more closely resemble the "users"  – inhabitants --  in Alexander's thoughts on patterns for cities, towns, neighbourhoods, buildings, etc.
    • What a pattern language for Infusion might be.
      • Not just patterns of software development code
        • User experience
        • System integration
        • Software design/architecture
        • Construction
  • No labels