Develop Reference

What can I do with property .set and .get?

I have an interface
public interface IIntf { string Foo { get; set; } }
and a class
class MyClass : IIntf
{
public string Foo { get; private set; }
}
. Now I get the compiler error
'MyClass' does not implement interface member 'IIntf.Foo.set'.
'MyClass.Foo.set' is not public.
So it seems that Foo.set is its own entity somehow (and Foo.get analogously). Can I do anything with them? If yes, what?
E.g. I tried implementing the missing setter property by using Foo.set - it was even suggested by Visual Studio
but I did not find any syntax that works. When following the suggestion and trying to implement the Foo.set method (without corresponding get because I have that already), I get a different type of compiler error:
But since Visual Studio shows (and, at times, suggests while typing code) Foo.set and Foo.get, I assume that something can be done with them. Any ideas what? Maybe some nice way of redirecting methods to only the getter / only the setter? Or something else?

Dealing with the issues / questions that #Kjara has raised in the comments:
Properties are implemented using get and set methods behind
the scenes (by the compiler).
You cannot easily access / pass around these
methods (without reflection).
When define properties, you must
define the get and set at the same time (you can't define the
get on one line and the set on another).
As per #FrankM and #Dirk above - the confusion here appears to stem from the fact that the IDE implies (falsely) that you can define the getter and setter separately.

Like this
public class MyClass : IIntf
{
public string Foo { get; private set; }
string IIntf.Foo { get => Foo; set => Foo = value; }
}

Why not explicitly initialized readonly autoimplemented property is valid in c# 6?

Update 1
It seems like either my English is terribly awful, or people just don't give a sh... to understand what I'm asking about or simply look at the title of the post.
C#5 specification clearly states:
Because the backing field is inaccessible, it can be read and written
only through the property accessors, even within the containing type.
This means that automatically implemented read-only or write-only
properties do not make sense, and are disallowed.
public string MyProperty {get;} has no sense, yet it costs nothing for compiler to emit getter not even warring about lacking setter. Backing field will be initialized with a default value. What does it mean? It means that designers spent some effort to implement a verification, to introduce functionality that could be left out.
Let's now consider C#6:
In C#6 the initialization of auto-implemented properties was introduced.
public string FirstName { get; set; } = "Jane";
or
public string FirstName { get; } = "Jane";
In the latter case property can be set in a constructor as well:
public class Program
{
public string ImagePath { get; }
public static void Main()
{
}
public Program()
{
ImagePath = "";
}
}
But only in constructor of the class where property was declared. Derived classes cannot set property's value.
Now ask yourself what this property means, if it was not initialized in constructor:
property string My {get;}
This is a 100% equivalent of C#5 prohibited property. It has no sense.
But such declaration being invalid in C#5 became valid in C#6. However semantics didn't change at all: this property is useless without explicit initialization.
That's why I am asking:
Why not explicitly initialized readonly auto-implemented property is valid in c# 6?
What I expect to see as an answer:
Either debunking of my initial assumptions about changes in C#6
Or the explanation of how and why compiler designers changed their mind
about what makes sense, and what does not.
I find the answer It's by design to be completely irrelevant. It is just a fact. I look for reasons. I don't believe compiler designers decide on changes in behavior of compiler with just tossing the coin.
This is an example of good answer.
Original question
In VS2015 this code is compiled without errors:
public class Program
{
public string ImagePath { get; }
public static void Main()
{
Console.WriteLine("Hello World");
}
}
However, in VS2013 I get error:
Compilation error (line 5, col 28): 'Program.ImagePath.get' must
declare a body because it is not marked abstract or extern.
Automatically implemented properties must define both get and set
accessors.
I know about initializable auto implemented properties, and in case of VS2015 field gets default value, that is null here. But then it's interesting to know why this snippet was invalid in C# 5?
Initializable auto-implemented readonly property left without explicit initialization seems to me a bit ODD. It is likely a mistake rather than intention. I'd personally prefer compiler to require explicit initialization in this case:
public string ImagePath { get; } = default(string);
Ok, I know that such property can be also assigned in constructor:
public class Program
{
public string ImagePath { get; }
public static void Main()
{
}
public Program()
{
ImagePath = "";
DoIt();
}
public void DoIt()
{
//ImagePath = "do it";
}
}
public class My : Program
{
public My()
{
//ImagePath = "asdasd";
}
}
But if compiler can check that local variable is not initialized, the same is possible for the property.
So why is it as it is?

The compiler is telling you that automatic properties must have both accessors defined. For example, you could fix the error with
public string ImagePath { get; private set; }
assuming that you do not intend the property to be settable outside the class.
As to why you have to declare a setter or manually implement the property -- well, what good would be a property that you can read from, but will always return the default value of its type since there is no way to set it? Conversely, what good would be a property you can write to but can neither read from nor hook into its setter?
C# 6.0 gives you the option of having write-once, read many auto-properties; this is a huge difference as the value can be arbitrarily chosen, allowing you convenient syntax for properties with immutable values.

I have no idea why your question have been down voted. This is interesting observation but please keep in mind that it is not a breaking change - it is just 'new functionality' that is 'leftover' of other functionality - initialization of auto-implemented properties.
That means it had no sense previously, but now it has.
Moreover, I think it has always had sense. E.g. when you have some base class or interface, for example
interface IPerson
{
int Age { get; }
}
Some day you may want to implement null-object pattern where the age is irrelevant. In c#5 you have to write public int Age { get { return 0; } }, while in c#6 you can simply do public int Age { get; } or even transform interface to abstract class changing only its definition from interface to abstract class.

Common code for multiple properties

We have a helper function to remove html tags from the string that we want to apply to few properties of our classes like Name, Firstname, Comments etc.
So for that what I am doing right now is removing html tags before assigning value to the property like this
public string Name
{
get { return _dalObj.Name; }
set { _dalObj.Name = Helper.StripHTML(value); }
}
This is working fine!
But I am looking for some better and centralized way to do this rather than applying it to all the properties setter.
So that I will write this code once somewhere centrally and then will mark the properties (may be by custom data annotation or registering them somewhere or using reflection) and those properties will be picked automatically and this code will be applied to there setter.
Is there any way to achieve this or what I am doing is right?

You could always encode it as part of your types!
_dalObj could be some type which declares name as such:
private NoHtmlString _name = ""
with the class NoHtmlString looking something like this:
public class NoHtmlString
{
private readonly string _value;
private NoHtmlString(string str)
{
_value = str;
}
public static implicit operator string(NoHtmlString noHtmlString)
{
return noHtmlString._value;
}
public static implicit operator NoHtmlString(string someString)
{
return new NoHtmlString(StringHelpers.StripHtml(someString));
}
}
This way your outer accessing layers could just do the following:
public string Name
{
get { return _dalObj.Name; }
set { _dalObj.Name = value; }
}
You get the benefit of having something you can implicitly use as a string, but with the guarantee that it will always be stripped of the HTML.
As others have mentioned, this could be achieved using Aspect-Oriented Programming as well.

As mentioned in the comments, it looks like a code smell, that the property will have a different value than the one that was set.
I would suggest to store the value as it is, and implement in the abstract base class a Sanitize() method, which will go trough all those properties and strip the html, it can be done trough reflection for exploring properties to sanitize (e.g. those with some attribute), or it can be an abstract method implemented by each class to sanitize the proper properties.

It seems to me that you need to do some Aspect Oriented Programming.
One AOP tool that you can use with C# is PostSharp. You can use it to create an Aspect, e.g. HtmlStripperAspect and then apply it to your properties.
For example, you would have something like this:
[HtmlStripperAspect]
public string Name
{
get { return _dalObj.Name; }
set { _dalObj.Name = value; }
}
where HtmlStripperAspect is a centralized class that you create with the help of PostSharp and inside such class you call your Helper.StripHTML method.
You can apply the aspect also on the class, namespace, or assembly level if you don't want to decorate all your properties with HtmlStripperAspect.
Take a look at PostSharp documentation on how exactly this is done.
PostSharp is a compile-time AOP tool, it injects IL code into your assemblies at compile time. If you don't like this, there are run-time AOP tools such as Dynamic Proxy.

Object Oriented - Class Variables

I am pretty new to OOP and looking into things in a bit more depth, but I have a bit of confusion between these 3 methods in C# and which one is best and what the differences are between 2 of them.
Example 1
So lets start with this one, which (so I understand) is the wrong way to do it:
public class MyClass
{
public string myAttribute;
}
and in this way I can set the attribute directly using:
myObject.myAttribute = "something";
Example 2
The next way I have seen and that seems to be recomended is this:
public class MyClass
{
public string myAttribute { get; set;}
}
With getters and setters, this where I dont understand the difference between the first 2 as the variable can still be set directly on the object?
Example 3
The third way, and the way that I understand the theory behind, is creating a set function
public class MyClass
{
string myAttribute;
public void setAttribute(string newSetting)
{
myAttribute = newSetting;
//obviously you can apply some logic in here to remove unwanted characters or validate etc.
}
}
So, what are the differences between the three? I assume example 1 is a big no-no so which is best out of 2 and 3, and why use one over the other?
Thanks

The second
public class MyClass
{
public string MyAttribute { get; set;}
}
is basically shorthand for:
public class MyClass
{
private string myPrivateAttribute;
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
}
That is an auto-implemented property, which is exactly the same as any regular property, you just do not have to implement it, when the compiler can do that for you.
So, what is a property? It's nothing more than a couple of methods, coupled with a name. I could do:
public class MyClass
{
private string myPrivateAttribute;
public string GetMyAttribute()
{
return myPrivateAttribute;
}
public void SetMyAttribute(string value)
{
myPrivateAttribute = value;
}
}
but then instead of writing
myClass.MyAttribute = "something";
string variable = myClass.MyAttribute;
I would have to use the more verbose, but not necessarily clearer form:
myClass.SetMyAttribute("something");
string variable = myClass.GetMyAttribute();
Note that nothing constraints the contents of the get and set methods (accessors in C# terminology), they are methods, just like any other. You can add as much or as little logic as you need inside them. I.e. it is useful to make a prototype with auto-implemented properties, and later to add any necessary logic (e.g. log property access, or add lazy initalization) with an explicit implementation.

What your asking here has to do with encapsulation in OOP languages.
The difference between them is in the way you can access the propriety of an object after you created an object from your class.
In the fist example you can access it directly new MyClass().MyAttribute whether you get or set it's value.
In the second example you declare 2 basic functions for accessing it:
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
In the third example you declare your own method for setting the value. This is useful if you want to customize the setter. For example you don't want to set the value passed, but the value multiplied by 2 or something else...
I recommend some reading. You can find something here and here.

Property is a syntactic sugar over private attribute with get and set methods and it's realy helpful and fast to type;
You may treat automatic property with { get; set;} as a public attribute. It has no additional logic but you may add it later without uset ever notice it.
Just exchange
public string MyLine { get; set;}
to
string myLine;
public string MyLine
{
get { return myLine; }
set { myLine = value + Environment.NewLine; }
}
for example if you need so.
You can also easily create read only property as { get; private set }.
So use Properties instead of public attributes every time just because its easier and faster to write and it's provides better encapsulation because user should not be used get and set methods if you decide to use it in new version of yours programm.

One of the main principles of OOP is encapsulation, and this is essentially the difference between the first example and the other 2.
The first example you have a private field which is exposed directly from the object - this is bad because you are allowing mutation of internal data from outside the object and therefore have no control over it.
The other 2 examples are syntactically equivalent, the second being recommended simply because it's less code to write. However, more importantly they both restrict access & control mutation of the internal data so give you complete control over how the data should be managed - this is ecapsulation.

Getters, setters, and properties best practices. Java vs. C#

I'm taking a C# class right now and I'm trying to find out the best way of doing things. I come from a Java background and so I'm only familiar with Java best-practices; I'm a C# novice!
In Java if I have a private property, I do this;
private String name;
public void setName(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
In C#, I see that there are many ways of doing this.
I can do it like Java:
private string name;
public void setName(string name) {
this.name = name;
}
public string getName() {
return this.name;
}
Or I can do it this way:
private string name;
public string Name {
get { return name; }
set { name = value; }
}
Or:
public string Name { get; set; }
Which one should I use, and what are the caveats or subtleties involved with each approach? When creating classes, I am following general best-practices that I know from Java (especially reading Effective Java). So for example, I am favoring immutability (providing setters only when necessary). I'm just curious to see how these practices fit in with the various ways of providing setters and getters in C#; essentially, how would I translate best-practices from the Java world into C#?
EDIT
I was posting this as a comment to Jon Skeet's answer but then it got long:
What about a non-trivial property (i.e., with significant processing and validation perhaps)? Could I still expose it via a public property but with the logic encapsulated in get and set? Why would/should I do this over having dedicated setter and getter methods (with associated processing and validation logic).

Pre-C# 6
I'd use the last of these, for a trivial property. Note that I'd call this a public property as both the getters and setters are public.
Immutability is a bit of a pain with automatically implemented properties - you can't write an auto-property which only has a getter; the closest you can come is:
public string Foo { get; private set; }
which isn't really immutable... just immutable outside your class. So you may wish to use a real read-only property instead:
private readonly string foo;
public string Foo { get { return foo; } }
You definitely don't want to write getName() and setName(). In some cases it makes sense to write Get/Set methods rather than using properties, particularly if they could be expensive and you wish to emphasize that. However, you'd want to follow the .NET naming convention of PascalCase for methods, and you wouldn't want a trivial property like this to be implemented with normal methods anyway - a property is much more idiomatic here.
C# 6
Hooray, we finally have proper read-only automatically implemented properties:
// This can only be assigned to within the constructor
public string Foo { get; }
Likewise for read-only properties which do need to do some work, you can use member-bodied properties:
public double Area => height * width;

If all you need is a variable to store some data:
public string Name { get; set; }
Want to make it appear read-only?
public string Name { get; private set; }
Or even better...
private readonly string _name;
...
public string Name { get { return _name; } }
Want to do some value checking before assigning the property?
public string Name
{
get { return m_name; }
set
{
if (value == null)
throw new ArgumentNullException("value");
m_name = value;
}
}
In general, the GetXyz() and SetXyz() are only used in certain cases, and you just have to use your gut on when it feels right. In general, I would say that I expect most get/set properties to not contain a lot of logic and have very few, if any, unexpected side effects. If reading a property value requires invoking a service or getting input from a user in order to build the object that I'm requesting, then I would wrap it into a method, and call it something like BuildXyz(), rather than GetXyz().

Use properties in C#, not get/set methods. They are there for your convenience and it is idiomatic.
As for your two C# examples, one is simply syntactic sugar for the other. Use the auto property if all you need is a simple wrapper around an instance variable, use the full version when you need to add logic in the getter and/or setter.

In C# favor properties for exposing private fields for get and/or set. The thie form you mention is an autoproperty where the get and set automatically generate a hidden pivot backing field for you.
I favor auto properties when possible but you should never do a set/get method pair in C#.

public string Name { get; set; }
This is simply a auto-implemented property, and is technically the same as a normal property. A backing field will be created when compiling.
All properties are eventually converted to functions, so the actual compiled implementation in the end is the same as you are used to in Java.
Use auto-implemented properties when you don't have to do specific operations on the backing field. Use a ordinary property otherwise. Use get and set functions when the operation has side effects or is computationally expensive, use properties otherwise.

Regardless of which way you choose in C# the end result is the same. You will get a backinng variable with separate getter and setter methods. By using properties you are following best practices and so it's a matter of how verbose you want to get.
Personally I would choose auto-properties, the last version: public string Name { get; set; }, since they take up the least amount of space. And you can always expand these in the future if you need add something like validation.

Whenever possible I prefer public string Name { get; set; } as it's terse and easily readable. However, there may be times when this one is necessary
private string name;
public string Name {
get { return name; }
set { name = value; }
}

In C# the preferred way is through properties rather than getX() and setX() methods. Also, note that C# does not require that properties have both a get and a set - you can have get-only properties and set-only properties.
public boolean MyProperty
{
get { return something; }
}
public boolean MyProperty
{
set { this.something = value; }
}

First let me try to explain what you wrote:
// private member -- not a property
private string name;
/// public method -- not a property
public void setName(string name) {
this.name = name;
}
/// public method -- not a property
public string getName() {
return this.name;
}
// yes it is property structure before .Net 3.0
private string name;
public string Name {
get { return name; }
set { name = value; }
}
This structure is also used nowadays but it is most suitable if you want to do some extra functionality, for instance when a value is set you can it to parse to capitalize it and save it in private member for alter internal use.
With .net framework 3.0
// this style is introduced, which is more common, and suppose to be best
public string Name { get; set; }
//You can more customize it
public string Name
{
get;
private set; // means value could be set internally, and accessed through out
}
Wish you better luck in C#

As mentioned, all of these approaches result in the same outcome. The most important thing is that you pick a convention and stick with it. I prefer using the last two property examples.

like most of the answers here, use Automatic properties. Intuitive, less lines of code and it is more clean. If you should serialize your class, mark the class [Serializable]/ with [DataConract] attribute. And if you are using [DataContract] mark the member with
[DataMember(Name="aMoreFriendlyName")]
public string Name { get; set; }
Private or public setter depends on your preference.
Also note that automatic properties require both getters and setters(public or private).
/*this is invalid*/
public string Name
{
get;
/* setter omitted to prove the point*/
}
Alternatively, if you only want get/set, create a backing field yourself

Which one should I use, and what are the caveats or subtleties involved with each approach?
When going with properties there is one caveat that has not been mentioned yet: With properties you cannot have any parametrization of your getters or setters.
For example imagine you want to retrieve a list items and want to also apply a filter at the same time. With a get-method you could write something like:
obj.getItems(filter);
In contrast, with a property you are forced to first return all items
obj.items
and then apply the filter in the next step or you have to add dedicated properties that expose items filtered by different criteria, which soon bloats your API:
obj.itemsFilteredByX
obj.itemsFilteredByY
What sometimes can be a nuisance is when you started with a property, e.g. obj.items and then later discovered that getter- or setter-parametrization is needed or would make things easier for the class-API user. You would now need to either rewrite your API and modify all those places in your code that access this property or find an alternative solution. In contrast, with a get-method, e.g. obj.getItems(), you can simply extend your method's signature to accept an optional "configuration" object e.g. obj.getItems(options) without having to rewrite all those places that call your method.
That being said, (auto-implemented) properties in C# are still very useful shortcuts (for the various reasons mentioned here) since most of the time parametrization may not be needed – but this caveat stands.