Random Thoughts on Component Based Programming 

If you're not aware, I've become quite active in the GotDotNet forums, answering a lot of questions for people are having random issues with programming in .NET. (My username there is schweitn in case you're wondering... go figure). Of late, I've seen a lot of discussions and issues centered around different features of a component, or usually a group of similar components... not understanding the difference between them, or even caring that there are differences in the first place. One example of this is with the usage of Data Structures. People often times only use one or two different data structures, but probably have no clue how they are implemented underneath, and what the advantages or disadvantages are of a specific one.

Another example of this phenomena can be found at CodeGuru: Performance Matters: Choose Your Library Wisely. I would just like to mention that that article has a lot to do with VB 6 libraries... and from my personal experience it is the VB programmers who are most guilty of this.

So some of you may ask... why does this matter? Isn't the beauty of component based programming the fact that you can use a lot of off the shelf software, plug them together with some Elmers, and not care about how they're implemented underneath? Isn't this what C++, then COM, then .NET all have been working toward? What are you... some sort of heretic? Of course not. I love components. I WRITE components. But I think what is being lost is the fine art of understanding a concept called "Theory of Operation". People are so busy throwing components into their software, that they're not looking at whether this is the right component to use in the first place.

One area where this is especially clear is in the lack of variety by some people in their use of Data Structures. Most programmers in the C++ world (and now in C#) will stick to about 3. Built in arrays, some form of vector (re-dimensionable array like STL Vectors or the ArrayList in .NET) and some form of Linked List (Once again like those offered in STL). Those are great. But do you understand when you should use one and when to use the other? What about Queue's, and Stacks, and Hash Tables, and Binary Trees and Skip Lists and Sets!? They all have different advantages and disadvantes depending on your purpose. Do you need random access? Do you need high performance searches? Are you going to know the size of the structure ahead of time? Do you need good insertion performance? There are many questions to ask, and depending on your answer, your structure of choice may radically change.

Components are great at abstracting away details so that you don't have to worry about them. But before you go and and use that component, have an understanding of those details. I know it sounds contradictory... but you should always know what something is doing for you. That of course is why Wizards and I have never been in good standing... but thats for another post.