Identity

[ha-nabi]

Identity

Choosing Between Structures and Classes

공식 문서엔 아래와 같은 구절이 존재합니다.

모델링하는 데이터의 identity를 컨트롤해야 할 때는 class를 사용하라

여기서 데이터의 아이덴티티 (identity of the data) 란 무엇을 의미할까요?

이 글을 통해 class의 선택 기준이 되는 데이터의 고유성(Identity) control 이란 무엇인지 알아봅시다.

class와 struct의 선택 기준

AppleDeveloper_Choosing Between Structures and Classes

identity 라는 키워드를 어디서 마주할 수 있는가.

애플 공식 문서는 class와 struct 선택 기준에 대해 아래와 같이 말한다.

• 기본적으로 struct를 사용하라
• Objective-C 상호 운용성이 필요한 경우 class를 사용하라
• 모델링하는 데이터의 identity를 컨트롤해야 할 때는 class를 사용하라
• 구현을 공유하여 동작을 채택하려면 protocol과 함께 struct를 사용하라

첫 번째 문장이 인상 깊다.

기본적으로 struct를 사용하라

swift를 사용하며 class의 필요를 느낄 상황은 흔치 않습니다.

그렇다면 class를 선택할 상황은 정말 없는 걸까?

(명쾌하게도) 위의 세번째 문장에서 class를 선택해야 할 상황이 언급됩니다.

모델링하는 데이터의 identity를 컨트롤해야 할 때는 class를 사용하라.

데이터의 identity? 그리고 그걸 control?

identity의 사전적 뜻은 고유성, 독자성, 신원입니다.

아이디 비밀번호 할 때 그 id가 바로 identity의 약어이기도 합니다.

무엇이 데이터를 고유하도록, 식별 가능하도록 할까?

더 나아가 데이터의 식별성을 조절 한다는 말이 무슨 뜻 일까?

Identity, Identifier

먼저 Identity란 무엇일까 고민하며 자연스레 변수 / 상수 개념을 돌아보게 되었다.

변하지 않는 정체성- 에 대해 고민하자면 변하지 않는 값, 상수(let)가 떠오르기 때문이다.

그렇게 var랑 let이 뭐였는지 생각하다 새삼스레 발견하게 된 것이 있다.

var test: String = ""

바로 위 변수(또는 상수)의 이름인test를 부르는 명칭이 Identifier, 식별자라는 것입니다.

매번 '이름'이라고 불렀기에 Identifier라는 명칭이 있었음을 잊고 있었다.

아무튼 변수 상수의 이름, 즉 Identifier가 데이터를 식별하는 기준은 뭘까?

struct와 class의 근본적인 차이라 하면, 값 타입이냐 참조 타입이냐이다.

struct 데이터의 식별자는 스택에 저장된 값을 바라보고, class의 식별자는 힙에 저장된 인스턴스 주소를 가지고 값을 바라본다.

자연스레 얻는 깨달음이 있다.

아. 구조체에겐 원본 개념이 없구나

struct는 값타입으로 데이터 자체에 특별한 정체성이 존재하지 않습니다.

스택 내부에서 생성되고, 사라지며 누군가 보고 있다는 이유로 유지되지 않기 때문임. (참조 카운트 증가 개념이 없음)

---

다시 돌아가 아래 문장을 보자.

모델링하는 데이터의 identity를 컨트롤해야 할 때는 class를 사용하라.

identity란 데이터의 정체성을 대변하는 요소로, 문맥상 데이터의 주소를 의미하는 것으로 보인다. 그러니 identity 컨트롤이란 주소가 유지되는 상황 전제를 통한 여러 접근을 의미하는 게 아닐까 추측할 수 있다.

여기까지 생각을 좁히자 자연스럽게 뒤따르는 또 다른 질문이 있었다.

Identity와 Identifiable은 무슨 차이지 ?

Identity와 Identifiable의 차이

Identifiable은 swift의 프로토콜이다.

인스턴스(class)가 안정된 identity를 가진 엔티티의 값을 보유함을 보증한다

설명 상으론 객체로 상황을 제한하는 것 같지만, AnyObject라는 제한이 걸려있지 않다.

더불어 struct 타입의 데이터를 만들다 보면 Identifiable이라는 채택할 경우가 제법 흔한 것 같다.

떠오르는 예시를 들자면, SwiftUI에서는 ForEach를 돌리기 위해서 Identifiable한 데이터나 hashable한 내부 속성값을 요구한다.

그래서 struct에 Identifiable을 채택시켜 주어 id를 정의해주었다.

위의 이해를 토대로 정리해보자면,

컴퓨터 기준으로 값 타입에는 원본 개념이 없다.

그러나 우리의 프로젝트는 이전 값과 이후의 값이 같은 데이터를 기준으로 탄생했음을 식별해야 할 일이 생긴다.

즉, 값 타입에게 식별 기준을 요구하게 된다.

이때 Identifiable은 식별성을 보증하는 프로토콜로, 값 타입에게 명시적으로 구분자를 제공하는 역할로 활용될 수 있다.

Identifiable protocol in SwiftUI explained with code examples

또한 위 글을 참고해보면

! class에 Identifiable 채택 시 Id 구현이 필수적이지 않다.

객체의 Id값은 자동으로 ObjectIdentifier 타입으로 할당된다.

즉, 따로 id를 만들어주지 않아도 객체의 주소값이 데이터의 식별 요소가 된다는걸 알 수 있다.

Identity Operators

Identity Operators는 객체의 고유성을 판별하기 위한 연산자이다.

해당 연산자는 객체의 Identity를 비교하기 위해 참조(주소)를 비교한다.

만약 struct 인스턴스의 비교를 수행하고자 한다면,

클래스 타입이 아니라는 경고가 출력된다.

identifiable을 채택한 구조체라도 마찬가지다.

명시적으로 식별성을 심어준다 한들 값 타입에겐 원본 개념이 없다.

편의를 위해 심어준 식별성은, 데이터의 식별성(참조)을 대변해주지 못한다.

데이터의 정체성(Identity)이란,

값 타입에게는 컴퓨터가 그 정체성을 식별한 만한 요인이 없다.

일반적으로 정체성(identity)이란 객체(클래스 인스턴스)의 주소를 의미한다.

모델링하는 데이터의 identity를 컨트롤해야 할 때는 class를 사용하라.

아래는 내 나름대로 정리해본 생각이다.

• identity를 컨트롤해야 할 때란, 유지가능한 데이터에 여러 접근이 이루어져야 할 때 를 의미한다.

• 덧붙여 struct는 본질적으로 식별이 불가능하다.

• Identifiable을 채택하여 구조체에게도 Id(id)를 심어주는 것은 서로다른 값이라도 id를 통해 '같다'고 판별할 수 있도록 식별 요소를 제공할 뿐, 데이터가 자체가 유지되는-는 참조타입의 특성을 주입하는 것은 아니다.

정리

사용단의 주기보다 오래 유지되어야 하는 데이터는 그 정체성(identity) 이 유지되어야 하므로 class로 두어야 겠다 값 타입(struct)은 원본이 없다. 즉 식별할 수 없다.

하지만 우리의 필요에 의해 명시적으로 식별성을 심어줄 수 있다. 그러나 이는 데이터를 구분하기 위한 사용자의 수단으로 그 값이 유지된다는 의미는 아니다.

유지된다- 는 원본 개념은 오직 참조 타입에만 존재한다

적절히 판단하여 활용하자