Object Studio
Object anatomy
An object models an application and exposes actions to processes. Internally it uses pages, actions, decisions, and reads/writes. Objects have business objects (application interfaces) and utility objects (reusable helpers such as date or string utilities).
Interface design
Actions should be coarse-grained and meaningful: 'Create Customer' rather than 'Click Save'. Inputs and outputs should be typed and documented. Objects should hide application detail so that a UI change requires changing only the object.
Traps
A common trap is exposing UI-level actions to processes, which couples processes to screens. Another is putting business validation in objects. Questions may test spy modes: Win32, Accessibility, HTML, and Region modes each suit different technologies, and the correct mode depends on the target application. Region mode is a fallback and is brittle. Also remember that objects can be shared across processes, so changes need impact analysis.
Error handling in objects
Objects should raise clear exceptions and avoid swallowing errors. Recovery and retry policy generally belongs to the calling process, though objects may retry transient UI issues.
Rule of thumb
If a process would break when a button moves, the object interface is too fine-grained.
Worked example
A CRM object exposes 'Create Customer' with inputs for name and ID. Internally it navigates, fills fields, saves, and confirms the record. If the confirmation fails, it raises a clear exception rather than returning a silent success.