Skip to main content

11. Protocols

04/11/22

tldr: windows is shit, linux is great

Protocols​

Protocol is a set of signatures to which a class responds. Final step of design, first step of implementation

  1. Construct protocols for each class - specific signatures for methods. Good decisions require careful attention to refining responsibilities and naming messages
  2. Write design specification for each class and subsystem
  3. Write design specification for each contract

Goal is to produce precise and complete design Specifying protocols exposes fuzzy, incomplete areas of design

Make them general​

  • Protocol for a contract (set of responsibilities) must cover the full generality of each responsibility in contract
  • Simple responsibility may only need one signature
  • General responsibility may need many signature

Refining Responsibilities​

  • Need to derive an implementation for classes. Implementation spec represented by:
    • A protocol for each contract
    • Protocol for some private responsibilities

Guidelines​

Avoid over-specifying implementation detail, which normally advises against a protocol for private responsibilities. Useful if parent class is implemented by different person than children classes

Method Names​

Need to preserve encapsulation and general class utility while imposing implementation details. Proper overloading can be important vehicle, confusing if 1 name is used for 2 conceptually different things.

Guidelines​

  • Each method name should imply a unique intent
  • Use same name everywhere for each conceptual operation
  • Associate a single conceptual operation with each method name
  • Classes that fulfil same responsibility should inherit it

Define Reasonable Defaults​

  • Classes are easily used and more reusable if protocols are designed to reflect their different uses more accurately
  • Good to speculate on potential future use as well as immediate use. Helps to abstract and generalise

Guidelines​

  1. Always start by defining the most general message, allowing clients to specify all possible parameters
  2. Provide default values for parameters as appropriate
  3. Analyse likely uses. Determine set of signatures that require only subsets of parameters in order to make the signature match most naturally to each likely use - defaults used for unspecified parameters

Parameters​

Default analysis:

  • default display, bg colour, clipping region etc

Guideline​

Order of parameters is based on probability (determined by designers) that client will want to specify parameters

Return values​

Do not just return void in methods. Instead specify Boolean by default: true - if the method succeeds in fulfilling its responsibilities false - if anything goes wrong

Methods should be performing error checks, especially accessory methods

Specifying the Design​

  • Hierarchy and collaboration graphs need to be updated and revised as appropriate to reflect final design decisions.
  • Hierarchy graphs - Single page system overview is highly desirable; include all hierarchy 'roots' on this page and all subsystems. Include all first level children

Specifying Classes​

  • Each class must be fully specified
  • Text suggests discarding 'cards' and more or less starting over with full page documentation, one page per class.

Full class design documentation​

  1. Class name and abstract/concrete identification at top of page
  2. Immediate parent and child classes
  3. References to hierarchy and collaboration graph locations
  4. Class description - purpose and intended use - expansion of original purpose on class card
  5. List each collaboration that the class is involved in
  6. For each new collaboration defined in this class, list responsibilities that support it; for each responsibility, list signatures that implement the responsibility.
  7. List private responsibilities. If they have been further defined, include same information as public responsibilities.
  8. Identify implementation notes or guidelines, error responses, performance requirements etc

Specifying Subsystems​

  1. Subsystem name at top of page
  2. List all subsystem classes
  3. References to hierarchy and collaboration graph locations
  4. Subsystem description - purpose and intended use - expansion of original purpose on subsystem card.
  5. List each contract supported by subsystem
  6. For each contract supported by this subsystem, identify class or subsystem for which contract is delegated

Final design summary​

  • One or more hierarchy graphs, showing inheritance and overall class structure of the application
  • One or more collaboration graphs showing patterns of communications
  • Class and subsystem specifications with purpose, relationship to other class and subsystems, collaborations and responsibilities, implementation notes