Choosing Between Structures and Classes

 

 

 

구조체와 클래스는 앱에서 데이터를 저장하고 동작을 모델링하는 데 좋은 선택이지만, 유사성으로 인해 하나를 선택하기 어려울 수 있습니다.

앱에 새로운 데이터 유형을 추가할 때 어떤 옵션이 적합한지 선택하는 데 도움이 되도록 다음 권장 사항을 고려하십시오.

- 기본적으로 구조를 사용합니다.
- Objective-C 상호 운용성이 필요할 때 클래스를 사용하십시오.
- 모델링하는 데이터의 ID를 제어해야 할 때 클래스를 사용하십시오.
- 프로토콜과 함께 구조체를 사용하여 구현을 공유하여 동작을 채택합니다.

 

기본적으로 구조체를 사용합니다.

구조체를 사용하여 일반적인 종류의 데이터를 나타냅니다. Swift의 구조체에는 다른 언어의 클래스로 제한되는 많은 기능이 포함되어 있습니다. 저장된 속성, 계산된 속성 및 메서드를 포함할 수 있습니다. 게다가, 스위프트 구조체는 기본 구현을 통해 동작을 얻기 위해 프로토콜을 채택할 수 있다. Swift 표준 라이브러리와 Foundation은 숫자, 문자열, 배열 및 사전과 같이 자주 사용하는 유형에 대한 구조체를 사용합니다.

구조체를 사용하면 앱의 전체 상태를 고려할 필요 없이 코드의 일부에 대해 쉽게 추론할 수 있습니다. 구조체는 클래스와 달리 값 유형이기 때문에 앱의 흐름의 일부로 의도적으로 변경 사항을 전달하지 않는 한 구조에 대한 로컬 변경 사항은 앱의 나머지 부분에 표시되지 않습니다. 결과적으로 코드 섹션을 보고 해당 섹션의 인스턴스에 대한 변경 사항이 접선적으로 관련된 함수 호출에서 보이지 않게 이루어지는 것이 아니라 명시적으로 이루어지도록 더 확신할 수 있습니다.

 

Objective-C 상호 운용성이 필요할 때 클래스를 사용하십시오.

데이터를 처리해야 하는 Objective-C API를 사용하거나 Objective-C 프레임워크에 정의된 기존 클래스 계층에 데이터 모델을 맞춰야 하는 경우 클래스와 클래스 상속을 사용하여 데이터를 모델링해야 할 수 있습니다. 예를 들어, 많은 Objective-C 프레임워크는 하위 클래스로 예상되는 클래스를 노출합니다.

 

모델링하는 데이터의 ID를 제어해야 할 때 클래스를 사용하십시오.

스위프트의 클래스는 참조 유형이기 때문에 식별자(identity)에 대한 개념이 내장되어 있습니다. 이는 두 개의 서로 다른 클래스 인스턴스가 각각의 저장된 속성에 대해 동일한 값을 가질 때, 그것들은 여전히 식별 연산자(===)에 의해 다른 것으로 간주된다는 것을 의미한다. 또한 앱 간에 클래스 인스턴스를 공유할 때 해당 인스턴스에 대한 변경 사항이 해당 인스턴스에 대한 참조를 보유하는 코드의 모든 부분에 표시됩니다. 인스턴스가 이러한 종류의 정체성을 가져야 할 때 클래스를 사용하십시오. 일반적인 사용 사례는 파일 핸들, 네트워크 연결 및 CBCentralManager와 같은 공유 하드웨어 중개자입니다.

예를 들어, 로컬 데이터베이스 연결을 나타내는 유형이 있는 경우, 해당 데이터베이스에 대한 액세스를 관리하는 코드는 앱에서 볼 수 있는 데이터베이스의 상태를 완전히 제어해야 합니다. 이 경우 클래스를 사용하는 것이 적절하지만, 앱의 어느 부분이 공유 데이터베이스 객체에 액세스할 수 있는지 제한해야 합니다.

 

중요

식별자를 조심히 대하세요. 앱 전체에 걸쳐 클래스 인스턴스를 널리 공유하면 논리 오류가 발생할 가능성이 높아집니다. 많이 공유된 인스턴스를 변경하면 결과를 예상하지 못할 수 있으므로 그러한 코드를 올바르게 작성하는 데 더 많은 작업이 있습니다.

 

식별자를 제어할 일 없다면 구조체를 사용하세요

제어할 수 없는 신원을 가진 엔티티에 대한 정보가 포함된 데이터를 모델링할 때 구조체를 사용하십시오.

예를 들어 원격 데이터베이스를 참조하는 앱에서 인스턴스의 신원은 외부 엔티티가 완전히 소유하고 식별자에 의해 전달될 수 있습니다. 앱 모델의 일관성이 서버에 저장되면 레코드를 식별자가 있는 구조로 모델링할 수 있습니다. 아래 예에서 jsonResponse는 서버에서 인코딩된 PenPalRecord 인스턴스를 포함합니다.

struct PenPalRecord {
    let myID: Int
    var myNickname: String
    var recommendedPenPalID: Int
}

var myRecord = try JSONDecoder().decode(PenPalRecord.self, from: jsonResponse)

 

PenPalRecord와 같은 모델 유형에 대한 로컬 변경 사항이 유용합니다. 예를 들어, 앱이 사용자 피드백에 대한 응답으로 여러 개의 다른 펜팔을 추천할 수 있습니다. PenPalRecord 구조는 기본 데이터베이스 레코드의 ID를 제어하지 않기 때문에 로컬 PenPalRecord 인스턴스에 대한 변경이 실수로 데이터베이스의 값을 변경할 위험이 없습니다.

앱의 다른 부분이 myNickname을 변경하고 서버에 변경 요청을 다시 제출하면 가장 최근에 거부된 펜팔 추천이 변경에 의해 실수로 선택되지 않습니다. myID 속성은 상수로 선언되기 때문에 로컬에서 변경할 수 없습니다. 결과적으로 데이터베이스에 대한 요청은 실수로 잘못된 레코드를 변경하지 않습니다.

구조체와 프로토콜을 사용하여 상속을 모델링하고 행동을 공유합니다.

구조체와 클래스 모두 상속의 형태를 지원합니다. 구조체와 프로토콜은 프로토콜만 채택할 수 있으며 클래스에서 상속할 수 없습니다. 그러나 클래스 상속으로 구축할 수 있는 상속 계층의 종류는 프로토콜 상속 및 구조체를 사용하여 모델링할 수도 있습니다.

처음부터 상속 관계를 구축하는 경우 프로토콜 상속을 선호합니다. 프로토콜은 클래스, 구조 및 열거가 상속에 참여할 수 있도록 허용하는 반면, 클래스 상속은 다른 클래스와만 호환됩니다. 데이터를 모델링하는 방법을 선택할 때 먼저 프로토콜 상속을 사용하여 데이터 유형의 계층 구조를 구축한 다음 해당 프로토콜을 구조에 채택하십시오.

 

https://developer.apple.com/documentation/swift/choosing-between-structures-and-classes

Choosing Between Structures and Classes | Apple Developer Documentation