OO Design: Negating methods? 1

[Glenn9999]

I've had the recent occasion to code something involving TFileStream, and came across a question regarding design.

What I'm doing (more or less) makes it suitable to descend a class from that. The problem is, a lot of the methods of TFileStream are either irrelevant or run completely counter to the function of the code I'm writing. I know I can override methods and get what I want done, and in fact I need to completely replace two of the methods in TFileStream in order to do what I want. The problem is the list of counter-productive methods.

So...I have two options. Option #1: List counter-productive methods in the protected section with overrides and define empty methods.

TMyClass = class(TFileStream)
...
protected
  function Seek(Offset: Longint; Origin: Word): Longint; override;

function TMyClass.Seek(Offset: Longint; Origin: Word): Longint;
begin
end;

Or Option #2: Define an instance of TFileStream in my class, create/destroy it in my constructor/deconstructor and then use it.

TMyClass = class(TObject)
  private
    fFileStream: TFileStream;
...

So the question: Which is the more preferred way to do it?

 

[whosrdaddy]

Encapsulation (option 2) is the way to go.
The goal of a class should be clear and concise.
But encapsulation renders testability difficult, but can be solved in this case by using constructor injection (ie passing a TStream object via the constructor).

I hope this makes sense

/Daddy

-----------------------------------------------------
Helping people is my job...

 

[Glenn9999]

Option #2 smelled right (as it has in most of the cases I've run into). The problem is that I'm not sure if there were any standard design sets or rules on when to do one or the other.

So when does one actually favor using inheritance as opposed to encapsulation?

 

[whosrdaddy]

Inheritance is needed when you want to share the same behavior but the inherited object can change the implementation.

Think along these lines:

type 
 TAnimal = class
 public
   procedure MakeNoise; virtual; abstract;
 end; 

 TDog = class(TAnimal)
 public
  procedure MakeNoise; override;
 end;

 TCat = class(TAnimal)
 public
  procedure MakeNoise; override;
 end;

...

procedure TDog.MakeNoise;
begin
 ShowMessage('woef woef');
end;

procedure TCat.MakeNoise;
begin
 ShowMessage('miauw');
end;

-----------------------------------------------------
Helping people is my job...

 

[Glenn9999]

Thanks. So inheritance is functionally more for minor modifications, while encapsulation is for major ones?

 

[whosrdaddy]

Ask yourself this simple question:
Is the class that you are making a TStream like class? in other words, does it behave as a Stream object?
Yes -> Inherit from the abstract class
No -> Encapsulate

-----------------------------------------------------
Helping people is my job...

 

[Griffyn]

Agreed with all this. There are lots of examples in the Delphi source where encapsulation is done, eg. TThreadList - a thread-safe list. Even though it presents like a TList, it encapsulates and presents methods that handle the locking aspects.