Swift TIL(39)

정말 부끄럽지만 뜸했던 TIL
약 일주일정도의 텀이 있었던 듯 하다.
무얼 했나? => 네이버 블로그에..
공부는 무얼했나? => 약 2일정도는 리액트에 빠져있었다. 뽀모도로 타이머 만들기 중독적. ios는 공부량 전무했다
오늘은 풀집중이 어려웠다. 가볍게 몸푸는 느낌으로 진도를 나가보았다(제발)

복습

가볍게 프로토콜에 대해 입문해 보았다. 오랜만에 보니까 반갑기도 하고, 사실 집중을 잘 하지는 못했지만 그래도 했다는 것에 의의를 둬본다 (눈물)

프로토콜은 사실 상속을 배운 후에 배우는 부분이라 이해가 아주 어렵지는 않고, 상속과 확장을 이해하는 논리를 바탕으로 이해하면 어느정도 로지컬하게 이해가 된다.

중요한 부분

• 프로토콜은 타입이다! 업캐스팅, 다운캐스팅, 파라미터, 변수사용여부 생각하기
• 프로토콜이 타입이라서(일급객체라서 타입으로 쓸수있다) 좋은 점 : 공통타입으로도 저장할 수 있는 타입이 되어 좋고, 함수파라미터로도 쓸수있어 좋다.
• 프로토콜은 클래스 상속의 단점을 보완하기 위해(다중상속 불가, 메모리구조까지 상속하여 불필요한 멤버들도 상속됨, 클래스에서만 사용가능) 탄생한 문법이다. 뒤에서 swift 는 프로토콜지향 언어라는것도 들을 생각에 두두근
• 프로토콜의 기본사용법은 protocol정의 부분에서는 메서드의 헤더(인풋, 아웃풋타입명시)만 구현하고 내용은 protocol을 채택하는 타입에서 내부에서 자세히 구현해줘야한다(채택했다면 당연히 구현은 필수다)
• 프로토콜이 파라미터로 들어가 있는 함수에서는 해당 프로토콜을 채택한 타입들이(구조체던 클래스던지) 아규먼트로 사용가능하다

프로토콜 내에서의 멤버가 속성일때

• 프로토콜내에 메서드 뿐만아니라 계산속성, 타입 계산속성 정의가 가능한데 포함관계에 따라 구현하는 쪽에서 계산속성의 읽기 => 읽기 혹은 읽기,쓰기로도 구현가능하고, 타입static 계산속성도 => static 혹은 class키워드로도 구현가능하다. class키워드는(채택한 타입이 Class라는 전제하에) 재정의 가능한 타입계산속성임을 알려준다.
• 위에서 프로토콜 내에 계산속성들을 정의할때는 당연히..var 로 정의하되 구현할때 읽기만으로 할거라면(수정될 염려없으므로) let으로 선언해도 되는 경우가 있다.

프로토콜 내에서의 멤버가 메서드일때

• 위에서 말한 것 처럼 프로토콜 내에는 메서드의 헤더만(최소요구사항)만 정의해준다.

• 타입메서드는 static 키워드를 붙여주면 되고 mutating 키워드가 붙을 경우는 해당 프로토콜을 구조체에서 채택했고, 해당 메서드(프로토콜에서 정의된)내에서 구조체의 속성을 변경시키고 싶을때 붙여야만 하는 키워드이다.

• 단!!(오해금지)
  mutating 키워드가 붙은 메서드라고 무조건 해당 프로토콜을 struct즉 구조체만 쓸수있다는 의미는 아니다. 클래스 타입도 해당 프로토콜을 채택하고 매서드를 구현할 수 있다.

• 채택한 타입 내에서 mutating 키워드 붙은 메서드를 구현할때는 클래스는 물론 mutating 키워드가 없이도 구현가능하고, 구조체는 mutating 키워드 필수로 붙여줘야 한다. 예: mutating func ~

프로토콜 내에서의 생성자 구현(드뭄)

• 클래스는 상속을 고려해야 하므로 채택한 프로토콜에 생성자가 있다면 해당 생성자 내부 구현시 required 키워드 필수로 붙여줘야 한다.
  하지만 상속과 비슷하게 예외적으로 내부에서 다른 생성자를 구현하지 않았다면 required 생성자가 자동상속되므로 required 키워드가 없어도 된다.
  =>

정확히 알기

• final class로 구현시 내부에 required 키워드 생각가능하다(당연히 상속고려 필요 없기때문이다)

• 클래스의 경우 반드시 채택한 프로토콜의 생성자를 내부에서 지정생성자로 구현할필요없이 편의생성자 구현도 가능하다. 단 이경우 원래 생성자 문법에 따라 지정생성자, 혹은 편의생성자라도 호출해야겠다(델리게이트 어크로스 고려)

• 클래스로 하위클래스에서 (상위클래스가 채택한 프로토콜의) 필수생성자를 상속받게 된 경우 + 재정의를 원한다면 required override 키워드를 사용해야 한다.

• 실패가능 생성자의 경우 포함관계를 잘 고려해보자 (프로토콜에서 init?으로 실패가능 생성자로 정의 => init? init! init으로 구현가능)

• 서브스크립트 subscript문법 역시 포함관계를 잘 고려하면 쉽다. (프로토콜에서 get 요구 => get/ getset 구현가능 , getset 요구 => getset으로만 구현가능)

프로토콜의 is as! as? as

• is 연산자 : 프로토콜 채택여부를 확인 가능하고 혹은 해당 인스턴스가 특정 타입(어떤 프로토콜을 채택한) 인지 역으로도 확인 가능하다
• as 연산자 : 업캐스팅 (프로토콜이 상위 up 타입 개념)
• as? as! 연산자 : 다운캐스팅 => 이때 다운캐스팅 후에는 옵셔널 타입이 됨을 알아야 한다. 이경우 옵셔널 타입을 접근할때 사용하는 ? 를 인스턴스뒤에 붙여줘야 타입(다운캐스팅 된, 프로토콜을 채택한 타입)내부의 메서드등에 접근이 가능하다

연휴에 사람을 많이 만났다. 혼자 공부하는 장소에 가보았다