Type Members in C#
A class or struct is not just a bag of fields and methods. Between "data" and "behavior", C# has a whole layer of members that look like one thing and work like another: a property reads like a field but is a pair of methods behind it; an indexer gives array syntax obj[i] to any type; a const pretends to be a variable while it is actually baked into every caller's code. These distinctions separate someone who "writes C#" from someone who understands the language.
This topic is a map of type members: how a property differs from a field, why const and readonly are not synonyms, how an enum becomes a bit field, where LINQ gets its methods on any collection, and why StringBuilder rescues a concatenation loop. Each layer below dissects one member by its mechanics, not by its name.
Topic map
- Properties —
get/setas a method pair, an auto-property and its hidden backing field,initand validation. - Indexers —
this[int i], a property with parameters, overloading by key type. - const and readonly — compile time vs run time, value inlining, and assembly versioning.
- Enums — named integral constants, the underlying type,
[Flags]and powers of two. - Extension methods — a
staticmethod with athisparameter, called like an instance method, the roots of LINQ. - ref and out parameters — an alias rather than a copy, who must assign and when,
infor read-only. - Partial classes — one type across several files, merged at build time, code generators.
- StringBuilder — the immutability of
string, the O(n²) trap, and a growable buffer.
Common traps
| Mistake | Consequence |
|---|---|
| Treating a property as binary-compatible with a field | Swapping a field for a property breaks already-compiled callers and serializers — they are different members |
| Thinking an auto-property has no backing field | The compiler silently generates a hidden one; { get; set; } is not "just a field" |
Expecting a changed library const to reach callers | The value is baked into their compiled code — all consumers must be recompiled |
Confusing readonly with static | A readonly field is instance-level by default — each object has its own value, unlike a const |
Using values 1, 2, 3 for a [Flags] enum | The bits overlap, so & tests give false positives; use powers of two |
| Expecting an extension method to see private members | It is called as a static method and works only through the type's public API |
Treating ref and out as a copy | Both alias the caller's storage; additionally the method must assign an out before returning |
Building a string with + in a loop | Each + recopies the whole string — O(n²) and GC garbage; use StringBuilder |
Interview relevance
Type members are asked not as a syntax checklist but as a test of your model: do you understand what sits behind the familiar { get; set; } or const? A candidate who says "a property is a method pair, so swapping a field for a property is not binary-compatible" immediately stands out from one who thinks they are the same thing.
Typical checks:
- How a property differs from a public field, and why an auto-property still has a backing field.
- The difference between
constandreadonly— compile time vs run time and the versioning consequence. - That
[Flags]needs powers of two, not sequential values. - That an extension method is a
staticmethod with no access to private members. - That
refandoutpass an alias, and who must initialize the argument. - Why
StringBuilderturns an O(n²) concatenation into O(n).
Common wrong answer: "a property and a field are the same thing, just with get/set". That opens the discussion that a property compiles to methods, so its implementation can change without recompiling callers, while a field cannot.