Object Design
What Object Design covers
Business Objects encapsulate application interaction. Candidates must understand object layers (the object, its pages, and actions), the distinction between action stages exposed to processes and internal sub-pages, and the conventions for naming and parameter design. Key concepts: input and output parameters, the object's internal data items, the use of the Application Modeller to define elements and their attributes, spying modes (HTML, accessibility, region, UIA), and the importance of robust element matching over coordinates.
Also understand wait stages, timeouts, and attach/detach behaviour for applications; how to expose a single action per business task rather than one action per click; and how objects should throw exceptions upward rather than deciding business outcomes. Objects should be stateless where possible, with session state managed explicitly.
Traps in questions
Frequent traps: exposing low-level click actions to processes (leaking UI detail into orchestration), spying by screen coordinates (fragile), hard-coding waits instead of using wait stages with sensible timeouts, and letting an object mark a queue item complete. Another trap is an object that silently returns a failure flag instead of throwing, forcing every caller to re-implement error handling.
Rule of thumb
Design one action per meaningful business interaction ("Log In", "Enter Reference"), with parameters that describe business data, not UI widgets. If an action needs more than a handful of parameters or exposes element names, it is probably too granular. Elements should match on stable attributes such as element id or path, with fallbacks, never on absolute position.