Should a programmer be able to perform all operations programmatically on a object that a user could do?
By way of example, I’m working with a list selection object. To populate the list List.AddItem(itemData) is repeatedly called until it is built. A user can then:
- View the entire list
- Select a single item from the list
However there is no programmatic way to list all of the items. Nor is there an easy way to set an item as selected. You can if you keep track of what was added to the list and call List.SelectItem(itemData). This means you’d have to maintain an independent list of the items separate from the object, which could cause it’s own problem (This bit of ugliness isn’t necessary to the question, but part of the motivation).
In general if a user can get information about an object or perform an action on an object should this same functionality be available to the programmer and not hidden? I suspect the answer is “yes” but recognized I may be overgeneralizing from this one case that I’m unhappy with.
7
What you’re asking is really “Should the programmer have access to the applications state?”. I would argue yes. The situation you’re describing lacks a clear separation between the model and view of your application. Specifically the state of the model seems to be wrapped up in view code.
With better separation of concerns you would have a model that held a list object, and a view that then reflected that list. You could then manipulate the list as you chose.
So to answer your original question, I would say YES the programmer should be able to do anything the user could do, because the full state of the application should be held in the model where the programmer has access. The user should simply be interacting with a view that exposes ways to interact with the model to which a developer has full access.