PDA

View Full Version : Constructor functions are cluster bombs


glantucan
12-04-2010, 07:44 PM
I would like to know your opinion on what Bill Sanders, one of the co-authors of "ActionScript 3 Design Patterns" says about not using constructors at all, here is asummary of his original post Constructors functions are Cluster bombs (http://www.as3dp.com/2010/09/21/constructor-functions-as-cluster-bombs/):

* "If you do not include one, you’re not tempted to add properties and methods in the constructor that might generate dependencies. Your client isn’t a problem because its just making requests and none of the other classes instantiate your client."
* "With “parameterized” classes, instead of passing a parameter to the class, it’s less binding to pass it just to the method that uses it."
* "If everything in a class is needed immediately by the constructed instance, first instantiate an instance and then call a method through the instance that fires off the whole crew."

Personally, I am starting to think he is right. Hey! He (among others) wrote the most interesting book I've red about AS3. In fact I think I will read it again just when I finish it. But as with the book, the concepts related loose-coupling between classes, are a litle difficult to grasp for me. Yet ;)

drkstr
12-05-2010, 12:45 PM
Yeah, I would agree that constructors are bad for some classes (especially view classes). They're fine for simple things like a model, or a custom event. However, view classes usually get created in stages, or as part of a life-cycle such as the case with Flex. Lots of logic in the constructor also makes them harder to extend. In general, it's usually best to break up functionality into as many chunks as possible, which is not just limited to the constructor. For exmple, you may have an init function which just bootstraps more specific functions like initStyles(), initModel(), etc.

glantucan
12-05-2010, 04:11 PM
Yup, I understand that,... I think :)

But what I don't get very well, hoaw could you not use constructors at all. In a MVC pattern you have, at least, to tell the Views which controllers and models to use, and I don't see how they are less coupled with them by doing it through another method instead of the constructor.

the binary
12-05-2010, 04:30 PM
..at least, to tell the Views which controllers and models to use..

this could be done by e.g. programming to interfaces like..


package
{

public interface IAbstractView
{
function setModel (model:IAbstractModel);
function getModel () :IAbstractModel;

function setController (): IAbstractController;
function getController (): IAbstractController;
}
}


if any view is implementing this interface you don't have to deal with the constructor..
please note, this is just an 'dirty example' but should point you in the direction..

glantucan
12-05-2010, 05:07 PM
Ok, I see. That way you can change models and controllers even at runtime if they implement IAbstractModel and IAbstractController.

But if you include this methods while initializing them in the constructor, why are the classes more coupled. Still don't see it. Perhaps I didn't get the "coupling" thing at all.
For instance
public class myView
{
public function myView(model:IAbstractModel, controller:IAbstractController)
{
...}
function setModel (model:IAbstractModel):void{
...}
function getModel () :IAbstractModel{
...}
function setController (controller:IAbstractController):void{
...}
function getController (): IAbstractController{
...}
...
}


Oh!, maybe... without initialization that class could work without the need of models and controllers instantiated. Is that the reason?

Tanks guys, I'm learning a lot

Flash Gordon
01-10-2011, 10:05 PM
I've read some stuff before by that guy and I kind of thought he's not the greatest person to be giving advice on design patterns or even programming. Take it with a metric ton of salt....

There are definitely occasions where constructors are needed such as adapters and commands to name a quick one.

maskedMan
01-11-2011, 01:26 AM
Take it with a metric ton of salt....

I would agree with the grain of salt appraisal. Basic operator precedence (http://www.as3dp.com/2011/01/07/actionscript-3-0-to-screw-with-your-head-lets-meet-at-the-algonquin/) isn't something you should be surprised by after so many years.

Flash Gordon
01-11-2011, 04:25 AM
you're right, harsh words. Allow me to edit them and you may as well.

newblack
01-11-2011, 12:10 PM
well based on that "operator precedence" post, i'm inclined to agree with calling him an idiot, but that doesn't change the fact that i can't think of one decent reason you should ever need a constructor--architecturally or otherwise.

maskedMan
01-11-2011, 02:36 PM
you're right, harsh words. Allow me to edit them and you may as well.

No problem. :)

the binary
01-11-2011, 07:08 PM
I've read some stuff before by that guy and I kind of thought he's not the greatest person to be giving advice on design patterns or even programming.

are you pointing in my direction ?

Take it with a metric ton of salt....
What does that mean ? Is that some kind of a phrase ?

cheers

Flash Gordon
01-11-2011, 09:19 PM
What does that mean ? Is that some kind of a phrase ?
cheersNo. The American phrase is "take it with a grain of salt." I changed it to "take with a metric ton of salt" to emphasize how much I didn't agree with him.

the binary
01-11-2011, 09:40 PM
ok, thanks..
was a bit confused and thought i missed something..

.. to emphasize how much I didn't agree with him ..
Whom did you mean?

Flash Gordon
01-11-2011, 10:00 PM
Bill Sanders