일단 컴포넌트를 개발할 때는 서비스 만들 때와 같이 누가 어떻게 사용할 지에 대한 target이 필요해.
이게 결정되어야 API수준이 결정되거든 예를 들어, 누구나 쉽게 사용하는 컴포넌트라면 기능이 별로 없고 특정 상황에서 바로 동작하는 수준으로 API을 디자인해야 하고, core 컴포넌트는 자세히 접근해서 사용할 수 있도록 디자인을 해야 하는게 좋다.
물론 대부분은 core컴포넌트가 있고 이를 바탕으로 쉽게 사용할 수 있는 컴포넌트를 만든다.
core컴포넌트는 자신의 역활이 뚜렷하게 가지는게 좋아.
현재 너가 만든 컴포넌트를 보면, AudioHelper에는 주파수를 분석하고 graph도 그리고 버튼을 만드는 역활도 한다.
이를 좀 나누는게 좋을 것 같아. 주파수를 분석하는 역활을 하는 객체, graph을 그리는 객체, 버튼을 만드는 객체.
이렇게 나누면 좀 더 코드를 개발하기가 좋고 버그가 발견될 때 좀 더 디버깅하기가 쉽다.
이렇게 3개를 만들고 각각을 사용하여 사용자들이 사용하는 AudioHelper같은 객체가 있는거지.
그리고 각 객체를 직접 통신하기 보다는 이벤트로 통신하는게 의존도를 낮추고(event emitter pattern을 활용), 또한 컴포넌트에서는 가능하면 엘리먼트를 안에서 만들기 보다 제어하는 API을 만들고 이를 활용하는게 좀 더 의존도를 낮출 수 있어.
그 다음에 사용자는 어떻게 사용할지 API을 가상으로 만들어보면 좋다.
이 때 사용자는 어떤 경우에 사용할지를 생각해보면 자연스럽게 API을 만들 수 있어.
예를 들어,
나는 오디오 객체를 넣고 실행하면 기본으로 그래프를 그려주고
그래프의 모습등은 커스텀하게 제어하고 싶고
실행하고, 잠시 멈추고, 다시 실행하기 가능하면 좋을 것 같아.
var audioHelper = new AudioHelper(audio);
// 그래프를 그릴 때.
audioHelper.on("beforePaintGraph",function(e){
e.stop() // 기본으로 동작하는 그림을 막고
customPaintGraph(e.frequency);// 내가 원하는 그림을 그리고
});
document.getElementById("stop").addEventListener("click",funtion(){
audioHelper.stop();
});
document.getElementById("run").addEventListener("click",funtion(){
audioHelper.run();
});
일단 컴포넌트를 개발할 때는 서비스 만들 때와 같이 누가 어떻게 사용할 지에 대한 target이 필요해. 이게 결정되어야 API수준이 결정되거든 예를 들어, 누구나 쉽게 사용하는 컴포넌트라면 기능이 별로 없고 특정 상황에서 바로 동작하는 수준으로 API을 디자인해야 하고, core 컴포넌트는 자세히 접근해서 사용할 수 있도록 디자인을 해야 하는게 좋다.
물론 대부분은 core컴포넌트가 있고 이를 바탕으로 쉽게 사용할 수 있는 컴포넌트를 만든다. core컴포넌트는 자신의 역활이 뚜렷하게 가지는게 좋아.
현재 너가 만든 컴포넌트를 보면, AudioHelper에는 주파수를 분석하고 graph도 그리고 버튼을 만드는 역활도 한다. 이를 좀 나누는게 좋을 것 같아. 주파수를 분석하는 역활을 하는 객체, graph을 그리는 객체, 버튼을 만드는 객체.
이렇게 나누면 좀 더 코드를 개발하기가 좋고 버그가 발견될 때 좀 더 디버깅하기가 쉽다.
이렇게 3개를 만들고 각각을 사용하여 사용자들이 사용하는 AudioHelper같은 객체가 있는거지. 그리고 각 객체를 직접 통신하기 보다는 이벤트로 통신하는게 의존도를 낮추고(event emitter pattern을 활용), 또한 컴포넌트에서는 가능하면 엘리먼트를 안에서 만들기 보다 제어하는 API을 만들고 이를 활용하는게 좀 더 의존도를 낮출 수 있어.
그 다음에 사용자는 어떻게 사용할지 API을 가상으로 만들어보면 좋다. 이 때 사용자는 어떤 경우에 사용할지를 생각해보면 자연스럽게 API을 만들 수 있어. 예를 들어,