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.

Practice

1.

What does record inheritance in C# allow you to do?

easy

A. Delete properties from the base record in the derived record

B. Change the data type of existing properties in a record

C. Convert a record into a class automatically

D. Create a new record that extends an existing record with additional properties

Solution

1. Step 1: Understand record inheritance purpose

   Record inheritance lets you build new records based on existing ones, adding new properties while keeping the base properties.

2. Step 2: Analyze options

   Only Create a new record that extends an existing record with additional properties correctly describes extending an existing record with new properties. Options A, B, and D describe actions not supported by record inheritance.

3. Final Answer:

   Create a new record that extends an existing record with additional properties -> Option D

4. Quick Check:

   Record inheritance = extend with new properties [OK]

Hint: Inheritance means adding new features, not removing or changing [OK]

Common Mistakes:

• Thinking inheritance changes base properties
• Confusing records with classes
• Assuming inheritance deletes base properties

2.

Which of the following is the correct syntax to inherit a record Person in C#?

public record Person(string Name, int Age);

easy

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

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

C. public record Employee(string Name, int Age, string Position) inherits Person(Name, Age);

D. public record Employee(string Name, int Age, string Position) extends Person(Name, Age);

Solution

1. Step 1: Recall record inheritance syntax

   In C#, a derived record uses colon : to inherit and passes base parameters in parentheses after the base name.

2. Step 2: Check each option

   public record Employee(string Name, int Age, string Position) : Person(Name, Age); correctly uses colon and passes base parameters. Options B, C, and D use incorrect keywords or syntax.

3. Final Answer:

   public record Employee(string Name, int Age, string Position) : Person(Name, Age); -> Option A

4. Quick Check:

   Use ':' and pass base params in parentheses [OK]

Hint: Use ':' and pass base parameters in parentheses [OK]

Common Mistakes:

• Using 'inherits' or 'extends' keywords
• Not passing base parameters
• Placing base parameters incorrectly

3.

What will be the output of this code?

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

var emp = new Employee("Alice", 30, "Developer");
Console.WriteLine(emp.Name + ", " + emp.Age + ", " + emp.Position);

medium

A. Alice, 30

B. Developer, 30, Alice

C. Alice, 30, Developer

D. Compilation error

Solution

1. Step 1: Understand record inheritance and properties

   The Employee record inherits Name and Age from Person and adds Position. Creating Employee sets all three properties.

2. Step 2: Analyze output statement

   The code prints emp.Name, emp.Age, and emp.Position separated by commas, so output is "Alice, 30, Developer".

3. Final Answer:

   Alice, 30, Developer -> Option C

4. Quick Check:

   Inherited + new properties print correctly [OK]

Hint: Inherited properties are accessible like own properties [OK]

Common Mistakes:

• Assuming only base or only derived properties print
• Expecting compilation error due to inheritance
• Mixing property order in output

4.

Identify the error in this record inheritance code:

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

var emp = new Employee("Bob", 25, "Tester");

medium

A. Employee record cannot have more than two properties

B. Missing base constructor arguments in Employee inheritance

C. Position property must be in base record

D. Cannot inherit from a record

Solution

1. Step 1: Check inheritance syntax

   Employee inherits Person but does not pass required base constructor arguments (Name, Age) after Person.

2. Step 2: Identify correct fix

   Base constructor arguments must be passed like : Person(Name, Age). Omitting them causes a compilation error.

3. Final Answer:

   Missing base constructor arguments in Employee inheritance -> Option B

4. Quick Check:

   Base constructor args required after ':' [OK]

Hint: Always pass base constructor parameters after ':' [OK]

Common Mistakes:

• Forgetting to pass base parameters
• Thinking inheritance disallows extra properties
• Assuming records can't inherit

5.

You have a base record Vehicle(string Make, string Model). You want to create a derived record Car that adds int Doors and overrides the ToString() method to show all info. Which is the correct way to do this?

hard

A. public record Car(string Make, string Model, int Doors) : Vehicle(Make, Model) { public override string ToString() => $"{Make} {Model} with {Doors} doors"; }

B. public record Car : Vehicle { public int Doors; public override string ToString() => $"{Make} {Model} with {Doors} doors"; }

C. public record Car(string Make, string Model, int Doors) inherits Vehicle { public override string ToString() => $"{Make} {Model} with {Doors} doors"; }

D. public record Car(string Make, string Model, int Doors) extends Vehicle(Make, Model) { public override string ToString() => $"{Make} {Model} with {Doors} doors"; }

Solution

1. Step 1: Use correct inheritance syntax with parameters

   Derived record Car must inherit Vehicle using colon and pass Make and Model parameters: : Vehicle(Make, Model).

2. Step 2: Override ToString() properly

   Inside Car, override ToString() with the correct string interpolation including Doors property.

3. Step 3: Check options

   public record Car(string Make, string Model, int Doors) : Vehicle(Make, Model) { public override string ToString() => $"{Make} {Model} with {Doors} doors"; } uses correct syntax and override. Options B, C, and D use invalid keywords or omit constructor parameters.

4. Final Answer:

   public record Car(string Make, string Model, int Doors) : Vehicle(Make, Model) { public override string ToString() => $"{Make} {Model} with {Doors} doors"; } -> Option A

5. Quick Check:

   Use ':' with base params and override method inside record [OK]

Hint: Use ':' with base params and override inside record body [OK]

Common Mistakes:

• Using 'inherits' or 'extends' keywords
• Not passing base constructor parameters
• Trying to add fields instead of properties