BLOG main image
분류 전체보기 (92)
Cocoa Touch (11)
Cocoa (10)
Objective-C (13)
Swift (6)
Development (11)
Tools (11)
Books (7)
etc (21)
Application release (1)
Document Project (1)
106,256 Visitors up to today!
Today 14 hit, Yesterday 5 hit
daisy rss
tistory 티스토리 가입하기!
'2014/04'에 해당되는 글 3건
2014. 4. 25. 13:49

일전에 Objective-C의 property dot notation이 디미터의 법칙을 어기기 쉽게 만드는 특성이 있다고 (오버스럽게) 쓴 글이 있었는데 조금 더 이야기를 해볼 만한게 있어 포스팅 합니다.


일단, 그 글을 안 읽으신 분은 읽었다고 계속 이야기를 진행합니다.


하지만 디미터의 법칙은 클래스에만 적용되고 자료구조에는 적용되지 않는다(Clean Code)는 말이 있습니다.

즉 이 말을 Objective-C에 적용하자면 공개된 자료구조는 "."으로 쭉 붙여써도 괜찮다는 말 처럼 들립니다.

약간의 논란의 여지가 있겠군요. 여기서 "자료구조"라는 말의 해석에 따라 이야기가 많이 달라질 듯 합니다.


여기서 말하는 자료구조란 거의 C struct같은 느낌일텐데요, Objective-C를 제대로 쓰게되면 struct대신 Class를 만들게 될것이고 맴버 변수를 모두 public으로 하거나 property로 처리하게 되겠지요.

이런 상황이라면 이 객체는 거의 자료구조라고 판단해야 할듯 합니다.

하지만 이것을 일반 클래스와 구분 짓기는 쉽지 않은듯 하고요, 실제로 그렇게 자료구조 표현으로만 Class를 잘 만들지 않게 되지요. (하지만 그렇게 하는게 좋다고는 하는군요!!)

결국 자료구조와 클래스의 짬뽕구조가 되어버리는데 이것이 안좋다고는 합니다만, 데이터와 로직을 분리하다보면 또 수많은 클래스들이 만들어지겠지요.


이래저래 "이것이 정답이다!"라고 확신이 서지 않는데요, 이런 부분에 대해서 경험 많은 분들은 어떤 조언을 해줄지 궁금하네요. 이럴 땐 정말 비행기표 끊어서 밥 아저씨를 만나러 가보고 싶어지는군요.


하지만 여기서 중요한건 그래도 여전히 property를 접근하기 위해서 "."을 쓰는건 여전히 마음에 들지 않는답니다. 특히  "."으로 chain을 만들어놓은 코드를 보면 돌아버릴 것 같습니다.

Name
Password
Homepage
Secret
2014. 4. 25. 13:35

프로젝트를 진행하면서 은근히 Class Cluster 객체를 상속받아 사용하는 경우가 많았는데 치명적인 문제점을 만났습니다.

다름이 아니라 NSKeyedArchiver를 통해 archiving한 객체를 NSKeyedUnarchiver를 통해 decode하면 상속받은 오브젝트로 만들어지지 않고 superclass의 오브젝트로 만들어지는군요.


즉, NSArray를 상속받아 MyArray를 만들었는데 그것을 인코딩/디코딩하면 결과물이 NSArray로 나옵니다. (헛)


일단 방법이 없나 찾아봤는데 아직은 뾰족한 방법을 찾지 못했습니다. (뭔가 있을것 같기는 한데 말이죠.)

시간을 두고 방법이 있는지 계속 확인은 해보겠지만... 현재로서는 조금 회의적입니다.

만일 정말 방법이 없다면... Class Cluster객체의 상속을 조금 자제해야 할 것 같습니다. T_T

Name
Password
Homepage
Secret
2014. 4. 14. 23:03


Objective-C가 계속 발전하면서 오랫동안 Objective-C를 개발하던 사람들에게는 눈에 거슬리는 문법이 하나 있는데 이름 하여 property dot notation이다.

주변에 꽤 오래된 (10년 정도) Objective-C 개발자들(그래 봐야 몇 안되지만)에게 물어보면 대체로 property dot notation에 대해서 부정적이었다.

그들의 생각을 속속들이 모두 들어보지 않았기 때문에 모두들 어떠한 이유로 그런 생각을 가지고 있는지는 모르겠지만 내가 주장하는 큰 이유는 아래와 같다.


1. dot notation을 사용하는 property는 마치 public 변수와 같은 느낌을 준다.

당연히 public 변수는 아니지만 그런 느낌으로 사용되는 것은 부정할 수 없으리라 생각한다. OOP에서 그런것이 그렇게 남발되어서는 안된다고 생각한다. 모든 죄악의 근본이다.


2. message sending syntax의 일관성을 해친다.

뭐 반드시 코드가 일관성을 가져야 하는가에 대해서 강하게 주장하지는 못하겠지만 깔끔하게 정리된 느낌을 주지 못하는 것은 사실이다.


3. Law of Demeter를 너무 쉽게 어기게 만든다.

C++이나 Java같은 언어에서도 메시지 체인은 피해야 할 코딩 습관인데 Objective-C에서도 너무 쉽게 메시지 체인을 만들어 버리게 한다. 물론 dot notation이 아니라도 메시지 체인을 만들 수 있지만 아무래도 매우 번거롭고 보기만 해도 위압적이다. 그러므로 잘 안하게 된다.


결국 1, 3번은 1번이 원인이고 3번이 결과인 셈인것 같다. 여튼 이 주장의 근거로 삼기에 강력한 순으로 따지자면 3, 1, 2쯤 될것 같기도 하고 보는 이에 따라 1, 3, 2쯤 될것 같기도 하고…


이쯤되면 이런 주장이 나올법하다.

“결국 문법은 문법일 뿐 그렇게 사용하지 않으면 괜찮지 않은가? []을 사용하는 메시지 전달 방식도 결국 하기에 따라 동일하지 않은가?”


뭐 맞는 말이다. 하지만 좀 많이 어거지로 같다붙이자면 언어는 사고를 지배한다(사피어-워프 가설. 이런데 갖다 붙이기엔 좀…).

프로그래밍도 근본적으로 언어를 이용하여 컴퓨터의 동작을 기술한다는 점에서 언어를 사용하는 것과 동일 선상에 놓고 볼 수 있을것 같은데 프로그래밍에 사용하는 언어, 그리고 그 언어를 사용하는 습관이 전체적인 애플리케이션의 구조와 동작 방식에 영향을 준다고 생각한다.

즉, 메시지 체인을 만들기 쉬운 문법을 제공하면 그만큼 메시지 체인을 만들 확률이 높아질 수 밖에 없다고 생각한다. 마치 public변수 처럼 사용하기 쉬운 문법을 제공하면 그렇게 코딩하게 된다.


그래서 결론은… 조금 귀찮더라도 dot notation을 사용하지 않고 한번 작업을 해보라고 권해보고 싶다.

어떻게 될것 같냐고?


조금 더 귀찮지만 훨씬 괜찮은 코드가 되어 있을 것이라 생각한다.


Name
Password
Homepage
Secret
prev"" #1 next