Get and set accessors in C Sharp (C#) - Deep Dive

Overview - Get and set accessors

What is it?

Get and set accessors are special parts of a property in C# that let you read or change the value of a private field safely. The get accessor returns the value, while the set accessor assigns a new value. They help control how data inside an object is accessed or modified without exposing the field directly.

Why it matters

Without get and set accessors, all data fields would have to be public, which can lead to mistakes or unwanted changes. These accessors protect data by controlling access and allowing validation or extra logic when reading or writing values. This keeps programs safer and easier to maintain.

Where it fits

Before learning get and set accessors, you should understand classes, objects, and fields in C#. After this, you can learn about properties with different access levels, auto-implemented properties, and advanced topics like expression-bodied properties or property change notifications.

Mental Model

Core Idea

Get and set accessors act like controlled gates that manage how you read and write data inside an object.

Think of it like...

Imagine a mailbox with a slot to put letters in (set) and a door to take letters out (get). You don’t open the mailbox directly; you use these controlled openings to safely add or retrieve mail.

┌─────────────┐
│   Property  │
│ ┌─────────┐ │
│ │  get    │ │  ← Returns the value
│ └─────────┘ │
│ ┌─────────┐ │
│ │  set    │ │  ← Assigns a new value
│ └─────────┘ │
└─────┬───────┘
      │
┌─────▼───────┐
│  Private    │
│  Field      │
└─────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding fields and encapsulation

Concept: Introduce private fields and why direct access is restricted.

In C#, fields store data inside a class. Making fields private hides them from outside code to protect data. For example: class Person { private string name; // private field } Outside code cannot access 'name' directly, which keeps data safe.

Result

The field 'name' is hidden from outside the class, preventing direct access.

Understanding private fields is key because get and set accessors exist to safely expose these hidden fields.

2

Foundation

Introducing properties with get and set

Concept: Show how properties use get and set to access private fields.

Properties let you read or write private fields safely. A property has a get accessor to return the field's value and a set accessor to assign a new value. Example: class Person { private string name; public string Name { get { return name; } set { name = value; } } } Here, 'Name' is a property controlling access to 'name'.

Result

You can now read or write 'Name' from outside the class, but the field 'name' stays private.

Properties with get and set let you control access to data without exposing fields directly.

3

Intermediate

Adding validation in set accessor

🤔Before reading on: do you think you can add rules inside set to reject bad values? Commit to your answer.

Concept: Show how set can include logic to check or modify values before saving.

The set accessor can run code before assigning a value. For example, to prevent empty names: class Person { private string name; public string Name { get { return name; } set { if (string.IsNullOrWhiteSpace(value)) { throw new ArgumentException("Name cannot be empty"); } name = value; } } } This protects the field from invalid data.

Result

Trying to set an empty name throws an error, keeping data valid.

Knowing that set can validate inputs helps prevent bugs and keeps data consistent.

4

Intermediate

Using auto-implemented properties

🤔Before reading on: do you think you always need a private field when using get and set? Commit to your answer.

Concept: Explain the shortcut syntax where C# creates the hidden field automatically.

Instead of writing a private field and full get/set, you can write: public string Name { get; set; } C# creates a hidden field behind the scenes. This is called an auto-implemented property and is useful when no extra logic is needed.

Result

You get a simple property that stores and returns values without extra code.

Understanding auto-properties saves time and keeps code clean when no validation or extra logic is needed.

5

Intermediate

Controlling access with different get/set levels

🤔Before reading on: can get and set have different access levels like public or private? Commit to your answer.

Concept: Show how to make get or set more or less accessible than the property itself.

You can restrict either get or set to be private or protected: public string Name { get; private set; } This means anyone can read 'Name', but only the class can change it. This is useful for read-only properties from outside.

Result

The property can be read publicly but only changed inside the class.

Knowing how to control access levels helps enforce rules about who can change data.

6

Advanced

Expression-bodied get and set accessors

🤔Before reading on: do you think get and set can be written in a shorter form? Commit to your answer.

Concept: Teach the concise syntax for simple get and set accessors using lambda-like expressions.

For simple properties, you can write: private int age; public int Age { get => age; set => age = value; } This is shorter but works the same as full get/set blocks.

Result

The property behaves the same but code is cleaner and easier to read.

Knowing expression-bodied accessors helps write modern, concise C# code.

7

Expert

Backing fields and compiler-generated storage

🤔Before reading on: do you think auto-properties and manual properties use the same storage? Commit to your answer.

Concept: Explain how auto-properties use hidden backing fields created by the compiler, and how manual properties use explicit fields.

Auto-properties hide the backing field from you; the compiler creates it. Manual properties use a field you write. This difference affects reflection, serialization, and debugging. Example: // Auto-property public string Name { get; set; } // Manual property private string name; public string Name { get { return name; } set { name = value; } } Understanding this helps when you need to customize behavior or inspect objects.

Result

You know when and how backing fields exist and how they affect your code.

Understanding backing fields clarifies how properties work internally and helps with advanced scenarios like debugging or serialization.

Under the Hood

At runtime, a property is a pair of methods: a getter and a setter. The get accessor is a method that returns the value of a field, and the set accessor is a method that takes a value and assigns it to the field. When you use a property, the compiler translates property access into calls to these methods. For auto-properties, the compiler generates a hidden field to store the value. This method-based approach allows adding logic inside get or set without changing how the property is used.

Why designed this way?

Properties were designed to combine the simplicity of field access with the power of methods. Before properties, developers had to write separate get and set methods, which was verbose and less readable. Properties allow using simple syntax like fields but with the flexibility to add validation or other logic. Auto-properties were added later to reduce boilerplate when no extra logic is needed, improving developer productivity.

┌───────────────┐
│   Property    │
│ ┌───────────┐ │
│ │  get()    │ │  ← Method returning field value
│ └───────────┘ │
│ ┌───────────┐ │
│ │  set(val) │ │  ← Method assigning field value
│ └───────────┘ │
└───────┬───────┘
        │
┌───────▼───────┐
│  Backing Field │
│  (hidden or    │
│   explicit)    │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a property always have a private field you can access directly? Commit to yes or no.

Common Belief: Every property must have a private field that you can access directly.

Reality: Auto-properties have compiler-generated backing fields that are not accessible directly in code.

Why it matters: Assuming you can access the backing field can lead to confusion and errors when trying to manipulate data or debug.

Quick: Can you put complex logic in both get and set without changing how the property is used? Commit to yes or no.

Common Belief: Properties are just simple wrappers and cannot contain complex logic.

Reality: Get and set accessors can contain any code, including validation, logging, or calculations, while still being used like fields.

Why it matters: Underestimating properties limits their use and can lead to messy code with separate methods instead of clean properties.

Quick: If a property has only a get accessor, can you assign a value to it from outside? Commit to yes or no.

Common Belief: If a property has only a get accessor, you can still assign a value to it from outside the class.

Reality: A property with only a get accessor is read-only from outside; you cannot assign a value to it externally.

Why it matters: Misunderstanding this can cause compilation errors or unexpected behavior when trying to set read-only properties.

Quick: Does making the set accessor private make the property completely immutable? Commit to yes or no.

Common Belief: Making the set accessor private makes the property immutable everywhere.

Reality: A private set means only the class itself can change the property; outside code cannot, but the object can still modify it internally.

Why it matters: Confusing private set with full immutability can lead to incorrect assumptions about object state and thread safety.

Expert Zone

1

Properties with only get accessors can be used to create immutable objects that still allow lazy initialization internally.

2

Auto-properties can be initialized inline or in constructors, which affects object initialization patterns and immutability.

3

Using expression-bodied accessors can improve readability but may hide complex logic, so balance clarity with conciseness.

When NOT to use

Avoid using properties with heavy or time-consuming logic in get or set accessors because properties are expected to be quick and side-effect free. Instead, use methods for operations that are costly or have significant side effects.

Production Patterns

In real-world C# code, properties are used extensively for data encapsulation, often combined with data binding frameworks like WPF or MVVM where change notifications are added inside set accessors. Read-only properties with private sets are common for immutable or controlled state objects.

Connections

Encapsulation in Object-Oriented Programming

Builds-on

Get and set accessors are a practical way to implement encapsulation by controlling how data inside objects is accessed and modified.

Functional Programming Immutability

Contrast

Properties with only get accessors support immutable patterns, connecting object-oriented design with functional programming ideas about unchangeable data.

Access Control in Security

Same pattern

Just like security systems control who can enter or exit a building, get and set accessors control who can read or write data, enforcing rules and protecting integrity.

Common Pitfalls

#1 Trying to assign a value to a property that has no set accessor.

Wrong approach:

person.Name = "Alice"; // when Name has only get accessor

Correct approach:

// Provide a set accessor or use a constructor to set the value
public string Name { get; private set; }
// or
public Person(string name) { Name = name; }

Root cause:

Misunderstanding that properties without set accessors are read-only and cannot be assigned to outside the class.

#2 Putting heavy logic or long-running code inside get accessor.

Wrong approach:

public int Data {
get {
Thread.Sleep(5000); // simulate delay
return data;
}
set { data = value; }
}

Correct approach:

public int Data { get; set; } // keep get fast
// Use a method for heavy operations
public int GetDataWithDelay() {
Thread.Sleep(5000);
return Data;
}

Root cause:

Assuming properties can behave like methods with side effects, ignoring that properties should be quick and side-effect free.

#3 Exposing public fields instead of using properties.

Wrong approach:

public string name; // public field

Correct approach:

private string name;
public string Name {
get { return name; }
set { name = value; }
}

Root cause:

Not understanding the importance of encapsulation and control over data access.

Key Takeaways

Get and set accessors are special methods inside properties that control reading and writing private data safely.

They allow adding validation, logic, or access control while keeping simple syntax like fields.

Auto-implemented properties provide a shortcut by creating hidden backing fields automatically.

Properties should be quick and side-effect free; heavy logic belongs in methods.

Understanding backing fields and access levels helps write safer, cleaner, and more maintainable C# code.