Record inheritance in C Sharp (C#) - Deep Dive

Overview - Record inheritance

What is it?

Record inheritance in C# allows one record type to extend another, inheriting its properties and behavior. Records are special classes designed for immutable data with built-in value equality. By inheriting records, you can create new records that reuse and extend existing data structures easily. This helps organize related data models with less code.

Why it matters

Without record inheritance, you would have to duplicate properties and logic across similar data types, leading to more errors and harder maintenance. Record inheritance solves this by enabling reuse and clear relationships between data models. This makes programs easier to understand and evolve, especially when working with complex data.

Where it fits

Before learning record inheritance, you should understand basic C# classes, properties, and the concept of records. After mastering record inheritance, you can explore advanced topics like pattern matching with records, record structs, and how inheritance affects equality and immutability.

Mental Model

Core Idea

Record inheritance lets one immutable data type build on another, sharing properties and behavior while keeping value-based equality.

Think of it like...

It's like a family recipe where a child recipe inherits the ingredients and steps from the parent recipe but adds its own special twist.

BaseRecord
  ├─ Property1
  ├─ Property2
  └─ MethodA()
DerivedRecord : BaseRecord
  ├─ Inherits Property1, Property2
  ├─ Adds Property3
  └─ Overrides MethodA()

Build-Up - 7 Steps

1

Foundation

Understanding C# Records Basics

Concept: Introduce what records are and how they differ from classes.

In C#, a record is a reference type designed to hold immutable data. It automatically provides value-based equality, meaning two records with the same data are equal. You define a record like this: public record Person(string Name, int Age); This creates a record with two properties, Name and Age, and a constructor to set them.

Result

You get a simple data container with built-in equality and immutability.

Understanding records as immutable data holders with value equality sets the stage for why inheritance in records is useful and different from classes.

2

Foundation

Basic Class Inheritance Refresher

Concept: Review how inheritance works with normal classes in C#.

In C#, classes can inherit from other classes to reuse code: public class Animal { public string Name { get; } public Animal(string name) => Name = name; } public class Dog : Animal { public Dog(string name) : base(name) {} } Dog inherits Name property from Animal.

Result

You see how derived classes reuse properties and constructors from base classes.

Knowing class inheritance helps understand how record inheritance extends this idea but with immutable data and value equality.

3

Intermediate

Defining a Derived Record

🤔Before reading on: Do you think derived records can add new properties and still keep value equality? Commit to your answer.

Concept: Show how to create a record that inherits from another record and adds properties.

You can define a record that inherits from another record like this: public record Person(string Name, int Age); public record Employee(string Name, int Age, string Position) : Person(Name, Age); Employee adds a Position property but reuses Name and Age from Person.

Result

Employee has all properties of Person plus Position, and equality compares all three properties.

Understanding that derived records extend data while preserving value equality helps you model complex data hierarchies cleanly.

4

Intermediate

How Equality Works in Record Inheritance

🤔Before reading on: Do you think equality compares only base properties or all properties including derived ones? Commit to your answer.

Concept: Explain how value equality compares all properties in the inheritance chain.

Records override Equals and GetHashCode to compare all positional properties, including those in base and derived records. For example: var e1 = new Employee("Alice", 30, "Manager"); var e2 = new Employee("Alice", 30, "Manager"); Here, e1.Equals(e2) is true because all properties match. If Position differs, equality returns false.

Result

Equality checks all properties from base and derived records, ensuring accurate comparisons.

Knowing that equality spans the full inheritance chain prevents bugs when comparing records with inherited properties.

5

Intermediate

Using 'with' Expressions in Derived Records

Concept: Show how to create modified copies of records with inheritance using 'with'.

Records support 'with' expressions to create copies with some properties changed: var emp1 = new Employee("Bob", 25, "Developer"); var emp2 = emp1 with { Position = "Lead Developer" }; emp2 is a new Employee with the same Name and Age but a different Position.

Result

You can easily create modified copies of derived records without changing the original.

Understanding 'with' expressions with inheritance helps manage immutable data efficiently in real applications.

6

Advanced

Customizing Equality and ToString in Derived Records

🤔Before reading on: Can you override equality or ToString in derived records without breaking base behavior? Commit to your answer.

Concept: Explain how to override methods in derived records safely.

You can override methods like ToString or equality members in derived records: public record Employee(string Name, int Age, string Position) : Person(Name, Age) { public override string ToString() => $"{Name}, {Age}, {Position}"; } Overriding lets you customize behavior while preserving base functionality if you call base methods.

Result

Derived records can have custom string representations or equality logic as needed.

Knowing how to safely override methods in records allows flexible customization without losing value semantics.

7

Expert

Record Inheritance and Immutability Trade-offs

🤔Before reading on: Do you think record inheritance can cause subtle bugs with mutable properties? Commit to your answer.

Concept: Discuss how inheritance interacts with immutability and potential pitfalls.

Records are designed for immutability, but if you add mutable properties in derived records, it can break expected behavior: public record Person(string Name); public record Employee(string Name, List Tasks) : Person(Name); If Tasks is modified after creation, equality and hash codes may become inconsistent, causing bugs in collections or comparisons.

Result

Mutable properties in records with inheritance can cause unexpected bugs and violate immutability assumptions.

Understanding the risks of mutable state in records with inheritance helps avoid subtle, hard-to-find bugs in production.

Under the Hood

Under the surface, C# records generate compiler code that implements value-based equality by overriding Equals and GetHashCode methods. When a record inherits another, the compiler combines the base and derived positional properties into these methods. The compiler also generates a Deconstruct method and a 'with' clone method that copies all properties. This machinery ensures that records behave like immutable value objects even though they are reference types.

Why designed this way?

Records were introduced to simplify immutable data modeling with value equality, a common need in modern programming. Inheritance support was added to allow reuse and extension of data models without losing the benefits of records. The design balances immutability, inheritance, and usability by generating code automatically, avoiding boilerplate and errors.

Record Inheritance Flow:

┌─────────────┐       ┌───────────────┐
│ Base Record │──────▶│ Derived Record│
│ - Props     │       │ - Base Props  │
│ - Equals()  │       │ - New Props   │
│ - GetHash() │       │ - Equals()    │
└─────────────┘       │ - GetHash()   │
                      └───────────────┘

Equality and cloning methods combine base and derived properties.

Myth Busters - 4 Common Misconceptions

Quick: Does record inheritance mean records behave exactly like classes in all ways? Commit to yes or no.

Common Belief: Record inheritance works exactly like class inheritance with no differences.

Reality: Records have special compiler-generated methods for value equality and immutability that differ from normal classes, affecting how inheritance behaves.

Why it matters: Assuming records behave like classes can lead to incorrect assumptions about equality, cloning, and mutability, causing bugs.

Quick: Can you add mutable properties safely in derived records without issues? Commit to yes or no.

Common Belief: You can freely add mutable properties in derived records without affecting behavior.

Reality: Adding mutable properties breaks the immutability contract and can cause equality and hash code inconsistencies.

Why it matters: Ignoring this leads to subtle bugs in collections or comparisons that rely on stable hash codes.

Quick: Does the 'with' expression copy only derived properties or all properties? Commit to your answer.

Common Belief: 'with' expressions only copy properties declared in the derived record.

Reality: 'with' expressions copy all properties from the entire inheritance chain to create a full clone with modifications.

Why it matters: Misunderstanding this can cause unexpected data loss or bugs when cloning records.

Quick: Is it safe to override Equals in derived records without calling base? Commit to yes or no.

Common Belief: You can override Equals in derived records without calling base Equals safely.

Reality: Not calling base Equals breaks the equality chain and can cause incorrect comparisons.

Why it matters: This leads to inconsistent equality behavior and bugs in collections or logic relying on equality.

Expert Zone

1

Derived records must call base constructors explicitly to initialize inherited properties, or compilation fails.

2

Positional parameters in records define which properties participate in value equality and deconstruction; adding non-positional properties changes behavior subtly.

3

Records with inheritance generate synthesized methods that combine base and derived data, but manual overrides must preserve this chain to avoid breaking equality.

When NOT to use

Avoid record inheritance when your data requires mutable state or complex behavior beyond simple data containers. Use classes or structs with explicit control instead. Also, if you need multiple inheritance or interfaces with state, records may not fit well.

Production Patterns

In production, record inheritance is used to model domain entities with shared data, such as a base 'Person' record extended by 'Employee' and 'Customer'. It simplifies DTOs and immutable data transfer objects in APIs. Developers often combine records with pattern matching and 'with' expressions for clean, concise data transformations.

Connections

Object-Oriented Inheritance

Record inheritance builds on the same inheritance principles but adds value equality and immutability.

Understanding classic inheritance helps grasp record inheritance, but records add a layer of automatic equality and cloning that changes how inheritance is used.

Immutable Data Structures

Records are a form of immutable data structure; inheritance extends these structures safely.

Knowing immutable data principles clarifies why records avoid mutable properties and how inheritance must respect immutability.

Mathematics: Algebraic Data Types

Record inheritance resembles algebraic data types where complex types build from simpler ones.

Seeing record inheritance as building blocks of data types helps understand how data models compose and extend in programming.

Common Pitfalls

#1 Adding mutable properties in derived records breaks immutability.

Wrong approach:

public record Employee(string Name, List Tasks) : Person(Name);

Correct approach:

public record Employee(string Name, IReadOnlyList Tasks) : Person(Name);

Root cause:

Misunderstanding that records should be immutable leads to using mutable collections, causing equality and state bugs.

#2 Overriding Equals in derived record without calling base Equals.

Wrong approach:

public override bool Equals(object? obj) => obj is Employee e && Position == e.Position;

Correct approach:

public override bool Equals(object? obj) => base.Equals(obj) && obj is Employee e && Position == e.Position;

Root cause:

Not chaining base equality breaks the full property comparison, causing incorrect equality results.

#3 Forgetting to call base constructor in derived record.

Wrong approach:

public record Employee(string Name, int Age, string Position) : Person;

Correct approach:

public record Employee(string Name, int Age, string Position) : Person(Name, Age);

Root cause:

Confusing record constructor syntax causes compilation errors and incomplete initialization.

Key Takeaways

Record inheritance in C# allows you to create immutable data types that extend other records, sharing properties and behavior.

Value equality in records compares all positional properties across the inheritance chain, ensuring accurate data comparisons.

Using 'with' expressions with derived records lets you create modified copies easily while preserving immutability.

Be careful to maintain immutability by avoiding mutable properties in records, or you risk subtle bugs.

Overriding methods in derived records requires calling base implementations to keep consistent behavior.