Options Information Evening for Future Success at Johnstone High School
This session covers the importance of making informed choices for post-school pathways, including employability updates, skill development, and positive destinations post-graduation. Discover the various pathways to success beyond traditional higher education, such as apprenticeships and work-based learning opportunities. Learn how Johnstone High School aims to equip students for successful transitions into the workforce or further education.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Application Programming Interface (API) An API is a kind of interface as well one designed for developers. You may be familiar with several: OS, language, graphics, GUIs, network protocols. Even if not writing a library, in a large code team, your code is an interface to other developers 2
Bezos Mandate 1. All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. It doesn t matter what technology they use. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 2. 3. 4. 5. It ended with: Anyone who doesn t do this will be fired. https://www.cio.com/article/3218667/have-you-had-your-bezos- moment-what-you-can-learn-from-amazon.html 3
Using what we know from this class, how might we design an API? 4
Methods for Improving Design Design principles 1. Follow iterative processes that lead to improved design 1. Reduce iterations by grounding design in principles and knowledge of human capabilities are most important for APIs? Design process What design principles do you think 2. Conduct evaluations on our designs and principles Evaluation 5
Nielsen 1. 2. Shneiderman S1. Strive for consistency S2. Seek universal usability S3. Offer informative feedback S4. Design dialogs to yield closure S5. Prevent errors S6. Permit easy reversal of actions S7. Keep users in control S8. Reduce short-term memory load Norman N1. Discoverability N2. Feedback N3. Conceptual Model N5. Affordances N4. Signifiers N5. Mappings N6. Constraints Visibility of system status Match between system and the real world User control and freedom Consistency and standards Error prevention Recognition rather than recall Flexibility and efficiency of use Aesthetic and minimalist design Help users recognize, diagnose, and recover from errors 10. Help and documentation 3. 4. 5. 6. 7. 8. 9. 6
Design Principles for APIs 1. Abstract/Model a Problem: API should solve a particular task in a general way 2. Minimal Completeness: API should be as small as possible, but no smaller ( when it doubt, leave it out ) 3. Discoverable: Model and naming intuitive and logical 4. Consistent: Names, objects, behavior, other APIs 5. Orthogonal: There should be no side effects, minimal overlap in exposed concepts 6. Loosely Coupled: Components should have few connections 7. Robust: Stable and tested 8. Documentation: API isn t an API without documentation Martin Reddy, API design for C++
Iterative Design Process Preliminary Investigation Identify Need (Re-)Design System Create representation of System Identify changes to be made Evaluate Outcome 8
Preliminary Investigation & Identifying Needs Recall: Functional & Non-Functional Requirements Non-Functional: Performance Platforms supported Security Scalability Concurrency Cost Functional: The intended functionality of the API What does the system do? Martin Reddy, API design for C++ 9
Considerations In Determining Requirements When collecting data What are users trying to achieve? What is their ideal workflow? What kinds of inputs should the API expect (types, value ranges)? What kinds of outputs should the API generate (types, formats, value ranges)? What formats & protocols must it support? What is their central mental model? What terminology do they use? Martin Reddy, API design for C++ 10
Requirements, Users, and Use Who are the users? Develop personas What are the uses? Develop use cases. Use cases should NOT assume any design but focus on tasks. Alternatively, user stories, which are at a slightly more abstract level, popular in Agile. From requirements, personas, and scenarios, identify key nouns, behaviors, and properties to help develop model. Martin Reddy, API design for C++ 11
Iterative Design Process Preliminary Investigation Identify Need (Re-)Design System Create representation of System Identify changes to be made Evaluate Outcome 12
Applying the Design Principles: Naming Name classes/objects after their piece of the model and purpose Abstract/base classes and interfaces should be named with adjectives for purpose Functions should be named for what they do Use Get, Set, Is, Are, Has liberally May be specific with Save, Print, etc. Functions not already associated with an object (e.g., non-member functions) should have their associated object in the name e.g., openFile() and formatString() Martin Reddy, API design for C++ 13
Applying the Design Principles: Naming Should convey relation to model and purpose. If this requires too many characters, you may be trying to do too much in one class or function. Example: Suppose you have a function that calculates the bill total and closes the order. checkout() is not descriptive as the total calculation is unclear calculateTotalAndCheckout()is descriptive but too long, suggesting this function does too much. Divide into two functions calculateTotal() and checkout() Martin Reddy, API design for C++ 14
Applying the Design Principles: Naming Use terms consistently: Should not have getPreviousVertex() and getNextNode() Avoid abbreviations, especially unknown ones Use abbreviations consistently: Should not have both getPrevVertex() and getPreviousEdge() Names should make clear what something does: isEmpty() vs empty() Use natural pairs, e.g. undo/redo, get/set Martin Reddy, API design for C++ 15
Applying the Design Principles: Parameters var getSubstring = function(s1, s2) Vs. var getSubstring = function(targetString, matchString) How many parameters? Recall Miller s law keep number of parameters low, <5 If you need more and they re optional, bundle in an object Martin Reddy, API design for C++ 16
Applying the Design Principles: Documentation var myColorAPI = {}; myColorAPI.setRed = function (redValue) { // }; myColorAPI.setGreen = function(greenValue) { // }; myColorAPI.seBlue = function (blueValue) { // }; myColorAPI.getRed = function () { // }; myColorAPI.getGreen = function() { // }; myColorAPI.getBlue = function () { // }; What are the valid values? What happens if you input a value outside of them? Martin Reddy, API design for C++ 17
Design Rationale Along with your requirements and designs should be a written design rationale. Users of an API have difficulty learning and using APIs if they don t understand the API s high level architecture of the intent behind its design. (Robilliard 2009) Martin Reddy, API design for C++ 18
