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