It is not a question of "bad code"... though some will debate the point... but a matter of better code practice. What may work in a certain instance may not be a best practice in the long run.
 
Key buzz word here is "encapsulation"... which will mean slightly different things to different people. Bottom line, it means the object does not know about the world outside of the object. It has an interface that allows it to hear requests, and reply to them... but it doesn't "depend" on variables like session scope variables. Instead it builds those dependencies into the instantiation (passed in when creating the cfc) or to the cfc functions (passed in when calling the object method). If something is missing it will cry out when you call the method. This makes it easier to debug because you know everything it is requesting, and the error message should tell you if a required variable is missing.
 
So, you see the focus is object interaction. We are thinking about the CFC's like objects. If you are compare objects to biology, you will get an illustration of how objects work. (not a perfect illustration... but it carries some of the concept to make it understandable) The lungs don't know about the muscles, and yet a muscle is the key to making the lungs work. They are seperate objects with a container system to tie them together and tell them how to interact. Sometimes objects are inside of each other. If you look at a body as an object, then the heart is a required object to make the body work. Thus the object world would say... the body "has a" heart. Yet, the lungs do not "have a" diaphram. The diaphram on the other hand "is a" muscle. Thus you have a has a/is a view of the object world. Now from Coldfusion, to Java, to C++ the object world starts to have differances... but these are common features. Best practice is based on years of experience of pitfals and avoiding them. To maximize code reuse objects have a "standard interface" to the methods. This means it does not matter to the application if data is stored in SQL, XML or any other format. In a shopping cart when items are added to the cart, it just needs to know the user said to add an item. Then if the container of the object request a shopping cart list... it need to be able to give it back. Interface is most of what makes objects work. And the point that is made for OO types, is to build instantiation and method dependencies rather than internal calls to the outside world. That is the general concept.
 
John Farrar
----- Original Message -----
Sent: Friday, October 03, 2003 10:14 PM
Subject: Re: [CFCDev] Just starting CFC's -- Session Question

> I have to throw in the obligatory and oft repeated advice that you should not be directly manipulating session variables
> inside your CFCs, generally speaking. 
 
Nathan, do you mean that if I use session scope in my CFC instances store in the Application scope... that I should consider this like not a good practice to do!... Could you explain a bit more... I'm thinking right now of how to avoid this...  and I'm not like you guys... OOP oriented!... because now! in my CFC intances... I'm using Session and Application scope (to call other services)...  and it's working very find!!... but I would like to know, why it's not a good practice to do so!...
 
Thanks for any advice
 
Stephane
Buidding a Flash MX/ColdFusion MX site

Reply via email to