Object-Oriented C# · Lesson 25

Explicit interfaces for separate object roles

Expose focused capabilities without placing every member on the concrete public surface.

How it works

Explicit interface implementation associates a member directly with one interface contract. The member is accessed through that interface type rather than as an ordinary public member of the concrete class. This is useful when an object serves several roles with different surfaces, or when interface members would otherwise conflict in name or meaning.

The feature organizes an API; it is not a security boundary. Code that can obtain the object may still cast it to a supported interface. Use role-specific references to communicate what a consumer is intended to do, and use actual authorization mechanisms when permissions must be enforced. A read-only role can improve design clarity without pretending that a cast is an access-control system.

Walk through the example. Profile implements a readable role and an editing role. The caller stores the same instance under both interface types. The readable role exposes the name, while the editing role renames it. Reading again observes the new name because both references identify the same object. The explicit implementations keep those members off Profile's ordinary concrete member list.

Watch the boundary. Separating roles does not create independent state or a snapshot. A consumer holding only the readable interface can still observe updates made through another role. If stable data is required, return an immutable value or snapshot instead. Also avoid explicit implementation merely to hide a confusingly broad interface; a smaller interface may be the clearer design in the first place.

Practice independently. Add a reset role to a profile model and decide which consumers should receive it. Verify that all roles observe the same underlying state. Then create an immutable snapshot returned through a separate method and show how its behavior differs after a rename. Explain why the readable role is an API-shaping choice, while enforcing user permissions would require a separate policy and trusted boundary.

A working example

using System;
using System.Collections.Generic;
using System.Linq;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.RegularExpressions;

var profile = new Profile("Ada");
IReadableProfile view = profile;
IProfileEditor editor = profile;
Console.WriteLine(view.Name);
editor.Rename("Lin");
Console.WriteLine(view.Name);
interface IReadableProfile { string Name { get; } }
interface IProfileEditor { void Rename(string name); }
sealed class Profile : IReadableProfile, IProfileEditor
{
    private string name;
    public Profile(string name) { this.name = name; }
    string IReadableProfile.Name => name;
    void IProfileEditor.Rename(string name) { this.name = name; }
}

Expected output

Ada
Lin
Try this
Explicit interfaces shape roles, but they neither freeze state nor enforce a security permission.