user interface principles in api design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
User Interface Principles in API Design PowerPoint Presentation
Download Presentation
User Interface Principles in API Design

Loading in 2 Seconds...

play fullscreen
1 / 26

User Interface Principles in API Design - PowerPoint PPT Presentation


  • 158 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

User Interface Principles in API Design


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
user interface principles in api design

User Interface Principles in API Design

Elliotte Rusty Harold

elharo@metalab.unc.edu

http://www.cafeaulait.org/

programmers are people too
Programmers Are People Too
  • Eat Like Humans
  • Sleep Like Humans
  • Mate Like Humans
  • Think Like Humans
user interface design is a science
User Interface Design is a Science
  • Based on hypothesis, observation and experiment
  • Well-proven, well-tested theories
fundamental principles
Fundamental Principles
  • Consistency is next to godliness
  • Simpler is better
  • Visible complexity is bad
  • Smaller equals easier to use
libraries vs applications
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
Remember the People
  • Why you need an API
  • Who uses the API
  • Who designs the API
be user focused
Be User Focused
  • Ask what the user wants to do with your API
  • Do not ask what the internal data structures and algorithms look like
  • High level API is better than lower level--Reduce the number of method calls needed to accomplish the task
  • Design from the outside in
what to put in an api
What to put in an API
  • Write sample programs first
  • 80/20 rule
  • Maximal vs. Minimal APIs
  • YAGNI
  • When in doubt, leave it out!
  • Why I’m a conservative
dependencies
Dependencies
  • Platform version
  • Library dependencies
  • Built-in vs. 3rd party libraries
data encapsulation
Data Encapsulation
  • Public vs. Published
  • Fields are private
  • Methods are mostly private
  • Methods are atomic
  • Constructors and destructors
  • Communicating with the user
constraints
Constraints
  • APIs must enforce domain validity
  • Preconditions
  • Postconditions
  • Class invariants
  • System invariants
error handling
Error Handling
  • Specify what happens on bad input as well as good
  • Important for security
  • No undefined behavior
  • Don’t silently swallow exceptions
  • Error messages should be verbose but clear
  • Don’t warn the user
naming conventions
Naming Conventions
  • Review naming conventions
  • Use standard terminology
  • Do not abbreviate
  • Use domain specific vocabulary
  • Consistent terminology: always use the same word for the same idea
    • e.g. add vs. append
  • Do not use two words for one idea
avoid complexity
Avoid Complexity
  • Prefer classes to interfaces
  • Prefer constructors to factory methods
  • Avoid excessive abstraction
  • You usually don’t need multiple implementations
  • Refactor to patterns; don’t start with them. Avoid pattern overload!
inheritance
Inheritance
  • Prefer finality
    • (at least on methods)
  • Factories and interfaces
  • The proper use of protected
plays well with others java
Plays well with others (Java):
  • Serializable
  • Cloneable(*)
  • Comparable
  • equals()
  • hashCode()
  • toString()
  • Exception handling
  • Thread safety
plays well with others net
Plays well with others (.NET):
  • Equals() / GetHashCode()
  • ToString()
  • IEquatable<T> / IComparable<T>
  • “Collection” suffix for IEnumerable classes
  • Icloneable*
  • Override ==, etc. for value types (only)
  • No pointer arguments to public methods
  • Don’t throw exceptions from overloaded operators and implicit casts
testability
Testability
  • The API itself
  • Client code that uses the API
  • This is a secondary concern
documentation
Documentation
  • Specification
  • Quick Start
  • Tutorials
  • Example code
  • API Documentation
  • Per method checklist
conformance testing
Conformance Testing
  • Specifications
  • Test Suites
  • Implementation dependent behavior
  • Implementation dependent extensions
maintenance
Maintenance
  • Planning for the future
  • Forwards compatibility
  • Backwards compatibility
  • Unexpected limits
  • Deprecation
  • Breaking compatibility
  • Interfaces vs. classes
further reading
Further Reading
  • Effective Java: Joshua Bloch
  • Effective C#: Bill Wagner
  • Framework Design Guidelines: Krzysztof Cwalina, Brad Abrams
  • Tog on Interface: Bruce Tognazzini
  • GUI Bloopers: Jeff Johnson