BorlandTalk.com

BMitchell · Guest

I know this may be over engineering here but I am trying to learn how to
do something. Basically take two derived classes that could be used in
the same object but not at the same time.

Lets say I have an object called TContact. This object can be used for
any number of entities (person or company). I need the phone number to
work with different countries. But TContact only needs one object for
the phone number but only based on the current country. How do I do
this? OOP seems to be escaping me right now. I have been doing some
reading but can not get the grasp of it so I am trying to put objects
together and see what happens.

Thank you for your help.

TPhone = class(TObjectList)
private
FNumber: string;
FExtension: string;
FPhoneType: TPhoneType;

public
property PhoneNumber: string read FNumber write FNumber;
property PhoneExtension: string read FExtension write FExtension;
property PhoneType: TPhoneType read FPhoneType write FPhoneType;
end;

TUSPhone = class(TPhone)
public
function GetNumber: string; //Just returns the phone number in
the correct format for US
procedure SetNumber(pNumber: string); //checks the phone number
for correct number of digits
end;

TEnglandPhone = class(TPhone)
public
function GetNumber: string; //Just returns the phone number in
the correct format for England
procedure SetNumber(pNumber: string); //checks the phone number
for correct number of digits
end;

TUSAddress = class(TObjectList)
private
FAdressType: TAddressType;
FNumber: string;
FStreetName: string;
FAptNumber: string;
FState: string;
FCity: string;
FCountry: string;
FCounty_Prov: string;
public
//Add getters and setters for address
end;

TContactInfo = class(TObject)
private
FPhone: ?; //This could be either TUSPhone or TEnglandPhone; I
have seen examples where I would just declare it as TPhone, but I don't
understand how that helps me.
FUSAddress: TUSAddress;
public
Q: What procedures and properties would I need here to complete the
contact list?

end;

Yannis · Guest

BMitchell wrote:

Joanna Carter [TeamB] · Guest

"BMitchell" <billy.dean.mitchell (AT) gmail (DOT) com> a écrit dans le message de news:
448a1517 (AT) newsgroups (DOT) borland.com...

Yannis has given you the idea of using virtual methods to allow you to treat
Phone numbers correctly.

| TPhone = class(TObjectList)

You would never derive a singular noun like Phone from a list class. You
should always have a separate typesafe list class for every type for which
you need to hold a list.

| TUSAddress = class(TObjectList)

Once again, don't confuse single entities with lists.

Now to look at a couple of other issues.

First, I cannot see why you would need a TPhoneType and then You don't have
to repeat the "Phone" in the property names, otherwise you get code that
looks like :

begin
aPhone.PhoneNumber
...

You know that it is a phone so just use "Number" for the property name.

So your Phone class would look like this :

TPhone = class(TObject)
private
fNumber: string;
fExtension: string;
protected
function GetNumber: string; virtual;
procedure SetNumber(const value: string); virtual;

procedure SetExtension(const value: string); virtual;
public
property Number: string
read GetNumber
write SetNumber;
property Extension: string
read fExtension
write SetExtension;
end;

Then you will need a "metaclass" for our "factory" method

TPhoneClass = class of TPhone;

Then you need a typesafe list class to hold lists of Phone numbers. You
should never derive from TObjectList as this then allows users of your list
class to add anything, not just Phone objects to your list.

TPhoneList = class(TObject)
private
fItems: TObjectList;
public
constructor Create;
procedure Add(item: TPhone);
property Item[idx: Integer]: TPhone
read GetItem; default;
...
end;

You don't need a default property value unless you intend to use these
classes in the IDE designers, but then you would have to derive from
TComponent and I wouldn't recommend having business classes in the IDE
designer, they should be totally UI neutral. Instead of using the default
modifier, which doesn't set the property value outside of the designers, you
should initialise the field in the constructor.

Then you can add the list of numbers to the Contact class, but you really
should add a "Factory" method to create an appropriate Phone for the country
of the Contact :

TContact = class(TObject)
private
fCountry: TCountryCode;
fPhones: TPhoneList;
procedure SetCountry(country: TCountryCode);
function GetPhone(idx: Integer): TPhone;
public
constructor Create;
property Country: TCountryCode
read fCountry
write SetCountry;
property Phone[idx: Integer]: TPhone
read GetPhone;
function AddPhone: TPhone;
procedure RemovePhone(phone: TPhone);
end;

implementation

function TContact.GetPhone(idx: Integer): TPhone;
begin
if (fPhones = nil) then
raise Exception.Create('No phones stored')

if (idx < 0) or (idx >= fPhones.Count) then
raise Exception.Create('Index out of bounds');

result := fPhones[idx];
end;

constructor TContact.Create;
begin
fCountry := ccUS;
end;

function TContact.AddPhone: TPhone;
var
phoneClass: TPhoneClass
begin
case fCountry of
ccUK:
phoneClass := TUKPhone;
ccFrance:
phoneClass := TFrancePhone;
else
phoneClass := TUSPhone;
end;

result := phoneClass.Create;

if fPhones = nil then
fPhones := TPhoneList.Create;
fPhones.Add(result);
end;

procedure TContact.RemovePhone(phone: TPhone);
begin
if fPhones != nil then
begin
fPhones.Remove(phone);
if fPhones.Count = 0 then
begin
fPhones.Free;
fPhones := nil;
end;
end;
end;

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

BMitchell · Guest

So, the TContact list would just need a new property for the country,
and a constructor that would check which one is selected and set the
field to the correct version. Example:

type
TCountryCode = (ccUS, ccEngland); //Short list

TPhone = class(TObjectList)
private
FNumber: string;
FExtension: string;
FPhoneType: TPhoneType;
public
property PhoneNumber: string read FNumber write FNumber;
property PhoneExtension: string read FExtension write FExtension;
property PhoneType: TPhoneType read FPhoneType write FPhoneType;
function GetNumber: string; virtual; abstract;
procedure SetNumber(pNumber: string); virtual; abstract;
end;

TUSPhone = class(TPhone)
public
function GetNumber: string; override;
procedure SetNumber(pNumber: string); override;
end;

TEnglandPhone = class(TPhone)
public
function GetNumber: string; override;
procedure SetNumber(pNumber:string);override;
end;

TContact = class(TObject)
FCountry: TCountryCode;
FPhone: TPhone;
procedure SetCountryCode(pCountry: TCountryCode);
public
property Country: TCountryCode read FCountry write SetCountryCode
default ccUS;
constructor Create; override;
end;

implementation

constructor TContact.Create;
begin
inherited;
SetCountryCode(pCountry);
end;

procedure TContact.SetCountryCode(pCountry: TCountryCode);
begin
case pCountry of
ccUS: FPhone := TUSPhone.Create;
ccEngland: FPhone := TEnglandPhone.Create;
end; //Case
end;

Jim Cooper · Guest

Peter Morris [Droopy eyes · Guest

Peter Morris [Droopy eyes · Guest

Bob Dawson · Guest

Having things like TEnglandPhone or TUSPhone is a bad bad idea.
Combinatorial explosion.

Look up the strategy pattern. Basically we're going to remove all
localisation issues from TPhone and move them into a Localization class.
Initial implementation might look something like this:

TPhone
private
FNumber : string;
FLocation: integer;
procedure SetNumber(const aNumber : string);
function GetFormattedNumber(const aLocation : integer) : string;
function GetValid: boolean;
public
property Number : string read FNumber write SetNumber;
property FormatedNumber : string read GetFormattedNumber;
property Location : integer read F write F. //todo
property Valid : boolean read GetValid;
end;

function TPhone.GetFormattedNumber(const aLocation : integer): string;
var
localizer : TPhoneLocalizer;
begin
localizer := TPhoneLocalizer.Create(FLocation);
try
Result := localizer.Format(FNumber);
finally
localizer.Free;
end;
end;

procedure TPhone.SetNumber(const aNumber : string);
var
localizer : TPhoneLocalizer;
begin
localizer := TPhoneLocalizer.Create(FLocation);
try
FNumber := localizer.StripFormattingIfPresent(FNumber);
finally
formatter.Free;
end;
end;

function GetValid : boolean;
var
localizer : TPhoneLocalizer;
begin
localizer := TPhoneLocalizer.Create(FLocation);
try
Result := localizer.IsValid(FNumber);
finally
formatter.Free;
end;
end;

bobD

Joanna Carter [TeamB] · Guest

"Bob Dawson" <RBDawson (AT) prodigy (DOT) net> a écrit dans le message de news:
448acb40$1 (AT) newsgroups (DOT) borland.com...

| Having things like TEnglandPhone or TUSPhone is a bad bad idea.
| Combinatorial explosion.
|
| Look up the strategy pattern. Basically we're going to remove all
| localisation issues from TPhone and move them into a Localization class.
| Initial implementation might look something like this:

I would totally agree with you Bob, my simple example was only to further
demonstrate the principle of polymorphism to the OP; sufficient for a small,
limited test program. Your use of the Strategy pattern has to be the only
real way to go for a full blown commercial app.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

Yannis · Guest

Jim Cooper wrote:

Peter Morris [Droopy eyes · Guest

Jim Cooper · Guest

CheGueVerra · Guest

Peter Morris [Droopy eyes · Guest

Bob Dawson · Guest

"Peter Morris wrote