Question about a solution (todo2) of the code-challenge

1) does this mean, that having no setter is not an indication of immutability?

Well you are modifying the object, not the field that has the access modifier right? You can't set that list to a new value. You are mutating the object because it allows mutation, but you are not changing the private field. The difference is slippery. If you don't want that mutability in your object this is a great example of using the getter to wrap the private list and return an immutable copy of it.

2) is this not making private properties less useful to rely on (by having a false sense of security, because private properties can be changed by any public getter, that returns that property)?

In reference to the question(1) above you have to be careful, and yes it is a false sense of security, and that feeling you are having shows great API design skills, so keep thinking like this! If you don't want mutability you have to take charge.

3) am I maybe misunderstanding the purpose of "private properties + public methods" as a security mechanism, or should it just be avoided to directly return private properties?

Remember it is the field that is protected, not the inner workings of the other object.

4) If I remember well, public int getAxisLength() is returning the value of the integer, so other dangerous things I can imagine by bypassing a setter should not be possible. Does only List/Maps/Arrays/Queues return object-references? Is there some nice overview somewhere?

int is a primitive type. Everything in Java returns things by value. So you are getting the value of the primitive. Objects are a little different because an Object's value is just an Object Reference, so it points (like a pointer in C) to the same place in memory. Certain objects, like Strings, are immutable. So when you return a String, you cannot modify it, it makes a new one. There are objects that take this into account. But yes by default most of the Java Collections Framework default implementations are mutable.

The forum is a great place to make these suggestions, also feel free to email me whenever. We are working on a review mobile app and it uses similar algorithms to what you suggested. Still working on how to get Java to fit on a mobile screen ;) So....many....words.....

Thanks for your questions! I'm sure they are gonna help everyone! Keep at it!

Thanks for the quick reply!!

If it makes sense?

Yes, I understand your answer. But

1) does this mean, that having no setter is not an indication of immutability?

2) is this not making private properties less useful to rely on (by having a false sense of security, because private properties can be changed by any public getter, that returns that property)?

3) am I maybe misunderstanding the purpose of "private properties + public methods" as a security mechanism, or should it just be avoided to directly return private properties?

4) If I remember well,

public int getAxisLength()

is returning the value of the integer, so other dangerous things I can imagine by bypassing a setter should not be possible. Does only List/Maps/Arrays/Queues return object-references? Is there some nice overview somewhere?

Sorry for so many questions.

I really love treehouse and your java course is truly great. Where is the best place to give some feature suggestions? For example it would be nice to have some "refresher-quizzes" that are kind of part of the course, but more independent in some way: a user could opt-in to be asked refresher-quizzes, that would be asked even after the course is finished (using some algorithm that recognize when the answer is correct or wrong a couple of times in a row so that it schedules these more or less and less often; a simplified version of http://mnemosyne-proj.org/).

Edit: typo

Many thanks for the detailed answers!!

Oh... one more question:

Is

course.getVideos().add(1, newVideo);

the intended answer, or are there better solutions?

I guess it might be ok for the exercise (to ensure that we understood why .add is even possible), but not the recommended way in "normal coding" (to "hijack" a getter to add an element), right?