Runtime & concurrency
Reveal answer and reasoning
Define a deliberate external key and an allowed capability, then select known factories or Type entries according to the product's extension requirements. Validate target-to-source assignability as one step, but separately establish a supported constructor or factory and the policy that permits that handler. For a fixed set, explicit factories can make reachability and dependencies easier to inspect than scanning arbitrary assemblies and reconstructing identities from simple names.
Test an accepted implementation, a sibling or incompatible type, an unknown key, and a compatible type lacking the chosen construction contract. Preserve distinct failures so a missing constructor is not reported as ordinary input rejection. If real plugin loading is required, test the actual host's loading, lifetime, and deployment restrictions. The wrong design assumes IsAssignableFrom makes every discovered type safe and instantiable, or assumes two types with the same printed name identify the same implementation across assemblies.
What a strong answer covers
- Separate key, compatibility, construction, and policy.
- Prefer explicit allowed factories when a fixed set fits.
- Test real extension-host and deployment boundaries.
Common pitfall
Using a compatibility check as both a constructor guarantee and an authorization decision.
Follow-up questions
- How would NativeAOT change unrestricted discovery?
- How would you avoid collisions between identical simple type names?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.