4

Possible Duplicate:
Best Practice: Initialize class fields in constructor or at declaration?

I am working with C# but this probably applies to Java (or any other language that allows this behavior as well)...

Which way is preferable/best practice? Assume I will ALWAYS need _memberVar

1.

class MyClass
{
    private Dictionary<int, string> _memberVar = new Dictionary<int, string>();

    public MyClass() {}
}

- OR -

2.

class MyClass
{
    private Dictionary<int, string> _memberVar = null

    public MyClass() 
    {
        _memberVar = new Dictionary<int, string>();
    }
 }

Now lets say that MyClass has upwards of 10 constructors... So I don't want to have _memberVar = new Dictionary<int, string>(); in all of those constructors lol. Is there anything wrong with the 1st way? Thanks

Edit: I realize I can chain the constructors, but this is a rather complex class... some constructors call the base, some call other constructors already etc etc.

Community
  • 1
  • 1
DigitalZebra
  • 39,494
  • 39
  • 114
  • 146
  • duplicate of http://stackoverflow.com/questions/24551/best-practice-initialize-class-fields-in-constructor-or-at-declaration – M4N Jul 30 '09 at 14:21

4 Answers4

1

With respect to _memberVar being initialized in 10 constructors: I think you need to rethink your class. That sounds excessive. If you're doing the same work in each constructor, then you're violating DRY. Instead, try to adopt this structure:

public class MyClass {
    Foo _foo;
    Bar _bar;
    Baz _baz;

    public MyClass(Foo foo, Bar bar, Baz baz) {
        _foo = foo;  _bar = bar; _baz = baz;
    }

    public MyClass(Foo foo, Bar bar) : this(foo, bar, new Baz()) { }

    public MyClass(Foo foo) : this(foo, new Bar()) { }

    public MyClass() : this(new Foo()) { }
}

Note, that I intentionally did not call into the broadest constructor in each of the rest, but instead cascaded so as to inherit behavior in case the sense of defaults changed for each.

As to member initialization at declaration, if the member is not constructed using one of the arguments to a constructor, I prefer to initialize at declaration.

plinth
  • 48,267
  • 11
  • 78
  • 120
1

You do not have to initialise member variables, but it does not hurt if you do. Member variables acquire their default values automatically, usually a null for objects and the default value for primitive types (such as 0 for an int).

As for having different constructors, you do not have to repeat the member initialisation in each version since you can call an overloaded constructor from any other just as you would with an overloaded method.

Regarding best practice, personally I initialise member variables in the constructor as this is where I want to "construct" my object into a stable state. In other words, even if I would have initialised member variables where I declare them, when the constructor is called, it would be as if I was wiping the slate clean.

0

Ideally, you should be using dependency injection for this. This means that you leave it to the instantiator of your class to create new instances of dependencies and inject them into a new instance of the class rather than to have the class create the dependencies itself.

jpoh
  • 4,536
  • 4
  • 35
  • 60
  • This code is in the provider... soooo yeah haha – DigitalZebra Jul 30 '09 at 14:25
  • I would take this advice with a grain of salt. In this day and age, people throw "dependency injection" at every problem, but ultimately some object is responsible for instantiating other objects. In your example, the member variable is a `Dictionary`, so I would assume it to be a leaf object right at the end of the object graph, in which case the current object would be responsible for creating it. –  Jul 30 '09 at 14:32
0

The first method is the way I generally do it, and is completely acceptable if all your constructors would initialize it to the same value. I definitely prefer it for static variables as well to avoid the explicit declaration of a static constructor.

Will Eddins
  • 13,628
  • 5
  • 51
  • 85