Swift를 계속 쓰다보니 어느 정도 적응이 되는 것같다. 처음에는 생소했던 옵셔널이나 옵셔널 바인딩 같은 것들도 이제는 감이 잡힌다.
 |
이 책이 상당히 도움이 많이 된다. 다른 책들에 비해 인기순위도 낮고 서점에서는 매대에 올라있지도 못하고 아래에 꽂혀있는 책이었지만 가장 유용하게 활용하고 있는 책이다.
guard 문은 별 것 아니지만 아이디어가 마음에 든다. 조건들을 나열하고, 만족되지 않으면 else 블럭을 실행한다. 물론 if문으로도 처리할 수 있는 내용이긴 하다. Empty statement를 가지는 if문과 else를 조합하거나, guard 조건을 invert해서 if문을 만드는 거랑 동작은 같다. 그러나 early return 식으로 if문을 사용하려면 실제 관심있는 조건과 반대되는 조건문을 써서 걸러내야한다. 아래와 같은 상황을 생각해보자.
void myFunc(MyClass param) {
if (param.isVaild()) {
// do some stuff here
}
}
처음에는 이런 식으로 작성해도 문제가 없다. 그리고 “param이 valid하면 작업을 수행한다”라는 사고의 흐름이, “valid하지 않으면 리턴하고 나머지를 수행하지 않는다”라는 것보다 훨씬 자연스럽기 때문에 코드는 최초에 이런 식으로 작성되기 쉽다.
그러나 시간이 흘러 점점 많은 작업들을 담다보면 이렇게 된다.
void myFunc(MyClass param) {
if (param.isValid()) {
int value = param.getSome();
if (value > 0) {
for (int i = 0; i < value; ++i) {
// some more lines of code
// ...
} // end if
}
만약 이 버전을 먼저 봤다면 ‘그냥 if(!param.isValid()) { return; } 해버리면 될걸 저 긴 코드를 왜 if 하나에 넣어뒀지?’라고 생각할 것이다. 그리고 이렇게 고치고 싶을 것이다.
void myFunc(MyClass param) {
if (!param.isValid()) {
return;
}
int value = param.getSome();
if (value <= 0) {
return;
}
for (int i = 0; i < value; ++i) {
// some more lines of code
// ...
}
depth가 확 줄었다.
그런데 Swift는 guard라는 문법을 통해서 이런 것을 방지하겠다는 전략인 것같다.
guard를 사용하면 이렇게 된다.
func myFunc(_ param: MyClass) {
guard param.isValid() else { return }
// do simple things
}
말 그대로 미리 가드를 쳐놓고 시작할 수 있다. (중간에 와도 상관없다.) 사고의 흐름을 거스르지 않으면서도 처음부터 early return을 하도록 유도하는 것이다. 나중에 작업이 아무리 늘어나도 상관없다.
http://alisoftware.github.io/swift/pattern-matching/2016/05/16/pattern-matching-4/ 이 글을 읽고 나서는 Swift가 더 흥미로워졌다! 특히 for case 부분. 한 가지 궁금한 것은 현재 루프에서 처리하는 리스트 항목의 각 요소들(title, director, year) 외에 그 항목 자체에 대한 참조를 가져올 수 있는가 하는 것이다. 객체를 다른 리스트에 추가하거나 할 때 그 참조가 필요할텐데, 일단 그냥 루프를 쭉 돌면서 항목들을 처리하고 끝내는 작업만 할 때는 간결하게 작성할 수 있을 것 같다. 그러나 여전히 for case let 같은 형식이 썩 직관적이라는 생각은 들지 않고 짧은 코드 안에 너무 많은 맥락이 포함되어있다는 생각이 든다. 바인딩에 익숙하지 않아서일지도…
for in where는 충분히 직관적인 것 같다.
enum의 extension을 선언해서 속성들을 리턴하거나 문자열을 리턴하는 건 알아두면 유용할 것같긴 한데 자주 써보지 않으면 응용하기 어려울 것 같다. kind 속성을 추가한 부분은 왠지 Java의 toString과 비슷한듯하다.
kotlin에도 저 글에 나온 것같은 문법이 있으려나…