This content has been marked as final. Show 3 replies
Encapsulation is not important to me at all. I see two uses for cfc's. One is to make code re-useable. The other is make cf code available to a non-cf app.
I have no qualms whatsoever about invoking a function from cfc_number_2 in cfc_number_1.
I also have no qualms about using cfc's as function libraries. To be frank, that's what most of mine are.
I think it's very important to not let dogmatic adherence to rules get in
the way of common sense and productivity.
Plus it's completely normal for programming components to have dependencies
on other programming components.
How many Java classes - for example - do you know that *don't* start with a
few import statements? Also how often are Java solutions distributed as a
single class, as opposed to a jar file? Why do you think that is? Because
the jar file gathers together a bunch of files all of which depend on one
another to varying degrees.
Why would you expect a CF-based solution to be any different?
Thanks for the feedback. Yes, it does help to see that encapsulation isn't always the highest priority. Or perhaps I need to expand my definition of "encapsulation" to include *groups* of CFC's, which, together, are "stand-alone."