[Apple Developer Docs] Choosing Between Structures and Classes (구조체와 클래스 사이에서 선택하기)

원본 문서 : Apple Developer Documentation

구조체와 클래스 사이에서 선택하기

데이터와 모델 행동을 어떻게 저장할지 결정합니다.

개요

구조체와 클래스는 당신의 앱에서 데이터를 저장하기 위한, 그리고 행동들을 모델링하기 위한 좋은 선택입니다. 하지만 이들의 유사성이 둘 중 하나를 선택하는 것을 어렵게 만들 수 있습니다.

당신의 앱에 새로운 데이터 타입을 추가할 때, 어떤 선택이 합리적인지 선택하도록 도와주는 아래의 권장사항을 따르는 것을 고려해 보십시오.

• 기본적으로 구조체를 사용합니다.
• Objective-C 상호운용성이 필요한 경우, 클래스를 사용합니다.
• 당신이 모델링하고 있는 데이터의 동일성을 관리할 필요가 있다면, 클래스를 사용합니다.
• 구현사항들을 공유함으로서 행동을 채택하기 위해, 구조체와 프로토콜을 함께 사용합니다.

기본적으로 구조체를 선택하기

일반적인 종류의 데이터를 나타내기 위해 구조체를 사용하십시오. Swift의 구조체는 다른 언어들에서는 클래스에만 제한되는 많은 기능들을 포함합니다: 저장 프로퍼티, 연산 프로퍼티, 메서드를 포함할 수 있습니다. 게다가, Swift의 구조체는 프로토콜을 채택하여 기본 구현들을 통해 행동을 얻을 수 있습니다. Swift 표준 라이브러리와 Foundation은 당신이 자주 사용하는 숫자, 문자열, 배열, 딕셔너리와 같은 타입들에 대해 구조체를 사용합니다.

구조체를 사용하는 것은 앱의 전체 상태를 고려하지 않고도 당신의 코드 일부에 대해 추론하는 것을 더 쉽게 해 줍니다. 구조체는 값 타입이기 때문에 - 클래스와는 다르게 - 한 구조체의 변화는 당신이 의도적으로 그 변화를 앱 흐름의 일부로서 전달하지 않는 한 보이지 않습니다. 그 결과로, 당신은 어떤 코드 부분을 보고, 그 부분 안의 인스턴스에 대한 변화가 별로 관계가 없는 함수 호출로부터 보이지 않게 일어나는 것이 아니라, 명시적으로 일어날 것임을 확신할 수 있습니다.

Objective-C 상호운용성이 필요할 때 클래스를 사용하기

만약 당신이 당신의 데이터를 처리하기 위해 Objective-C API를 사용하거나, Objective-C 프레임워크에 정의된 존재하는 클래스 계층 구조 속에 당신의 데이터 모델을 맞출 필요가 있다면, 당신은 데이터를 모델링하기 위해 클래스와 클래스 상속을 사용해야 할 것입니다. 예를 들어, 많은 Objective-C 프레임워크는 당신이 서브클래스로 예상하는 것들을 클래스로 노출합니다.

동일성을 관리할 필요가 있을 때 클래스를 사용하기

Swift의 클래스는 참조 타입이기 때문에 동일성에 대한 내장된 개념이 있습니다. 이는 두 서로 다른 클래스 인스턴스들이 각각의 저장 프로퍼티로 같은 값을 가질 때, 여전히 동일성 연산자(===)에 의해 다르다고 고려된다는 것을 의미합니다. 이는 또한 당신의 앱 내에서 클래스 인스턴스를 공유할 때, 그 인스턴스에 대해 당신이 만든 변화를 그 인스턴스에 대한 참조를 가지고 있는 다른 모든 코드 부분에서도 볼 수 있음을 의미합니다. 당신의 인스턴스가 이러한 종류의 동일성을 가져야 할 필요가 있을 때 클래스를 사용하십시오. 일반적인 사용 예시는 파일 처리, 네트워크 연결, 그리고 CBCentralManager 같은 공유 하드웨어 중재자입니다.

예를 들어, 만약 당신이 로컬 데이터베이스 연결을 나타내는 타입을 가지고 있다면, 그 데이터베이스에 대한 접근을 관리하는 코드는 당신의 앱에서 보이듯 데이터베이스의 상태에 대한 완전한 제어를 필요로 합니다. 이러한 경우 클래스를 사용하는 것이 적절합니다. 하지만 당신의 앱의 어떤 부분이 공유 데이터베이스 객체에 대한 접근권을 가지는지 제한하는 것을 확실히 해야 합니다.

중요
동일성을 주의 깊게 다루십시오. 클래스 인스턴스를 앱 전체에 걸쳐 널리 공유하면 로직 에러가 발생하기 쉽습니다. 당신은 매우 널리 공유되는 인스턴스의 변화에 대한 결과를 예측하기 어려우며, 따라서 그러한 코드를 올바르게 작성하는 것이 추가적인 일이 됩니다.

동일성을 통제하지 않을 때 구조체를 사용하기

당신이 통제하지 않는 동일성을 가진 엔티티에 대한 정보를 담은 데이터를 모델링할 때는 구조체를 사용하십시오.

예를 들어 원격 데이터베이스를 참조하는 앱에서는, 인스턴스의 동일성은 외부 엔티티에 의해 완전히 소유되고 식별자(identifier)에 의해 전달되어야 합니다. 만약 앱의 모델의 일관성이 서버에 저장되어 있다면, 당신은 식별자를 가진 구조체로 기록을 모델링할 수 있습니다. 아래 예시에서, jsonResponse는 서버로부터 인코딩된 PenPalRecord 인스턴스를 가지고 있습니다:

PenPalRecord와 같은 모델 타입에 대한 로컬의 변화는 유용합니다. 예를 들어, 앱이 유저 피드백을 위한 응답으로 여러 다른 펜팔을 추천할 수 있습니다. PenPalRecord 구조체는 기저의 데이터베이스 기록의 동일성을 통제하지 않으므로, 로컬의 PenPalRecord 인스턴스에 대해 이루어진 변화가 의도치 않게 데이터베이스의 값을 바꾸는 상황에 대한 어떤 위험부담도 없습니다.

만약 앱의 다른 부분이 myNickname을 바꾸고, 그 변경 요청을 서버에 다시 제출한다면, 가장 최근에 거절된 펜팔 추천이 변경에 의해 사고로 선택되지 않을 것입니다. myId 프로퍼티가 상수로 선언되어 있으므로, 로컬에서는 변경될 수 없습니다. 그 결과, 데이터베이스에 대한 요청은 다른 기록을 의도치 않게 변화시키지 않을 것입니다.

모델 상속과 행동 공유를 위해 구조체와 프로토콜 사용하기

구조체와 클래스는 모두 상속이라는 형태를 지원합니다. 구조체와 클래스는 프로토콜만을 채택할 수 있습니다; 이들은 클래스를 상속할 수 없습니다. 하지만, 당신이 클래스 상속을 통해 형성할 수 있는 유형의 상속 계층들은 프로토콜상속과 구조체를 사용해도 똑같이 모델링할 수 있습니다.

만약 맨 처음부터 상속 관계를 만들고 있다면, 프로토콜 상속을 선호합니다. 프로토콜은 상속에 클래스, 구조체, 열거형이 참여하도록 허용합니다. 반면 클래스 상속은 오직 다른 클래스에만 호환이 가능합니다. 당신이 데이터를 어떻게 모델링할지 선택하는 중이라면, 먼저 프로토콜 상속을 사용해 데이터 타입의 계층을 만드는 것을 시도하십시오. 그런 다음 당신의 구조체에 그 프로토콜들을 채택합니다.