I can recommend the following article:
The Basics of Programming Model Design
Dave Stearns
Microsoft Corporation, June 1998
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_basicpmd.asp
Of particular relevance is the chapter, 'When to Use Properties vs.
Methods', so I'll quote some of it here:
"The first question people will often ask me is, "When should I make
something a property and when should I make it a method?" Note that in
COM everything is really a method. Properties are always just a pair
of get and set methods that have been marked as a property in the
Interface Description Language (IDL). For Microsoft Visual Basic
developers, this is accomplished by using Property Get and Property
Let/Set procedures instead of functions and subroutines. When the
developer marks something as a property, Automation clients such as
Visual Basic and Visual Basic Scripting Edition (VBScript) can then
refer to that as if it were a data member of the object, but code is
always run in the class. In fact, if you just mark a class-level
variable in your Visual Basic class as Public, Visual Basic
automatically creates a simple set of property procedures for you.
"To determine if something should be a property or method, use the
following rules:
• Anything that reflects a state of the object should be exposed as a
property. Examples include Caption, Opened, or Visible.
• If the object state is read-only, it should still be exposed as a
property but should be read-only (that is, it does not include a
propput or, in Visual Basic, a Property Let/Set procedure). Examples
might include hWnd, hDC, or WindowStyle.
• If getting a value has no real side effect on the object, it's
likely a property and not a method. A property get can involve code
that retrieves something from a data source the first time it's
requested, but that should be hidden from the developer using the
interface.
• Similarly, getting a property's value should not be order-dependent.
It should make no difference if you get the value of property A and
then B, or vice versa.
• Anything that performs an action and has no real "property get"
meaning should be a method. Examples here include Open, Save, Export,
Add, and Remove. If the method is directly affecting a state that
would be valuable for a developer to also be able to read, it's
probably a property and not a method.
"This last point is important. I have often designed something as a
method first and then later realized that it also would be useful to
get the value of the state affected by the method. This sometimes
means turning the method into a Read/Write property, and other times
just means adding a Read-only property that is affected by the
existing method call. The right choice depends on your design style
and what you are trying to expose to the developer."
--