0
public class MotoXCellPhone {

    //assume there's a speaker class
    private BlueToothSpeaker speaker; 

    //why instantiate in constructor?

    MotoXCellPhone() {
        speaker = new BlueToothSpeaker();
    }

    //or if i instantiate in a method?
    public BlueToothSpeaker useSpeaker() {
        speaker = new BlueToothSpeaker();
        return speaker;
    }
}

why would i want to instantiate a class in another class' constructor? i don't fully understand composition yet so i'm fuzzy on the 'why" of everything

Turing85
  • 18,217
  • 7
  • 33
  • 58
Bryan
  • 87
  • 6

4 Answers4

1

If you instantiate it in the method, you'll create a new one each time that method is called. If that doesn't make sense -- if you want one BlueToothSpeaker object to be tied to the MotoXCellPhone object for its lifetime -- then you need to create it (or inject it) in the constructor.

Louis Wasserman
  • 191,574
  • 25
  • 345
  • 413
  • THANKS! it's more clear to me. says i wanted to connect the phone to the speaker (assume proper methods/variables were in both classes) would i use put a class reference as an instance variable? – Bryan Apr 13 '15 at 20:30
  • If you wanted the speaker to be a property of the phone, you'd have a field of type `BlueToothSpeaker` in which you stored the speaker. – Louis Wasserman Apr 13 '15 at 20:35
  • would that logic still apply even if the speaker was an independent object, and the phone class just "used" that speaker object? – Bryan Apr 13 '15 at 20:40
  • In that case you might want to pass in the speaker to the constructor instead of instantiate a new one. – Louis Wasserman Apr 13 '15 at 20:44
  • @Bryan where would the speaker come from? Some call has to create the speaker. The technique Louis Wasserman has mentioned is also know as [Inversion of Control](http://en.wikipedia.org/wiki/Inversion_of_control) (not coming from this context, but still applicable here) – Turing85 Apr 13 '15 at 21:01
  • the speaker is a separate class. in that case i'd pass it from the main() – Bryan Apr 13 '15 at 22:14
1

The argument is as follows: if someone else uses your code, they might not call useSpeakser() and thus speakers might be null. Instantiating speakers within the constructor asserts that it will not be null.

Turing85
  • 18,217
  • 7
  • 33
  • 58
  • okay so i should set a class reference instance variable, and the instantiate it in the constructor if my MotoX class were to use the speaker? – Bryan Apr 13 '15 at 20:32
  • Depends on your application. Normally, it is easier to assume that attributes are not `null`. For convenience you can call `useSpeaker()` in the constructor, avoiding code duplication. – Turing85 Apr 13 '15 at 20:40
0

The constructor will run and instantiate BlueToothSpeaker right when MotoXCell is instantiated, whereas the method will only instantiate the new class when it is called.

Jhenr
  • 46
  • 3
0

There are two types of member initialization, each with pros and cons, I'll try to enumerate them:

  1. early-initialization:

    • done when declaring the member, or within the class constructor
    • pros:
      • the created object begins it's lifecycle at the same time as it's "parent", and is available at any time without needing to do any checks
      • in the case of a worker class, the created object can start working right away
    • cons:
      • more CPU/memory used for that object
      • depending on the context the object might never be used

  2. lazy-initialization:

    • done on demand, usually within its getter
    • pros:
      • the object will be created only when firstly needed, thus reduces its CPU/memory usage
      • no context dependent, if the member is not needed at all, it will not be created
    • cons:
      • you will need to always access the member via it's getter within the "parent" class, otherwise you might run into crashes
      • care must be taken when dealing with multithreading (e.g. a lock must be used), and this has a performance impact

Depending of the implementation of your class you might choose one over another.

Cristik
  • 30,989
  • 25
  • 91
  • 127