Showing posts with label design patterns. Show all posts
Showing posts with label design patterns. Show all posts

Friday, December 23, 2011

Design Patterns Refresher

The most common design patterns from "Head First Design Patterns" by Eric Freeman and Elisabeth Freeman - the best book ever about design patterns:

Strategy
Encapsulate algorithms. Allows object's behaviour to be changed at runtime by substituting default algorithms. 

Observer 
Notify dependents of state changes. A very common pattern, often part of the language, see events and listeners in C#.

Decorator
Use and extend behaviour of the object being wrapped, while acting as that object to the external world. A decorator object is created with an instance of an object of the same type. When a method is invoked, it calls the embedded object's method, modifies the result, and returns it.

Simple Factory
Encapsulate object creation. Useful when you need to decide at runtime which object to create.

Factory Method
Same purpose as Simple Factory, but more abstract: moves actual object creation to other factory objects. 

Singleton
Indispensable when there is one of something in the system, like one database, or one set of configuration data. Implemented as a sealed class with private constructor and a static method that returns the only instance.

Command
Encapsulate actions. Every action object has "execute" method. Very useful for a processing system that needs to queue commands and then execute them in order. 

Adapter
Provide a converter that allows clients to use the interface they expect with an object that has a different interface.

Facade
Provide a simplified interface. Used to hide complexity of the underlying system from the external world.

Template Method
Provides extension points or hooks by defining steps of an algorithm and allowing or forcing subclasses to provide implementation for some of them. This pattern is often used in frameworks.

Iterator 
Provides a uniform way of accessing sequentially elements in an aggregate object of any type. Typically found in collections.

Composite
Organize objects into tree structures so a group of them can be treated the same way as a single element. Each object in the hierarchy is a component that can have sub-components. User interfaces are usually built as composites.

State
Encapsulate behaviours of an object in state objects. Current state object can request transition to another state.

Proxy
Provide a surrogate object that controls access to an object that is remote, needs to be secured or is expensive to create.

Monday, March 7, 2011

Language Implementation Patterns by Terrence Parr

Rating: Lot's of information, but poorly presented.

Basic Patterns:
  • Mapping Grammars to Recursive-Descent Recognizers: convert formal language specification (grammar) into a parser.
  • LL(1) Recursive-Descent Lexer: break up character streams into tokens.
  • LL(1) Recursive-Descent Parser: make a parsing decision (choose parsing method) for the current (1) input symbol.
  • LL(k) Recursive-Descent Parser: make a parsing decision (choose parsing method) for up to k next input symbols.
Quotes:
  • "A language is just a set of valid sentences."
  • "To parse, then, is to conjure up a two-dimensional parse tree from a flat token sequence."

Criticism:
This book could have been much better. It suffers from the following problems:
  •  Code examples:
    • Incompleteness - critical functions are missing initially: code which uses match() starts on page 41, but match() implementation is shown on page 55 for the first time.
    • Names of variables and functions are cryptic/not clear and do not follow one convention: 
      • variable names: T, p, c, x, k, i, r, Integer memoI, int memo, FOLLOW_INT_in_point37, _save,
      • function names: LT(), LA(), isSpeculating(), alreadyParsedRule(), _list(), speculate_stat_alt1().
  • Critical terms are used without introduction.
  • Definitions seem chaotic/incomplete.
  • Concepts are introduced in chaotic order.
  • Some concepts seem to change meaning: current token becomes a lookahead token.
  • There is a lot of alternative terminology that is used without introducing it properly: here are my notes on  "lexer":  Lexer: a type of recognizer; aka scanner, aka lexical analyzer, aka tokenizer: reads a stream of characters and yields a stream of tokens aka input symbols, aka vocabulary symbols.