2
public final class Multi {
    private final String name;
    private final int number;
    private final ArrayList<String> otherNames;

    Multi(String name, int number) {
        this.name = name;
        this.number = number;
        this.otherNames = new ArrayList<String>();
    }

    public void addOtherNames(String name) {
        this.otherNames.add(name);
    }


    // All getter methods should be a copy of the class fields
    public ArrayList<String> getOtherNames() {
        return new ArrayList<String>(otherNames);
    }  
}

I am having some trouble understanding immutability when it involves data structures such as ArrayList ect.

When I have a method such as addOtherNames which will add contents to the list after object creation.

Thanks

Michael
  • 41,989
  • 11
  • 82
  • 128
Jordan Dixon
  • 99
  • 8
  • 6
    If there is a way to change the data inside the object after it has been constructed, then it is mutable. – Jason Aug 31 '17 at 22:22
  • 1
    No, this is not immutable. If `addOtherNames` weren't there, it probably would be. – Louis Wasserman Aug 31 '17 at 22:23
  • I don't think this one is immutable object.There is similar question in here: https://stackoverflow.com/questions/4658453/difference-between-mutable-objects-and-immutable-objects – Kenny Tai Huynh Aug 31 '17 at 22:25
  • @Socowi Good point. Having the *exposed API to mutate the object state* (via contained type or not) is something hard to argue against.. however, "strictly", since all the fields are final I could also argue with splitting hairs *if* there was no exposed API. – user2864740 Aug 31 '17 at 22:26
  • 1
    getOtherNames returns a new ArrayList, so adding values to it shouldn't have any effect on the internal one. – Lothar Aug 31 '17 at 22:29
  • It has shallow immutability but not deep immutability. – EJoshuaS - Stand with Ukraine Aug 31 '17 at 22:30
  • @Socowi I would have thought that by creating a new arrayList it should not affect the internal List? – Jordan Dixon Aug 31 '17 at 22:30
  • @JordanDixon I was wrong. Please excuse the confusion. But still, there's the method `addOtherNames`. – Socowi Aug 31 '17 at 22:31
  • 'Immutability' is not particularly well-defined so it's sort of [open to interpretation](http://www.yegor256.com/2016/09/07/gradients-of-immutability.html). Some would say its immutable because all of the fields are final. Others would argue it is not immutable because it contains a mutable object. Most of the things people praise immutable objects for - i.e. thread safety, etc. - come *only* with the objects that are completely **constant** so I favour the latter opinion. – Michael Aug 31 '17 at 22:32
  • so the addOtherNames makes this class mutable? – Jordan Dixon Aug 31 '17 at 22:36
  • 2
    Yes, `addOtherNames()` allows the list to be mutated after construction so the state of the class is mutable. – Brad Aug 31 '17 at 22:40

1 Answers1

-3

Technically, it's immutable.

But an object you can reach through it (otherNames) is not, so it's not thread safe.

tpdi
  • 34,554
  • 11
  • 80
  • 120