다형성
이번주도 정신없이 개발하다보니 한주가 끝나있었다.
뷰 프로그래밍, OOP, POP, 터치이벤트 등등 정말 많은 것들을 학습했다.
그 중 iOS에서 가장 활발하게 토론했던것은 프로토콜 VS 상속이였다.
마스터클래스에서 다형성에 대한 강의를 해주시기도 했고
이번주차의 미션 요구사항을 보면 다형성을 잘 구현해 놓고 확장에 대해 열려있어야
다음주차의 개선 요구사항을 쉽게 구현할 수 있을것이라는 생각이 들었기 때문이다.
상속 VS 프로토콜
캠퍼들과 정말 많은 이야기를 했다. 피어세션, 그룹세션 뿐만 아니라 마스터클래스에서도 질문을 올리면서
끊임 없이 각자의 생각들을 정리하고 발전시켜나갔다.
단순히 상속이 맞다, 프로토콜이 맞다 라는 이유로 토론하는 것이 아니라 어느 상황에 어떤 것을 써야 더 좋을까??
이 상황에는 프로토콜이 더 좋지 않을까요 ?? 라는 식으로 각자의 의견을 교환해나갔다.
이야기를 하다보니 프로토콜에 프로퍼티를 넣는것에 대한 이야기가 나왔다.
프로토콜에 프로퍼티
프로토콜로 다형성을 구현하려고 하다보면 프로퍼티를 명시해주어야 했다.
하지만 프로퍼티가 프로토콜에 명시되어 버리면 prviate으로 프로퍼티를 은닉화 할 수 없게된다.
protocol SomeProtocol {
var someProperty: SomeType { get set }
}
class SomeClass: SomeProtocol {
// private 키워드 사용불가능
var someProperty: SomeType
}
프로퍼티를 외부에서 접근할 필요가 없기 때문에 은닉화 해야하는데 프로토콜에 명시되어 있어 은닉화 하지 못하는 상황이 발생하는 것이다.
그렇다고 프로토콜에 프로퍼티를 명시해주지 않는다면 getter/setter 메서드를 추가해주어야 하는 문제점이 있었다.
그래서 나온 방법이 프로토콜에는 get으로만 선언하여 private(set)을 사용하여 외부에서는 읽기 전용으로 프로퍼티를 설정해주는 것이였다.
protocol SomeProtocol {
var someProperty: SomeType { get }
}
class SomeClass: SomeProtocol {
private(set) var someProperty: SomeType
}
나는 처음에는 상속보다는 프로토콜을 사용하는것이 더 좋다라고 생각하는 편이였다.
프로토콜에서 프로퍼티를 읽기전용 프로퍼티로 선언하여 채택한 곳에서 private(set)으로 만들어주면 해결된다고 생각했기 때문이다.
JK님께서도 이와 관련해서 조언을 해주셨는데
“충분히 고민하고 프로퍼티가 프로토콜에 넣는것이 필요하다고 생각되면 문제가 되진 않는다. 하지만 프로토콜에 프로퍼티가 너무 많다면 즉 private(set)이 많은것 은 다시 한번 생각해볼 필요가 있다” 라고 하셨다.
마스터의 조언과 캠퍼들과 토론한것을 바탕으로 내 나름대로 프로토콜과 상속에 대한 기준을 세울 수 있었다.
상속은 프로퍼티 위주로
프로퍼티는 보통 외부에서 접근하면 안되는것이 일반적이기 때문에 private로 선언하는것이 일반적이다.
그래서 프로토콜에 프로퍼티를 사용하는것이 정말 필요한가 ?? 라고 생각했을 때 필요 없다 라고 생각하게 되었다.
물론 필요한 경우가 있다면 프로토콜에 프로퍼티를 사용하겠지만 기본적으로 프로퍼티는
객체내에 private으로 선언하는 것이 더 좋다는 결론을 내렸다.
프로토콜은 메서드를 위주로
반대로 메서드는 프로토콜위주로 작성하는 것이 좋다고 결론을 내렸다.
프로토콜로 선언하는 것이 상속보다 더 자유롭다고 생각했기 때문이다.
예를 들어 체스를 생각해본다면 체스말마다 움직임이 다르다.
그 중에는 움직이는 방법이 겹치는 말들이 있는데 이를 상속으로 해결하기 쉽지 않다.
퀸은 룩과 비숍이 움직이는 방법 두가지를 합친것인데 Swift에서는 다중상속을 지원해주지 않기도 하고
설사 다중상속을 지원한다 하더라도 매번 다중상속을 받아 객체를 생성하는 방법 역시 좋지 않은 방법이다.
하지만 프로토콜을 메서드 위주로 선언하면 해결하기 쉬워진다.
protocol RookMoveable {}
protocol BishopMoveable {}
protocol QueneMovable: RookMoveable, BishopMoveable {}
class ChessPiece { }
class Quene: ChessPiece, QueneMovable {}
위와 같이 프로토콜로 선언해버리면 룩이나 비숍의 움직임이 겹치는 말이 있다면 원하는대로 추가할 수 있어진다.
이것이 부스트캠프 ??
위에서 언급을 했는데 상속과 프로토콜에 대해서 각자의 생각을 말하는것이 정말 좋은 경험이었다.
무작정 내 의견이나 상대방의 의견을 맞다 틀리다를 판가름 하는 것이 아니라 상대방의 의견을 존중해주고
언제든 수용할 수 있는 상태로 이야기를 하다보니 모두가 좋은 결과를 얻을 수 있었던 것 같다.