우선 핸들은 손잡이를 뜻한다 그리고 핸들링은 손잡이를 돌리는것이고 그래서 핸들러는 손잡이를 돌리는 객체 정도로 정의 할 수 있다.
예를 들어 식당이 있다고 생각해보자. 식당에는 대표적인 직업들로 요리사, 웨이터, 매니저가 있다. 여기서 요리사라고 하면 요리하는 사람, 웨이터는 음식을 대접하는 역할을 한다. 하지만, 매니저는 식당에 관심을 두지않는 사람이라면 어떤 역할을 수행하나 고민하게 된다.
사실 매니저를 핸들러라고도 부르기도한다. 매니저는 식당을 운영을 하는 직업이며, 요리사와 논의후 식자재를 조달하고,직원들에게 알맞은 월급 분배와 고객의 데이터들을 관리하기도 한다.
이러한 식당을 코드로 만든다.
class 식당
{
Chef chef;
Waiter waiter;
Handler handler;
Frige* frige;
Cookwares* cookwares;
};
위처럼 식당이라는 객체에 객체들을 만들었으면 냉장고의 재고관리나 필요한 도구들을 구입해야한다. 만약 이 과정을 요리사나 웨이터가 한다면 자신의 일이 아니기 때문에 서로에게 책임전가 하거나 고용인에게 불만을 늘어 놓을 것 이다.만약 매니저(핸들러)가 있다면 그가 식당의 핸들을 잡고 잘 운영할 수 있을것이다. 그러한 느낌을 주는 코드들로 예를 들어보면,
void 식당::재료구입(상점& market)
{
market.buy(handler);//핸들러는 구매목록를 구입해서 개인 장바구니에 담을것이다.
Item* items = handler.pull_items();//구입한 물건들을 얻을수 있을것이다.
frige.push(items);
cookwares.push(items);
};
이부분에서 마켓 입장이 될 필요가 있다. 왜냐하면 여러가지 API를 사용할때 대부분의 프로그래머는 핸들러를 만든다는 입장이 아닌 핸들러를 사용하는 입장이기 때문이다.
//만약 윈도우 API라면 창을 띄우길 원하듯이 돈을 위한 핸들러를 다룰것이다.
void 상점::구입(매니저* handler)
{
//핸들러를 매게변수로 받는 코드는 콜백 함수일 경우가 크다.
Money money = handler.see_market([](ItemInfo& iteminfo)
{//스스로 물건을 찾도록 매니저는 람다함수를 원한다.
return new_item(iteminfo);//창고든 진열장이던 꺼내서 줄것이다.
});
safe.push(money);
}
대부분의 핸들러는 이러한 느낌이고 크게 벗어나지 않는다. 만약 Button의 핸들이라면 버튼의 속성이나 상태를 핸들링 할 수 있는 객체일 것 이고 Button의 핸들러 라면 Button의 매니저를 의미하는 객체이다.
핸들을 처음 접할때 헷갈리는 이유는 객체지향 규칙에 의해 만들어진 개념이며 따라서 추상적이다. 딱딱한 프로그래밍 언어로 추상적인 개념을 얻기에는 익숙하지 않은 사람들에게 빠른 이해는 힘들것이다.
하지만 세탁기, TV, 전자레인지를 이용하는 것처럼 핸들러를 이용하다보면, 가전제품의 공통적인 특징을 알듯 쉽게 이용할 수 있다.