We Keep Coding

shadowed field does not get set in base class constructor

Why is it that when I set a shadowed field (declared using new keyword) in a base class constructor, the field that was shadowed gets set but not the field that is shadowing?
I thought that this.GetType() referred to the outermost class all the way down into base class calls including the constructor. I also thought that shadowing made the shadowed field not accessible.
In my quick watch I can see two fields, the shadowed one that got set and the shadowing one (of the subclass) that is still not initialized.
I fixed it by explicitly setting the shadowing field in the subclass constructor after it calls the base class constructor, but I'd still like to know why it acts this way. .Net Fiddle
using System;
public class Program
{
public static void Main()
{
SubClass subClass = new SubClass(2);
Console.WriteLine(subClass.MyField);
}
}
public class BaseClass
{
public BaseClass(int value)
{
MyField = value; // This doesn't point to SubClass.MyField
}
public int MyField;
}
public class SubClass : BaseClass
{
public SubClass(int value):base(value)
{
}
public new int MyField = 4;
}
Update
After reviewing the answers, I see I didn't ask what I wanted to know in the most direct way. Sorry for any inconvenience. Here's what I really want to know:
I do understand shadowing. I don't agree with it. I don't think it should be allowed for fields (as long as overridable fields were made a language feature). I don't see the point in shadowing fields and having the shadowed field hanging around. I do however see the point in overridable fields and I don't understand why that language feature doesn't exist when it exists for properties and methods. So, why have shadowing on fields? Why is there not overriding on fields?

We have
I also thought that shadowing made the shadowed field not accessible.
Followed by
I do understand shadowing.
I'm not entirely sure that you do. You've already expressed one false belief about shadowing; how do we know there aren't more?
I don't agree with it.
Your opinion is noted. I note that you are not required to use the feature if you don't like it.
I don't think it should be allowed for fields (as long as overridable fields were made a language feature).
Noted.
I do however see the point in overridable fields and I don't understand why that language feature doesn't exist when it exists for properties and methods.
Fields should be private implementation details of classes. If they are, then there is no accessible name to shadow or override, so the problem is moot. A feature that we would want no one to use is a bad feature.
So, why have shadowing on fields?
Suppose there is a protected field in a derived class. Now consider the brittle base class problem. Work through a number of such scenarios; you're critiquing a language design choice, so think like the language designers think. What do you conclude from your investigation into typical brittle base class scenarios?
Why is there not overriding on fields?
Because (1) we have no mechanism for overriding fields; methods have vtables but there is no vtable mechanism for fields. And (2) fields should be private implementation details of classes, and therefore there is never a need to override them. If you want to override a field, make a property that wraps it and override that. The code change is tiny to go from a field to a virtual property.
Fields should be in the mechanism domain of the class; properties are in the business domain. Specialization of behaviour belongs in the business domain.

public class BaseClass
{
public BaseClass(int value)
{
MyField = value; // This doesn't point to SubClass.MyField
}
public int MyField;
}
The base class doesn't know about its derived types. MyField = value does exactly what it says it's doing: it assigns MyField with value.
public class SubClass : BaseClass
{
public SubClass(int value):base(value)
{
}
public new int MyField = 4;
}
Are you expecting the value 4 to propagate to the base type? Your question is quite hard to answer, because it's not exactly clear what your definition of "intuitive" and expectations are.... and your example code is very poor OOP design.
There aren't lots of valid reasons to ever expose a public field, base class or not.
Let me rephrase your example:
public abstract class BaseClass
{
protected BaseClass(int value)
{
_value = value;
}
private int _value;
public virtual int Value { get { return _value; } set { _value = value; } }
}
public class SubClass : BaseClass
{
public SubClass(int value) : base(value)
{
}
public new int Value { get; set; } // hides base class member
}
Now. SubClass.Value is its own thing - if you want to access the value that was passed down the constructor, you need to do so via the base class.
The base class member doesn't "cease to exist", it's only hidden, or shadowed, by a new member in a derived type, that just so happens to have the same identifier:
var foo = new SubClass(42);
Console.WriteLine(foo.Value);
Console.WriteLine(((BaseClass)foo).Value);
Console.ReadKey();
This code outputs 0, then 42 - because when foo.Value gets accessed the SubClass says "hey base class, let me handle this - I have my own definition of Value, and this call mine to pick up." ...and returns 0 because, well, it's never actually assigned; the 42 is only visible via the base class.
That is what member shadowing does.
And it works the same even without the new keyword - the new keyword merely suppresses a compiler warning that says "you're hiding a base class member here, are you really totally completely sure you intend to be doing this?" - because in a normal world, that typically isn't what you would want to be doing.
Now, notice I made the Value property virtual. What happens if you override it instead?
public class SubClass : BaseClass
{
public SubClass(int value)
: base(value)
{
}
public override int Value { get; set; }
}
The little console program above (a few snippets up) will now output 0 and 0 - because the subclass' Value overrides the base class member, effectively telling C# to resolve member calls to the derived type. So to output the 42 you're passing in, because you're overriding the member, you become responsible for how it works - the _value private field in the base class still says 42, but the Value property being overridden, the field is left unused.
So you assign it in your derived type's constructor (here sealing the class to avoid a virtual member call in the constructor):
public sealed class SubClass : BaseClass
{
public SubClass(int value)
: base(0)
{
Value = value;
}
public override int Value { get; set; }
}
So, here the derived type is passing 0 to the base class, and overriding the member. What does the little snippet output for 42 now?
static void Main(string[] args)
{
var foo = new SubClass(42);
Console.WriteLine(foo.Value);
Console.WriteLine(((BaseClass)foo).Value);
Console.ReadKey();
}
it will output 42 for both the derived and the downcasted calls, because the type cast is now redundant, since the virtual member is overridden.

Not sure why you want to do this, but here is how :
public class BaseClass
{
public BaseClass(int value)
{
SetValue(x => x.MyField, value);
}
public int MyField;
public void SetValue<TField>(Expression<Func<BaseClass, TField>> memberSelector, TField value)
{
var expression = memberSelector.Body as MemberExpression;
if (expression == null)
throw new MemberAccessException();
this.GetType().GetField(expression.Member.Name)
.SetValue(this, value);
}
}

Keep in mind that shadowing a field just makes a new field, it is in no way related to the field in the base class (except by virtue of the fact that you've given it the same name).
Simply put, you haven't written any code that sets the field in SubClass, you've only written code that sets the field in BaseClass:
public class BaseClass
{
public BaseClass(int value)
{
MyField = value; // This doesn't point to SubClass.MyField
}
public int MyField;
}
MyField here can only ever refer to the MyField in BaseClass. It can't possibly know that you're going to create a subclass later and put a field in it with the same name. And even if you do that, all you've done is create a different field with the same name, so why would setting BaseClass.MyField also set the mostly unrelated SubClass.MyField?

Adding accessor to interface property allowed, but not to abstract property

Why is it that the following is legal C#:
public interface ISomeInterface
{
int SomeProperty
{
get;
}
}
public class SomeClassImplementingInterface : ISomeInterface
{
public int SomeProperty
{
get { return 32; }
protected set {}
}
}
but this is not:
public abstract class SomeAbstractClass
{
public abstract int SomeProperty
{
get;
}
}
public class SomeClassExtendingAbstractClass : SomeAbstractClass
{
public override int SomeProperty
{
get { return 32; }
protected set {}
}
}
The latter results in the following compile-time error:
'InterfaceAbstractTest.SomeClassExtendingAbstractClass.SomeProperty.set':
cannot override because
'InterfaceAbstractTest.SomeAbstractClass.SomeProperty' does not have
an overridable set accessor InterfaceAbstractTest
What is the reasoning for not disallowing the latter whilst allowing the former?

Because a caller using the interface only cares that an implementer of the interface at least implements the interface's definition, as #davisoa states, whereas SomeAbstractClass in your example defines a public contract which states exactly the type, accessibility, and (for properties) readability/writability of members.
If you use reflection to get the PropertyInfo of SomeProperty (from either the base or child class), it needs to resolve that information from somewhere. Allowing the child class to change the readability/writability would be as much of a contract violation as a change in return type or argument list.
Imagine for instance:
SomeAbstractClass sc = new SomeClassExtendingAbstractClass();
PropertyInfo pi = sc.GetType().GetProperty("SomeProperty");
Console.Out.WriteLine(pi.CanWrite); // What should be printed here?

This is because the Interface implementation is making a promise that there will be a property SomeProperty that you can "Get".
The abstract class implementation is making a promise that it's child classes will provide an implementation of a property SomeProperty with a public get method.
In the end, the base class is defining something that must be overridden, whereas the interface is defining a contract.

This is by design. I am quoting from the C# language specs:
An overriding property declaration must specify the exact same
accessibility modifiers, types and name as the inherited property, if
the inherited property has only a single accessor (i.e.,... ready only
or write-only), the overriding property must include only that
accessor.
The reason behind that decesion could be because the interfaces are more flexibly type of contracts than abstract classes. Interfaces cares only about the least common denominator rather than the whole implementation. I think there are good reasons to choose one design over the other.

You're trying to override a set operator that doesn't exist. Either define a set portion of the property in the abstract class, or don't try to define one in the concrete class. Since you have the set as protected in the concrete class, my guess is what you want to do is make a protected set operator in the abstract definition.

What is necessary is to both override the existing property and shadow it with a new read-write one. Unfortunately, .net does not provide any means of both overriding and shadowing a member within a single class. The best one can do is probably to have the abstract base class define a concrete non-virtual read-only property whose getter calls an abstract function. A derived class can then shadow the property with a non-virtual read-write function which calls the same function in its getter, and a new abstract or virtual function in its setter.

How to hide set method of an implemented property from an interface in C#?

Greetings everyone...
If I have the following interface:
interface IMyInterface
{
int property { get; set; }
}
And the following implementation:
class MyClass : IMyInterface
{
// anything
}
How can I hide the set method of property from the instances of MyClass... In other words, I don't want the set method of property to be public, is that possible?
It would be easy to do with abstract class:
abstract class IMyInterface
{
int property { get; protected set; }
}
Then I could only set the property within the class that implements the abstract class above...

Don't have the set in the interface to begin with. You can still implement it as private.
You can't "hide" it, it's part of the contract. If you don't want it to be part of the contract, don't define it.

If you use the following interface the set method will be unavailable when classes are manipulated via the interface:
interface IMyInterface
{
int property { get; }
}
You could then implement the class like this:
class MyClass : IMyInterface
{
int property { get; protected set; }
}

If some implementations will only implement some parts of an interface, it may be a good idea to subdivide the interface into the parts which each implementation will either implement completely or not at all, and then define interfaces which inherit all the common combinations of them. Adapting your example:
interface IMyReadableInterface
{
int property { get; }
}
interface IMyFullInterface : IMyReadableInterface
{
new int property { get; set; }
}
Classes which want to support read-write access should implement IMyFullInterface; those which want to only support read access should only implement IMyReadableInterface. This segregation will not require any extra work for implementations of either interface which are written in C# and implement property implicitly. Code which implements property in VB, or explicitly implements property in C#, will have to define two implementations of property--a read-only one and a read-write one, but such is life. Note that while one could define an IMyWritableInterface which just had a setter, and have IMyFullInterface inherit both IMyReadableInterface and IMyWritableInterface, IMyFullInterface would still have to define a read-write property of its own, and when using explicit implementation one would then have to define three properties (I really don't understand why C# can't use a read-only and write-only property together as thought they were a read-write property, but it can't).

Assuming you need the setter to be part of the interface but for some reason it does not make sense for it to be used on a particular implementer (in this case MyClass) you can always throw an exception in the setter (such as an InvalidOperationException). This will not protect you at compile time, only at run time. It is a bit strange though, as code that operates on the interface has no idea whether calling the setter is allowed.

There are certainly cases where you want the interface to have a set and then hide it in some concrete class.
I believe the code below shows what we want to accomplish. I.e. the implementation hides the setter, but any IMyInterface aware component will have access to it.
public static void Main()
{
var myClass = new MyClass();
myClass.Property = 123; // Error
((IMyInterface)myClass).Property = 123; // OK
}
It's basically the same pattern you often see for IDisposable.Dispose() where you have an Explicit Interface Implementation. Here's an example for completeness.
public interface IMyInterface
{
int Property { get; set; }
}
public class MyClass : IMyInterface, IDisposable
{
public int Property { get; private set; }
int IMyInterface.Property
{
get => Property;
set => Property = value;
}
void IDisposable.Dispose() {}
}
Too much typing :(
C# doesn't help us much here. Ideally, it would be possible to have an explicit interface implementation for the setter:
// In C# 10 maybe we can do this instead:
public class MyFutureClass : IMyInterface
{
public int Property { get; IMyInterface.set; }
}
See C# feature proposal here.

There is no protected or private in interface, everything is public. Either you don't define any set or use it as public.

Interface with getter and setter in c#

As I read here http://msdn.microsoft.com/en-us/library/75e8y5dd%28v=VS.100%29.aspx
It is possible to have get in an Interface BUT NOT set ?
OR if I want getter and setter in Interface, do I have to use the old syntax getVar setVar just because new syntax doesn't fit Interface syntax?
Update: If I must omit set in Interface, does this means I cannot enforce class to have setter which defeats the purpose of having an Interface in this case as I can only partially enforce?

No. I think you misunderstood. That article is about the possibility of having an interface with a readonly property (a property with only getter). But, if you need, you can put also the setter in the interface:
interface IHasProperty
{
string Property{ get;set; }
}
class HasProperty:IHasProperty
{
public string Property{ get;set; }
}

You can use property syntax. Use this combination:
interface ISomething
{
string Test { get; }
}
class Something : ISomething
{
public string Test { get; private set; }
}
You can of course add full implementations for the getters in Something.Test, if you choose to. I only used backing fields for brevity.
Remember that an interface defines the bare minimum set of things you must implement. You can add any gravy (new methods, accessors, members, etc) on top that you want. You could even add a public setter:
interface ISomething
{
string Test { get; }
}
class Something : ISomething
{
public string Test { get; set; } // Note that set is public
}
The only restriction is that someone can't use the gravy you add, unless they have a reference of the concrete type (the class, not the interface), or a different interface that defines the methods you added.

Yes, just omit set; from the property declaration. For example:
interface IName
{
string Name { get; }
}

The answer in fact is the mixture of the above answers: omitting setter on the interface and having get; private set; on the class.

If you only want the get available just use {get;private set;}
http://msdn.microsoft.com/en-us/library/bb384054.aspx
The class that is shown in the previous example is mutable. Client code can change the values in objects after they are created. In complex classes that contain significant behavior (methods) as well as data, it is often necessary to have public properties. However, for small classes or structs that just encapsulate a set of values (data) and have little or no behaviors, it is recommended to make the objects immutable by declaring the set accessor as private. For more information, see How to: Implement a Lightweight Class with Auto-Implemented Properties (C# Programming Guide).
Attributes are permitted on auto-implemented properties but obviously not on the backing fields since those are not accessible from your source code. If you must use an attribute on the backing field of a property, just create a regular property.

You misunderstood.
According to the article you cannot use access modifiers on interface.
You CAN use both get and set in interface property!
See in the following MSDN example:
http://msdn.microsoft.com/en-us/library/87d83y5b(v=VS.100).aspx

Why can't C# interfaces contain fields?

For example, suppose I want an ICar interface and that all implementations will contain the field Year. Does this mean that every implementation has to separately declare Year? Wouldn't it be nicer to simply define this in the interface?

Though many of the other answers are correct at the semantic level, I find it interesting to also approach these sorts of questions from the implementation details level.
An interface can be thought of as a collection of slots, which contain methods. When a class implements an interface, the class is required to tell the runtime how to fill in all the required slots. When you say
interface IFoo { void M(); }
class Foo : IFoo { public void M() { ... } }
the class says "when you create an instance of me, stuff a reference to Foo.M in the slot for IFoo.M.
Then when you do a call:
IFoo ifoo = new Foo();
ifoo.M();
the compiler generates code that says "ask the object what method is in the slot for IFoo.M, and call that method.
If an interface is a collection of slots that contain methods, then some of those slots can also contain the get and set methods of a property, the get and set methods of an indexer, and the add and remove methods of an event. But a field is not a method. There's no "slot" associated with a field that you can then "fill in" with a reference to the field location. And therefore, interfaces can define methods, properties, indexers and events, but not fields.

Interfaces in C# are intended to define the contract that a class will adhere to - not a particular implementation.
In that spirit, C# interfaces do allow properties to be defined - which the caller must supply an implementation for:
interface ICar
{
int Year { get; set; }
}
Implementing classes can use auto-properties to simplify implementation, if there's no special logic associated with the property:
class Automobile : ICar
{
public int Year { get; set; } // automatically implemented
}

Declare it as a property:
interface ICar {
int Year { get; set; }
}

Eric Lippert nailed it, I'll use a different way to say what he said. All of the members of an interface are virtual and they all need to be overridden by a class that inherits the interface. You don't explicitly write the virtual keyword in the interface declaration, nor use the override keyword in the class, they are implied.
The virtual keyword is implemented in .NET with methods and a so-called v-table, an array of method pointers. The override keyword fills the v-table slot with a different method pointer, overwriting the one produced by the base class. Properties, events and indexers are implemented as methods under the hood. But fields are not. Interfaces can therefore not contain fields.

Why not just have a Year property, which is perfectly fine?
Interfaces don't contain fields because fields represent a specific implementation of data representation, and exposing them would break encapsulation. Thus having an interface with a field would effectively be coding to an implementation instead of an interface, which is a curious paradox for an interface to have!
For instance, part of your Year specification might require that it be invalid for ICar implementers to allow assignment to a Year which is later than the current year + 1 or before 1900. There's no way to say that if you had exposed Year fields -- far better to use properties instead to do the work here.

The short answer is yes, every implementing type will have to create its own backing variable. This is because an interface is analogous to a contract. All it can do is specify particular publicly accessible pieces of code that an implementing type must make available; it cannot contain any code itself.
Consider this scenario using what you suggest:
public interface InterfaceOne
{
int myBackingVariable;
int MyProperty { get { return myBackingVariable; } }
}
public interface InterfaceTwo
{
int myBackingVariable;
int MyProperty { get { return myBackingVariable; } }
}
public class MyClass : InterfaceOne, InterfaceTwo { }
We have a couple of problems here:
Because all members of an interface are--by definition--public, our backing variable is now exposed to anyone using the interface
Which myBackingVariable will MyClass use?
The most common approach taken is to declare the interface and a barebones abstract class that implements it. This allows you the flexibility of either inheriting from the abstract class and getting the implementation for free, or explicitly implementing the interface and being allowed to inherit from another class. It works something like this:
public interface IMyInterface
{
int MyProperty { get; set; }
}
public abstract class MyInterfaceBase : IMyInterface
{
int myProperty;
public int MyProperty
{
get { return myProperty; }
set { myProperty = value; }
}
}

Others have given the 'Why', so I'll just add that your interface can define a Control; if you wrap it in a property:
public interface IView {
Control Year { get; }
}
public Form : IView {
public Control Year { get { return uxYear; } } //numeric text box or whatever
}

A lot has been said already, but to make it simple, here's my take.
Interfaces are intended to have method contracts to be implemented by the consumers or classes and not to have fields to store values.
You may argue that then why properties are allowed? So the simple answer is - properties are internally defined as methods only.

Interfaces do not contain any implementation.
Define an interface with a property.
Further you can implement that interface in any class and use this class going forward.
If required you can have this property defined as virtual in the class so that you can modify its behaviour.

Beginning with C# 8.0, an interface may define a default implementation for members, including properties. Defining a default implementation for a property in an interface is rare because interfaces may not define instance data fields.
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
interface IEmployee
{
string Name
{
get;
set;
}
int Counter
{
get;
}
}
public class Employee : IEmployee
{
public static int numberOfEmployees;
private string _name;
public string Name // read-write instance property
{
get => _name;
set => _name = value;
}
private int _counter;
public int Counter // read-only instance property
{
get => _counter;
}
// constructor
public Employee() => _counter = ++numberOfEmployees;
}

For this you can have a Car base class that implement the year field, and all other implementations can inheritance from it.

An interface defines public instance properties and methods. Fields are typically private, or at the most protected, internal or protected internal (the term "field" is typically not used for anything public).
As stated by other replies you can define a base class and define a protected property which will be accessible by all inheritors.
One oddity is that an interface can in fact be defined as internal but it limits the usefulness of the interface, and it is typically used to define internal functionality that is not used by other external code.