이 포스팅은 iOS Experience 시리즈 18 편 중 7 번째 글 입니다.

  • Part 1 - 01: 스토리보드의 장단점
  • Part 2 - 02: 코드리뷰 Part 1
  • Part 3 - 03: 코드리뷰 Part 2
  • Part 4 - 04: IBOutlet에서의 Optional
  • Part 5 - 05: Optional Chaining의 동작 방법
  • Part 6 - 06: UITableView에 대해서
  • Part 7 - This Post
  • Part 8 - 08: 패키지 매니저
  • Part 9 - 09: URL Loading System
  • Part 10 - 10: Lazy를 잘 안쓰는 이유
  • Part 11 - 11: iOS Gitignore
  • Part 12 - 12: Toast UI에 대한 생각
  • Part 13 - 13: XCTest
  • Part 14 - 14: RunLoop
  • Part 15 - 15: UIApplication
  • Part 16 - 16: 코드리뷰 Part 4
  • Part 17 - 17: MVC to MVVM
  • Part 18 - 18: VIPER
▼ 목록 보기

Cell은 초기화해야 한다.

  • 기본적으로 collectionView나 TableView 같은 경우는 셀을 재사용하게 된다.
  • 그렇기 때문에 재사용할 때, 이를 초기화하도록 prepareForReuse 함수를 오버라이딩 해야한다.
  • 일반적으로 지금 진행하는 작업의 경우 데이터가 모두 있기 때문에 그럴일이 없지만,
  • 만약에 네트워크 환경에서 진행한다면, 데이터를 다 받기전에 보여주어야 할 일이 생긴다.
  • 그렇기 때문에 만약 초기화를 하지 않는다면, 사진의 경우 이전 사진이 노출되었다가, 데이터를 다 받게되었을 때, 이미지가 갱신되는 경우가 발생한다.

죽음의 다이아몬드

image죽음의 다이아몬드

  • 다중 상속의 문제를 단적으로 보여주는 예시
  • 부모가 둘 이상인 예시 -> 의미론적으로도 사실 이상하다.
  • 부모의 자식 클래스가 둘 이상일 때, 이 자식 클래스들을 상속받은 클래스가 있을 때 발생하는 문제.
  • burn() 이라는 함수는 어떤 클래스의 메서드를 사용해야할까?
  • 같은 구문이 다른 의미로 해석되고 있다.

프로토콜을 만드는 이유

  • 사실 프로토콜은 C++의 추상 클래스, 자바의 인터 페이스와 유사한 개념이다.
  • 추상 클래스, 프로토콜, 인터페이스는 클래스와는 다르다. 특히 추상 “클래스”라고 되어 있지만, 클래스로 여기지 않는다.
  • 프로그래밍을 하다보면, 상속 구조로 엮이지 않은 다수의 클래스를 묶어서 관리할 필요성이 생긴다. 목적이나, 행동 방식이 유사하기 때문이다.
  • 대부분의 언어는 다중 상속을 지원하지 않기 때문에, 이러한 작업에 상당한 제약을 받게된다.
  • 이런 경우, 프로토콜을 정의하고, 해당 클래스를 이 프로토콜을 준수하게 한다음에, 이 프로토콜로 여러개의 인스턴스를 한번에 관리할 수 있다.

프로토콜 지향 프로그래밍

  • 프로토콜은 변수와 메서드의 리스트이다.
  • 그런데, 이 프로토콜을 확장하면 추상 메서드를 구현할 수 있다.
  • 원래는 안되지만 확장하면 가능하다.
  • 이렇게 확장한 추상 메서드는, 이 프로토콜을 채택하는 클래스, 구조체, 열거형에 대한 기본 로직을 설정할 수 있다.
  • 이렇게 프로토콜로만으로도 프로그래밍이 가능한데, 이런 방식을 프로토콜 지향 프로그래밍이라 부른다.
  • 프로토콜 초기 구현이 핵심!

특징

  • 기능의 모듈화
  • 기존에 가능했던 클래스에서의 상속의 한계를 풀었다.
    • 열거형, 구조체에서도 이러한 프로토콜의 다중 상속을 통해 값타입에서도 이러한 방식을 사용할 수 있다.
  • 프로토콜과 구현체의 의존관계가 없다.
  • 각각이 독립적이고 안전하다.
  • 수평적인 기능확장이 가능하다.
  • Generic 사용 가능

Strong, weak, unowned

  • ARC 관련 키워드
  • 참조 타입의 경우 Heap 공간에 저장된다.
  • Swift는 Reference count를 자동으로 관리하며, count가 0이 되었을 때, 할당을 해제한다.

Strong

  • 일반적인 Reference 방식
  • 내가 가리키고 있으면 할당 해제하지마! 라는 의미
  • Retain count를 1 늘려준다.

weak

  • 다른 변수가 참조하고 있을 때, 내 의미가 생겨
  • 내가 참조하고 있다고 해서 나를 신경쓰지는 마
  • 즉, 다른 변수가 참조하고 있을 떄, 해당 변수는 포인터로 가리키지만, 다른 변수가 모두 참조를 해제했다면, 해당 변수는 nil로 변경됨
  • 그래서 항상 옵셔널이어야 함
  • delegate
    • 뷰 입장에서 이 뷰의 delegate protocol을 구현하고 있는 VC가 할당 해제된다면 더이상 해당 view에서 메시지를 보낼 필요가 없어진다. 그렇기 때문에 nil로 설정한다.
  • outlet
    • 뷰 계층 구조에서 상위뷰는 하위뷰를 strong으로 참조하고 있다.
    • outlet으로 strong으로 참조가 가능하고, 제대로 할당해제가 되지만, 의미론적으로 outlet은 해당 계층 구조를 갱신하기 위한 목적으로 참고하는 것이기 때문에 weak이 좀더 합당
    • 하지만 strong으로 잡는 경우도 있음.

unowned

  • 클로저와 연관된 키워드
  • 내가 참조하는 것을 count하지마! 라는 의미
  • 힙에서 사라졌을 때, 접근하지 않는다는 것이 보장되어야 함(100%)
  • 참조 순환을 방지하기 위한 방법

Reference