| User Interface Principles in API Design |
| Elliotte Rusty Harold | |
| elharo@metalab.unc.edu | |
| http://www.cafeaulait.org/ |
| Programmers Are People Too |
| Eat Like Humans | |
| Sleep Like Humans | |
| Mate Like Humans | |
| Think Like Humans |
| User Interface Design is a Science |
| Based on hypothesis, observation and experiment | |
| Well-proven, well-tested theories |
| Fundamental Principles |
| Consistency is next to godliness | |
| Simpler is better | |
| Visible complexity is bad | |
| Smaller equals easier to use |
| Libraries vs. Applications |
| Applications are monolithic | |
| Only other programmers on the same team use an application’s API | |
| Libraries can make very limited assumptions about how, when, where, and why API will be invoked | |
| Boundary is fuzzy |
| Remember the People |
| Why You Need An API | |
| Who Uses the API | |
| Who Designs the API |
| What to put in an API |
| Write sample programs first | |
| 80/20 rule | |
| Maximal APIs | |
| When in doubt, leave it out! |
| Data Encapsulation |
| Public vs. Published | |
| Fields are private | |
| Methods are mostly private | |
| Methods are atomic | |
| Constructors and destructors | |
| Communicating with the user |
| Constraints |
| APIs must enforce domain validity | |
| Preconditions | |
| Postconditions | |
| Class invariants | |
| System invariants |
| Requirements |
| Platform version | |
| Library dependencies | |
| Built-in vs. 3rd party libraries |
| Naming Conventions |
| Review naming conventions | |
| Use standard terminology | |
| Do not abbreviate |
| Plays well with others (Java version): |
| Serializable | |
| Cloneable | |
| Comparable | |
| equals() | |
| hashCode() | |
| toString() | |
| Exception handling | |
| Thread safety |
| Plays well with others (.NET version): |
| The Last Concern (Performance) |
| Speed | |
| Size | |
| Energy |
| Documentation |
| Specification | |
| Quick Start | |
| Tutorials | |
| Example code | |
| API Documentation | |
| Per method checklist |
| Inheritance |
| Prefer finality | |
| Factories and interfaces | |
| The proper use of protected |
| Maintenance |
| Planning for the future | |
| Forwards compatibility | |
| Backwards compatibility | |
| Unexpected limits | |
| Deprecation | |
| Breaking compatibility | |
| Interfaces vs. classes |
| Conformance Testing |
| Specifications | |
| Test Suites | |
| Implementation dependent behavior | |
| Implementation dependent extensions |
| Avoid Complexity |
| Prefer classes to interfaces | |
| Prefer constructors to factory methods | |
| Avoid excessive abstraction |
| Case Study: JDOM |
| Case Study: GridBagLayout |
| Further Reading |
| Effective Java: Joshua Bloch | |
| Tog on Interface: Bruce Tognazzini |