automatic-properties

I'm still pretty new to ObjC. I noticed that it's pretty standard everywhere to create your @interface myObj : NSObject { id delegate; NSDictionary *dict; } and then @property (nonatomic,retain) NSDictionary *dict; @property (retain) id delegate; --for example. I know how useful the auto code generation + clearer definition of @property is thanks to the Declared Properties page over at Apple. What I do not understand, however, is why it's standard for people to do both -- declare their properties and then have them again in the {curly brackets}. I mean, if I had a class where I wanted some of

In C# you can create getter/setters in a simpler way than other languages: public int FooBar { get; set; } This creates an internal private variable which you can't address directly, with the external property 'FooBar' to access it directly. My question is - how often do you see this abused? It seems like it has a high potential to violate encapsulation best-practices often. Don't get me wrong, I use it as appropriate, and partial variations of it for read-only write-only types of properties, but what are your unpleasant experiences with it from other authors in your code base? Clarification:

So, with the brand new C# 6 we got those neat auto-property initializers. I thought I might as well take advantage of these to make more concise singletons than ever. Apparently someone else got that idea, too. public sealed class Singleton { public static Singleton Instance { get; } = new Singleton(); private Singleton() { /* some initialization code */ } } My questions are: How thread-safe it is? How lazy it is, or when the instance is actually created? (not a priority, but it would be good for future reference) Is it a good idea overall? (it might look similar to this question , but it's

Is there any way to put contracts on automatically implemented properties in .NET? (And how if the answer is 'Yes')? (I assume using .NET code contracts from DevLabs) Yes, this is possible - all that is needed is to add your contract condition to the [ContractInvariantMethod] method in your class, which then adds the equivalent Requires precondition to the automatic set ter, and a post condition Ensures is added to the get . From section 2.3.1 of the Reference As the example illustrates, invariants on auto-properties turn into: A precondition for the setter A postcondition for the getter An

I have the simple class using auto-implemented properies: Public Class foo { public foo() { } public string BarName {get; set;} } I obviously use the variable BarName throughout my class and now need to add logic when the property value is set (it must be all upper case, go figure). Does this mean that I need to now create a private variable for BarName , e.g. _BarName, and change the current BarName variable used throughout my class to _BarName? Public Class foo { public foo() {} private string _BarName = ""; public string BarName { get {return _BarName;} set {_BarName = Value.ToString()

In classes whose instances I persist using an object database, I keep having to do this: private string _name; public string Name { get { return this._name; } set { _name = value; this.Save(); } } whereas I would much rather type this: [PersistedProperty(Name)] private string _name; where the PersistedProperty attributes generates a Getter and Setter just like the default [Property()] attribute, except I want to add a line of code to the generated Setter. Is there a way I can create an attribute which does this? Hopefully , which works with Intellisense. How does the default [Property()]