이벤트에 대해 알아보자.
이벤트는 이해하기 어렵지 않으니 Delegate에 대한 첫번째 발걸음으로 적합하다.
이벤트는 객체지향 프로그래밍의 가장 기본적인 설계 기법 중 하나라 할 수 있다.
객체지향 프로그래밍의 특징이 여러가지 있지만 그 중 하나가 “재사용성”이다.
재사용성과 이벤트가 무슨 관계가 있을까. 아래 마이클잭슨의 사례로 한번 생각해 보자.
마이클 잭슨 한국에 오다. 100여명의 스탭과 함께.
이제는 고인이 된 마이클 잭슨이 한국에 온 적이 있다. 그가 온다는 것만으로도 울트라 빅빅빅 이슈였지만, 함께 이슈가 되었던 건 100여명의 스탭과 함께 오기 때문에 모셔오는 비용이 어마어마하다는 거였다.
같이 오는 100여명의 스탭 중에는 헤어디자이너, 무대 감독, 음향 감독 뿐 아니라 전용 요리사들도 포함되어 있었다.
여기서 우리는 전용 요리사들에 주목해 보자.
물론 무대 준비를 때문에 예민해진 마이클 잭슨을 위해, 그의 입맛에 맞는 요리를 준비하는 요리사들은 어쩌면 필수일지 모른다. 하지만 이런 개인적인 감정 문제는 다 접어두고 큰 그림만 생각해 보자.
마이클 잭슨이 배가 고프면 밥만 제공해 주면 된다. 마이클 잭슨은 입맛이 까다롭지 않고 주는대로 먹는 착한 어른이니까.
그리고 총괄 스태프는 마이클 잭슨에게 요리사들을 전부 알려주고 배가 고프면 이 요리사들에게 얘기하라고 정해주고 자기는 싹 빠졌다.
이제 마이클 잭슨이 배가 고프면 아래의 프로세스를 따를 거다.
1. 마이클 잭슨이 배가 고프다.
2. 한식이 먹고 싶으면 한식 요리사를, 중식이 먹고 싶으면 중식 요리사를, 양식이 먹고 싶으면 양식 요리사를 찾는다.
3. 배가 고프니 밥달라고 얘기한다.
4. 요리사가 그 요구를 받아들인다.
5. 요리사가 요리를 준비하고 식사를 제공한다.
너무도 당연한 흐름이지만, 객체지향 프로그램을 설계하는 입장에서는 약간 문제가 있어 보인다.
객체지향 프로그래밍을 설계하는 입장에서 가장 문제가 되는 것은 “2번 요리사를 찾는다”이다.
만약 마이클 잭슨이 “나 배고파” 라고 총괄 스태프에서 얘기하면 총괄 스태프가 알아서 요리사를 찾아 음식을 제공해 주는 구조였다면 전용 요리사는 필요하지 않았을 거다.
문제가 되는 건 마이클 잭슨이 특정 요리사를 직접 찾았다는 거다.
위 문제에 대한 객체지향적인 해결 방안은 다음과 같다.
1. 마이클 잭슨이 배가 고프다.
2. 배가 고프다고 하늘에 대고 소리친다.
3. 총괄 스태프가 이 소리를 듣고 한식, 중식, 양식 요리사 들 중 한명을 배정해 음식을 만들어 달라고 요구한다.
4. 요리사가 그 요구를 받아들인다.
5. 요리사가 요리를 준비하고 식사를 제공한다.
둘의 차이를 명확히 알 수 있는가.
배고픈 당사자인 마이클 잭슨이 직접 요리사를 찾는지, 아니면 그냥 하늘에 대고 배고프다고 소리치면 총괄 스태프가 듣고 알아서 상황에 맞는 요리사를 찾아서 일을 시키는지가 가장 큰 차이이다.
마이클 잭슨의 입장에서는 배가 고프면 말할 수 있는 상대가 특정의 몇몇 요리사들 뿐이기 때문에 배가 고플 때를 대비해서 그 요리사들을 데려올 수 밖에 없었던 거다.
배가 고프다고 다른 사람들한테는 얘기할 수 없고 꼭 그 요리사들한테만 얘기하도록 정해져 있기 때문에 그 요리사들을 데려와야만 한다.
이걸 좀더 확대하면, 헤어를 위해 전용 헤어 디자이너, 전용 의상 담당, 구두, 악세사리, 무대, 음향, 기타 등등 마이클 잭슨이 직접 다 찾아서 얘기해야 하기 때문에 마이클 잭슨 한명만 오면 그 모든 스태프들이 다 딸려와야 한다.
그중 한명이라도 없으면 마이클 잭슨은 제대로 된 공연을 할 수 없다.
헤어를 다듬어야하면 하늘에 대고 “나 머리 좀 잘라줘~” 라고 소리치면 총괄 스태프가 이걸 듣고 알아서 한국에서 잘 나가는 헤어 디자이너를 섭외해 머리를 잘라주는 구조였다면 굳이 전용 헤어 디자이너를 미국에서 여기까지 데려오느라 큰 돈을 쓰지 않아도 되었을 거다.
이런 식으로 전부 확대하면 100여명의 스태프가 아니라 1-2명의 총괄 스태프 등 핵심 스태프 몇 명만 같이 왔어도 되었을지 모른다. 그럼 돈도 무지 절약했을텐데.
그런데 우리 프로그래머들도 이렇게 돈을 무지 쓰는 일을 하고 있다.
프로그래머라면 대부분 어떤 프로젝트에서 클래스 하나를 만들어 놓고 와~ 잘 만들었다~ 혼자 감탄하면서 다른 프로젝트할 때도 가져다 쓰기 위해 다른 프로젝트에 던져 놓았더니, 그 클래스 안에서 다른 클래스나 파일들을 요구해서 하나씩 복사해 넣다가 결국은 프로젝트 전체를 다 복사해 넣어야 하는 상황이 발생해서 포기한 경험이 있을거다. ㅋ.
바로 마이클 잭슨과 같은 경우다.
한 클래스에서 다른 클래스를 사용하도록 프로그래밍 하는 경우가 바로 그런 경우다.
물론 대부분 한 클래스에서 다른 클래스를 사용하도록 설계하지만, 어떤 클래스들은 내부적으로 아무런 클래스도 사용하지 않도록 설계되어야 한다.
그래야 다른 프로젝트에서 사용할 때 아무런 문제없이 사용할 수 있다.
이래야 객체지향 프로그래밍의 특징 중 하나인 “재사용성”을 높일 수 있다.
예를 들어 질량 계산을 담당하는 클래스라면 그 클래스의 헤더파일과 구현 파일들만으로 (상속을 받았다면 그 상위 클래스들까지 포함) 모든 기능을 제공해야 한다는 거다.
다른 클래스를 가져다 쓰기 시작하면 그 클래스가 또 다른 클래스를 필요로 하고 그 또 다른 클래스는 또또 다른 클래스를.. 또또또 다른 클래스를… 이래서는 재사용성이 보장되지 않는다.
이렇게 클래스의 헤더 파일과 구현파일만으로 하나의 기능이 완벽하게 보장되면 재사용성이 보장될 수 있다.
그런데 이렇게 다른 클래스를 쓰지 않기 위한 또 하나의 조건이 있다.
바로 마이클 잭슨처럼 배고프면 배고프다고 외치는 매커니즘으로 구현되어야 한다는 거다.
배고프다고 특정 요리사에게 얘기한다면, 이거이 바로 클래스 안에서 다른 클래스를 쓰는 거다.
재사용성이 보장되기 위해선 나 외에 다른 클래스는 아예 알아서도 안된다.
그냥 “나 배고파요~”라고 외치기만 해야 한다.
똑같은 쇠구슬 하나를 놓고 은하계의 각 행성마다 다르게 나타나는 질량을 계산하는 클래스에서 중력가속도가 필요하다면 중력가속도를 알려주는 클래스를 이용할 게 아니라,
“XX 행성의 중력가속도를 알려줘요~” 라고 소리치기만 해야 한다는 거다.
실제로 아이폰용 프로그램 개발의 많은 부분이 이런 식으로 이루어지고 있다.
이렇게 소리지르고 난리를 치면 담당하는 누군가가 듣고 그 값을 알려준다.
여기서 중요한 건, 질량을 계산하는 클래스는 그 담당자가 누구인지는 전혀 모르고, 그게 누구이건 아무런 상관이 없다는 거다.
기억하자. 우리의 “재사용용성이 보장되는” 클래스는 자기 자신 외에는 아무도 모르고 있어야 한다.
소리만 칠 줄 알아야 한다.
버튼의 경우를 보자.
우리는 버튼에게 색상, 크기, label 등을 정해준다.
내가 버튼에게 명령을 내리는거다.
그런데 버튼이 눌려진 처리를 해야 한다면?
많은 사람들이 위와 같은 그림을 그려놓고 이벤트를 설명하지만, 위 그림은 틀렸다.
버튼은 아무런 클래스도 모르는 “재사용성이 뛰어난” 클래스이기 때문에 form에게 자기 버튼이 눌렸음을 알려주지 못한다.
다만 “나 눌렸어요~” 하고 소리치는 것밖에 할 수가 없다. 다른 아무런 클래스도 알지 못하니까 .
그냥 소리만 치는거다.
모든 건 form이 다 알아서 한다.
form에서 버튼 클래스를 하나 사용하면서 이 버튼이 “나 눌렸어요~” 라고 소리치면 어떻게 처리할지를 정해놓는거다.
그러면서 계속 버튼 클래스에 귀를 기울이고 있다. “나 눌렸어요~”라고 소리치는지 안치는지 듣고 있는거다.
이거 큰 차이다. 버튼 클래스가 form에게 알려주는지, 아님 그냥 소리만 치고 마는거지.
듣는 사람이 없으면 그냥 소리는 공허하게 흩어지고 만다. (실제로 이런 경우는 많다.)
자, 이런 게 이벤트다.
한 놈은 소리만 치고, 다른 놈은 소리치는지 듣고 있다가 불편한 거 해결해 주고.
뭐라고 소리지를지 미리 약속을 정해놓은 게 protocol이고 이런 체계가 Delegate다.
이제 계속 연재를 통해 프로토콜과 Delegate의 동작 방법에 대해 설명하겠다.
이 글이 도움이 되셨다면 아래 손꼬락을 꼬옥 눌러주세요. 큰 힘이 됩니다. 그리고 댓글도 남겨주시면 더더욱 크~ㄴ 힘이 됩니다. ^^;
humanChecker.zip
