OOP in Rust

러스트식 객체 지향 판별 지도

클래스 상속을 그대로 찾기보다 데이터와 동작의 결합, 공개 범위, 코드 공유, 다형성을 각각 어떤 러스트 장치로 해결하는지 분리해서 본다.

특성별 해석 매트릭스

compare matrix

질문

전통 OOP 기대

러스트 해석

판정

데이터와 동작값과 메서드가 한 개념으로 묶이는가.

객체가 필드와 메서드를 가진다.

struct, enum, impl이 같은 역할을 나눠 맡는다.

지원이름만 클래스가 아닐 뿐이다.

캡슐화외부가 내부 필드를 직접 흔들 수 없는가.

공개 API로만 상태를 바꾼다.

기본 비공개와 pub 선택으로 경계를 세운다.

지원불변식 보호에 강하다.

상속부모 구현을 자식이 물려받는가.

클래스 계층이 코드 공유와 대체 가능성을 담당한다.

직접 상속은 없고 조합, 기본 메서드, 제네릭으로 나눈다.

대체계층보다 역할을 먼저 본다.

다형성여러 타입을 같은 인터페이스로 다루는가.

부모 타입 자리에 자식 타입을 넣는다.

트레이트 바운드와 트레이트 객체가 호출 계약을 만든다.

지원컴파일 타임과 런타임 선택지가 있다.

route map

같은 메서드 계약이면 트레이트와 기본 구현을 먼저 검토한다.

공통 필드가 핵심이면 내부 구조체를 포함하는 조합이 단순하다.

런타임에 다양한 구현을 섞어야 하면 dyn Trait이 후보가 된다.

정적 디스패치가 맞으면 제네릭과 트레이트 바운드로 단형화한다.

state board

좋은 신호

필드는 감춰져 있고, 호출자는 메서드와 트레이트 계약만 안다.

주의 신호

단순 재사용을 위해 깊은 타입 계층을 흉내 내고 있다.

선택 기준

코드 공유는 기본 메서드, 데이터 공유는 조합, 대체 가능성은 트레이트로 분리한다.