Class

같은 대상을 코드 곳곳에서 제각각 만들기 시작하면 필드 이름, 초기화 규칙, 검증 책임이 조금씩 어긋납니다. 어떤 곳은 email 을 쓰고 어떤 곳은 mail 을 쓰는 식이 되면, 시스템은 같은 사용자를 다루면서도 서로 다른 전제를 갖게 됩니다.

초기 객체지향 언어는 데이터와 함수를 따로 두는 방식만으로는 개체의 상태와 행동을 안정적으로 표현하기 어렵다는 문제를 안고 있었습니다. 상태와 행동의 소속을 한 타입 안에 묶어 두려는 요구가 커지면서 클래스가 객체 모델의 중심 도구로 자리 잡았습니다.

클래스에는 필드 선언, 생성 규칙, 메서드 정의가 함께 들어갑니다. 인스턴스를 만들면 각 객체는 자기 상태를 따로 가지지만, 어떤 속성이 존재하고 어떤 연산을 제공하는지는 클래스 정의를 공유합니다. 그래서 클래스는 값을 담는 컨테이너가 아니라 인스턴스들의 공통 구조와 행위를 정하는 타입 정의에 가깝습니다.

클래스는 설계이고 객체는 그 설계로 생성된 런타임 인스턴스입니다. 클래스가 어떻게 생기고 어떻게 동작해야 하는지를 정한다면, 객체는 실제 값을 들고 메서드 호출에 응답하는 개별 실체입니다. 이 구분이 잡혀야 타입 설계와 인스턴스 상태를 헷갈리지 않습니다.

도메인 모델, UI 컴포넌트 상태 모델, 서비스 객체처럼 같은 종류의 대상을 반복해서 만들고 공통 규칙을 유지해야 하는 곳에서 클래스가 특히 유용합니다. 반대로 값 몇 개를 잠깐 묶어 전달하는 정도라면 클래스를 도입하는 순간 구조가 지나치게 무거워질 수 있습니다.