Hi Nancy

*snipped*

>>I don't see why these concepts cannot be applied to functions/prgs etc.
>>
>>>I think this would be a good candidate for an interface. And you could implement this method as a DWORD interface. What do you think about that idea?
>
>Let me come back to the above...
>
>>So is putting the code from DWORD into each class that needs it _tight_ coupling and therefore wrong?
>
>I don't think you're dealing with issues of coupling or cohesion at all, except indirectly as a byproduct of where you put this functionality. Would you agree?

I'd not agree with that. Since DWORD is a module then coupling and cohesion should apply. They are not just OOP specific terms.

>
>I don't know what heading I'd stuff it under, but basically you have a snippet of code that you want to reuse, yes? And you want it to be lightweight enough that clients of the code can use it w/o getting a lot of other baggage.
>

Yes.

>You're right it should be in one place and one place only. Oh, sheesh. Now I would have to go back to the first post, though I'll lose my place. What the heck was wrong with making this an object that you instantiate, it returns the dword, then poof! it's gone and done. IIRC, your original post had an extension that seemed to me to be artificial.

What is the artificial extension? My associate is in favor of putting the DWORD code into every class that needs it. What I'm surprised about is that he's saying the class(es) is/are more cohesive because dword is inside them.

Cohesive does not apply to the physical locations of the code, but to the idea that the class is a meaningful unit. Dword started out as a meaningful unit. Embedding it in another class may make the class a meaningful unit, but it did it at the expense of the meaningful-ness of dword.

>
>BTW, what about the idea of using an interface?

What do you mean by "using an interface"? A separate class that calls the DWORD.PRG? Isn't that an artificial extension? ;)

Embedding it in a distinct class may be fine, but a class done in code or visually takes longer to create than a prg as it must have more code.

DWORDVCX.PRG
DEFINE CLASS DWORD AS CUSTOM
PROCEDURE DWORD
Insert dword code here. Putting it in the init doesn't seem right, but even so, you'd have to include PROCEDURE INIT...ENDPROC.
ENDPROC
ENDDEFINE

VS

DWORD.PRG
insert dword code here.

Then using the class would require more steps than using the .PRG.

SET CLASSLIB TO DWORD.VCX ADDITIVE OR SET PROCEDURE TO DWORDVCX.PRG ADDITIVE
loDword = CreateObject("dword")
?loDword.dword(parameters)

VS

?DWORD

Never mind that dword must be found in the DOS path. That is a non-issue when the code is part of the EXE. Compiling the EXE would not remove the requirement of the SET CLASSLIB or SET PROCEDURE of the other approach.

Thanks!