|Think about Loose Coupling|
Re^3: The fallacy of the *requirement* for read-only instance variables.by BrowserUk (Pope)
|on Apr 21, 2011 at 14:07 UTC||Need Help??|
And my response remains the same.
Outside of the myopia of a for-arguments-sake-only, do-nothing-and-no-details example, this does not stand up to scrutiny.
For your example of dogs, which live longer than the program runs, your unique ids have to persist longer than one run of the program, else they serve no purpose. The object handle is already a unique identifier for programmic purposes.
And once you persist your objects (with identifiers) to disk, you need to be able to re-constitute them by instantiating instances that will be given their ids as read from disk. But, you also need to be able to instantiate new instances which will get their ID from the class.
Now you need to be able to set the ID to be either then next increment of the monotonically rising counter; or set it to the value read back from disk.
Therefore, you need a setter. Even if that setter is programmed to only work once per instance. (Ie. Write-once, not Read-only)
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.