That is an interesting way of thinking about UI design, and I think I tend to agree.
I was talking about the programming level, though. The code using a text entry box should not need to know the details of the position of the selected text rectangle(s), or the color of the selection, or the position of scrolling if the text is too long. You probably want to expose the selection in terms of start and end indices, but the cached coordinates that are used for drawing the rectangles are internal details that are not useful outside the class.
Actually, I think saying "hiding state" was actually incorrect on my part, I think one typically says "encapsulating state". The object provides a nice way of bundling all the necessary information into one place and code outside the object does not need to worry about it, and can only interact with it through a well-defined interface (the methods).
I was talking about the programming level, though. The code using a text entry box should not need to know the details of the position of the selected text rectangle(s), or the color of the selection, or the position of scrolling if the text is too long. You probably want to expose the selection in terms of start and end indices, but the cached coordinates that are used for drawing the rectangles are internal details that are not useful outside the class.
Actually, I think saying "hiding state" was actually incorrect on my part, I think one typically says "encapsulating state". The object provides a nice way of bundling all the necessary information into one place and code outside the object does not need to worry about it, and can only interact with it through a well-defined interface (the methods).