Concordo com Phil Lello que isso provavelmente foi simplificado demais, possivelmente ao ponto de ser confuso. Um exemplo muito mais claro da necessidade e indesejabilidade de (precisar fazer) cópia defensiva é o seguinte usando C # para concretude.
class House {
private Thermostat thermostat;
private ControlDisplay cc;
// ...
public void ShowDisplay() {
// ...
cd.SetTemperatureField(thermostat.Temperature.Clone());
// ...
cd.UpdateDisplay();
}
}
Agora, se Temperature for mutável, toda vez que quisermos mostrar o display de controle, precisamos copiar a temperatura do termostato, mesmo que seja improvável que seja alterado pelo display. Mesmo se nós controlarmos o código para ControlDisplay e, portanto, pudermos verificar, olhando para o código-fonte que ele não sofreu mutação, o passado em Temperature , nós ainda copiamos porque isso pode ser alterado no futuro. Não havia como comunicar e impor que não deveria ser alterado.
Se Temperature fosse imutável, por outro lado, não haveria necessidade dessa cópia. O resultado seria um código mais limpo e eficiente, que simplesmente impossibilita certos erros e acoplamentos.
Eu imagino que a maioria das instâncias nas bibliotecas principais da Apple são mais parecidas com as anteriores do que com o exemplo fornecido no vídeo. Eu posso apenas imaginar alguns cenários, um tanto estranhos, onde código como o exemplo original poderia ser preferível para codificar mais como seu segundo exemplo (ou seu aludido para reescrever).