프로그래밍스위프트 개발자

스위프트에서 computed property의 작동 메커니즘을 설명해 주세요. computed 속성과 stored 속성의 주요 차이점은 무엇이며 computed 속성은 왜 필요한가요?

Hintsage AI 어시스턴트로 면접 통과

답변.

역사적으로 Objective-C에서 속성은 접근 메서드(게터와 세터)를 통해 구현되었습니다. 스위프트에서는 computed properties를 쉽게 생성할 수 있도록 특별한 구문이 도입되어, 값이 즉석에서 계산되는 속성을 만들 수 있습니다. 이는 타입의 캡슐화 가능성과 코드의 표현력을 확장합니다.

문제: stored property로 결과를 저장하는 것이 항상 편리한 것은 아닙니다. 특히 값이 다른 속성에 따라 달라지거나 지속적으로 변경되는 경우에는 더욱 그렇습니다. 계산기 메서드를 사용하는 것은 타입의 본질을 숨기고 인터페이스를 덜 가독성 있게 만듭니다.

해결책: Computed property는 get 및 필요에 따라 set으로 정의됩니다. 이러한 속성에 접근할 때마다 메모리에서 읽는 것이 아니라 계산이 수행됩니다. 이는 예를 들어, 객체의 나머지 상태와 자동으로 동기화된 파생 속성을 구축할 수 있게 해줍니다.

코드 예시:

struct Rectangle { var width: Double var height: Double var area: Double { get { return width * height } set { // 새로운 area 필드 값을 기반으로 width 자동 업데이트 (예시) width = sqrt(newValue / height) } } } var rect = Rectangle(width: 5, height: 2) print(rect.area) // 10 rect.area = 36 print(rect.width) // 3.0

주요 특징:

  • Computed property는 추가 메모리를 차지하지 않으며, 결과를 자동으로 저장하지 않습니다.
  • get 또는 get 및 set만 가질 수 있습니다.
  • 파생 속성 또는 동기화된 속성을 생성하는 편리한 방법입니다.

난이도가 있는 질문들.

computed property에서 willSet/didSet을 사용할 수 있나요?

아니요, willSet 및 didSet은 stored property에만 적용됩니다. computed property에는 자동으로 값을 저장하지 않기 때문에 이러한 관찰자가 작동하지 않습니다.

computed property는 약한 타입이나 암시적으로 펼쳐진 타입을 가질 수 있나요?

네, computed property는 옵셔널이거나 암시적으로 펼쳐된 타입이 될 수 있습니다. 그러나 이러한 속성을 weak으로 만드는 것은 의미가 없는데, 왜냐하면 그들은 참조를 포함하지 않고 오직 계산만 수행하기 때문입니다.

computed property에서 private set을 사용하는 것이 더 좋은 경우는 언제인가요?

접근 제어자 private(set)은 computed property에 get과 set이 있는 경우 적용할 수 없고, 오직 stored property에만 적용할 수 있습니다. computed property의 set은 private set을 통해 완전히 비공개로 만들 수 있지만, 이는 set 블록의 접근 가능성을 통해 암묵적으로 구현됩니다.

public var area: Double { private set { ... } get { ... } }

전형적인 오류 및 안티패턴

  • get 블록에서 무거운, 긴 계산을 수행하여 낮은 성능으로 이어지는 경우.
  • 게터 내에서 상태를 변형하여 부작용이 없는 접근자의 개념을 어기는 경우.
  • set을 잘못 사용하여 한 속성의 변경이 여러 다른 속성에 영향을 미쳐야 할 때.

실생활 예시

부정적인 사례

computed property의 get이 매번 접근할 때마다 큰 데이터를 네트워크에서 로드하면 프리징과 네트워크 과부하가 발생합니다.

장점:

  • 작은 데이터의 경우 사용하기 쉬움.

단점:

  • 실제 데이터에서의 취약성 및 예측할 수 없는 동작.
  • 성능 및 전력 소비에 대한 상당한 부정적 영향.

긍정적인 사례

computed property가 다른 stored property를 기반으로 최소한의 비용으로 최종 값을 계산하고, 무거운 로직 캐싱은 별도의 메커니즘으로 외부화됩니다.

장점:

  • 높은 성능.
  • 상태 동기화 및 예측 가능한 작업 계약.

단점:

  • 계산이 복잡할 경우 캐싱을 위한 추가 코드가 필요합니다.