There is a class method (static method) in which I create and build some object. And for filling that object, I create it as mutable object.
My mutable object is a subclass of immutable object. So i can return it as super Class type.
That object is just created in class method and returns. It is not a part of object or class state.
Should I return mutable object or it immutable copy? (what solution will be correct in concept of encapsulation)
For example there is some pseudo code:
// MutableArray is subclass of Array
MutableArray : Array;
// Another class
static (Array *)getEngineers {
Array *employees = Array.arrayWithContentsOfResource("employees.txt");
MutableArray *engineers = new MutableArray;
for (Employee *employee in employees) {
if (employee.profession == "Engineer") {
engineers.addObject(employee)
}
}
return engineers; // should I return Array.arrayWithArray(engineers) instead of engineers ?
}
Update:
I mean, if I have a mutable array that is a member of the object, then it makes sense to return immutable copy in getter method (to provide access control and encapsulation). But if I have method like in example. I need only immutable object for using. But creating immutable copy of array is additional operations. Does it make sense to make it immutable?
3
if only your team is using this code in the same process then i would return the same object (mutable object) . keep it simple and fast. Your own team would not change something on the objects unless they needed to, and if they did then they would have to make another copy.
If I was making a API too I would not keep it immutable, simple because engineer looks like its an object that can change (like if the object had something like reporting To or degrees-held – that can change over time.
Objects should mimic their real world counter parts as much as possible. Some attributes could be immutable (like date of birth etc)
Good external docs or code comments could explain how to use the object where required
0
Encapsulation doesn’t have anything to do with immutability. Well, maybe it does a little. A more accurate term would be “access control.” An immutable object restricts access control because you cannot write it; you can only read it.
You make objects immutable when you are using them in a multi-threaded context, and you want to make your code more… “deterministic.” There is no right or wrong about this, no “correct” or “incorrect;” if you’re not using multiple threads, you probably don’t need to worry about immutability at all.
Make objects immutable when you want to guarantee “safe” access to the object via another thread. An object is “safe” to access in a multi-threaded context when you can guarantee that another thread won’t be writing an object while you’re trying to read it. You can do this with immutability, but you can also do it with locks, mutexes, semaphores and other concurrency mechanisms.
11
Without knowing more about the use of this mutable/immutable Array, perhaps one factor to consider is the lifetime of the Array. Are you going to store the Array object for later use or pass it around to other parts of your code? If so, then an immutable object might be better because it reduces the chance of accidentally (or perhaps maliciously) having the Engineer array changed. If this is a one-time use, then you might be able to get away with a mutable array because the exposure of that array is already minimal.
Your subclass shouldn’t violate the contract that the super-class has with its clients.
It isn’t automatically true that returning something mutable when the client expects something immutable will violate that contract, but I’m assuming the super-class returns something immutable for a reason, and that clients therefore expect to have an immutable object returned. So, unless you have specific knowledge that it’s OK in this case, don’t break any client code relying on immutability – return something immutable.
(An example of what might go wrong – maybe classes written to work with the super-class never check its state because they assume it was checked on creation and can’t be modified. Then it gets an instance of your class, and fails to verify it is currently in a valid state).