In a TypeScript class, what do the `public`, `private` and `protected` modifiers each control, and which code is allowed to touch a member marked with each?
answer
- the default is the permissive one
- declaring class only, versus class plus subclasses
- privacy is per class, not per object
- a subclass may widen, never tighten
- checked by tsc, absent from the emitted JS
basics
~20 spublic, the default, allows access from anywhere. private limits access to the body of the declaring class. protected allows the declaring class and its subclasses. All three are checker-only rules that disappear when TypeScript emits JavaScript.
solid answer
~50 sA member with no modifier is `public`, so any code holding the instance can read and write it. `private` narrows that to the body of the class that declared it — note that this is per class, not per object, so one instance may reach another instance's private member. `protected` sits between them: the declaring class and any subclass may use it, but outside code may not. The modifiers work the same on methods, accessors and static members, and a `private constructor` blocks construction from outside. The important caveat is that none of this exists at run time: TypeScript erases the modifiers on emit, so they are a design and review tool rather than an enforcement mechanism. A subclass may loosen visibility — re-declaring a `protected` member as `public` — but it may never tighten a `public` member to `private`.
code
typescript · 21 linesclass Account {
public id = "acc-1"; // default; the keyword is optional
protected balance = 0; // declaring class + subclasses
private auditLog: string[] = []; // declaring class only
deposit(amount: number): void {
this.balance += amount;
this.auditLog.push(`+${amount}`);
}
}
class SavingsAccount extends Account {
applyInterest(rate: number): void {
this.balance *= 1 + rate; // ok: protected
// this.auditLog.push("interest"); // error: private to Account
}
}
const a = new SavingsAccount();
console.log(a.id); // ok: public
// a.balance; // error: protectedgo deeper
Be able to state the three rules in one sentence each and say that public is the default. Mention that the modifiers vanish when the code compiles to JavaScript - that single caveat separates a prepared answer from a memorised one.
Explain the mechanics precisely: privacy is per class rather than per object, protected access from a base-typed reference is rejected, and subclasses may widen but never narrow visibility. Know that constructors and static members take modifiers too.
Argue visibility as API surface. Show that protected is a contract with every subclass and is hard to withdraw, that private is the correct default under least privilege, and that none of it survives compilation for JavaScript consumers of a published package.
Own the policy question: how much of a class should ever be protected, whether the codebase prefers composition over an inheritance-shaped extension point, and how visibility choices interact with what you publish in .d.ts files and can never quietly take back.
## The three modifiers TypeScript lets you annotate class members — fields, methods, getters/setters and static members alike — with one of three visibility modifiers. They constrain where in your *source* the member may be referenced; the checker enforces them and then the emitter throws them away. ### public `public` is the default, so writing it is optional and mostly a matter of house style. A public member may be read or written by anything holding a reference to the instance. ```ts class User { name = "ada"; // implicitly public public greet() {} // explicitly public, identical meaning } ``` ### private `private` restricts references to the body of the class that declared the member. What surprises people is that the rule is **per class, not per object**: ```ts class Money { private cents: number; constructor(cents: number) { this.cents = cents; } plus(other: Money) { return new Money(this.cents + other.cents); // legal: same class body } } ``` `other.cents` is fine because the reference sits inside `Money`. That is what makes binary operations like `plus`, `equals` and `compareTo` writable without exposing state. ### protected `protected` opens the member to the declaring class *and* its subclasses, while keeping it closed to unrelated code. It is the modifier for a genuine extension point: state or a helper method that derived classes need but consumers must not see. ```ts class Shape { protected sides = 0; } class Square extends Shape { describe() { return `${this.sides} sides`; } // ok } new Square().sides; // error: 'sides' is protected ``` ## The cross-hierarchy rule A subclass may only reach a protected member **through an instance of its own class or a subclass of it**, not through a base-typed reference: ```ts class Base { protected id = 1; } class Child extends Base { read(other: Base) { return other.id; } // error readOwn(other: Child) { return other.id; } // ok } ``` The reason is that `other: Base` might actually be a `Sibling` at run time, and `Child` has no business reading `Sibling`'s protected state. Interviewers like this one because it separates people who have read the rule from people who have hit it. ## Widening, never narrowing A derived class may expose more than its base: re-declaring an inherited `protected` member as `public` is allowed, because every promise the base made still holds. Going the other way — turning a `public` member `private` in a subclass — is rejected, since the subclass must remain usable wherever the base is expected. ## Where they apply All three modifiers work on instance fields, methods, getters and setters, static members (`private static counter = 0`) and constructors. Marking a constructor `private` or `protected` prevents `new` from outside the class, which is the mechanical basis of factory and singleton patterns. ## The erasure caveat Every one of these rules lives in the type layer. The emitted JavaScript contains plain properties and methods; nothing checks visibility at run time, and a JavaScript consumer of your compiled code sees no difference between a public and a private member. Treat the modifiers as documentation the compiler enforces for TypeScript callers — excellent for keeping a codebase honest, useless as a security boundary. If you need a member that is genuinely unreachable after compilation, that is what a `#name` field is for. ## Choosing under least privilege Start every member `private` and widen only when a caller genuinely needs it. Prefer `private` to `protected` unless you are deliberately designing for inheritance: a `protected` member is part of your contract with every subclass, and taking it back later is a breaking change for them even though your public API never moved.
- Inside a subclass, why does reading a protected member off a parameter typed as the base class fail?Because a base-typed reference might hold a sibling subclass at run time, and protected access is meant to stay within your own branch of the hierarchy. TypeScript therefore only allows protected access through an instance of the accessing class or a subclass of it. Typing the parameter as the derived class fixes it.
- Can a subclass change the visibility of an inherited member?It can loosen it — re-declaring a `protected` member as `public` is allowed, since the subclass still honours every guarantee the base made. It cannot tighten a `public` member to `private` or `protected`, because that would break substitutability: code holding the base type would expect the member to be there.
- Does `private` stop one instance from reading another instance's field?No. TypeScript's privacy is per class, so any code inside the declaring class body may read `other.field` on another instance of that same class. This is what makes methods like `equals`, `compareTo` and arithmetic combinators possible without exposing state publicly.
saying these in an interview costs you the question
- Says members are private by default
- Claims private blocks access from another instance of the same class
- Thinks protected means visible to the whole module or package
- Believes the modifiers are enforced when the code runs
- Says a subclass can tighten a public member to private