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 티스토리 가입하기!
'Development'에 해당되는 글 11건
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
2013. 11. 1. 12:30

예전에 JPS를 Objective-C로 구현했다고 포스팅한 글이 있는데 github에 소스를 공개해놓고 블로깅을 하지 않았군요.


그래서 다시 관련 글을 포스팅합니다. 아래 링크에서 OS X에서 구현한 JPS 소스를 받아보실 수 있습니다.

제대로 사용하지 않아서 버그가 있을 수 있으니 알아서 보시기를...


https://github.com/bearkode/PathFinder


PS. 라이센스를 명시하지 않았는데... 뭐 그리 큰 소스도 아니고... 대충 사용하세요 라이센스쯤 되려나요?

Name
Password
Homepage
Secret
2013. 6. 13. 08:33

2006년을 마지막으로 WWDC와 인연이 없다가 올해 다시 참가하게 되었습니다.

감회가 새롭내요, 반면 그간 WWDC의 문화(?)도 꽤 바뀌었다는 것을 실감하게 됩니다.

뭐 San Francisco의 날씨는 여전하군요.


다행인지 불행인지 뭔가 많이 바뀐 타이밍에 WWDC를 참가하게 된것 같습니다.

언젠가부터 WWDC가 세간의 주목을 받기 시작했고 WWDC가 마치 신제품 발표회나 되는것 처럼 인식되는 요즘인데요, 올해는 신제품도 나왔고 기술적으로도 많은 부분이 추가/개선된 것으로 보여 소비자나 개발자 모두에게 재미있는 행사가 된것 같습니다.

특히 몇몇개의 이슈는 저의 호기심을 잔득 자극하기도 해서 놀러나가고 싶은 마음이 사라지고 있습니다.

다만, 커널쪽에 추가된 몇몇 재미있는 기능들에 대해서는 별도의 세션이 없는 것이 안타까울 따름입니다.


정신없이 세션을 듣는 동안 벌써 수요일 세션도 모두 종료되었군요. 그래봐야 월요일에는 기술적인 깊이 있는 내용이 없으니 화/수 이틀을 제대로 들은 것이라 볼 수 있겠지요.

예전에는 새 버젼의 OS가 발표되어도 크게 관심을 가지지 않고 넘어간 경우가 많았는데 이번에는 집에 컴퓨터를 싹 밀고 매버릭을 설치할까 어쩔까 고민스럽게 만들고 있습니다.

미리 설치해서 테스트해보고 싶은 코드가 너무 많거든요. NDA만 문제가 안된다면 제 블로깅 횟수를 생각하면 한 100년은 블로깅할만한 기술적인 내용이 있습니다. :P


일단 하나씩 공부해가면서 넷상에 해당 기술 내용이 오픈되기 시작하면 슬슬 하나씩 이야기를 해볼까 싶기도 합니다.

(하던거나 마저 다 하고 그런말 해야겠지만요.. 쿨럭..)


박종암 | 2013.06.18 03:47 | PERMALINK | EDIT/DEL | REPLY
재미나게 잘 보셨나요?
요번엔 모처럼 기술적으로 흥미로왔던게 꽤 있었던 것 같습니다.
근데 사용자에게 보여지는 부분에 있어선 실망이 개인적으로 크네요.

평생 프로그래밍은 재미가 있을 줄 알았는데, 요샌 재미가 없어지는 거 같습니다.
예전에도 한국 개발자들 별로 소통이 없었는데, 요샌 더 한거 같기도 하고.
기술적으로 재미있는 블로깅을 하는 사람들도 없고.. 미국인이든 한국인이든..

그럼 잘 지내세요.
maccrazy | 2013.06.18 05:55 신고 | PERMALINK | EDIT/DEL
:) 뭐 그럭저럭 재미있는 내용들이 많았습니다.
사용자에게 보여지는 부분에 있어서 있었던 실망도 기술적인 부분들이 공개되면서 어느정도 희석되었었고요.

프로그래밍 재미있게 하셔야지요. 전 이제 소통 같은건 기대도 안하고요, 그냥 저 혼자 재미로 합니다. ㅎㅎ
박종암 | 2013.06.19 00:35 | PERMALINK | EDIT/DEL | REPLY
회사에서 재미없게 굴어서요.
maccrazy | 2013.06.19 23:21 신고 | PERMALINK | EDIT/DEL
회사에게 본때를 보여줍니다.
Name
Password
Homepage
Secret
2013. 5. 26. 12:34

게임을 제작하다보면 간혹 길찾기 알고리즘을 사용해야 할 때가 있다.

학교에서는 Dijkstra를 많이 가르치는 것 같은데 실제 많이 사용되는것은 A*알고리즘인것 같다.

그런데 문제는 별다른 확인 없이 그냥 맹목적으로 그것을 사용하는 경우가 많은것 같다.

어느 날 갑자기(사실은 갑자기라기 보다는 더 빠른 알고리즘을 찾아봐야 할 필요가 생겼다.) 길찾기 알고리즘에 다른 것이 또 뭐있나 궁금해졌고 JPS(Jump Point Search)를 찾게 되었다.

여기저기 뒤적 뒤적하면서 확인해본 결과 JPS는 A*보다 꽤 많이 빠르다. 다만, 이동의 코스트가 각 grid 마다 다를때 처리가 좀 문제가 될것 같고 최단거리를 찾아주지는 못하는것 같다. 하지만 빠른 속도로 얼핏 봤을때 가까운 길을 찾아주는것 같다. 게임용으로는 최적이라는 판단이 들었다.


그런데 여기서 가장 중요한 문제에 부딪쳤다. Objective-C는 거녕, C/C++로 구현된 코드를 찾기 힘들었다. (C++코드를 하나 찾기는 했지만 수정없이 편하게 쓰기는 거의 불가능했다.)

그래도 비교적 깔끔하게 다른 길찾기 알고리즘과 비교해 볼 수도 있고 코드도 공개된 곳이 있었다.

그런데, 이것도 문제인 것이 코드가 JavaScript다. 정말 산너머 산이라고...


결국... Objective-C로 직접 구현하기로 마음 먹었다. (왜 C로 구현해야지 하는 생각을 안했는지...)

그리고... 얼핏 돌아가는 것 처럼 보이는 코드가 완성되었고 테스트 중이다. (언제 공개할 수 있을려나?)




Name
Password
Homepage
Secret
2011. 3. 30. 23:20
사실 이런 저런 바쁜 일들로 최근에 독서라는 걸 해본지가 까마득 해질려고 하는데, 어쩌다 보니 "생각의 탄생 (로버트 루트버너스타인, 미셀 루트번스타인)"이란 책을 읽기 시작하게 되었다. - 사실 이 책을 손에 쥔지 거의 4달만에 읽기 시작했다.
지금 다 읽은 것도 아니고 이제 겨우 1/10 정도 읽었을까? 답답한 마음에 목차 먼저 쭉 훑어보고 대충 이리 저리 뒤적 뒤적해본 결과 대략의 주제는 파악한듯 하다. 하지만 꼼꼼히 읽어봐야지, 어차피 주말엔 병원에서 보내야 하니...
여튼, 중요한 것은 그것이 아니고 이 책을 읽다보니 문득, 우리가 "관찰"이란 것에 대해서 얼마나 느슨하게 생각을 하고 있었는지 반성하게 되었다.
사실 사고의 시작을 관찰이라고 본다면 어떤 사고의 집합체인 프로그래밍 역시 관찰에서 시작되어야 할텐데 사실 그렇지 못한 경우가 너무나 많았던 것 같아 반성하게 된다.
물론 구현하고자 하는 내용에 대한 관찰도 매우 중요하지만 뭐 그런것 까지 바라지 않더라도 당장 내가 작성한 코드를 "관찰"하는데 얼마나 게을렀던가 반성하지 않을 수 없다.
버그가 발생했을 때 제대로 된 개발자는 사용할 수 있는 거의 모든 방법을 동원해서 그 현상과 결과 그리고 해당하는 코드, 디버거를 이용해서 변수와 콜스택 등등 들여다 볼 수 있는 모든 것들을 관찰해야 하고 그 내용을 기반으로 생각을 만들어 나가야 하는데... 사실 손이 먼저 나간다. (물론 관찰과 사고의 과정들이 너무나 빨리 순식간에 이뤄져서 금방 버그를 고치는 경우도 있지만...)
나도 그렇지만 많은 사람들이 버그의 원인에 대한 관찰과 분석 없이 현상을 틀어막는데 급급하지 않나 싶을 때가 있다. 물론,  시간에 쫒기거나 내용을 이해하기 힘들어서 그렇게 얼렁뚱땅 버그를 묻어버리는 경우가 많다는 것은 알고 있다. (그래, 분명히 나도 그런 적 있다.) 하지만, 이제서야 (뭐 사실 조금 더 오래되긴 했지만) 그런 만행에 대해서 통렬히 반성하고 있다.
역시 사람은 독서를 해야 하나보다. 책을 읽다보니 내가 예전에 무슨 짓을 저질러놨는지 보이니 말이다.
Name
Password
Homepage
Secret
2010. 5. 20. 12:22


아니면 애플의 aurioTouch 샘플

PS. 요즘 블로깅 날로 먹는다.
Name
Password
Homepage
Secret
2010. 5. 12. 11:56

쓸일이 있을것 같아서 간단하게 한번 만들어봤는데... 쓸일이 없을듯 하기도 하고...



#define CROSS_PRODUCT(sPt1, sPt2)   (sPt1.x * sPt2.y - sPt1.y * sPt2.x)



- (BOOL)isCross:(MyLine *)aLine

{

    NSPoint sL1S = [self pt1];

    NSPoint sL1E = [self pt2];

    NSPoint sL2S = [aLine pt1];

    NSPoint sL2E = [aLine pt2];

    NSPoint sV  = NSMakePoint(sL2S.x - sL1S.x, sL2S.y - sL1S.y);

    NSPoint sV1 = NSMakePoint(sL1E.x - sL1S.x, sL1E.y - sL1S.y);

    NSPoint sV2 = NSMakePoint(sL2E.x - sL2S.x, sL2E.y - sL2S.y);

    

    CGFloat sCrossV1V2 = CROSS_PRODUCT(sV1, sV2);

    if (sCrossV1V2 == 0)

    {

        return YES;

    }

    

    CGFloat sCrossVV1 = CROSS_PRODUCT(sV, sV1);

    CGFloat sCrossVV2 = CROSS_PRODUCT(sV, sV2);

    CGFloat sT1       = sCrossVV2 / sCrossV1V2;

    CGFloat sT2       = sCrossVV1 / sCrossV1V2;

    

    if (0.0 <= sT1 && sT1 <= 1.0)

    {

        return YES;

    }

    if (0.0 <= sT2 && sT2 <= 1.0)

    {

        return YES;

    }

    

    return NO;

}



Name
Password
Homepage
Secret
2009. 6. 9. 19:02
This function is equivalent to CFRelease, except that it does not cause an error if the path parameter is NULL.


이 뭥미?
꼭 이렇게 만들어야 했을까? 뭔가 가슴아픈 사연이 있었던 걸까?
assam258 | 2009.06.09 21:42 | PERMALINK | EDIT/DEL | REPLY
이 뭥미?
꼭 이 글을 써야만 했을까? 뭔가 가슴아픈 사연이 있었던 걸까?

copy & paste 가 필요한 시점. 이제 얼마 남지 않았다.
maccrazy | 2009.06.10 11:21 신고 | PERMALINK | EDIT/DEL
어디까지나 제가 까먹지 않기 위한 포스팅입니다. :)
요즘은 살짝 치매끼가 있는지 자꾸 까먹어서요. ㅎㅎ
이규호 | 2009.07.22 13:25 | PERMALINK | EDIT/DEL | REPLY
헐 벌써 치매까정....
박종암 | 2009.08.10 11:33 | PERMALINK | EDIT/DEL | REPLY
이 쓰레드를 타고 제 블로그로 들어온 링크가 보여서 들어와 봤습니다.
근데 다시 생각해보니, 나름대로 좋은 생각인거 같습니다. Cocoa와 Objective-C를 보면, nil object에 대한 method call이 가능하잖아요? 그러니 CGPath에 대한 Cocoa wrapper를 만들때, 아예 Core Graphics 레벨에서 저렇게 가능하게 하면, 편하겠죠. 그래서 저렇게 한게 아닐까 하네요.
Name
Password
Homepage
Secret
2008. 9. 6. 17:18
많은 개발자들에게 가장 유용한 방법론이 뭐였냐고 물어보면 "CCV방법론"이라고 우스개 소리로 대답한다. 이것은 Ctrl-C, Ctrl-V를 지칭하는 것으로 맥에서 같으면 Command-C, Command-V라고 보면 될것 같다. 즉, 소스의 다른 부분을 "베껴다" "붙이는" 방법론(?)인 것이다.
소스의 재사용성을 높이고 귀찮은 타이핑 작업을 줄여준다는 점에서 찬양(?)되는 방법론(?) 중 하나이다.

하지만, 절대로 사용하지 말기를 바란다.

첫번째 이유는 CCV는 중복된 코드를 생성 시킨다. 마틴 파울러의 "Refactoring"을 봐도 소스코드에서 나는 나쁜 냄새의 No 1으로 duplicated code를 꼽고 있고 앤드류 헌트와 데이비드 토머스의 "The Pragmatic Programmer"에서도 많은 분량의 내용이 중복의 해악에 대해서 다루고 있다. 두 책을 보신 분이라면 부연 설명이 없어도 공감하실거라 생각한다.

"The Pragmatic Programmer"에 나오는 중복이 생기는 이유에 대해서 한번 들여다 보자.
  • 강요된 중복 - 개발자들은 다른 선택이 없다고 느낀다. 환경이 중복을 요구하는 것처럼 보인다.
  • 부주의한 중복 - 개발자들은 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한다.
  • 참을성 없는 중복 - 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 중복을 하게 된다.
  • 개발자간의 중복 - 한 팀에 있(혹은 다른 팀에 있는)는 여러 사람들이 동일한 정보를 중복한다.
여기서 말하는 "참을성 없는 중복", 이것이 CCV방법론과 완전히 일치하지 않는가? 중복된 코드는 프로그램을 수정하기 힘들게하고 버그를 키운다. 나는 조금이라도 중복된다 싶은 코드의 경우 일단 다른 중복 되는 부분과 함께 comment로 남겨놓는다. comment 역시 코드에서 나는 "나쁜 냄새"라는 말을 신뢰하는 나로서는 이렇게 해둔 부분은 확실하게 나쁜 냄새를 풍기는 위치가 되고 우선적으로 리팩토링 대상이 된다. 중복이 되는 경우가 생겨도 인지하고 리팩토링 대상으로 올려놓는 과정인 샘이다.

두번째 이유, 만일 내 자신의 코드가 아닌 다른 부분 또는 샘플에서 CCV를 하는 것은 어떤가? 이것 역시 권하고 싶지 않은 방법이다. 보통 이런 코드들은 직접 제작한게 아니다보니 꼼꼼하게 들여다 보지 않게 되고 잘못 사용되는 경우도 종종 발생하며, 버그를 안고 있을 수 있다. 다른 곳에서 잘 돌던 코드가 내 코드와 함께해도 잘 돌 것이라고 단정해서는 안된다. 그래서 나는 CCV로 작업하는 것 보다 조금 불편하더라고 일일이 코드 한줄 한줄을 보고 이해한 후 제대로 쓸려고 노력한다. 스스로 소화시켜내지 못하는 긁어온 소스코드는 나중에 암과 같은 존재가 될 수 있다.

예제코드 없이 한 줄도 코딩 할 수 없는 개발자는 더 이상 개발자가 아니다. 코더일 뿐이다.
박종암 | 2008.09.14 06:42 | PERMALINK | EDIT/DEL | REPLY
Trackback이 안걸리는 거 같네요.
http://jongampark.wordpress.com/2008/09/13/coding-convention-which-is-more-important-than-design-patterns/
littlehj | 2008.09.14 20:47 신고 | PERMALINK | EDIT/DEL | REPLY
허걱....난 Copy & Paste만 하는데.....흑흑흑
maccrazy | 2008.09.15 19:43 신고 | PERMALINK | EDIT/DEL
이건 팀장님 같은 고수한테는 해당되지 않는 내용이지 않나요? :) CCV하셔도 중복된 코드는 안 만드시잖아요. 게다가 다 이해하고 사용하시는 거니까...
littlehj | 2008.09.16 04:58 신고 | PERMALINK | EDIT/DEL | REPLY
아직 똥오줌을 구분못하는 내가 우연찮게 계속 그런 경우에 해당하고 있는건지도....흑흑흑...
근데...티스토리를 통한 이야기를 진행하는 게 재밌네....슬슬 재미가 붙고 있으~ 아이웹을 버려야징....ㅎㅎ
브람스토커 | 2008.09.17 22:55 신고 | PERMALINK | EDIT/DEL | REPLY
예제코드 없이 한 줄도 코딩 할 수 없는 개발자는 더 이상 개발자가 아니다. 코더일 뿐이다... 에궁.. ㅠㅠ
littlehj | 2008.09.18 00:00 신고 | PERMALINK | EDIT/DEL
여기서는 너하고 나를 지칭하는 말이야...흑흑흑....
반성하며 살자.....엉엉
Name
Password
Homepage
Secret
2008. 9. 1. 13:12
이 이슈에서 마틴 파울러도 지적했듯이 변수가 정의된 클래스 안에서는 변수에 직접 접근할지 아니면 accessor를 이용해서 접근할지에 대한 문제는 항상 고민되는 부분이다. 융통성과 편의성, 어떻게 보면 유사한 관점에서 바라보는것 같지만 이 문제에 관해서는 상반되는 양상을 보여주는것 같다.
나는 주로 직접 접근 방법을 선호했지만 가끔 accessor를 통한 간접 접근이 더 나은게 아닌가 하는 의문도 들고 있다.
이전 Refector Tool에 대한 포스팅에서 맴버 변수를 encapsulate 시켰을때 너무 지나치게 간접 접근으로 코드를 생성한다고 투덜댔다. 뭐, 내가 직접 접근 방식을 더 선호하기 때문에 그런 부분이 있었다.
이쯤에서 갑자기 궁금해지기 시작했다. 다른 개발자들은 어느쪽을 더 선호하는 걸까? 각자 리플로 선호하는 방식을 한번씩 써 보는 것은 어떨까 싶다.
홍민희 | 2008.09.01 13:27 | PERMALINK | EDIT/DEL | REPLY
저는 직접 접근 방식을 좋아합니다. 접근자를 쓰는 경우, 대체로 나중에 기능이 추가되어도 인터페이스에 변화를 주지 않기 위해서인데, Python 같은 언어에서는 property 같은 기능이 있어서, 직접 접근 인터페이스를 유지하면서 또다른 일을 할 수 있거든요. 하지만 Objective-C 같이 컴파일이 필요한 언어에서는 조금 생각해볼 문제겠죠.
maccrazy | 2008.09.02 11:31 신고 | PERMALINK | EDIT/DEL
Obj-C도 2.0으로 가면서 property가 지원되죠. 이게 지원되면 직접 접근이냐 간접 접근이냐 고민할 필요가 조금 적어지는것 같네요. 간접 접근을 해도 직접 접근 만큼이나 편해지니까요.
박종암 | 2008.09.03 04:35 | PERMALINK | EDIT/DEL | REPLY
여행에서 돌아온 후 첫 포스트를 답변으로 시작하겠습니다.

저는 그때 그때 적당한 것으로 합니다.
즉, 어떤 클래스의 메소드에서 자체의 variable을 접근할때는 직접 접근 법을 씁니다. 그리고 다른 클래스나 함수에서, 해당 클래스의 변수를 접근할때는 간접적인 방식을 씁니다. Objective-C 2.0에서 비록 property를 넣어주긴 했어도, 전 이 방식을 그대로 쓰려고 합니다.
이유는 code의 readability와 performance때문입니다.
직접 접근을 하면, 아.. 이 클래스의 멤버 변수구나라고 알 수있고, 다른 함수/클래스의 멤버 메소드에서 어떤 클래스에 대한 간접 접근을 하면, 아.. 이건 다른 클래스에 정의된 것이구나를 알 수있게 해 주면서 동시에, 그 변수에 대한 접근법을 모르더라도 투명하게 접근할 수가 있습니다. 또한 그 accessor 함수 내에, access 를 하기 전에 필요한 이런 저런 일들을 해 줄 수가 있죠. 이를테면, 어떤 포인터 변수를 억세스할 때, 제대로 된 값을 가지고 있는지 검사해준다던가.. 그렇게 함으로써 caller측에서도 좀더 깨끗하고, 하고자하는 바에 대해서 촛점이 있는 코딩을 할 수가 있죠. 제가 다루는 회사의 코드는 그런게 너무 잘 안되어 있어서, 이를테면 모션에 대한 함수가 있으면, 아.. 이 함수는 모션에 대해서 이런 일을 하는구나를 알 수가 있어야 하는데, 너무 지엽적인 코드가 많이 붙어 있어, 하다보면 길을 잃게 되더군요. Obj-C 2.0의 프로퍼티를 쓰게 되면, 도대체 직접 접근하는 것인지 아닌지 탁 눈에 들어오지 않고(편하긴하지만), 그리고 결정적으로 pre-10.5 시스템에서 컴파일이 안되죠.

또 하나는 성능에 대한 고려입니다. 간접 억세스는 해당 함수에 대한 stack을 만들고, return 할 위치를 저장해 놓는등, 이러 저러한 작업을 사전에, 혹은 컬 하고 돌아온 후에 해 주게 됩니다.아무래도 성능에 영향이 오죠.

그래서 위의 두가지에 대해서 나름대로 생각해서 그렇게 두가지를 섞어서 쓰고 있습니다.
근데 다들 이렇게 하지 않나요?
maccrazy | 2008.09.03 10:52 신고 | PERMALINK | EDIT/DEL
다른 객체의 맴버를 접근 할 때의 간접 접근은 그다지 이슈가 되지 않을것 같은데 자기 자신의 맴버도 억세서를 이용해서 간접 접근 하는 것이 좋은가에 이야기였습니다. :)
종암님도 자기 맴버 변수는 직접접근 다른 객체의 맴버에 대한 접근은 간접접근을 이용하고 계신것으로 이해되네요.
저도 경우에 따라서는 자신의 맴버도 억세서를 이용해서 접근 하기도 합니다만... :)
han9kin | 2008.09.04 16:55 신고 | PERMALINK | EDIT/DEL | REPLY
저는 가만히 생각해보면 제 편한대로 썼던 것 같습니다. ㅋㅋㅋ
종암님의 의견과 거의 일치하지만 좀 더 확대(?)해서...
자기 클래스내의 멤버변수라도 해당 메쏘드가 그 멤버변수의 추상화범위에 포함되어 있지않으면 accessor를 통한 간접접근을 선호한다라고 할 수 있겠습니다.
하지만, 다시 그 범위의 기준이 뭐냐라고 물으신다면 제 마음대로라는... ㅋㅋ
박종암 | 2008.09.05 00:09 | PERMALINK | EDIT/DEL | REPLY
아.. 그런 경우요. 기본적으론 직접 접근법을 이용합니다. 하지만 그 변수를 억세스하기 전에 공통적으로 뭔가 준비 작업을 해야 하는 경우는 간접 접근법을 이용하고 있습니다.
han9kin님과 같은 거로 보이네요.
Name
Password
Homepage
Secret
prev"" #1 #2 next