[design] Large-Scale C++: Advanced Levelization Techniques, Parts I & II - reading note

Study note excerpt from:
https://github.com/boostcon/cppnow_presentations_2015/raw/master/files/accu2014.150513.pdf

Logical: Classes and Functions
Physical: Files and Libraries

Logical content aggregated into a
Physical hierarchy of components

Exactly 3 levels of physical aggregation.

Essential Physical Design Rules:
1.No Cyclic Physical Dependencies!
2.No Long-Distance Friendships!

Criteria for Colocating “Public” Classes:
1.Friendship.
2.Cyclic Dependency.
3.Single Solution. (BAD: Hierarchy of Solutions)
4.“Flea on an Elephant.”

---
Escalation –
  Moving mutually dependent functionality higher in the physical hierarchy.
 
Demotion –
  Moving common functionality lower in the physical hierarchy.
  用integral types當作dumb types來做demotion. 避免dependency.
 
Opaque Pointers –
  Having an object use another in name only.
 
Dumb Data –
  Using data that indicates a dependency on a peer object,
  but only in the context of a separate, higher-level object.

Redundancy –
  Deliberately avoiding reuse by repeating a small amount of code or data to avoid coupling.
  Demotion is mandatory for vocabulary types!
 
Callbacks –
  Client-supplied functions/data that enable lower-level
  subsystems to perform specific tasks in a more global context.

There are several flavors:
1.DATA (Effectively Demotion)
2.FUNCTION (Stateless/Stateful)
3.FUNCTOR (Function Object)
4.PROTOCOL (Abstract Interface)
5.CONCEPT (Structural Interface)

Manager Class –
  Establishing a class that owns and coordinates lower-level objects.
 
Factoring –
  Moving independently testable sub-behavior out of the implementation
  of a complex component involved in excessive physical coupling.
 
Escalating Encapsulation –
  Moving the point at which implementation details are hidden from
    clients to a higher level in the physical hierarchy.
* Multi-component wrappers don't work!
* single-component wrappers don't scale!

-------
Total and Partial Insulation Techniques
  Avoiding Unnecessary Compile-Time Coupling


Logical encapsulation versus physical insulation:
  An implementation detail of a component (type, data, or function)
that can be altered, added, or removed without forcing clients
to rework their code is said to be encapsulated.
  An implementation detail of a component (type, data, or function)
that can be altered, added, or removed without forcing clients
to recompile is said to be insulated.

-------
Procedural Interface
Every procedural interface (PI) function is:
1.Entirely independent of every other PI function.
2.Physically separate from any C++ components.
3.Totally devoid of additional implementation (beyond that needed for insulation purposes).
4.Named in a natural, regular, and predictable way.
5.Callable from both C and C++.
6.Exposing the actual underlying opaque C++ types.

-------
Must ensure exceptions don't leak out to C code.

-------
All of the software we write is governed by a common
  overarching set of Organizing Principles.
Among the most central of which is achieving
  Sound Physical Design.
-------
Conclusion
1.Review of Elementary Physical Design
Components, Modularity, Physical Dependencies
•A Component is the fundamental unit of both logical and physical software design.
•No cyclic dependencies / long-distance friendships.
•Colocate logical constructs only with good reason:
  i.e., friendship; cycles; parts-of-whole; flea-on-elephant.
•Put a #include in a header only with good reason:
  i.e., Is-A, Has-A, inline, enum, typedef-to-template.