What Are Components?
Components are simply little bits of an overall system.  If you have had any experience with Object-Oriented design, please don't shoot me for such a simplistic explanation - I'll do better, honest ;-).  Components can help code reuse - if you find yourself repeating the same code, you can write a component for your task and place it on future projects with two mouse clicks.

Have a look at the Delphi component palette.  You will see all sorts of objects - buttons, checkboxes, shapes and so on.  If you find you have a recurring task that is getting pretty monotonous, you can create a component to do the job for you.  Once you've finished it, you can install it and use it like any other. 

   Properties
Properties are data held by the component.  An example here would be a "car" component, which would properties for "PaintColour", "Manufacturer", and so on.  You can consider properties to be just variables, although they are more complex than that.

When you are defining properties, you usually specify three things: its data type, how to read the property and how to write the property (if applicable). The first is obvious; if you want the property, you need to know what it is actually representing! The next two aren't quite as obvious.

Accessing properties seems straightforward... we've all done it (e.g. "Button1.Caption := 'xyz';", where we're accessing Button1's Caption property).  This just seems like a simple variable assignment, and that's probably what you assumed it was. Well, it's not!  Delphi performs some trickery and actually does some work behind the scenes.  So:

When accessing properties, you could either be using variables directly or calling functions behind the scenes!

The standard property declaration looks like this:

property SomeProperty: Integer read FMyInteger write SetMyInteger;

This defines a property "SomeProperty", of type Integer.  Note that properties are not actually variables in themselves, just ways of accessing other variables! Thus, the variable actually accessed with "SomeObject.SomeProperty" will be FMyInteger.  Now for the interesting bit: the read and write parts say how to access the data.  In this case, when the property is read (e.g. "if SomeObject.SomeProperty = 1") the value is taken directly from the variable, as if the code had said "SomeObject.FMyInteger".  However, when the property is set, it is not done directly!  The code actually calls a SetMyInteger procedure, which would be of the form:

procedure SetMyInteger(NewValue: Integer);

This gets called instead, as if the code had said "SomeObject.SetMyInteger(23)" instead of "SomeObject.SomeProperty := 23".

Now, the read and write parts can specify direct data access (by putting the variable name) or via procedures/functions (by putting the procedure/function name).  To give another example, here's a read-only property that gets its data from a function:

property SomeReadOnlyProperty: Boolean read GetMyValue;

This property cannot be written to, which safeguards the data nicely :-).  The GetMyValue function would be of the form: "function GetMyValue: Boolean;"  Whenever the property is accessed, it would call this function to retrieve the value... so the code "if SomeObject.SomeReadOnlyProperty = True then" would get translated into "if SomeObject.GetMyValue = True then" behind the scenes.

Important note!
The variables (e.g. FMyInteger) and procedures/functions (e.g. GetMyValue, SetMyInteger) are not available to the outside world!  They are hidden away using "private" or "protected", so any direct calls would result in errors.  This is good, as otherwise the entire purpose of read/write specifiers would be defeated.  Private, protected and other such keywords will be explained (much) later.

   Advantages of Properties
You should have noticed why properties are pretty cool, but here's a summary:

• They allow you to say how data gets accessed, protecting it
• They save you from 50,000 "get/set" lines of code, helping readability
• They allow you to check data integrity before changing the variables

The first one is pretty obvious, really.  If you declared your variables publicly they could be changed in any old way.  However, you can still allow direct access to your variables if you so desire.  Properties allow you to change the behind-the-scenes way of getting or setting data without having to rewrite any code that uses the component!

The second point is something that makes you really appreciate Delphi.  In other languages (for example C++) you do need to say "someObject.setThisValue(23)" everywhere.  This makes your code less readable and just plain sucks!  It, in my view, reduces the readability as it detracts from your main intent: you want to change the value, not call the function! Delphi has provided an elegant mechanism to avoid this kind of unnecessary code.

The last point is good for efficiency - if you have a graphical component, for example, you want to reduce the drawing as much as possible.  This can be done by a set procedure that checks if the old value is different from the new value.  Here's an example:

procedure TSomeComponent.SetBackgroundColour(NewColour: TColor);
begin
  if NewColour <> FBackgroundColour then
  begin
    FBackgroundColour := NewColour;
    Invalidate; // redraws the component
  end;
end;

This means that your component will only redraw itself if it gets a different property value.  This technique can be applied elsewhere, with error checks and other such data checking.

   Methods
Methods are very important!  These are procedures or functions, and define the behaviour of your objects. They are defined in the usual way, with one-line prototypes in the component and definitions later on.

   Events
Events get defined by you, and are called whenever you want to notify the programmer of something. You can usually ignore these until you get more experienced with components.  They boil down to pointers to class procedures, which means slight complications.  Events will be covered later, so don't worry too much about them. 

   Question, Suggestions...
If you have any questions or comments to this (huge) article, please post them on the Delphi Programming Forum. Discuss!