제가 만든게 웹상에 돌아다니니까 신기하네요.. 지돌스타님이 손봐주신거지만.. ㅋㅋ
http://webnoon.net/entry/플레시-Actionscript-30-10만개-파티클-테스트-mouseX의-비용-체험
| 3D 농구게임 - 플래시 (2) | 2010/10/20 |
|---|---|
| 유머나라에 올라간 예전에 만들었던 플래시 (2) | 2010/07/23 |
| Actionscript 3 - 읽기쉬운 프로그래밍 하기 (2) | 2010/07/08 |
| 플렉스로 만든 웹기반 그래픽 저작 툴 – Sumo Paint (2) | 2010/07/03 |
택배아저씨는 언제나 책을 마당에 휙~ 던져버리시곤 한다. 가뜩이나 먼길 오느라 고생했을텐데 마지막까지…ㅡㅡ;
Away3D 엔진을 제대로 활용하려면 모델링하는 방법도 공부해야하는데.. Max도 한번..
| Begginning Android Games-안드로이드 게임 개발서 (0) | 2011/06/24 |
|---|---|
| 3D in Flash 도착 (4) | 2010/07/12 |
| 켄트 벡의 구현패턴 (0) | 2010/06/26 |
| 데이터 통신과 네트워킹 (3) | 2010/06/19 |
Actionscript 3 로 만든 프로그램을 이해하기 위해서는 프로그램의 수행흐름을 따라가야 합니다. 즉, 머리속에 현재 프로그램의 수행상태, 제어흐름, 데이터 흐름등을 파악하고 있어야 합니다.
저는 플래시 프로그래밍을 하다보면, 이벤트 모델의 사용으로 인해 수많은 함수 분기가 일어나서 나중에 그 프로그램을 다시 보았을때 수행흐름을 파악하는데 어려움을 겪었습니다.
즉, 제가 원했던 것은 아래와 같은 수행흐름을 이해하기 편한 표현방법 이었다면,
실제로는 아래와 같이 되는게 일반적이였습니다.
이렇게 되면 구현내용을 일일이 파악해야지 이 프로그램이 무엇을 하는것인지 이해가 가능할것입니다.
이런 어려움을 겪고 있던 저는 얼마전 구세주와 같은 해결방법을 보게되었습니다. 바로 hika님이 포스팅 하신 “Message Queueing 서비스” 라는 포스트입니다. hika님이 알려주신 팁을 적용하면, 위와 같은 문제점은 대략 아래와 같이 해결가능해졌습니다.
(위에 예를든 프로그램과 별개입니다. 헷갈리실수도 ^^;) 아래는 디버그 결과입니다.
init 함수 안에 이 프로그램에 대한 수행흐름을 모두 나타낼수 있었습니다. 이로써 자세한 구현사항을 파악하지 않아도 이 프로그램이 무엇을 하는 프로그램인지 보다 쉽게 이해가 가능해진것 같습니다.
p.s - 제목은 마치 읽기쉬운 프로그래밍을 할수 있는 방법을 제시할것처럼 해놓았지만 결국은 “Message Queueing 서비스”에 대한 저의 감상문 정도의 글이 였습니다. ^^; 개인적으로 이런 훌륭한 팁을 마구마구 알려주시는 hika님께 매우 감사드린다는… 아무튼, 보다 구체적이고 원론적인 내용을 원하시는 분들은 위에 언급한 포스트를 읽어보세요.
| 유머나라에 올라간 예전에 만들었던 플래시 (2) | 2010/07/23 |
|---|---|
| Actionscript 3 - 읽기쉬운 프로그래밍 하기 (2) | 2010/07/08 |
| 플렉스로 만든 웹기반 그래픽 저작 툴 – Sumo Paint (2) | 2010/07/03 |
| 플래시의 uint 표현방법 (0) | 2010/06/29 |
웹기반 소프트웨어에 대한 자료를 조사하던중 플렉스로 제작된 그래픽 저작툴을 발견하였습니다. 아무래도 포토샵에 비해서는 기능이 부족해보이지만 플렉스로 이런 소프트웨어를 만들었다는 자체가 저에게는 놀랍기만 하네요.
Sumo Paint는 보시는 바와같이 무료는 아니지만 Try Online 버튼을 클릭하시면 테스트하실수 있습니다. 아래는 테스트 화면입니다.
| Actionscript 3 - 읽기쉬운 프로그래밍 하기 (2) | 2010/07/08 |
|---|---|
| 플렉스로 만든 웹기반 그래픽 저작 툴 – Sumo Paint (2) | 2010/07/03 |
| 플래시의 uint 표현방법 (0) | 2010/06/29 |
| Actionscript Project 로 Air 프로그래밍 하기 (0) | 2010/06/26 |
위의 클래스 다이어그램은 리팩토링 하기전의 클래스 다이어그램 입니다. 언뜻보기에는 문제가 없어보이지만, AlphaStyleSoftJob과 AlphaStyleHard 클래스에서 AlphaStyle에 관한 코드가 있을듯 합니다. 또한 BetaStyleSoftJob과 BetaStyleHardJob도 마찬가지로 BetStyle에 관한 코드가 있을것 같습니다.
이러한 것을 리팩토링에서는 {중복된 코드}라는 코드의 악취라고 합니다.
중복이 발생하게 되면 유지보수 단계에서 많은 비용이 발생하게 됩니다. 위의 예로, AlphaStyle에 대한 속성값을 변경할라치면 AlphaStyleSoftJob과 AlphaStyleHardJob이라는 두개의 클래스 모두 변경이 필요합니다.
“켄트 벡의 구현 패턴” 에서는 위와 같은 중복을 없애는 한가지 방법으로 프로그램을 여러가지 작은 부분 – 짧은 구문, 짧은 메소드, 작은 객체, 작은 패키지 – 으로 나누라고 하고 있습니다.
위의 클래스 다이어그램에서 보이는 하위 클래스 AlphaStyleSoftJob에는 두개의 개념이 포함되어 있습니다. 이러한 부분을 두가지 개념으로 나누어서 개념의 중복을 없애 보면, Style과 Job 으로 나눌수 있을것 같습니다.
이렇게 나누어진 개념으로 다시 상속구조를 다이어그램으로 나타내어 본것은 아래와 같습니다.
위와 같은 구조에서는 대부분의 코드 변경이 지역적으로 일어날 것을 알수 있습니다.
| 중복을 최소로 하는 프로그래밍 하기 (4) | 2010/07/01 |
|---|---|
| CDATA !? (0) | 2009/04/22 |
 재미를 넘어서자 by 웹눈 |
||
|
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
