Do Components Exist

DoComponentsExist? I couldn't resist based on this identity crisis we're having on whether a component is an object or a class or a library or graphical or non-graphical, etc. Descartes must be rolling over in his grave right now ;-)

They have to exist. Sales and marketing people are talking about them. Components are not a technology. Technology people seem to find this hard to understand. Components are about how customers want to relate to software. They want to be able to buy their software a piece at a time, and to be able to upgrade it just like they can upgrade their stereo. They want new pieces to work seamlessly with their old pieces, and to be able to upgrade on their own schedule, not the manufacturer's schedule. They want to be able to mix and match pieces from various manufacturers. This is a very reasonable requirement. It is just hard to satisfy. -RalphJohnson

It's also something that happens quite regularly, Photoshop for example, is a perfect example of allowing plug in components to extend the functionality of the base program, and anyone can build plug-ins, same with audio software. Components most certainly exist.

Are components best understood by technology people as ObjectsSharedWithUsers? in the context of either (or both) visual builder tools (like JavaStudio?) or scripting languages (the best example currently being VBA within Excel but we can live in hope...)? This still calls into question their existence, but at least it preserves an interesting definition. --RichardDrake

If one of your goals is to make a system that users can extend with components, it helps to view your architecture as a big circle. In the center you have your domain code. The boundary of the circle is where you interface with the world (databases, devices, UI, etc).

Every time you add a new capability to your system, you have to change your domain classes and work your way outward to express the new capability at the edge of the circle. This is one of the reasons why most components are graphical rather than NonGraphicalComponents. Decreasing the amount of code that has to change from the center to the edge of the circle makes extensibility easier. One of the ways to avoid code change is use data and metadata extensively. For instance, if you use XML, you can add components closer to the center of the system and give them a data channel to the UI.

-- MichaelFeathers

I am not saying that components are about users. I'm saying they are about customers. It is the people who pay for software who are driving components. That is why sales and marketing people are talking about them. They know that people want this. So, they tell us to make it, or they tell us they have it already and our management buys it and tells us to use it.

In fact, making good components requires more than a particular technology like COM or EJB. It requires understanding the problem domain and figuring out how to carve it into the right kind of pieces. Component software requires some sort of underlying structure like COM or EJB, but that is just the start. You also have to develop standard interfaces on top of it, and they have to be the right kind of interfaces.

People do buy software in pieces and plug it into the rest of their software and have it work. In that sense, components exist. They aren't perfect, and the components you want often don't exist, but the fact that you can buy a new program and have it fit in with the others you already have shows that, by my definition, components exist.

--RalphJohnson

CategoryComponents