Simple Programming Design Question

Hello All:

    I am debating the most effective way to consolidate and/or organize my 
code in a small area of my program.

   My program is a vertical market application.

   What I am trying to organize is the retrieval and storage of individual 
workstation data settings.

   Currently most of those settings are stored in registry keys

   I eventually will want to move that data out of the registry and into an 
Ini file

   Sometimes I need to access one value, sometimes I need to access 3 or 4 
values.

   Currently - I do 2 things as follows:
        1) I use the following procedural routines: (I listed 2 of about 8)
                 function  GetStringRegValue(RegKey, RegVal, DefRegVal: 
String;ForceCreate: Boolean): String;
                 procedure SetStringRegValue(RegKey, RegVal, NewStValue: 
String);
        2) In older sections I actually wrote the code to create the 
TRegistry item and access it as well


    My question is this - should I re-write these procedures as objects ??? 
What benefits would I receive ???

   My own short answer is from a pragmatic standpoint - probably not
       Detriment to using an object - I have to create and free the object 
as it is used and I have to assign its properties - this makes my code 
verbose. In the procedural process - I can use a 1 line call to the 
procedure or function and simply put all of the "properties" as
parameters 
into the procedure/function. This procedureal approach also lets me change 
to an ini file format just like an object.
       Benefit to using an object - I could possibly extend that object in 
ways I am not aware of at present

   If I were to define the Object it might be as listed below.

Thank you.

Neil Huhta



Type

   TKeyType=Record {used to allow multiple values to be read or written from 
same key}
       RValueName: String;  // Registry Key Value
       RType: String; // Registry Value Type String, Boolean, etc
       RDefault: Variant; // RValue Default Value
       RValueResult: Variant; // Retrieved Value
    End;


 TNHRegAccess = Class(TComponent)
    private

      ReadStringRegValue
      SetStringRegValue
    public
      constructor Create( AOwner : TComponent ); override;
      Execute

    published
      property OperationType: TRegType {TRead, TWrite}
      property RegKey: String;
      property ForceKeyCreation: Boolean;
      property KeyValues: Array [1..100] of TKeyType;

  end;

Huhtaman a écrit :

>     My question is this - should I re-write these procedures as objects ???


Not as objects, but as a class :-)

> What benefits would I receive ???

Centralisation of code, therefore easier to maintain.

>    My own short answer is from a pragmatic standpoint - probably not
>        Detriment to using an object - I have to create and free the object

> as it is used and I have to assign its properties - this makes my code 
> verbose.

By saying you should use a class rather than objects, I mean to use a 
class with static methods.

e.g.

type
   TSettings = class
   public
     class function  GetStringRegValue(RegKey, RegVal, DefRegVal: 
String;ForceCreate: Boolean): String;
     class procedure SetStringRegValue(RegKey, RegVal, NewStValue: String);
     ...
   end;

Now all you have to do is to call it like this :

var
   regValue: string;
begin
   regValue := TSettings.GetStringRegValue(...);

   ...
end;

Furthermore, since you are defining Workstation behaviour, why not call 
the class TWorkstation and use more meaningful method names pertinent to 
the properties of the workstation concept? this would also allow you to 
change from registry to ini files without the client code realising that 
anything has changed.

Joanna

-- 
Joanna Carter [TeamB]

On Fri, 08 Feb 2008 09:45:21 +0000, Joanna Carter [TeamB] wrote:

>>     My question is this - should I re-write these procedures as objects
??? 
> Not as objects, but as a class :-)
Maybe its just me, but I fail to see how a class method is any
different to a global procedure?

>> What benefits would I receive ???
> Centralisation of code, therefore easier to maintain.
Again how is the code any more centralised or any easier to maintain
than what he already has?

-- 
Marc Rohloff [TeamB]

Marc Rohloff [TeamB] a écrit :

> Maybe its just me, but I fail to see how a class method is any
> different to a global procedure?

Because, provided the compiler supports it, data can be held in private 
static variables thus allowing the replacement of one single class 
definition if needs dictate.

> Again how is the code any more centralised or any easier to maintain
> than what he already has?

I'm not implying that the OP does this but, it may be that the
"global" 
solution is not all written in one unit. Also, writing this kind of 
detail means that someone googling for such matters may be ignorant of 
the difference between scattered global stuff and a well-designed static 
class.

Not everyone that reads these groups writes well-behaved code :-)

Joanna

-- 
Joanna Carter [TeamB]

> Maybe its just me, but I fail to see how a class method is any
> different to a global procedure?

I like static methods because it adds clarity, e.g.

Settings.GetCompanyName
Settings.GetSomethingElse

You might have a GetCompanyName in a business object or something, so it 
would be a bit ambiguous, whereas adding Settings. makes it clear.   Now in 
Delphi you could name your unit "Settings" and do the same thing, but
the 
problem with that is you can also omit "Settings." from the code and
call 
GetCompanyName directly, being human this is likely to happen now and again.

So my reasons for using them would be

01: Forces the additional qualifier in the name
02: Prevents you from having to think up different unique names for methods 
which do the same thing in a different way.


> Again how is the code any more centralised or any easier to maintain
> than what he already has?

Ah, that one is easy, by his own declaration

"2) In older sections I actually wrote the code to create the
TRegistry item and access it as well"

That is not centralised and easy to maintain :-)



Pete