Inside the wrapper, this should not be an issue. Since this.PropertyX
is read-only you cannot unintentionally assign it a value and reading it returns the same value as _model.PropertyX
.
I do not know any object oriented construction, which hinders a programmer to produce errors.
If you should add logic to the getter in the future, it would be a good idea to give a different name to the property like NormalizedPropertyX
or LowerCasePropertyX
or the like explicitly stating the intention behind it.
First, I think you're asking many questions, not one.
And half of the answers of these questions is the ever correct "It depends".
In general, exposing object ivars directly is discouraged if you're aiming for looser coupling (obviously). Although I think when it comes to IBOutlets it is an acceptable practice, since after all the Interface Builder is tasked with the creation of the object.
On the other hand, a readwrite property for an NSInteger
makes little sense, unless you're doing something very funky, and you can easily use an ivar instead.
Once upon a time, in pre-ARC ages, there were some people, who advocated always using properties for objects, since then you don't need to care about retain
/release
. However now that ARC is widely used, this makes almost no difference and it is mostly a cosmetical thing.
A final piece of advice: aim for consistency project-wide.
EDIT: I'm not the greatest fan imaginable of Design Patterns, but it seems that most of your questions would find the best answer in this book.
Best Answer
You are correct up to this question:
Quite the opposite is true. Ideally, only the encapsulating object should have direct access to the object(s) it encapsulates. This is known as the Law of Demeter.
In reality, following this "law" (like most programming laws) religiously can lead to over-engineering, but it is a very good principle to bear in mind.
Make the mental shift so you have to justify the existence of a getter, and separately a setter, before you blindly implement them for all private fields.