Jamie Honan wrote:

> Is my buzz word detector too sensitive, having been decalibrated
> by caffinated beans and re-oriented by un-objective paradigms?

Naturally everyone that you ask will have different ideas. Therefore,
answering purely for myself, a component is a reusable unit of software
with some or all of the following characteristics:

- it is, or can be, distributed as a package, often in binary form
- the things that it depends upon (other components, libraries, remote
services, etc.) are known, and a list of them included in the package
- it typically uses only publically-specified interfaces of the things
that it depends upon
- it exposes a publically-specified API, and usually includes its own
documentation, perhaps in some standardised form
- typically, it does not allow things which use it (other components,
libraries, remote clients, etc.) to utilise anything other than its
public interfaces
- it is not intended to be an assumed part of a development environment,
rather it is intended to be a thing which can, optionally, be introduced
into a creation
- it manages its own (un)installation, or conforms closely to the
intended platform's (un)installation facility
- it is not intended for use on its own with just an OS under it, it is
expected to be used in some container context (i.e. it is not,
typically, an application for a user to use)
- it is a higher-level abstraction than a class, if implemented in an OO
language it typically consists of many classes
- its intended user is a developer, thus the exposing of an API
- it often has a (default) UI, again, for ease of dropping it into an
application by a developer
- even though it consists of more than a single class, it typically has
instances. In this sense, it differs from a typical library, even though
it may be implemented as a library.

It might help to describe a component as a generalised plug-in. Plug-ins
tend to have most of the above characteristics, but are tied to working
with a single (type of) application. Components are intended to be tied
to a framework that can be used for (almost) any kind of application. It
may well make sense to implement plug-ins as components, if they stand
any chance of having wider use than in the specific application that
they were built for.

Co-incidentally, Conrad and I had a similar discussion yesterday about
audio plug-ins for something that he's working on. It seems that making
things into Bonobo components, at least initially, might be overkill,
but it does seem attractive in the long term. One particular benefit of
Bonobo is that has already had to solve all of the problems that the
designer of a plug-in API has to solve, but does so rather more
generally so that it can be used in many types of application. This also
makes writing such "plug-ins" slightly more difficult. <sigh>

As per earlier conversations, the open-source community has an urgent
need to develop better means of re-use. Components are a likely part of
that.

- Raz


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Reply via email to