First of all, with things like this nothing is "written in stone"!

It sounds like your subroutine can be used without alteration by calls from
multiple class modules and can be regarded as generic. In that scenario I'd
probably put it in a normal module to be shared by all. However, if your
class module has the potential to be used as a ready made template that can
dropped into other projects, I'd probably keep such 'generic' procedures
within the class module, even if it might mean a little duplication.

One thing that is written in stone, fully declare all variables and head
modules Option Explicit

Regards,
Peter T



"Dave Unger" wrote in message
...
Hello,

Being a relative newcomer into the world of class modules, I’ve done a
fair amount of reading on the subject (including postings in this
group), and one keyword that always seems to pop up is
“encapsulation”. While I can appreciate the reason for this, it leads
me to a question about how rigorously encapsulation should be adhered
to.

In my case, I have an application containing a few class modules, 3 of
which make calls to the same subroutine. I see 2 alternatives he

1 – Include the common code inside each class module, which seems
inefficient, or

2 – Keep the subroutine outside the class modules, and lose
encapsulation.

Now, I have no doubt that my code is far from optimum, but it serves
to illustrate the point. Is “encapsulation” simply a guideline to an
ideal, or is it “written in stone”? I’d appreciate any comments/
advice on this.

Thank you,

Regards,

DaveU