Self Encapsulate Field: Let One Gatekeeper Guard Your Data

🍲 Amma's Kitchen Rule

In Meera's house in Chennai, the kitchen shelf holds everything — sugar, ghee, biscuits, pickle jars, the special Diwali sweets hidden behind the rice tin. Earlier, everyone simply walked in and grabbed what they wanted. Meera's little brother Karthik took six biscuits before dinner and then refused to eat his rasam. Thatha took extra sugar in his coffee even though Dr. Subramaniam had strictly said no. Nobody knew how much ghee was left until it was suddenly finished on Diwali morning, with twelve guests arriving and no time to buy more.

That Diwali disaster was the last straw. Amma made one rule, announced at the dinner table with the seriousness of a court order: nobody takes anything from the shelf directly. All requests go through Amma.

Karthik grumbled. Thatha pretended not to hear. But within a week, everyone saw what the rule made possible. When Karthik asks for biscuits, Amma checks the clock — no biscuits within one hour of dinner, no exceptions, no arguments. When Thatha asks for sugar, Amma quietly hands him the sugar-free sachets that look almost the same. When anyone takes ghee, Amma notes it in her little diary, so she knows exactly when the tin will be empty and buys a new one three days early. The Diwali disaster can never happen again.

And here is the truly clever part, the part worth reading twice: the family members did not change at all. Karthik still asks for "biscuits". Thatha still asks for "sugar". Nobody had to learn new words or new habits. Only the path changed — every request now passes through one gatekeeper who knows all the rules.

One day Amma travels to her sister's wedding in Madurai, and Chithi takes charge of the kitchen. Chithi has her own style — she gives a small piece of jaggery with every snack, because that was her own mother's tradition. Did the family have to be retrained? No. They asked for snacks the same way they always did, and the answers simply came out a little sweeter. Chithi overrode how requests are answered, without rewriting a single family member.

This is exactly what Self Encapsulate Field does in code. Instead of every method inside a class grabbing data straight from a field (the shelf), every read and write goes through one getter and one setter (Amma). The data gets a gatekeeper. And later, a subclass (Chithi) can change the answer without touching anyone else.

🧠 What is Self Encapsulate Field?

Self Encapsulate Field is a refactoring from Martin Fowler's Refactoring book. The instruction is short: create a getter and a setter for a field, and make the class use them even for its own internal access. No method inside the class touches the raw field anymore — only the getter and setter do.

Notice the word self. The ordinary "Encapsulate Field" refactoring protects a field from outside classes — it makes the field private and gives the public a getter. Self Encapsulate Field goes one level deeper. It says: even my own methods will not touch my field directly. Karthik lives in the house, but even Karthik asks Amma. In the 2nd edition of the book, Fowler folded this idea into a wider refactoring called Encapsulate Variable, but the self-encapsulation idea is still discussed on his bliki as its own useful habit.

Why would a class be so formal with its own data? Because a direct field read is a hard wire. It can never do anything except fetch the raw value. A getter, on the other hand, is a soft wire — a seam. Through that seam you can later add:

• Validation — the setter refuses bad values, every time, no matter which method assigns.
• Lazy loading — the getter computes or fetches the value only on first use.
• Logging and change tracking — the setter notes every change, like Amma's diary.
• Subclass overriding — a child class redefines the getter and changes behaviour politely, the way Chithi added jaggery.

One honest note before we continue: this is a preparation refactoring. By itself, it changes no behaviour at all. The biscuits taste the same on day one of Amma's rule. Its value comes from what it makes possible next. Many bigger data refactorings — like Replace Data Value with Object — become much easier once all access already flows through one method.

College corner: in compiler and design terms, what we are building here is an indirection layer. A direct field access compiles to a memory load with a fixed offset — fast, but frozen. A virtual accessor compiles to a dispatch through the object's method table, which means the runtime type of the object decides what code runs. That single level of indirection is what enables polymorphism on data: the famous line "all problems in computer science can be solved by another level of indirection" applies literally. Modern JIT compilers usually inline trivial getters, so the performance cost in practice is close to zero — the design flexibility is what you are really buying.

🔔 When do we need it?

Do not self-encapsulate every field on every class — that would be ceremony for its own sake, like Amma demanding a written application for a glass of water. Reach for this refactoring when you see these signals:

1. A subclass needs to vary a value. A PromotionalLoan must discount the rate; a TestClock must return a frozen time. Direct field reads give the subclass no hook. A virtual getter does.
2. The setter has rules, but internal code skips them. If setRate() validates that rate is not negative, but three internal methods write this.rate = x directly, the validation is a fence with holes. Karthik is sneaking biscuits through the back door. Routing every write through the setter closes the holes.
3. You want to add behaviour on access — caching, lazy initialization, logging, "dirty" flags for saving — and you want to add it in exactly one place.
4. You are preparing a bigger refactoring. Suppose a plain string field suffers from Primitive Obsession and you plan to wrap it in a proper class. If fifty lines touch the field directly, you must edit fifty lines. If everything goes through one getter, you edit one method. Similarly, when Data Clumps travel together and you plan to bundle them, self-encapsulation makes the bundling painless.
5. A field is about to become computed. Today totalMarks is stored; tomorrow it should be calculated from subject marks. If access already goes through getTotalMarks(), the switch from "stored" to "computed" is invisible to every caller.

And when should you not do it? When the class is small, final, value-like, and the field has no rules. A simple Point with x and y does not need a gatekeeper. Fowler himself admits he prefers direct access until it becomes inconvenient — then he refactors. That relaxed attitude is the right one.

Here is a small decision table you can keep in your pocket:

👀 Before and after at a glance

Here is a Loan class in TypeScript. Before the refactoring, methods read this.rate and this.principal straight from the fields.

// BEFORE — methods grab fields directly from the shelf
class Loan {
  private principal: number;
  private rate: number; // yearly rate, e.g. 0.12
 
  constructor(principal: number, rate: number) {
    this.principal = principal;
    this.rate = rate;
  }
 
  monthlyInterest(): number {
    return (this.principal * this.rate) / 12; // direct read
  }
 
  totalInterest(months: number): number {
    return ((this.principal * this.rate) / 12) * months; // direct read again
  }
}

After the refactoring, every read and write goes through accessors. The maths is unchanged — only the path changed, exactly like the family still asking for "sugar" but through Amma.

// AFTER — every request goes through the gatekeeper
class Loan {
  private principal: number;
  private rate: number;
 
  constructor(principal: number, rate: number) {
    this.principal = principal;
    this.setRate(rate); // writes get validation
  }
 
  protected getPrincipal(): number {
    return this.principal;
  }
 
  protected getRate(): number {
    return this.rate; // the seam — subclasses may override
  }
 
  protected setRate(value: number): void {
    if (value < 0) throw new Error("Rate cannot be negative");
    this.rate = value;
  }
 
  monthlyInterest(): number {
    return (this.getPrincipal() * this.getRate()) / 12;
  }
 
  totalInterest(months: number): number {
    return ((this.getPrincipal() * this.getRate()) / 12) * months;
  }
}
 
// Chithi takes charge — the subclass changes the answer, not the family
class PromotionalLoan extends Loan {
  private monthsElapsed = 0;
 
  protected override getRate(): number {
    return this.monthsElapsed < 3 ? super.getRate() / 2 : super.getRate();
  }
}

The promotional discount lives entirely inside PromotionalLoan. monthlyInterest() and totalInterest() did not change one character, yet they now compute discounted interest for promotional loans. That is the power of the seam.

College corner: notice that getRate() in the subclass calls super.getRate() rather than reading the field. This matters. If the override read this.rate directly, it would re-create the hard wire one level up and break the chain for any further subclass. Overrides that delegate to super compose cleanly — each layer decorates the layer below, which is the same shape as the Decorator pattern, just expressed through inheritance.

🪜 Step-by-step, the safe way

Refactoring is like crossing a busy road — small steps, look both ways, never run. Here is the safe order. Keep your tests green after every step.

1. Create the getter (and setter if the field is written). Do not change any other code yet. The class compiles; nothing uses the new methods. This step alone cannot break anything.

class Loan {
  private rate: number;
  // ... existing code untouched ...
 
  protected getRate(): number {
    return this.rate;
  }
 
  protected setRate(value: number): void {
    this.rate = value; // no validation yet — behaviour must not change
  }
}

2. Find every internal read of the field. Use your editor's "find usages" on the field. Replace one read at a time: this.rate becomes this.getRate(). Compile and run tests after each replacement, or after small batches.

3. Replace every internal write with the setter: this.rate = x becomes this.setRate(x).

4. Decide about the constructor. This deserves care. If the setter validates, calling it from the constructor gives validation for free. But if the getter or setter is meant to be overridden, the constructor would be calling subclass code before the subclass finished constructing — a classic trap. A common middle path: assign the field directly in the constructor, and move validation into a small private function that both the constructor and the setter call.

5. Only now add the new behaviour — validation, logging, laziness, or the virtual keyword for subclass hooks. Adding behaviour after the mechanical rewiring keeps each step small and testable.

protected setRate(value: number): void {
  if (value < 0) throw new Error("Rate cannot be negative"); // added last
  this.rate = value;
}

6. Tighten access. Make sure the field itself is private so nothing — inside or outside — can sneak past the gatekeeper. Lock the back door of the kitchen.

🏫 A bigger real-life example

Meet the software for a school library in Pune, maintained by a part-time developer named Sameer. A LibraryMember tracks how many books a student has borrowed and what their borrowing limit is. Sameer's first version reads fields directly everywhere:

// BEFORE
class LibraryMember {
  private borrowedCount = 0;
  private limit = 3;
 
  canBorrow(): boolean {
    return this.borrowedCount < this.limit;
  }
 
  borrow(): void {
    if (this.borrowedCount >= this.limit) {
      throw new Error("Limit reached");
    }
    this.borrowedCount = this.borrowedCount + 1;
  }
 
  returnBook(): void {
    this.borrowedCount = this.borrowedCount - 1; // oops — can go below zero!
  }
}

Two requirements arrive in the same week. First: during exam season, class 10 students get a higher limit of 5 books, says the principal. Second: the librarian, Mrs. Kulkarni, wants a log whenever borrowedCount changes, because the counts have been going wrong and she suspects a bug (look at returnBook — it can go negative if a student returns a book that was never recorded as borrowed!).

With direct field access Sameer would edit every method, and probably miss one. With self-encapsulation, both requirements land in one place each:

// AFTER
class LibraryMember {
  private borrowedCount = 0;
  private limit = 3;
 
  protected getLimit(): number {
    return this.limit; // seam for subclasses
  }
 
  protected getBorrowedCount(): number {
    return this.borrowedCount;
  }
 
  protected setBorrowedCount(value: number): void {
    if (value < 0) throw new Error("Count cannot go below zero"); // bug, caught!
    console.log(`borrowedCount: ${this.borrowedCount} -> ${value}`); // the log
    this.borrowedCount = value;
  }
 
  canBorrow(): boolean {
    return this.getBorrowedCount() < this.getLimit();
  }
 
  borrow(): void {
    if (!this.canBorrow()) throw new Error("Limit reached");
    this.setBorrowedCount(this.getBorrowedCount() + 1);
  }
 
  returnBook(): void {
    this.setBorrowedCount(this.getBorrowedCount() - 1);
  }
}
 
// Exam season rule lives in its own small class
class ExamSeasonMember extends LibraryMember {
  protected override getLimit(): number {
    return 5;
  }
}

Look closely at what Sameer gained:

• The negative count bug is now impossible. Any write, from any method — including methods written next year by someone who never read this article — passes the guard.
• The logging appears for every change, automatically. Mrs. Kulkarni's mystery will be solved by reading one log stream, not by adding print statements in five places.
• The exam season rule is four lines in a subclass. canBorrow() and borrow() did not change, yet they respect the new limit, just like the family got jaggery without being retrained.

💜 The same refactoring in C#

C# makes this refactoring feel natural, because C# properties are accessors that look like fields. A property is a gatekeeper wearing a field costume. To self-encapsulate in C#, you turn the raw field into a property and make internal code use the property:

public class Loan
{
    private decimal _rate;
 
    public Loan(decimal principal, decimal rate)
    {
        Principal = principal;
        Rate = rate; // goes through the setter — validation applies
    }
 
    public decimal Principal { get; }
 
    // virtual: the seam for subclasses
    public virtual decimal Rate
    {
        get => _rate;
        protected set
        {
            if (value < 0)
                throw new ArgumentOutOfRangeException(nameof(value),
                    "Rate cannot be negative");
            _rate = value;
        }
    }
 
    public decimal MonthlyInterest() => Principal * Rate / 12m;
 
    public decimal TotalInterest(int months) => MonthlyInterest() * months;
}
 
public class PromotionalLoan : Loan
{
    private readonly int _monthsElapsed;
 
    public PromotionalLoan(decimal principal, decimal rate, int monthsElapsed)
        : base(principal, rate)
        => _monthsElapsed = monthsElapsed;
 
    public override decimal Rate
        => _monthsElapsed < 3 ? base.Rate / 2m : base.Rate;
}

Three C# notes worth remembering:

• Auto-properties are already self-encapsulated. If you write public decimal Rate { get; set; }, every access — internal and external — goes through the compiler-generated accessor. You can later replace it with a full property with a backing field, and no caller changes. That is the refactoring done by the language.
• virtual is what opens the door for subclasses. A non-virtual property is a closed gate; mark it virtual only when you genuinely expect variation.
• Beware virtual calls in constructors. The Loan constructor above calls the Rate setter. If a subclass overrode the setter, that override would run before the subclass constructor body — a well-known C# pitfall. Here only the getter is overridden, so it is safe, but think about this every time.

College corner: the constructor trap deserves a precise explanation. In C# (and Java), virtual dispatch is active during base-class construction. So base constructor → virtual call → subclass override runs → but the subclass's own fields are still at their default values, because the subclass constructor body has not executed yet. C++ behaves differently — during base construction the object's dynamic type is the base type, so the base version runs. Knowing which rule your language follows is the difference between a safe constructor and a NullReferenceException that only appears for subclasses.

🐍 A quick look in Python

Python's property decorator gives the same seam without changing call sites at all — attribute access syntax stays identical, which makes this refactoring almost invisible to callers:

class Loan:
    def __init__(self, principal: float, rate: float) -> None:
        self._principal = principal
        self.rate = rate  # goes through the property setter below
 
    @property
    def rate(self) -> float:
        return self._rate  # the seam — override in a subclass if needed
 
    @rate.setter
    def rate(self, value: float) -> None:
        if value < 0:
            raise ValueError("Rate cannot be negative")
        self._rate = value
 
    def monthly_interest(self) -> float:
        return self._principal * self.rate / 12
 
 
class PromotionalLoan(Loan):
    @property
    def rate(self) -> float:
        return super().rate / 2  # first three months promotion

Callers still write loan.rate — they cannot even tell whether they are touching a raw attribute or a guarded property. Python essentially ships Self Encapsulate Field as a built-in upgrade path: start with a plain attribute, and the day it needs rules, promote it to a property without breaking a single caller.

🛠️ IDE support

Good news: this refactoring is so common that most IDEs automate the mechanical part.

The IDE does the boring rewiring without typos. Your job remains the thinking part: which fields deserve a gatekeeper, whether the accessor should be virtual, and what the constructor should do.

⚖️ Benefits, risks, and when the trade is worth it

The honest summary: Self Encapsulate Field trades a little indirection today for a lot of flexibility tomorrow. Make the trade when tomorrow is actually coming. Two pictures help you judge that.

College corner: there is a deeper principle hiding under this refactoring — the uniform access principle, stated by Bertrand Meyer: the notation a client uses should not reveal whether a value is stored or computed. C# properties and Python properties satisfy it natively; Java's getX() convention satisfies it socially. Self Encapsulate Field is the uniform access principle applied to a class's relationship with itself: even the class should not care whether rate is a stored number, a computed value, a cached fetch, or a subclass's overridden answer.

🧹 Which smells does it cure?

📦 Quick revision box

+--------------------------------------------------------------+
|              SELF ENCAPSULATE FIELD — REVISION               |
+--------------------------------------------------------------+
| Idea     : Class reads/writes its OWN field only through     |
|            a getter and setter (one gatekeeper, like Amma).  |
| Why      : Creates a seam — add validation, logging, lazy    |
|            loading, or subclass overrides in ONE place.      |
| Steps    : 1. Add getter/setter (no behaviour change)        |
|            2. Replace internal reads  -> getter              |
|            3. Replace internal writes -> setter              |
|            4. Decide constructor policy                      |
|            5. THEN add new behaviour                         |
|            6. Keep the field private                         |
| Watch out: virtual accessors + constructors = danger;        |
|            don't ceremonialize tiny value classes.           |
| Cures    : Primitive Obsession prep, Data Clumps prep,       |
|            duplicate validation, shotgun surgery.            |
| C# bonus : auto-properties give you this almost for free.    |
+--------------------------------------------------------------+

✍️ Practice exercise

Take this Student class. It has a bug and two upcoming requirements. Refactor it with Self Encapsulate Field.

class Student {
  private marks = 0; // out of 100
 
  addMarks(extra: number): void {
    this.marks = this.marks + extra; // can exceed 100!
  }
 
  grade(): string {
    if (this.marks >= 90) return "A";
    if (this.marks >= 75) return "B";
    return "C";
  }
 
  reportLine(): string {
    return `Marks: ${this.marks}, Grade: ${this.grade()}`;
  }
}

Your tasks:

1. Add getMarks() and setMarks(value) and rewire addMarks, grade, and reportLine so no method touches this.marks directly. Run your tests — behaviour must be identical.
2. Fix the bug in the setter: marks must stay between 0 and 100. Throw an error otherwise.
3. New requirement: a SportsQuotaStudent subclass gets 5 grace marks when reading (not stored!). Override the getter so grade() and reportLine() automatically respect grace marks without being edited.
4. Bonus: rewrite the class in C# using a property with a private backing field and a virtual getter. Check that the constructor does not call any overridable member.
5. Extra credit: rewrite it once more in Python with @property, and notice that callers using student.marks never change at all.

If step 3 needed zero changes to grade() and reportLine(), you have understood the whole lesson: the seam did the work, not the scissors. Amma changed; the family never noticed.