Skip to content

Latest commit

 

History

History
199 lines (135 loc) · 7.91 KB

patterns.md

File metadata and controls

199 lines (135 loc) · 7.91 KB
Raw

 

 home   |   syllabus   |   groups   |   moodle   |   video   |   review   |   © 2022

Patterns

If you want someone to understand something new, build it out of old stuff that they have seen before.

  • Express it in terms of a pattern that experienced programmers already might know something about.
  • Experts glance at things and see patterns missed by novices
    • When experts talk, they talk in patterns.
    • To document better, talk patterns

image

Q: So what have programmers seen before that might repeat in future systems?
A: Patterns

  • e.g. idioms : small code-level patterns
  • e.g. design patterns: common collections of a few classes
  • e.g. archtirctures: recurring "big picture" structures seen in large systems

Example 1: 3-tiered architectures

Data : model : dialog

  • Data = ? SQL
  • Model = ? some object system
  • Dialog = ? some gui tool

image

  • The power of patterns

    • Patterns come with review heuristics
    • Which can identify problems... which can be solved ... using other patterns.
    • So patterns take us naturally to design review/ critique/ improvement

  • Problem: data and dialog both need the same constraint info (e.g. 0 <= age <= 120): Where to store it?

    • A solution: Ruby on Rails, DRY: “don’t repeat yourself”
      • Database and Web-GUi generated from a class model
      • Simplified (amazing) last decade’s web designs
      • Each web url has actually a method on a class
    • A very popular solution (until we went much more "REST" ful)

image

Example 2: Composite design patterns

image

image

image

image

Patterns have review heuristics:

  • E.g. delete cascade? in composites
    • If “it” gets deleted, then do you delete the sub-parts

Example 3: Blackboard Architectures

Collaborative problem solving

image

Layered feature extraction: agents read from level[i], write to level [i+2]

image

image

Each agent has rules if <condition> then <action>

image

Patterns have review heursitcs:

  • No “best” answers, but issues that experts expect to debate
  • Issue #1: systems issues: how to get everyone onto the net?-
  • Issues #2: network intera lingue. How to share?
  • Issue #3: Schedule. How to pool the different agents?
  • Issue #4: Conflict resolution. What to do when 2 agents have satisfied conditions?

Example 4: Layers

  • Blackboards a kind of layered architecture
  • Code at level[X] only talks to levels[X+1], levels[X-1]
    • Via well-defined interfaces
  • Layer[X] can be pull out and easily replaced
    • Just as long as new layer[X] maintains the same interface
  • Low-level issues can be abstracted away to higher levels
  • Separation of concerns at different layers
  • E.g. OSI Network layers architecture:
    • “The purpose of the OSI reference model is to guide vendors and developers so the digital communication products and software programs they
      create will interoperate, and to facilitate clear comparisons among communications tools.”
  • E.g. LAMP, ISO network model

image

image

Patterns have review heursitics:

  • Implementation complexity
  • Slow (messages have to navigate many layers)
  • Internal barries to change

Mean: a fix to removing internal barries to change in layerd patterns

  • M = MongoDB: a non-SQL DB (nested key-value pairs)
  • E = Express.js : controller layer, directing application flow and marshaling data.
  • A = AngularJS : handles data presentation.
  • N = Node.js: an extensive javascript library (look ma, no operating system)
  • MEAN: one language up and down the stack (Javascript)
    • faster integrated testing;
    • faster invention of new patterns.

image

Example4: Layers at the Dept of Defence Software

Doug Schmidt:

  • Architectural Evolution of
    DoD Combat Systems Doug Schmidt, SEI blog, Nov 15, 2013
  • "The Department of Defense (DoD) must move away from stove-piped solutions:
  • "... towards a few technical reference frameworks ..."
  • "based on reusable hardware & software services"

image

Example 5: CRUD: low-level code idiom

CRUD = create, read, update, delete

  • In SQL: INSERT = C, SELECT = R , UPDATE and DELETE.
  • In http: : GET = R, DELETE.= D, PUT=?, POST=?
    • PUT : might create new user or update info on an existing user (so PUT = C or U?)
    • POST : sends data to the server and leaves it up to the server to do something with it

CRUD2 (a timm special)

  • CRUD + search + zoombie (a proxy that cannot be committed (inserted) used)
  • For GUI constrain info

BTW, CRUD can leap from idiom to architecture (web-scale RESTful applications)

Regardless

  • the main points here is that complex systems can be abstracted into reasonable chunks via Patterns
  • Such abstraction simplifies how we discuss even complex systems

For more on Patterns

image

Design Patterns: Elements Of Reusable Object-Oriented Software (1995)