Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Delphi Component Design Question

Status
Not open for further replies.

Glenn9999

Programmer
Jun 19, 2004
2,312
US
I'm working on something and one part of it seemed best to make into a component so I did that. The question I do have is this: I am in process of cleaning up the code and am wondering if it's best to make your processing variables as private object variables, or to pass them as part of the functions/procedures which operate on them?

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
Glenn,

there is a code pattern called "dependency injection" (DI).
you might want to read this:


ultimately the goal of DI is to make all code parts testable, as you can mock away the dependencies.

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
 
Okay, the rule I've generally thought about is to introduce input and output through the function or procedure header to a subroutine. The problem with these components is that you might want to design publish some things. I'm okay with doing that and pushing a parmless call, the problem is what to do with intermediary variables to make the code "clean".

What I have is:
Code:
Public method.
  Function 1.
  Procedure 1.
  Procedure 2.
     Procedure 3.
     Function 2.

Function 1, Procedure 1, and Function 2 can be tested independently. However, most all of these operate with procedure/function variables that are inter-related. So with most of them (all but procedure 2), the dependency is data-related more than code related.

Anyhow, I'm just asking what is good form, especially since this is turning out to be my first very involved (read lengthy) component that I'm turning out.

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
don't try to cram all things into one object (ie your component).
if there are interdependencies, move those away to a new object (and that object becomes a private variable of your component).
Separation of concerns comes to my mind:

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
 
Speaking of design considerations, I'm running into a problem on testing that is new to me now. Most all of my class procedures/functions are halting execution upon return to the main program. They work just fine, the program just stops after they're called. Any ideas on what I need to be looking for or checking into to solve this?

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
Okay so what would cause a function or procedure in an object to not return properly and hang? What I'm seeing is this:

Code:
procedure soandso;
  begin
    <some stuff>
    ShowMessage('Got here.');
  end;

procedure main;
  begin
    <some stuff>
    soandso;
    <some stuff2>
  end;

The ShowMessage line of "soandso" executes, but "<some stuff2>" does not. Since I haven't seen this before, I'm asking what to check for in debugging this.

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
Okay, I got this figured out. It seems that I was calling a method that enabled execution of the program on past the line itself, so you have to code a wait. It turns out though, the wait was for the initialization of the method and not completion of the task, so the method I wrote executed to the end and then just deadlocked.

The proper way to handle this method's execution seems to be to pass it a constructed pre-defined interface with an Invoke function which triggers the end of the task. The problem is if I do that (I corrected that too after I figured out the first thing), I get an access violation in OLE32.DLL.

Which means I'm not defining this thing correctly. And I'm not exactly finding a good reference of Delphi equivalents & examples for how to do this... Of course, Delphi would have to do things in a completely foreign way compared to other languages so I'm not finding any guide there...

Anyhow what I'm trying to do (Generically specified).

Code:
TCallBack1= class(TInterfacedObject, ICallBack1)
  function Invoke ... ; stdcall;
end;
TCallBack2= class(TAutoObject, ICallBack2)
  function Invoke ... ; stdcall;
end;

I understand TInterfacedObject is required for anything that's of an interface IUnknown, and I understand TAutoObject is for IDispatch? Or am I wrong right out of the gate on that?

Code:
Callback1 := TCallBack1.Create;
Callback2 := TCallBack2.Create;
JobDone := false;
JobState := MSCOMObject.MethodCall(CallBack1, CallBack2, State); // produces the AV, this is one of MS's com objects
repeat
  sleep(200);
until JobDone;

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top