Should a bean have a init() method?

 I'm currently building several new applications using ModelGlue, and as I was going through some example code I stumbeled upon a bean not containing a init() method. I thought this to be strange, as I thought the init() method is an unwritten law when it comes to beans. I asked the author of the code (via #coldfusion on dalnet) and he told me he did not think beans shold have init() methods. So now I'm a bit confused and don't know what to think. So I'm throwing the question out in the open. Please tell me, do you think a bean should have a init() method or not, and WHY do you think what you do? Hoping for a fruitfull discution from which I can make my own conclusion.

Go....

Comments
Yes, they should have an init method. While a lot of beans don't need to perform any initialization, some do, and in larger applications, it's almost always useful to treat all your beans in the same way in certain respects. Being able to call an init method on every bean, regardless of whether or not it needs it, is one example.

If you're against having a no-op init method in every bean, you might consider adding it to your base component (/WEB-INF/cftags/component.cfc), and then every CFC on your server will have one. I don't like tying my app to the server (unless I'm packaging the server as part of the app), so I'd stay clear of this and just put it in line in every bean, but it's a technique that might be useful.
# Posted By Barney | 3/23/06 6:30 PM
The Init() method for beans can be helpful if you need to instantiate anything into the variables scope. You create put another object into scope or a series of varaibles to use for immediate private method usage.

I imagine that you could use the bean with or without an Init(), but why not use soemthing that will save you code?
# Posted By Teddy | 3/23/06 7:09 PM
I agree with Barney: all beans should have init() even if it takes no arguments and does nothing (except return this). It's a basic consistency issue.

Ideally a bean's init() method would take named arguments matching every property of the bean and call setXxx() for each of them.
# Posted By Sean Corfield | 3/23/06 10:36 PM
I agree with Sean: when you instantiate a bean it is nice to have an init to load all of its properties:
myBean =createObject('component','bean').init(myProp1=', myProp2=')
is cleaner than
myBean =createObject('component','bean');
myBean.setMyProp1 = ';
myBean.setMyProp2 = ';
# Posted By Chip | 3/24/06 3:31 AM
You mean this, yes?

myBean =createObject('component','bean');
myBean.setMyProp1(');
myBean.setMyProp2(');
# Posted By Sean Corfield | 3/24/06 7:01 AM
Thank you guys, for your input on the subject. So far everybody is pro init(), and I'm not very surprised. It would have been interesting to hear "the other sides" arguments though.
# Posted By Trond Ulseth | 3/24/06 9:58 AM
I've been struggling with the idea of init in a Coldfusion bean and wondering why no-one seems to be using the built-in contructor functionality that Coldfusion give us. Is is just becasue we're trying to make the beans more Java like? Or is there some compelling reason why NOT to use the contructor area of the component?
# Posted By Chris Rockett | 3/25/06 7:19 PM
Chris,

The primary reason is that you can't pass arguments to the CFC psuedo-constructor, while you can pass args to an init method. In some cases, that's irrelevant, but again, it's all about consistency.

You can also run into issues with the psuedo-constructor with documentation tools. The CFC Explorer that ships as part of CF, for example, uses CFC metadata, and that can only be obtained from an INSTANCE of the CFC. And that means that the psuedo-constructor gets invoked when you want to browse the docs for the CFC. Often irrelevant, but it can lead to some really weird behaviour.
# Posted By Barney | 3/25/06 11:37 PM
When he asked for "WHY" the reasons were predictable. Some of the times the answers were tradition and not reason. (not singling anyone out here... just the different perspective he asked for..)

Number one... init is a constructor. I would suggest looking at several languages and see how constructors are used. Putting an init method in a CFC is ritual, not consistancy. If your CFC requires the init method then a good Unit Test would reveal the init was needed when it is needed. After all... that is like passing the DSN into all our CFCs for the sake of consistancy. Look at reactor, ARF and others. We certainly don't pass DSN into every CFC.

I think this falls more into the bigger concept of why people have things like 'design patterns'. Sometimes you need water (like in a desert), and other times you need milk (like a baby). It's over simplification to just say put an init in everything.

Therefore, how about some discussion on "WHY" we use init methods. If it isn't needed it is again like passing a DSN into every component for consistancy. (And my guess is there are some methodologies that actually pass an API into all the components, eh?)
# Posted By John Farrar | 4/1/06 4:09 PM
John, I think you make interesting arguments showing that this is not just "black and white" discusion. Thank you for your input (that goes to all you others who have voiced your opinions here as well).
# Posted By Trond Ulseth | 4/4/06 10:13 AM