Creating intuitive APIs
summary
Practical rules and concrete fixes drive decisions: rename ambiguous find to indexOf with CaseSensitivity enum so return types and intent match, replace long QSlider constructors with a property-based API for QSlider and defaults, remove unused virtuals and favor static polymorphism, protect binary stability with a pimpl private d-pointer, stop auto-detecting text formats, prefer enums over Booleans, avoid implicit conversions, and operate with no exceptions, heavy use of assertions while keeping source/binary compatibility for hundreds of thousands of users.
AI-written summary · about
chapters (29)
- 0:00Start
- 3:40For your project
- 10:32Easy to learn and use
- 11:49Leads to readable and maintainable code
- 14:54Minimal but complete
- 16:05Easy to extend and evolve
- 16:41Know your requirements
- 17:36API Specification
- 20:15Review the API
- 21:14Coding
- 22:06Prepare for extensions
- 25:05Choosing good names
- 26:44Make names specific
- 27:56Make names unambigous
- 29:17Avoid abbreviations
- 30:58Choose good default behavior
- 32:33Avoid magic
- 35:28Pay attention to edge cases
- 37:26Value based classes
- 39:18Polymorphic classes
- 43:02Static polymorphism
- 45:05Composition instead of inheritance
- 46:09Property based API
- 47:46Signals and slots
- 48:35Hide your implementation
- 50:34Method design
- 51:20Naming Arguments
- 56:24Property getters and setters
- 58:54Documentation
related talks
06mLightning Talk: The Most Important Design Guideline
34mPlaying Nice with UX and QA
49mQt Quick Best Practices and Design Patterns
55mUI Design for Small Screen Devices
30mThe Design of Everyday APIs
46mQt Quick Controls Re engineered
01h 02mBasics Designs and How We Got Them Wrong
26mType-driven User Interface Design