Chapter 08 — Super-sleek properties and expression-bodied members

Purpose of this chapter: learn modern property improvements (read-only auto-props, initializers, struct behavior) and when expression-bodied members improve clarity vs when they harm readability.

8.1 A brief history of properties

Properties are a C# abstraction for “field-like access with method-like control”.

Why they exist:

• Expose state while keeping encapsulation (validation, lazy init, notifications).
• Allow versioning (you can start with a field, then later need logic).

Interview framing:

• Prefer properties over public fields for encapsulation and compatibility.

8.2 Upgrades to automatically implemented properties

Auto-properties started as “just remove boilerplate” and later gained features that make them useful for immutable-ish designs too.

8.2.1 Read-only auto-properties

Read-only auto-props let you expose state that can be set only during construction:

• Supports designs where invariants are established in constructors and not mutated later.

Practical guideline:

• Prefer read-only where possible; mutation is often the root of concurrency and correctness issues.

8.2.2 Initializing auto-properties

Property initializers let you set default values at the declaration site:

• Good for default configuration, simple collections, and safe defaults.

Guideline:

• Don’t hide expensive work inside initializers; keep them simple and predictable.

8.2.3 Auto-properties in structs

Structs have value semantics; auto-properties in structs still work, but keep in mind:

• Copying a struct copies its fields (including backing fields).
• Mutating properties on a copy doesn’t affect the original.

Senior interview angle:

• Be able to explain “why mutating a struct property sometimes appears to ‘not work’” (because you mutated a copy).

8.3 Expression-bodied members

Expression-bodied members are about conciseness when the body is a single expression:

public int Count => _items.Count;
public override string ToString() => $"{Name} ({Id})";

8.3.1 Expression-bodied computed properties

Great for “pure” computed properties:

• Read-only, no side effects, easy to scan.

8.3.2 Expression-bodied methods, indexers, operators

Use when it stays readable:

• One expression with clear intent.
• Avoid if it hides branching or multiple concerns.

8.3.3 Restrictions in early versions (context)

Earlier versions limited what could be expression-bodied; modern C# allows more. The important point for interview prep:

• Know that this is primarily about syntax/readability, not new runtime capability.

8.3.4 Guidelines

Use expression-bodied members when:

• The member is short and “obviously correct”.
• It improves scanning and reduces boilerplate.

Avoid when:

• You need logging/validation/error handling.
• The expression becomes complex (nested ternaries, deep chains).

In trading/fintech services:

• Prefer clarity over cleverness; expression-bodied members are fine for simple, side-effect-free members.