On Tue, 16 Nov 2004 09:50:03 -0500, John D Farrar <[EMAIL PROTECTED]> wrote: > Also, who cares if they know the settings names inside the object, they > are protected!
The CFC may be protected against outside code messing with its state. But the clients of that CFC are not protected against changes made to its implementation. Most of the time I'm not worried about code using my CFC incorrectly* (provided that the "correct" contract is clearly specified). If it does it won't break any of the other code. What I am worried about is being able to change the CFC without breaking code that uses it. (I don't want to track down all of those references, fix them, test, and redeploy. That's usually a lot of work. It's often impossible.) So I seperate the CFC into two parts. The public parts, known as the interface, contract, specification, or "what," will never change. The private parts, known as the implementation or "how," may change as the code evolves, as requirements change, to improve performance or readability, or some other reason. Often one CFC will be substituted with another CFC that has the same interface but a different implementation. The client code is blissfully unaware of the fact that it's working with two or more different CFCs. Patrick * As a courtesy to the programmers using the CFC (myself always included) I may try to make it difficult if not impossible to use the CFC incorrectly. -- Patrick McElhaney 704.560.9117 http://pmcelhaney.blogspot.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
