Introduction

In languages such as C#, an interface can declare a property as part of a contract, and implementing types must provide compatible accessors. The important idea is that the interface specifies what can be read or written, while the class decides how that value is stored or computed.

Basic interface property syntax

In C#, an interface can declare read-only or read-write properties.

1public interface IUser
2{
3    string Name { get; }
4    int Age { get; set; }
5}

This means:

• every IUser implementation must expose a readable Name
• every IUser implementation must expose readable and writable Age

The interface does not contain storage. It only defines the shape of the contract.

Implement the property in a class

The simplest implementation is an auto-property:

1public sealed class User : IUser
2{
3    public string Name { get; }
4    public int Age { get; set; }
5
6    public User(string name, int age)
7    {
8        Name = name;
9        Age = age;
10    }
11}

This is enough in many applications because the compiler generates the backing field automatically.

Computed and validated properties

An interface property does not have to map to a plain field. The implementation can compute the value or validate it.

1public interface IRectangle
2{
3    double Width { get; set; }
4    double Height { get; set; }
5    double Area { get; }
6}
7
8public sealed class Rectangle : IRectangle
9{
10    private double _width;
11    private double _height;
12
13    public double Width
14    {
15        get => _width;
16        set
17        {
18            if (value <= 0) throw new ArgumentOutOfRangeException(nameof(value));
19            _width = value;
20        }
21    }
22
23    public double Height
24    {
25        get => _height;
26        set
27        {
28            if (value <= 0) throw new ArgumentOutOfRangeException(nameof(value));
29            _height = value;
30        }
31    }
32
33    public double Area => Width * Height;
34}

This is still a valid interface implementation because the public API matches the interface contract.

Explicit interface implementation

Sometimes you want a property to be available only when the object is viewed through the interface. That is where explicit implementation is useful.

1public interface ISecretValue
2{
3    string Token { get; }
4}
5
6public sealed class ApiClient : ISecretValue
7{
8    string ISecretValue.Token => "internal-token";
9}

Use it like this:

ApiClient client = new ApiClient();
ISecretValue secret = client;
Console.WriteLine(secret.Token);

You cannot access client.Token directly because the property is implemented explicitly.

Match accessors exactly

The implementation must satisfy the interface contract. If the interface says get; set;, the class cannot expose only get;.

Valid example:

1public interface ISettings
2{
3    string Theme { get; set; }
4}
5
6public sealed class Settings : ISettings
7{
8    public string Theme { get; set; } = "light";
9}

Invalid example:

1// Does not satisfy ISettings
2public sealed class BadSettings : ISettings
3{
4    public string Theme => "light";
5}

The compiler will reject this because the setter is missing.

Interface properties in modern C#

Recent C# versions support more advanced interface capabilities, but the normal guidance remains the same: keep interface properties focused on externally observable behavior, not implementation details.

Good interface property candidates:

• identifiers
• state needed by consumers
• values that naturally belong in a public contract

Bad interface property candidates:

• internal caches
• persistence-only fields
• values exposed only because one implementation happens to have them

The property should represent what callers can rely on across all implementations.

Common Pitfalls

The most common mistake is putting implementation details into the interface just because one class needs them. Another is forgetting that a read-write interface property requires both accessors in the implementation. Developers also sometimes use interface properties where a method would express intent more clearly, especially when the value is expensive to compute or has side effects. Explicit interface implementation is another source of confusion because the property seems to disappear until the object is cast to the interface type. Finally, people often treat interface properties as if they must use backing fields, when computed and validated implementations are perfectly valid.

Summary

• An interface property defines a contract, not storage.
• Classes can implement interface properties with auto-properties, custom accessors, or computed values.
• The implementation must satisfy the accessors declared by the interface.
• Use explicit interface implementation when the property should be exposed only through the interface.
• Keep interface properties focused on public behavior rather than implementation details.
• Prefer methods instead of properties when reading the value is expensive or effectful.