by Unknown user
When I started refactoring the UI code for the original many-to-many checkboxes class I had a pretty clear idea of where I wanted to go.
...
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.
This pretty typical of my class design process. I often change method and even class names as I go along, and sometimes classes go away entirely as I realize they don't fit with what I'm trying to accomplish.
Next time I'll look in more detail at how to go about saving and loading checkbox data.