The Delphi Object Model (PART II)

热     ★★★★

Object Life Cycle

For most objects, you call a constructor to create the object, use the object, and then call Free to free the object. Delphi handles all the other details for you. Sometimes, though, you need to know a little more about the inner mechanisms of Delphi''''s object model. Example 2-8 shows the methods that Delphi calls or simulates when it creates and frees an object.

Example 2-8: The Life Cycle of an Object

type
  TSomething = class
    procedure DoSomething;
  end;
var
  Ref: TSomething;
begin
  Ref := TSomething.Create;
  Ref.DoSomething;
  Ref.Free;
end;

// The hidden code in the constructor looks something like this:
function TSomething.Create(IsClassRef: Boolean): TSomething;
begin
  if IsClassRef then
  try
    // Allocate the new object.
    Self := TSomething.NewInstance;
 
    // NewInstance initializes the object in the same way that
    // InitInstance does. If you override NewInstance, though,
    // and do not call the inherited NewInstance, you must call
    // InitInstance. The call is shown below, so you know what
    // happens, but remember that ordinarily Delphi does not
    // actually call InitInstance.
    InitInstance(Self);
 
    // Do the real work of the constructor, but without all the
    // class reference overhead. Delphi does not really call the
    // constructor recursively. 
    Self.Create(False);
 
    Self.AfterConstruction;
  except
    // If any exception occurs, Delphi automatically calls the
    // object''''s destructor.
    Self.Destroy;
  end
  else
    Self.Create(False);
  Result := Self;
end;
 
// The hidden code in the destructor looks something like this:
procedure TSomething.Destroy(Deallocate: Boolean);
begin
  if Deallocate then
    Self.BeforeDestruction;
 
  // Delphi doesn''''t really call the destructor recursively, but
  // this is where the destructor''''s real work takes place.
  Self.Destroy(False);
 
  if Deallocate then
  begin
    // Delphi doesn''''t really call CleanupInstance. Instead, the
    // FreeInstance method does the cleanup. If you override
    // FreeInstance and do not call the inherited FreeInstance,
    // you must call CleanupInstance to clean up strings,
    // dynamic arrays, and Variant-type fields.
    Self.CleanupInstance;
    // Call FreeInstance to free the object''''s memory.
    Self.FreeInstance;
  end;
end;

Access Levels

Like C++ and Java, Delphi has different access levels that determine which objects can access the fields, methods, and properties of another object. The access levels are as follows:

private
Declarations that are declared private can be accessed only by the class''''s own methods or by any method, procedure, or function defined in the same unit''''s implementation section. Delphi does not have C++-style friend declarations or Java-style package level access. The equivalent in Delphi is to declare package or friend classes in the same unit, which gives them access to the private and protected parts of every class defined in the same unit.

protected
A protected declaration can be accessed from any method of the class or its descendants. The descendent classes can reside in different units.

public
Public methods have unrestricted access. Any method, function, or procedure can access a public declaration. Unless you use the $M+ compiler directive (see Chapter 8, Compiler Directives, for details), the default access level is public.

published
Published declarations are similar to public declarations, except that Delphi stores runtime type information for published declarations. Some declarations cannot be published; see Chapter 3 for details. If a class or a base class uses the $M+ directive, the default access level is published.

TIP:
Delphi''''s IDE declares fields and methods in the initial unnamed section of a form declaration. Because TForm inherits from TPersistent, which uses the $M+ directive, the initial section is published. In other words, the IDE declares its fields and methods as published. When Delphi loads a form description (.dfm file), it relies on the published information to build the form object. The IDE relies on the initial, unnamed section of the form class. If you modify that section, you run the risk of disabling the IDE''''s form editor.

automated
Automated declarations are similar to public declarations, except that Delphi stores additional runtime type information to support OLE automation servers. Automated declarations are obsolete; you should use Delphi''''s type library editor instead, but for now, they remain a part of the language for backward compatibility. A future release of Delphi might eliminate them entirely. Chapter 3 describes automated declarations in more depth.

A derived class can increase the access level of a property by redeclaring the property under the new access level (e.g., change protected to public). You cannot decrease a property''''s access level, and you cannot change the visibility of a field or method. You can override a virtual method and declare the overridden method at the same or higher access level, but you cannot decrease the access level.

Hiding a Constructor

Sometimes, a class is not for public use, but is a helper class whose use is entirely subservient to another class. In that case, you probably want to make the constructors for the helper class private or protected, but this is tricky. TObject declares a public constructor: Create. Even though the helper class''''s constructors are private or protected, you can call the public Create constructor inherited from TObject.

Although you cannot change the access level of the inherited Create constructor, you can hide it with another public constructor. Because the derived constructor should not be called, it can raise an exception. For example:

type
  TPublic = class;
  TPrivateHelper = class
  private
    // TPublic is the only class allowed to
    // call the real constructor:
    constructor Create(Owner: TPublic);
      overload;
  public
    // Hide TObject.Create, in case someone
    // accidentally tries to create a
    // TPrivateHelper instance.
    constructor Create;
      reintroduce; overload;
  end;
  TPublic = class
  private
    fHelper: TPrivateHelper;
  public
    constructor Create;
    destructor Destroy;
  end;
 
constructor TPrivateHelper.Create;
begin
  raise Exception.Create(''''Programming error'''')
end;
 
constructor TPublic.Create;
begin
  // This is the only place where
  // TPrivateHelper is created.
  fHelper := TPrivateHelper.Create(Self);
end;

Properties

A property looks like a field but can act like a method. Properties take the place of accessor and mutator methods (sometimes called getters and setters), but have much more flexibility and power. Properties are vital to Delphi''''s IDE, and you can also use properties in many other situations.

A property has a reader and writer to get and set the property''''s value. The reader can be the name of a field, a selector for an aggregate field, or a method that returns the property value. The writer can be a field name, a selector for an aggregate field, or a method that sets the property value. You can omit the writer to make a read-only property. You can also omit the reader to create a write-only property, but the uses for such a beast are limited. Omitting both the reader and the writer is pointless, so Delphi does not let you do so.

Most readers and writers are field names or method names, but you can also refer to part of an aggregate field (record or array). If a reader or writer refers to an array element, the array index must be a constant, and the field

[1] [2] [3] [4]  下一页

The Delphi Object Model (PART II)
作者：闵涛 文章来源：闵涛的学习笔记 点击数：3318 更新时间：2009/4/23 18:43:51
	The Delphi Object Model (PART II)
教程录入：mintao    责任编辑：mintao
上一篇教程： The Delphi Object Model (PART I) 下一篇教程： The Delphi Object Model (PART III)
【字体：小 大】【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】

注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网]

网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！）