Setting Up the Scenario

Let's say, for the sake of argument, that you have a bunch of classes you want to display in forms that contain listviews. And let's say that you only want to write the load routine once so that it can be used on all of the list forms in such a way that each developer does not have to come up with their own code to create and fill that list form. Does this sound familiar? If you have worked through the first nine chapters of this book, you will understand this scenario. You had to code each of the load listview routines. Now, expand that out by 20 or 30 forms…. Extrapolating out what you have created so far, each load list routine minus comments and empty lines, is approximately 30 lines of code. If you have 20 forms in an application that do the same thing, that is 600 lines of code that can be removed from the application if you implement this using reflection! And let me say that this is only the tip of the iceberg.

Caution

After seeing what you can do with this ability, you might be encouraged to start doing everything with reflection—do not. Reflection is great for certain tasks, but for other tasks it is a great deal more work than it is worth. Also, planning these types of classes correctly takes time. So, before you decide to start implementing attribute classes all over the place, think about the complexity and maintainability of the application. In general, reflection allows you to consume classes by using generic routines that do not have to be customized for each implementation.

The way this attribute class works is the following: You will attach an attribute class to each property you want to display in the listview. The listview load method looks in your class and determines which properties to add to the listview as columns. It creates those columns and then adds the values of the object to the listview. Once you have created this method the first time, it is a cinch to reuse it.