Notes on Designing and Evaluating Reusable Components https://www.youtube.com/watch?v=ZQ5_u8Lgvyk

gistfile1.txt

- Types of reuse
    - Layer
        - Completely abstracts underlying problem. Your code calls layer
        - Assume singleton, can conflict with another layer 
    - Engine
        - Orchestrates whole app Engine calls you
    - Component
        - You call component, but component might call you back
        - Most benefits, hardest to design
- Optimization axes
    - Granularity: A or BC
        - Flexibility vs simplicity
    - Redundancy: A or B
        - Convenience vs orthogonality
    - Coupling: A implies B
        - Less is always better
    - Retention: A mirrors B
        - Who keeps objects, why, how long
        - Synchronization vs automation
    - Flow Control: A invokes B
        - More control is always better
- Great APIs
    - Cover many varieties of use-cases
    - Spend amount of effort proportional to your problem
        - Do not require huge upfront investment (easy to start)
        - Do not force you, but let you go deep when you are ready
- Retained/Immediate modes
    - Retained can be pain to use in a game loop
        - First use different from subsequent uses (create vs update)
        - Needs tracking state, eventual delete
    - Make sure to have immediate mode equivalent
- Data types
    - Let users come with their own data types
    - High-level APIs (e.g. MakeFromFile) have low-level equivalents (MakeFromBytes)
    - Transparent when possible (allocate, initialize, access, modify)
- Decomposition
    - Long “convenience” functions are made of smaller “low level” ones that could be called too, maybe with a twist (different order, intermediate computations etc)
    - Source code is avaliable
- Tips for designing
    - Write code that uses your API
    - When wrapping something, don’t think in their terms first. Pretend you have perfect underlying API