Object

데이터를 전역 상태나 흩어진 레코드로만 다루면 어떤 값이 한 덩어리로 움직여야 하는지, 누가 그 상태를 관리해야 하는지가 흐려집니다. 주문 A의 상태를 바꾸는 코드와 주문 B의 규칙을 검사하는 코드가 분산되면, 변경 영향도와 책임 경계가 금방 보이지 않게 됩니다.

객체지향은 프로그램을 연산의 나열이라기보다 상태를 가진 개체들의 협력으로 이해하려는 시도에서 커졌습니다. 세션, 위젯, 게임 캐릭터처럼 각자 다른 상태를 유지하면서 반응해야 하는 대상을 모델링하려면 값 묶음보다 객체라는 단위가 더 자연스러웠습니다.

객체는 보통 정체성, 내부 상태, 공개된 메서드로 이해합니다. 외부 코드는 객체 내부 값을 직접 만지기보다 메서드 호출로 요청을 보내고, 객체는 현재 상태를 바탕으로 응답합니다. 같은 요청이라도 객체가 어떤 상태를 들고 있느냐에 따라 결과가 달라진다는 점이 핵심입니다.

객체는 클래스의 실행 결과이지 클래스의 다른 이름이 아닙니다. 클래스가 공통 설계를 담은 타입이라면, 객체는 그 타입으로부터 생성된 개별 인스턴스입니다. 설계 수준의 이야기와 인스턴스 수준의 이야기를 분리해야 상태와 책임을 정확하게 설명할 수 있습니다.

주문 하나, 사용자 하나, 연결 하나처럼 인스턴스마다 상태와 생명주기를 따로 추적해야 하는 문제에 객체 모델이 잘 맞습니다. 반대로 정체성도 없고 상태 변화도 거의 없는 값이라면 객체보다 값 중심 모델이 더 단순합니다.