...
My standard technique for breaking the impasse is to think not about not to think about how I want to implement the class to accomplish some end, but rather to think about how I want to use the class.
That's an important distinction. Most developers I know have a built-in bias to think about implementation details when presented with a problem, and I'm no different. I immediately think about the code, and . And why shouldn't I? I'm a developer, right? But thinking about the code can get in the way of a good implementation.
...
At first glance a call like ListCheckbox.LoadCheckboxData() makes me uneasy, because it suggests that this class is talking to a database of some kind, and that would mean that I'm mixing my UI layer and my data layer. But I am going to have to get the checkbox data from somewhere, and I am going to have to save it to somewhere, so and it probably won't be the checkbox class that does the actual saving and loading. I think I'll leave that in for now until I have a clearer picture of how everything fits together.
...