More object/class based ponderings

[Crisp_N_Dry]

After reading a recent post regarding the delights of object/class based development it spurred me to use them in my own projects. I was previously using records and separate functions and procedures. What I'm wondering is how small is too small for an object. Here's my class for my logger that records all goings on within the game (it's very basic but that's half my point):

type
  TLog = Class
    LogFile: TextFile;
    MessageStr: String;//Last message logged
    public
      constructor Create(Filename: String);
      destructor Destroy;Reintroduce;
      procedure AddLog(Msg: String;Fatal: Boolean);//A fatal error will always result in a report
      procedure Report(Msg: String);
  end;

Is it really worth me creating a class with just 2 fields and 2 procdedures (Not including Create and Destroy of course)? How small is too small?

[{MSX}]

There's no too small A class is always worth writing if it fits.. There could be classes with even few members, for example a TLogger with just a TStringList and a Log() method.
Designing all in object is a Good Thing (tm) IMHO.

[Balaras]

Well, one advantage of using objects for logging is that it is then very easy to have several logs. Say one for overall application state, one for error and one for timing.

I agree with {MSX}. No too small. I tend to think in objects when coding.

/Balaras

[JSoftware]

lol.. that logger looks extremely suspeciously much like my old

well i have all my major objects in classes. The only records i have are vector2f, vector3f, vector4f, plane, ray, matrix4, matrix4x4

[Sly]

There is a case where using a class is overkill, and that would be in the case of vectors or matrices. You tend to have thousands of vectors and matrices in a decent game. Using a class for these means having a four byte overhead for each instance for the pointer to the virtual method table. Also, allocating large blocks of instances means you have to override InitInstance and FreeInstance of the base class to change the way the instances are allocated and freed.

Compare this with using records. Block allocation is easy. The size of each instance is exactly what you specify in the record declaration. No hidden method calls in creation and destruction. A lot more efficient in memory and CPU.

There is a middle ground where you specify the type as 'object'. This works very similar to records, but you can have methods in an object type.

type
  TVector = object
  public
    x, y, z: Single;
    procedure Dot(const v: TVector): Single;
  end;

Of course, Borland are deprecating the use of 'object' so I wouldn't be surprised if it disappeared from the language in a few more releases.

[WILL]

Of course, Borland are deprecating the use of 'object' so I wouldn't be surprised if it disappeared from the language in a few more releases.

I think it is more fair to say it will disappear from the Delphi compiler than the Object Pascal language. With all these other compilers now supporting the Borland extended version of Apple's original dialect, they don't have full claim on the language anymore.

Some compilers that now use the Object Pascal standard in some form are: Chrome, Delphi, Kylix and Free Pascal.