객체에 직접 값을 넣었다가 삭제했는데 같은 이름의 값이 여전히 조회됩니다. 프로토타입을 따라 찾는 과정과 class 메서드의 저장 위치를 설명해 보세요.

프로퍼티를 읽을 때 JavaScript는 먼저 객체 자신의 own 프로퍼티를 찾고, 없으면 [[Prototype]] 연결을 따라가며 찾습니다. 상속받은 이름과 같은 own 프로퍼티를 만들면 상속 프로퍼티를 가리는 shadowing이 일어납니다.

own 프로퍼티에서 체인으로

const base = { kind: 'base', describe() { return this.kind; } };
const item = Object.create(base);
item.kind = 'item';
console.log(Object.hasOwn(item, 'kind'), item.describe()); // true item
delete item.kind;
console.log(item.kind); // base

class User { greet() { return 'hi'; } }
const user = new User();
console.log(Object.hasOwn(user, 'greet'));          // false
console.log(Object.hasOwn(User.prototype, 'greet')); // true

item.describe는 item에 own 프로퍼티가 없으므로 base에서 찾지만, 호출 형태가 item.describe()이므로 메서드 안의 this는 item입니다. 따라서 처음에는 own kind인 item을 읽고, 그 프로퍼티를 삭제한 뒤에는 프로토타입의 base를 읽습니다. 읽기에서는 in이 프로토타입까지 포함하고, Object.hasOwn은 객체 자신만 검사하므로 목적에 맞는 API를 선택해야 합니다.

공유 메서드와 입력 키

class 문법으로 만든 일반 인스턴스 메서드는 보통 각 인스턴스에 복사되지 않고 User.prototype에 놓여 공유됩니다. 그렇다고 프로토타입에 있는 모든 상태가 인스턴스별로 분리되는 것은 아니며, 배열 같은 가변 값을 프로토타입에 두면 여러 인스턴스가 공유할 수 있습니다. 인증·외부 입력 이름을 프로퍼티 키로 다룰 때는 hasOwn과 안전한 자료구조를 사용해 의도하지 않은 상속 프로퍼티를 데이터로 받아들이지 않겠습니다.

선택 기준과 검증

undefined를 읽었다고 프로퍼티가 없다는 뜻은 아니므로, 존재성은 Object.hasOwn이나 in으로 목적에 맞게 검사하겠습니다. 외부 입력을 일반 객체 키로 저장하면 상속 이름과 특수 프로퍼티가 데이터로 섞일 수 있어 Map이나 Object.create(null)을 검토합니다. prototype의 메서드 공유와 인스턴스별 가변 상태 초기화는 별도 책임입니다.

own 프로퍼티가 undefined라는 값을 가지면 프로토타입에 같은 이름의 값이 있어도 그것을 가립니다. 삭제해야 다음 프로토타입 값이 다시 보입니다. 또한 일반 프로퍼티 대입은 상속된 setter를 호출할 수 있으므로 '대입하면 언제나 own data property가 만들어진다'고 일반화하면 안 됩니다. 예제는 쓰기 가능한 일반 데이터 속성이라는 전제를 두고, 접근자와 읽기 전용 속성은 별도 검사하겠습니다.

class의 prototype 메서드는 기본적으로 열거되지 않지만 객체 리터럴의 메서드는 일반적으로 own enumerable 프로퍼티입니다. 그래서 for...in, Object.keys, spread의 결과가 같지 않을 수 있습니다. hasOwnProperty라는 이름 자체가 입력에 의해 덮일 수 있으므로 Object.hasOwn을 쓰거나 안전한 기본 메서드 호출을 선택합니다. Map과 null-prototype 객체는 상속 이름을 데이터로 오인하는 범위를 줄이지만 입력 검증과 권한 검사를 대신하지는 않습니다.