为什么在设置只读的覆盖属性时没有编译器错误？

Question

I've been learning about C# inheritance and interfaces ( 1 , 2 , 3 ). In the following example, why is there not a compiler error when the property is set in a derived class that makes the property read-only via the auto properties?

Fiddle

using System;
        
public interface IFoo {
    string Title { get; set; }  
}

public abstract class AbstractFoo : IFoo {
    public virtual string Title { get; set; }   
}

public class Foo : AbstractFoo {
    public string Title { get; set; }   
}

public class Bar : AbstractFoo {
    public override string Title { get { return "Read Only Title"; } } 
}

public class Program
{
    public static void Main()
    {
        var foo = new Foo();
        Console.WriteLine(foo.Title);
        
        var bar = new Bar();
        Console.WriteLine(bar.Title); // output: "Read Only Title"
        
        bar.Title = "A new and better title!"; // Why does this not generate an error?
        Console.WriteLine(bar.Title); // output: "Read Only Title" - value was not set
    }
}

The underlying question, is it possible to prevent bar.Title from being set , ie a read-only field for that derived class only ? I see in other related answers that the new keyword can be used to re-declare the property in the derived class, but at the same time advising against it.

Answer 1

You didn't override it making it read-only. You just only override the get , and left the set as the base implementation. If you wanted to make it angry:

public new string Title => "Read Only Title";

now it knows about a problem.

Answer 2

It seems you didn't understand how interfaces, implementations and redefines (new) works.

So, shortly, you can't change the property to make it readonly.

Using the "new" keyword, you can force the object of type Bar to have a readonly Title property. But, what if someone casts the object to the interface? In this scenario, the Title property is the one of the interface (Read/Write) and not the one of the Bar class (ReadOnly).

Just for explain it with an example. Suppose you change your Bar code in this way:

public class Bar : AbstractFoo
{
    public new string Title { get { return "Read Only Title"; } }
}

In this way you're saying that the Bar class has a property that will overwrite the Title property of the AbstractFoo class.

But, look at this code:

        var bar = new Bar();
        bar.Title = "John"; // Compile error: Bar Title is readonly

        var fooInterface = bar as IFoo;
        fooInterface.Title = "Doe"; // OK -> IFoo interface Title is writable
        Console.WriteLine(fooInterface.Title); // Doe -> Title is the one of the interface, not of the Bar class

As you can see:

• If you use the Bar class, you can't write the Title property (what you want)
• If you cast the object to the interface, it works with the AbstractFoo property... I'm not sure you want that

I hope it's clear

Answer 3

A property in .NET is effectively a combination of a get method and a set method. Although the two methods would be strongly associated with each other, there are times when it may make sense to override just one (more typically the "set" method). For example, a base "observable object" class may have a get and set method that simply read or write a private field, but a derived class might usefully raise an event from the setter without changing the getter behavior.

Even though changing a getter without changing a setter would be unusual, it may make sense in situations where a class has a properties to indicate whether its value can be modified via the reference, can be guaranteed never to change, or neither, and where the base class doesn't allow modification but doesn't guarantee immutability. In such cases, the default setter would throw a NotSupportedException ; a derived class might plausibly use a specialized getter that eg lazily creates its value, but still use the default setter.

Answer 4

All depends from what you need to do.

Usually people define interfaces for write a kind of contract that they have to respect. In this way you can write code that will work with any type of object that subscribe that contract (interface).

Looking at your example, I don't understand why you create an interface with read/write access and then you ask to use it as readonly.

In any way, you have three options:

• Change the Bar class for have the Title property with get/set method but throw an exception when someone sets the value (as supercat told before)
• Change the Bar class as I wrote before, but pay attention to the situation where you cast the object to the interface (as I explained before)
• Separeate the readonly and writeable interfaces

Here the code for the last options:

/// <summary>
/// Readeable Foo
/// </summary>
public interface IReadonlyFoo : ICommonFoo
{
    string Title { get; }
}


/// <summary>
/// Readeable and writeable Foo
/// </summary>
public interface IFoo : ICommonFoo
{
    string Title { get; set; }
}


/// <summary>
/// Common interface between readonly and complete Foo
/// </summary>
public interface ICommonFoo
{
    string Name { get; set; }
}



/// <summary>
/// Abstract implementation of common properties/functions
/// </summary>
public abstract class AbstractCommonFoo : ICommonFoo
{
    public string Name { get; set; }
}


/// <summary>
/// Abstract implementation of the writeable Foo
/// </summary>
public abstract class AbstractFoo : AbstractCommonFoo, IFoo
{

    public string Title { get; set; }
}



/// <summary>
/// Abstrac implementation of the readonly Foo
/// </summary>
public abstract class AbstractReadonlyFoo : AbstractCommonFoo, IReadonlyFoo
{
    public string Title { get; }
}


/// <summary>
/// Foo
/// </summary>
public class Foo : AbstractFoo
{

}


/// <summary>
/// Readonly Foo (Bar)
/// </summary>
public class Bar : AbstractReadonlyFoo
{

}

If you really need to have both readonly and writeable situations, maybe this is the best for you. So in your code, any method will accept:

• ICommonFoo when Title is not needed (so you can pass both Foo and Bar class)
• IReadonlyFoo when Title is only read (you can pass both Foo and Bar class)
• IFoo when you need to set the Title (you can pass only Foo)

Using the two interfaces make your code longer, but easier to use. For example, in method where you need to set the Title, you put in parameters the IFoo interface, so if someone tries to pass a Bar, the compiler show the error. If you use the "throw NotImplementedException" (one of the other solutions), your code will compile, but will fail at runtime..

It's not a simple topic. I hope I explain it in a good way.