OOP를 지향하기 위해서
작은 시도? 랄 수 있는 몇 가지 팁을 정리해봤습니다.
이미 OOP를 잘 구상하고 계신 분들이라면 숙지하고 있는 내용일 테지만
아직 OOP를 어려워하는 분들에게는 자그마한 이끌림이 되지 않을까 합니다.
1. parent, root 는 절대 사용금지.
없는 셈 치십시오.
OOP의 기본 원칙은 "재사용"과 "확장"인데 parent라 함은
OOP의 기본 관점인 "나"를 벗어난다는 뜻입니다.
하나의 클래스는 자기만 잘하면 됩니다.
내가 아닌 내 부모의 무언가를 참조하면 안된다는 것이지요.
부모의 무언가를 사용해서 움직이는 객체라면
부모가 바뀌면 못 쓰겠죠?
바로 그겁니다.
재사용할 수 없다는 뜻이지요.
parent를 써서 가져오던 값이나 함수는
이벤트나 메소드를 통해서 전달을 받으세요.
그러면 한결 OOP스러워집니다.
2. 클래스하나만 따로 예제로 만들어보세요.
지금 만드는 프로젝트에서 사용해야만 테스트 할 수 있다면
실패한 클래스입니다.
따로 예제를 만들어서 한 클래스만 테스트할 수 있도록 만들어 보십시오.
만들어진다면 그게 바로 재사용한 겁니다.
그만큼 튼튼한 클래스라는 이야기지요.
그리고 그렇게 만든 예제는 꼭 따로 저장해놓으시구요~
3. 다른 사람이 만든 클래스를 사용해보십시요.
잘하는 사람의 클래스를 사용해보라는게 아닙니다.
성공에서 배우는것보다 실패에서 배우는게 더 많은 법입니다.
이제 막 뭐 만들어보고 카페나 블로그에 올린 사람들의 소스를 보고
클래스를 만들었다면 그 클래스를 사용해보십시요.
뭐가 불편한지 왜 난 저 클래스를 어떻게 쓰는지 모르는지...
곰곰히 생각해보고 자신의 클래스를 되돌아 보는게 도움이 많이 됩니다.
4. 내 클래스를 다른 사람에게 사용해보게 하세요.
내가 짠 코드는 내가 볼땐 완벽합니다.
그러나 다른 사람이 볼때는 그렇지 않을수도 있습니다.
원래 버그는 모르는 사람이 더 잘 찾아냅니다.
내가 만든 클래스를 다른 사람에게 사용해보라고 부탁해보고
어디서 버벅대는지
어느 메소드를 잘못쓰는지
변수나 메소드 명을 잘못 이해하지 않는지 살펴보세요.
정말 큰 힘이 됩니다.
5. 내 클래스에 public 이 몇번이나 쓰였나 확인해보세요.
public 변수나 메소드가 많다는 것은 원래는 역할이 많다는 뜻이겠지만
사실상 public 메소드가 많을 수록 그 클래스는 "구려"지기 마련입니다.
구린 클래스는 쓰기도 힘들고 뭐하나 하려면 메소드 찾기도 복잡하죠.
public 메소드를 최대한 줄여보십시요.
getWidth() 와 getVisibleWidth() 메소드는
getWidth( visibleArea: Boolean = false ) 로 합칠 수 잇겠죠?
이런식으로 최대한 줄이다보면 어떤 식으로 public 을 구성해야되는지 감이 잡힐 겁니다.
6. public 변수, 메소드에는 약어를 쓰지 마세요.
strN, getSN(), appVer, n_part
무슨 변수, 메소드인지 아시겠어요?
모릅니다. 써놓은 저도 모르거든요 -_-+
내부에서 쓰는 메소드야 주구장창 특수문자로 하건, 한글로 하건 잘 돌아만 간다면 문제가 없겠죠.
그러나 public 으로 열어놓은 변수나 메소드는 나를 위한게 아니라
나를 사용하게될 다른 사람을 위한 것들입니다.
그렇기 때문에 다른 사람도 알아들을 수 있는 메소드명을 써야된다는 것이죠.
numberToString, getSerialNumber(), applicationVersion, numberOfPart
라고 풀어쓰면 누가 보더라도 알 수 있겠죠.
7. 내가 만든 클래스를 extends 해서 다른 클래스를 만들어보세요.
이건 "확장성"과 관련될수도 있지만
사실 제가 말씀드리고 싶은건
자신이 만든 클래스에 대한 검증절차입니다.
확장해서 사용하는데 큰 불편함이 없다면 잘만든 클래스입니다.
하지만 확장해서 사용하려면 이런 저런 값들이 바뀌어야 되는데
private 으로 숨겨져 있거나
값이 메소드안에 묶여있어서 바꿀수가 없다거나 하면
확장하기 편하지 않은 메소드라는 뜻이 됩니다.
이런 메소드가 있다고 예를 들면
이렇게 바꿔준다면 확장하는 클래스에서는 a, b 값만 바꿔주면 되겠지요.
요론게 확장입니다.
자신의 메소드중에서 이렇게 수정할 수 있을만한게 없을까 살펴보세요~
8. 억지로 어렵게 짜려고 하지 마세요.
고수들의 코드를 보면 막 알 수 없는 공식들과
메소드들, 특이한 표현들을 보면 막 멋져보이고
뭔가 있어보이고 그렇잖아요 그죠?
근데 절대 나한테는 좋은게 아닙니다.
그러한 것들은 "코드유희"라고 합니다.
무언가를 구현하는데 있어서 조금더 빠르고
조금 더 효율을 높이기 위해서 짜는 코드들이거나
좀 특이하고 개성있는 코드를 만들어보기 위한 코드들입니다.
대표적인게 Proxy 클래스나 Dictionary 클래스를 남발하는 경우죠.
물론 정확한 용도야 있지만 멋있어보이려고 쓰는 경우가 대부분입니다.
Proxy 클래스가 얼마나 느린데요 -_-+
이러한 코드들은 이해나 사용성을 위한 코드들이 아닙니다.
우리가 코드를 짜면서 퍼포먼스를 추구한다는것은
정말 대단한 과욕입니다.
퍼포먼스를 추구하려면 프로젝트 성격자체가 퍼포먼스가 매우 중요하거나
모든 Flash API를 자기 수족처럼 부릴 수 있을때에야 퍼포먼스를 추구할 수 있는 것입니다.
공부하는 입장에서 괴짜코드 흉내내면
정말 돌이킬 수 없는 습관을 가지게 될 수도 있습니다.
정석대로 하십시요 ㅎㅎ
가장 좋은 예제는 F1의 예제들입니다.
도움이 좀 되실려나 모르겠네용.
3.0을 처음 익히는데 여러가지 어려운 용어들때문에 고초를 겪는 분들이나
OOP를 공부하고 싶은데 딱히 답이 안보이는 분들에게
도움을 드리고자 쓴 글입니다.
저도 공부하면서 느꼈던거라 심히 공감되시는 분들도 있으리라 예상합니다^^
하지만 무엇보다 중요한건 시간을 길게보고 욕심내지않고
하나씩 차근차근 내것으로 만들어나가는게 중요합니다.
너무 고수들의 코드나 오픈소스 코드를 보고 따라하면서
공부하려면 토나옵니다.
...
...
...
...
...
...
이렇게요...
작은 시도? 랄 수 있는 몇 가지 팁을 정리해봤습니다.
이미 OOP를 잘 구상하고 계신 분들이라면 숙지하고 있는 내용일 테지만
아직 OOP를 어려워하는 분들에게는 자그마한 이끌림이 되지 않을까 합니다.
1. parent, root 는 절대 사용금지.
없는 셈 치십시오.
OOP의 기본 원칙은 "재사용"과 "확장"인데 parent라 함은
OOP의 기본 관점인 "나"를 벗어난다는 뜻입니다.
하나의 클래스는 자기만 잘하면 됩니다.
내가 아닌 내 부모의 무언가를 참조하면 안된다는 것이지요.
부모의 무언가를 사용해서 움직이는 객체라면
부모가 바뀌면 못 쓰겠죠?
바로 그겁니다.
재사용할 수 없다는 뜻이지요.
parent를 써서 가져오던 값이나 함수는
이벤트나 메소드를 통해서 전달을 받으세요.
그러면 한결 OOP스러워집니다.
2. 클래스하나만 따로 예제로 만들어보세요.
지금 만드는 프로젝트에서 사용해야만 테스트 할 수 있다면
실패한 클래스입니다.
따로 예제를 만들어서 한 클래스만 테스트할 수 있도록 만들어 보십시오.
만들어진다면 그게 바로 재사용한 겁니다.
그만큼 튼튼한 클래스라는 이야기지요.
그리고 그렇게 만든 예제는 꼭 따로 저장해놓으시구요~
3. 다른 사람이 만든 클래스를 사용해보십시요.
잘하는 사람의 클래스를 사용해보라는게 아닙니다.
성공에서 배우는것보다 실패에서 배우는게 더 많은 법입니다.
이제 막 뭐 만들어보고 카페나 블로그에 올린 사람들의 소스를 보고
클래스를 만들었다면 그 클래스를 사용해보십시요.
뭐가 불편한지 왜 난 저 클래스를 어떻게 쓰는지 모르는지...
곰곰히 생각해보고 자신의 클래스를 되돌아 보는게 도움이 많이 됩니다.
4. 내 클래스를 다른 사람에게 사용해보게 하세요.
내가 짠 코드는 내가 볼땐 완벽합니다.
그러나 다른 사람이 볼때는 그렇지 않을수도 있습니다.
원래 버그는 모르는 사람이 더 잘 찾아냅니다.
내가 만든 클래스를 다른 사람에게 사용해보라고 부탁해보고
어디서 버벅대는지
어느 메소드를 잘못쓰는지
변수나 메소드 명을 잘못 이해하지 않는지 살펴보세요.
정말 큰 힘이 됩니다.
5. 내 클래스에 public 이 몇번이나 쓰였나 확인해보세요.
public 변수나 메소드가 많다는 것은 원래는 역할이 많다는 뜻이겠지만
사실상 public 메소드가 많을 수록 그 클래스는 "구려"지기 마련입니다.
구린 클래스는 쓰기도 힘들고 뭐하나 하려면 메소드 찾기도 복잡하죠.
public 메소드를 최대한 줄여보십시요.
getWidth() 와 getVisibleWidth() 메소드는
getWidth( visibleArea: Boolean = false ) 로 합칠 수 잇겠죠?
이런식으로 최대한 줄이다보면 어떤 식으로 public 을 구성해야되는지 감이 잡힐 겁니다.
6. public 변수, 메소드에는 약어를 쓰지 마세요.
strN, getSN(), appVer, n_part
무슨 변수, 메소드인지 아시겠어요?
모릅니다. 써놓은 저도 모르거든요 -_-+
내부에서 쓰는 메소드야 주구장창 특수문자로 하건, 한글로 하건 잘 돌아만 간다면 문제가 없겠죠.
그러나 public 으로 열어놓은 변수나 메소드는 나를 위한게 아니라
나를 사용하게될 다른 사람을 위한 것들입니다.
그렇기 때문에 다른 사람도 알아들을 수 있는 메소드명을 써야된다는 것이죠.
numberToString, getSerialNumber(), applicationVersion, numberOfPart
라고 풀어쓰면 누가 보더라도 알 수 있겠죠.
7. 내가 만든 클래스를 extends 해서 다른 클래스를 만들어보세요.
이건 "확장성"과 관련될수도 있지만
사실 제가 말씀드리고 싶은건
자신이 만든 클래스에 대한 검증절차입니다.
확장해서 사용하는데 큰 불편함이 없다면 잘만든 클래스입니다.
하지만 확장해서 사용하려면 이런 저런 값들이 바뀌어야 되는데
private 으로 숨겨져 있거나
값이 메소드안에 묶여있어서 바꿀수가 없다거나 하면
확장하기 편하지 않은 메소드라는 뜻이 됩니다.
|
이런 메소드가 있다고 예를 들면
|
이렇게 바꿔준다면 확장하는 클래스에서는 a, b 값만 바꿔주면 되겠지요.
요론게 확장입니다.
자신의 메소드중에서 이렇게 수정할 수 있을만한게 없을까 살펴보세요~
8. 억지로 어렵게 짜려고 하지 마세요.
고수들의 코드를 보면 막 알 수 없는 공식들과
메소드들, 특이한 표현들을 보면 막 멋져보이고
뭔가 있어보이고 그렇잖아요 그죠?
근데 절대 나한테는 좋은게 아닙니다.
그러한 것들은 "코드유희"라고 합니다.
무언가를 구현하는데 있어서 조금더 빠르고
조금 더 효율을 높이기 위해서 짜는 코드들이거나
좀 특이하고 개성있는 코드를 만들어보기 위한 코드들입니다.
대표적인게 Proxy 클래스나 Dictionary 클래스를 남발하는 경우죠.
물론 정확한 용도야 있지만 멋있어보이려고 쓰는 경우가 대부분입니다.
Proxy 클래스가 얼마나 느린데요 -_-+
이러한 코드들은 이해나 사용성을 위한 코드들이 아닙니다.
우리가 코드를 짜면서 퍼포먼스를 추구한다는것은
정말 대단한 과욕입니다.
퍼포먼스를 추구하려면 프로젝트 성격자체가 퍼포먼스가 매우 중요하거나
모든 Flash API를 자기 수족처럼 부릴 수 있을때에야 퍼포먼스를 추구할 수 있는 것입니다.
공부하는 입장에서 괴짜코드 흉내내면
정말 돌이킬 수 없는 습관을 가지게 될 수도 있습니다.
정석대로 하십시요 ㅎㅎ
가장 좋은 예제는 F1의 예제들입니다.
도움이 좀 되실려나 모르겠네용.
3.0을 처음 익히는데 여러가지 어려운 용어들때문에 고초를 겪는 분들이나
OOP를 공부하고 싶은데 딱히 답이 안보이는 분들에게
도움을 드리고자 쓴 글입니다.
저도 공부하면서 느꼈던거라 심히 공감되시는 분들도 있으리라 예상합니다^^
하지만 무엇보다 중요한건 시간을 길게보고 욕심내지않고
하나씩 차근차근 내것으로 만들어나가는게 중요합니다.
너무 고수들의 코드나 오픈소스 코드를 보고 따라하면서
공부하려면 토나옵니다.
...
...
...
...
...
...
이렇게요...
'Adobe AIR > AIR 강좌' 카테고리의 다른 글
Flash 개발자가 갖춰야할 능력 (32) | 2009.07.18 |
---|---|
[펌] UXD(User eXperience Design)란? (17) | 2009.06.29 |
Adobe Labs의 Stratus 포스팅 번역 - 1/2 (12) | 2009.01.28 |
[기술문서] AIR로 할 수 없는 것들 (11) | 2009.01.21 |
[AIR, 번역] AIR 개발자가 흔히하는 실수 10가지 (23) | 2008.08.25 |