블로그 만보

명동을 떠나며, 두 직장동료의 선물

산골 — Wed, 17 Mar 2010 21:26:23 +0900

직장생활은 온갖 경험과 함께 장소에 대한 추억도 남겨준다. 강남은 신입때 좌충우돌 사람과 일에 적응하려고 애쓴 기억, 여의도는 멋있는 셀러리맨들에게 압도당하며 나도 저렇게 되고 싶다는 생각, 목동은 이제 평범한 직장인들과 동화된 느낌, 그리고 잠실은 극악의 교통과 업무량에 다시는 가고 싶지 않은 곳, 나에게 직장생활의 추억은 그 지명을 생각할때 저절로 그려지곤 한다.

처음 명동에서 일할때 나는 상상했다. 지금 서 있는 이곳 명동을 떠나면 나는 명동을 어떤 이미지로 상상할까. 나는 생각외로 많은 업무량과 높은 업무 난이도에 당황하며 혼자 저녁 밥을 먹었다. 밥을 먹고 명동 거리를 걸었다. 멋지고 화려한 젊은이들을 보니 왠지 기분이 들떴다. 그러나 나에게 명동도 왠지 고생의 이미지로 남을것도 같았다.

6개월이 지나고 이제 명동 구석을 제법 돌아다니게 되었다. 명동 구석을 돌아다니며 나도 대한민국에서 가장 멋진 거리를 알고 그 속에 함께 어울리는 젊은이가 된 듯한 뿌듯함이 생겼다. 나는 시골스러운 이미지가 있기에 도시적인 이미지를 약간은 동경하였고 명동은 멋진 도시인도 되고 싶은 나의 바람을 채워주는 듯 했다. 비록 산골이미지는 변하지 않았다 하더라도 일단 대한민국 최고의 번화가의 최고 멋진 젊은이들과 함께 있다는 관찰자 시점의 즐거움을 느꼈다.

[점심 시간에 대충 아이폰으로 찍은 명동 거리..]

[이곳에서 틈틈이 다른 회사 다니는 친구 만나서 식사하곤 했다.]

[여기는 명동 한복판]

[내가 일했던 사무실 입구]

여기서 끝이라면 명동은 강남, 목동, 여의도처럼 대한민국의 멋진 거리라는 관찰자 시점의 기억만 남을 것이다. 여기 명동 생활을 몇배 즐겁게 해준, 명동을 기분좋게 추억하게 만든 친구들이 있다.

내가 몰래 찍은 두 아가씨 뒷모습 사진을 어렵사리 허락받고 블로그에 올린다. 이 두 아가씨를 빼고는 명동을 추억하기 어렵다. 두 아가씨 뒷모습을 몰래찍고 두 아가씨의 어이없는 실소 섞인 승낙으로 이 사진을 블로그에 올릴 수 있었다.

또래 직원이 이 두 여직원 뿐이라 두 여직원과 많이 어울리며 명동 생활을 했다. 처음에는 남자 직원 위주로 지냈던 내가 예쁘장한 여직원들하고 지내니 좋았다. 중간쯤에는 또 편하게 대할수 있는 또래 남자 동료가 그립기도 했다. 사실 유독 여직원들이 성격이 까칠한 면도 있는 것 같다. 그러다가 이제는 여직원들하고 지내기 편해지니 이것저것 잔재미가 많아 즐거웠다.

예를들어 또래 여자의 관심거리, 화제거리, 싫어하는 것 들을 들을 수 있어서 좋았다. 두 여직원과 명동시내 파스타 식당 에서 분위기 있게 파스타 먹고 스타벅스니 커피빈이니 하는 비싼 커피집에서 커피한잔 하는 여유는 낯설지만 즐거운 경험이었다.

그러나 중요한건 이 둘은 다 임자가 있다는 것이다. 이 사실에서 모두 에~ 하며 김도 새고 어이없어 하겠지만, 덕분에 나는 둘을 편하게 대했고 이것저것 여자랑 잘 어울리는 법을 배웠다.

글을 쓰며 명동 시대를 정리해보니 내가 다른 장소에 비해 명동을 기분좋게 추억할수 있는 이유를 명확히 알게 되었다. 다른 장소는 항상 3인칭 관찰자 시점에서 그 장소에 어울리는 사람들을 부러워 하기만 했는데 명동에서는 나름 나도 구석 구석 동화하듯 어울렸다는 것에 있다.

명동 한 가운데 관찰자가 아닌 당사자가 된듯한 즐거운 추억은 한마디로 두 여직원 덕분이다. 덕분에 즐겁게 명동을 추억하며 떠났다. 그리고 명동에 있던 사무실은 잠실로 왔다. 사실 나는 다시는 잠실로 오지 않겠다고 2번이나 다짐했는데 벌써 3번째 잠실로 출근하게 됐다. 잠실은 직장생활 가장 안좋은 기억들이 몰려 있는 곳 이다. 그래도 지금은 또 어떤 일들이 생길까. 남은 근무 기간 잘 마무리 짓기를 기원했다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

상속과 구성 - 수필 객체지향

산골 — Mon, 15 Mar 2010 20:55:33 +0900

시골의 아이들은 어렸을때 물가에서 놀면서 형들이 약간만 알려주면, 저절로 헤엄치기를 배운다. 누가 정석으로 가르쳐 준것도 아닌데 잘도 헤엄친다. 상속은 시골 아이들의 야생 헤엄치기와 같다. 객체지향에 대해 약간의 지식만 익히고 사용할 줄 알면 상속을 습관처럼 저절로 쓰기 때문이다.

아이들의 야생 헤엄치기는 물가에서 놀기는 좋다. 그러나 수영 전문가가 볼때는 비효율적인 동작의 조합으로 조잡해 보인다. 만약 아이들이 물가에서 놀기위해 헤엄치기를 한다면 모르지만 좀더 전문적으로 수영을 하고 수영 대회도 나가고 짝사랑하는 영희에게 멋진 폼을 보여줄라면 지금의 헤엄치기는 문제가 있다.

상속은 복잡하지 않은 프로그램에서 대충 사용하기는 좋다. 그러나 객체지향 전문가가 볼때 상속을 무작정 사용하면 비효율적인 코딩이 눈에 뛴다. 만약 개발자가 아마추어스럽게 대충 객체지향 공부용 프로그램을 짠다면 모르겠지만 좀더 전문적이면서 유연하고 확장성 높게 개발하려면 지금의 상속 남발은 문제가 있다.

[삽화]

상속을 쓰면 부모의 속성과 기능을 중복 없이 재사용하거나 자신의 입맛게 재정의하여 폴리모피즘을 사용할수 있다. 그래서 객체지향의 장점을 누린다. 그러나 상속의 장점을 활용하기 위해 무분별하게 상속을 사용하면 여러가지 문제점이 생긴다. 마치 스타크래프트 프로토스에서 초기 질럿(=상속)이 막강하다고 질럿만 뽑았더니 테란의 배틀크루져 부대(=최강의 디자인패턴)가 몰려와 질럿을 몰살시키는 경우와 비슷하다.

[그림1.2.5-2, 등산화 클래스를 통한 상속 예제]

그림과 같이 등산화 클래스와 이를 상속받는 여러 등산화들이 있다. 그런데 등산화 클래스에 변경 요청이 생겼다. 등산화 클래스에 고어텍스 기능을 추가하는 요청이었다. 개발자는 별다른 고민 없이 고어텍스 메소드를 추가했다. 그러자 등산화 클래스를 상속받은 하위 클래스는 상위 클래스의 고어텍스 메소드를 상속받게 되어 특별히 수정할일이 발생하지 않게 되었다. 역시 상속은 재사용을 편하게 지원했다.

그러나 문제가 발생하였다. 등산화 하위 클래스중 고어텍스 기능이 없는 클래스가 존재했다. 현재 고어텍스 기능이 없는 WhiteYak-A등산화 클래스가 억지로 고어텍스 기능을 상속받은 문제가 발생하였다. 개발자는 해결 방법을 고민하였고, 곧 간단하게 문제를 해결한다. 고어텍스 기능이 없는 WhiteYak-A클래스는 고어텍스 메소드를 따로 오버라이드 하면서 아무작업도 하지 않게 처리하였다. 하지만 개발자가 곰곰히 생각해보니 뭔가 찜찜하기만 하다.

public class WhiteYakAClimbingBoots extends MountainClimbingBoots {
{ // WhiteYakA 등산화 클래스
…
   public void goreTexFunction() {
       // 부모 클래스에서 기본적으로 고어텍스 메소드를 정의하였지만,
       // 이 등산화 클래스는 고어텍스 기능이 없으므로, 일부러 고어텍스 기능 메소드를
       // 오버라이드 하여, 아무일도 안한다고 명시해야 한다.
       System.out.println("아무일도 안함");
   }
…
}

WhiteYak-A클래스처럼 이전에 만들어진 등산화 클래스는 고어텍스 기능이 없다. 따라서 그림1.2.5-2과 같은 등산화 구성이라면 고어텍스 기능이 없는 클래스를 하나하나 찾아내어 수정을 해줘야 한다. 만약 이 클래스가 수백가 넘는다면 하나하나 클래스 찾는일은 ‘짜증나는 삽질’이 될 것이었다.

더구나 고어텍스 기능이 없는 클래스의 고어텍스 메소드에 ‘아무 일도 안한다.’고 똑같이 수정한다면, 수백개의 같은 로직이 수백개의 클래스에 중복되는 것이므로 코드 중복을 최소화 한다는 프로그래밍 원칙에도 어긋난다. 상속을 통해 코드의 중복을 막으려고 했더니 코드가 중복되는 일이 발생하였다. 개발자는 혼란스러워 한다.

또한 고객은 등산화 클래스의 ‘기능 명세’는 정해진것이 아니고 종종 변경될일이 존재한다고 말했다. 만약 그런일이 생기면 개발자는 일단 ‘부모 클래스’의 기본적인 기능 명세 변경 후, 이어서 수 많은 자식 등산화 클래스를 뒤져야 한다. 그래서 자식 클래스에 맞게 기능을 재정의(=오버라이드) 하는 번거로운 수정 작업을 진행해야 한다.

[삽화]

상속의 장점은, 부모 클래스의 속성과 메소드를 재사용 하면서, 부모 클래스의 오버라이드 기능을 이용해 폴리모피즘(=다형성) 효과를 유도하는 효과에 있다.

그러나 상속은 모든 자식 클래스들이 부모 클래스의 속성과 기능을 똑같이 상속받아야 한다. 상속은 객체지향 언어에서 고정된 문법이기 때문에, 자식 클래스가 한번 상속 받은 속성과 기능은 컴파일 이후 변경이 불가능하다. 그래서 마치 한번 쓰면 지우지 못하는 볼펜처럼 프로그램 실행 후에는 유연하게 행동을 변경하지 못하고, 자식 클래스들의 일부 특성이 부모 클래스와 어긋날 경우, 프로그램 수정등의 유지보수 작업이 어려워질 것이었다.

[그림1.2.5-3, 등산화 구성 예제]

위와 같이 상속의 문제가 발견될 경우 구성을 사용한다. 위의 그림에서는 고어텍스 인터페이스를 만들고, 초강력 고어텍스, 고어텍스, 고어텍스 기능 제거 클래스가 구현되어 있다. 등산화 클래스에는 고어텍스 메소드가 추가되어 있고, ‘고어텍스 인터페이스’를 새로 속성으로 받아들였다.
public class MountainClimbingBoots { // 등산화 클래스
   private GoreTex goreTex = null; // 고어텍스 인터페이스

   // 등산화 클래스가 실행될때 폴리모피즘(=다형성)을 통해 고어텍스 클래스중
   // 하나를 인자로 받을 것이다.
   public MountainClimbingBoots(GoreTex goreTex) {
       this.goreTex = goreTex;
   }

   // 고어텍스 클래스 셋팅
   public void setGoreTex(GoreTex goreTex) {
       this.goreTex = goreTex;
   }

   public void goreTexFunction() {
       // 자신이 생성될때 넘겨받을 고어텍스 클래스에게, 같은 기능을 위임하고 있다.
       goreTex.goreTexFunction();
   }
….
}

만약 K3-A등산화가 초강력 고어텍스 기능을 쓴다면, ‘실행클래스’에서 아래와 같이 쓸수 있다.
public static void main( String[] args ) throws Exception {
   …..
   // 실행 클래스는 K3A등산화를 생성할때 초강력 고어텍스 클래스를 인자로 넘겨주었다.
   MountainClimbingBoots k3aBoots = new K3AClimbingBoots(new UltraGoreTex());
   …...
}

그런데 생산과정에서 다시 요구사항이 변경되어 K3-A등산화가 일반 ‘고어텍스’기능으로 다운그래이드 되었다면, ‘실행클래스’에서 아래와 같이 바꿀 수 있다.
public static void main( String[] args ) throws Exception {
   …..
   // 실행 클래스는 K3A등산화를 생성할때 초강력 고어텍스 클래스를 인자로 넘겨주었다.
   MountainClimbingBoots k3aBoots = new K3AClimbingBoots(new UltraGoreTex());
   …...
   // 프로그램 실행중에 일반 고어텍스 클래스를 인자로 넘겨주었다.
   k3aBoots.setGoreTex(new GeneralGoreTex());
   ....
}

또한 WhiteYak-A등산화는 저렴한 가격을 위해 고어텍스 기능을 제거했다고 한다. 아래와 같이 쓸 수 있다.
public static void main( String[] args ) throws Exception {
   …..
   // 실행 클래스는 K3A등산화를 생성할때 초강력 고어텍스 클래스를 인자로 넘겨주었다.
   MountainClimbingBoots k3aBoots = new K3AClimbingBoots(new UltraGoreTex());
   …...
   // 프로그램 실행중에 일반 고어텍스 클래스를 인자로 넘겨주었다.
   k3aBoots.setGoreTex(new GeneralGoreTex());
   ....
   // 실행 클래스는 WhiteYakA등산화를 생성할때 고어텍스 기능이 제거된 클래스를 인자로 넘겨주었다.
   MountainClimbingBoots whiteYakABoots = new WhiteYakAClimbingBoots(new NotGoreTex());
   …...
}

위와 같이 상속을 많이 썼더니 오히려 프로그램에 ‘나쁜 냄새(=코드가 지저분해짐)’가 나는 경우가 생긴다면, 구성 구조로 ‘개선(=리팩토링)’하여 객체지향에서 본래 의도하는 유연성, 확장성, 유지보수 편리성을 다시 회복할 수 있다.

상속을 많이 썼을때의 문제는 ‘그 객체의 행동’이 컴파일시에 완전히 결정되어 프로그램 실행 중에 그 행동을 바꿀 수 없고, 모든 자식 클래스가 무조건 똑같은 기능을 상속받은 결과, 자식 클래스 중 일부가 상속받지 않아야 하는 기능도 무조건 상속받아야 하는 것에 있다.

구성이란 클래스의 특정 기능을 수행하기 위해 다른 ‘객체 패밀리’의 유사하거나 같은 역할을 하는 메소드를 사용하기 위해 클래스들끼리 대등한 관계로 결합된 구조이다. 이렇게 객체를 구성하면, 기존 코드를 고치는 대신 새로운 ‘객체 그룹군’을 만들거나 이미 만들어진 ‘객체 그룹군의 자식 클래스’를 변경하여 기능의 추가, 수정을 자유롭게 제어할 수 있다.

그래서 기존 코드를 건들었을때 발생하는 생각하지 못한 버그(=부작용)가 연쇄 작용하는 것을 막을 수 있다. 기존 코드의 수정이 아닌 확장으로, 기존 프로그램 구성을 안전하게 지키면서 어플리케이션을 개선할 수 있다.

마치 상속이 한번 정한 정책은 수정하기 힘들고 위에서 명령한것은 억지로 따라야 하는 경직된 관료조직과 같다면, 구성은 급변하는 시장 환경에 빠르게 적응하고 직원 개인의 특성을 잘 살려주는 바람직한 기업 현장의 조직과 같다.

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

환상을 꿈꾸며, 아이폰과 안드로이드 헬로월드를 찍어보고

산골 — Fri, 05 Mar 2010 08:47:55 +0900

누구나 환상을 꿈꾸어 봅니다. 예쁜 여자와 데이트 하기를 바라고, 멋진 차를 모는 환상도 꾸고, 김연아처럼 우아하게 피겨하는 환상도 꾸지요. 환상은 마치 생각의 초콜릿입니다. 달콤하지만 곧 녹아버립니다.

저는 옛날부터 프로그래밍에 대한 바람이 있었습니다. 마치 레고 블럭을 쌓듯, 퍼즐 게임을 하듯 지적인 놀이로서의 프로그래밍과 고된 등산 끝에 성취감 같은 즐거움을 얻기를 바랐습니다. 처음 아마추어적인 개발을 할때는 이런 즐거움을 얻었습니다. 그러나 막상 현장에 투입되니 이런 즐거움은 사라지고 온갖 스트레스에 노출되지요. 군대에 비유하자면 멋진 군인을 동경해 고된 훈련을 마쳤더니 마치 라이언 일병 구하기 상륙작전 처럼 비피린내나는 현장이 기다리는 것과 비슷할 것 입니다.

그래서 옛날 블로그에 왜 그럴까 하며 이런저런 글도 쓰곤 했죠. 결론은 노가다성 웹개발등을 피하고 최대한 순수 어플리케이션을 개발하는 것 입니다. 그러나 순수 어플 개발을 할수 있는 길은 별로 없죠. 그러나 드디어 뭔가 새로운 길이 발견되었고 그 길이 발전되는 것 같습니다.

바로 아이폰과 안드로이드 개발환경입니다. 이곳에서 환상을 꿈꾸어 봅니다.

+ 아이폰으로 꿈꾸는 환상

처음 친구가 맥북을 권할때 윈도우하고는 차원이 틀리다고 했습니다. 저는 친구 권유따라 맥북을 사면서도 에잇~ 컴퓨터가 달라봤자 얼마나 다르겠어~ 하고 맥북을 샀지요. 근데 맥북과 윈도우 차이가 엄청 나더군요. 맥북의 환상적인 OS환경에 감탄을 금치 못했지요.

2주간 고민하고 아이폰을 살때, 아이폰이 좋아봤자 얼마나 좋을까..라는 생각도 했습니다. 막상 아이폰을 사보니, 그야말로 다른 폰은 아이폰 100년 전에 나온 구식인것 같더군요. 아이폰처럼 완벽하게 만족한 물건은 처음 사봅니다. 극찬의 극찬을 하더라도 부족한 아이폰은, 내가 구입한 세상의 모든 물건중에 가장 완벽한 제품이었습니다.

이렇게 애플의 제품은 기대 이상의 즐거움을 줍니다. 그래서 혹시 아이폰 개발환경까지도 다른 플랫폼과는 월등하게 다른 개발의 즐거움을 주지 않을까라는 환상~도 꿈꾸게 되었습니다. 에잇~ 개발환경이 거기서 거기지 라는 생각도 또 들지만..여지껏 경험한 애플의 멋진 환경이라면 아이폰 개발환경도 뭔가 기대이상의 즐거움을 주지 않을까라는 환상을 꿈꾸게 되었습니다.

+ 안드로이드로 꿈꾸는 환상

이클립스는 프로그래밍의 재미를 몇배 뻥튀기~ 해줍니다. F3키로 소스내부를 탐험하는 재미, 한방에 내 의도대로 리팩토링 하면서 코드가 확~ 정리되는 재미, 한줄 한줄 디버깅 추적 하는 재미, JUnit으로 안정감있게 개발하는 재미, 이클립스로 순수 어플을 개발할때 역시 일은 일이라 가끔 재미없을때도 있었지만 대부분 즐겁게 개발했죠.

이클립스를 이렇게 다뤄본적이 아늑하군요. 지금은 허겁지겁 좌충우돌 삽질노가다 땜방식 유지보수 하고 있네요. 그런데 안드로이드는 이클립스 안에서 온전히 순수 어플을 개발 합니다.

이클립스 안에서 자바로 개발할때 객체지향적으로 클래스를 구성하고 리팩토링 하는 그런 재미, 그런 재미를 안드로이드로 개발하면 항상 느낄수 있을것인가~ 안드로이드도 이런 환상을 꿈꾸어 봅니다.

이런 환상을 가지고 저는 저번 주말에 아이폰과 안드로이드 개발환경을 셋팅하고 ‘헬로 월드’를 찍어보았습니다. 에뮬레이터가 돌아가는 모습을 보니 마치 장난감 만지는것 같이 재미있더군요. 아이폰, 안드로이드 개발환경은 제가 생각했던 것처럼 무척 재미있을 것 같습니다.

그러나 저는 환상이란 단어를 썼습니다. 환상이란 단어는 '너무 긍정적으로 비약하여 생각하다~' 라는 뜻도 담겨 있지요. 그렇더라도 제가 많이 겪는 노가다성 일 보다는 나을것이라는 기대입니다.

아이폰과 안드로이드로 인해 1인 기업가, 인디 개발자로 활동할수 있어서 개발자를 위한 수많은 기회가 열린다..등의 장점은 나중에 얘기하고, 일단 IT개발자의 프로그램 짜는 관점에서 아이폰과 안드로이드에 꿈꾸는 환상을 생각해보았습니다.

그래서 요즘 아이폰과 안드로이드 개발자로 전업을 심각하게 생각하고 있습니다. 그외에도 무수히 많은 가능성과 장점이 있는 것 같습니다. 환상의 절반이라도 현실이라면.. 모험을 걸어도 좋을텐대 말이죠.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

상속과 폴리모피즘 - 수필 객체지향

산골 — Wed, 03 Mar 2010 10:38:11 +0900

객체지향 대부분의 장점은 상속과 폴리모피즘으로부터 출발한다. C등의 절차지향 개념을 공부한 사람이 처음 상속과 폴리모피즘 개념을 배울때도, 난생 처음 프로그래밍을 배우는 사람도, 상속과 폴리모피즘 개념을 이해하는데 어려움을 표시한다. 그러다가 결국 나는 절차지향이 좋아~하며 다시 익숙한 방식의 프로그래밍으로 돌아가거나, 상속과 폴리모피즘 개념을 이해하지 않은체 객체지향 언어지만 절차지향적으로 프로그래밍을 하곤 한다. 그러나 상속과 폴리모피즘은 마치 대한민국 젊은 남자의 군대생활 처럼 반드시 거쳐야 하고 반드시 이해해야 하는 과정이다.

상속은, 스승과 제자사이와 비슷하다. 스승은 제자에게 자신의 모든 기술을 전수한다. 제자는 스승의 기술을 고스란히 체득한다. 또는 스승의 기술을 완전히 습득하기 전까지는 스승의 힘을 빌린다. 스승은 제자가 자신의 기술을 아무 생각 없이 그대로 받아들이는 것은 싫어한다. 제자가 자신의 특성에 맞게 기술을 발전 시키길 바란다.

[삽화]

상속은, 부모 클래스의 기능을 자식 클래스가 물려받는 것이다. 자식 클래스가 부모 클래스를 상속받으면 private를 제외한 부모 클래스의 모든 속성과 기능을 물려받는다. 자식 클래스는 부모 클래스의 속성과 기능을 중복 코딩할 필요 없이 그대로 사용한다. 또는 부모 클래스의 기능을 자신의 특성에 맞게 재정의(=오버라이드) 한다. 오버라이드는 폴리모피즘(=다형성)이란 객체지향 요소를 지원하며 폴리모피즘은 ‘상속과 구성’ 구조 및 디자인 패턴에서 유익하게 쓰인다.

[그림1.2.4-2, 상속과 오버라이드등의 관련 요소 설명]

폴리모피즘(=다형성)은, ‘신비로운’ 산타클로스 할아버지의 ‘비밀스런’ 선물 효과와 비슷하다. 어린이는 매년 12월25일마다 산타 할아버지의 선물을 기다린다. 그런데 그 선물이 어떤 선물인지 알아서는 안된다. 어떤 선물이든 어린이는 선물을 받고, 그 선물의 포장지를 뜯고, 그 선물을 쓰면 된다. 그런데 만약 어린이가 산타 할아버지의 실체를 알고, 선물이 무엇인지도 알게 된다면 ‘어린이의 동심’은 건조해질 것이다.

[삽화]

폴리모피즘이란, ‘같은 종류의 여러 객체’에게 ‘동일한 메시지’를 주었을 때 ‘각자 다르게 행동’하는 현상이다. ‘같은 종류의 여러 객체’는, ‘같은 종류의 객체중 부모 클래스’가 제공하는 ‘같은 기능’을, ‘저마다의 기능으로 재정의(=오버라이드)’ 한 상태이다. 이 ‘객체 그룹’을 쓰는 ‘클라이언트 객체’는, ‘객체 그룹’의 ‘부모 클래스’만 알고 있다. ‘클라이언트 객체’가 ‘부모 클래스’만 알고 있는 상태에서, 이 ‘클라이언트 객체’를 실행하는 ‘실행 클래스’는 ‘클라이언트 객체’ 중에 ‘같은 기능’이지만 ‘각자 다르게 행동’하는 ‘자식 클래스’중 하나를 ‘인자’로 넘겨준다. ‘클라이언트 객체’는 자신이 ‘인자’로 받은 ‘객체 클래스’를 모른다. 그냥 실행할 뿐이다. 이것이 폴리모피즘의 작동 구조이다.

[그림1.2.4-4, 계속하여 반복 등장하는 전형적인 상속과 폴리모피즘 구성도, 객체지향 보물지도]

상속을 통해 부모 클래스와 자식 클래스가 생겼고, 오버라이드를 통해 부모 클래스의 기능을 저마다의 특성에 맞게 재정의 했고, 상속과 오버라이드의 요소를 활용해 폴리모피즘 기능이 작동한다. 이 모든 기능이 조화롭게 작동한다면, 저마다의 다양한 기능을 가진 ‘자식 클래스’를 자유롭게 교체하고, 새로운 기능을 확장할 수 있으므로 객체지향의 온갖 장점을 누릴 수 있다. 그래서 응집도는 높고 결합도는 낮으며, 유연하고 확장성이 높고 유지보수하기 편하다는 수식어를 붙일 수가 있다.

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

캡슐화와 정보은닉 - 수필 객체지향

산골 — Tue, 23 Feb 2010 08:46:08 +0900

캡슐화란 용어는 용어의 뜻을 이해하는것도 두루뭉실하지만 그 쓰임새도 애매모호하다. 나는 몇년 경력이 되어서도 캡슐화란, 객체의 속성을 private로 만들어 이것을 get/set 메소드로 호출하는 방법으로만 이해했다. 그런데 저 객체지향 캡슐화 이론과는 다르게 실제 프로그래밍에서는 객체의 속성을 public으로 만들어 직접 호출하는것과의 차이점을 느끼지 못했다. 오히려 private로 선언하면 클라이언트에서 저 속성을 가져올때 get/set을 쓰느라 코드 보기가 더 지저분해서 좋게 생각하지 않았다.

[삽화]

캡슐화는 객체지향 개발의 중요한 장점중에 하나이지만, 나는 상속과 구성 폴리모피즘의 장점은 이해하면서 유독 캡슐화의 장점을 이해하지 못했다. 캡슐화의 정의와 캡슐화가 왜 좋은지 따로 공부해야 했다.

캡슐화의 정의는 관련있는 여러 정보들을 어떤 틀안에 담는 것이다. 여기서 어떤 틀안에 담는다는 것은 외부에 필요없는 정보들을 노출시키지 않고 숨기는 것이다. 여기서 정보를 노출하지 않고 숨기는 것은 정보은닉의 정의와 같다. 이렇게 캡슐화와 정보은닉을 하는 이유는 캡슐화를 통해 객체 안의 데이터가 다른 객체에게 잘못 조작되는 것을 막기 위해서이다. 데이터를 직접 접근할수 없기 때문에 캡슐화된 속성에 대해 ‘그 속성을 가진 객체’가 별도로 조작해야 하는 경우, 그 속성이 보호되는 효과가 있다. 마치 친구에게 자신의 웹하드를 공개해주었는데 읽기 권한만 주고 쓰기 권한은 제한하여 자신의 파일을 보호하려는 경우와 같다.

캡슐화를 통해 데이터가 다른 객체에게 잘못 조작되는 것을 막을 수 있다. 그래서 데이터의 주인 객체가 따로 계산하거나 확인한 값이 보존되는 효과가 있다. 이 점이 캡슐화의 장점을 이해하는데 중요한 단서이다.

public class MountainClimbingBoots { // 등산화 클래스
   private int durability = 60;      // 내구성
   private boolean isGoreTex = true; // 고어텍스 유무

   public int getDurability() {      // 내구성 속성 get접근 메소드
       if(isGoreTex) {               // 고어텍스 기능이 맞으면
           return durability + 30;   // 내구성에다가 30을 더해서 리턴한다.
       }
       return durability;
   }
}
[캡슐화된 등산화 클래스]

등산화 객체는 내구성이란 속성이 있다. 내구성이란 속성은 기본적으로 60으로 지정되어 있다. 그리고 ‘클라이언트 객체’가 get메소드로 내구성 속성을 가지고 올때 내구성 데이터를 조작하는 로직이 포함되어 있다. 위의 예제처럼 만약 고어텍스 기능이 있다면 내구성에 +30을 더해 90을 리턴하는 로직이 추가되어있다. 그런데 만약 내구성 속성이 public으로 오픈되어 있어서 클라이언트가 직접 속성 값을 가지고 오는 경우가 생긴다면 본래 등산화 객체 설계자가 의도했던 설계를 망가뜨리는 참사가 발생한다.

더 나아가 ‘클라이언트 객체’가 객체 구성요소의 쓰임새를 잘 모른채 직접 속성 값을 조작하는 경우가 생긴다면, 직접 조작한 ‘클라이언트 객체’ 뿐만 아니라 다른 ‘클라이언트 객체’까지 조작된 속성값을 써야 되기 때문에 피해가 확대되는 더 큰 참사도 발생될 수 있다. 마치 ‘산에서 떨어트린 담뱃재가 산불이 되는 경우’와 같다.

만약 ‘캡슐화’를 지킨다면,
1. 속성은 private로 선언한다.
2. get메소드를 만들어 get메소드로만 속성을 가져올수 있게 한다.
3. set 메소드로 데이터를 제한적으로 조작하게 허용하거나, 아예 set메소드를 제거하여 외부로부터 속성값의 조작을 금지한다.
이렇게 하여 자신 객체의 설계 사상을 잘 모르는 다른 클라이언트 객체들의 ‘무자비한’ 조작으로부터 자신의 속성와 설계 사상을 안전하게 보호한다. 이제 내가 get/set메소드를 이용한 캡슐화 규칙을 지키기보다 속성을 조작하길 좋아했던 습관이 어떻게 잘못 되었는지 이해할 수 있었다.

[삽화]

객체지향에서 캡슐화란 뜻은 다른 관점 에서도 사용한다. 객체지향 설계관점에서도 사용한다. 예를들면 ‘변하는 기능을 분리해서 따로 캡슐화하라~’ 는 객체지향 원칙을 쓰곤 한다.

캡슐화의 정의는 관련있는 여러 정보들을 어떤 틀안에 담는 것이다. 그럼 객체의 기능중에 일부를 그 객체로부터 분리하여 다른 ‘객체 패밀리’로 새롭게 구성하는 것도 캡슐화이다. 객체의 일부 기능을 다른 ‘객체 패밀리’의 새로운 틀로 담았으니 이것도 캡슐화다. 이렇게 객체의 기능을 별도의 ‘객체 패밀리’ 틀로 분리하여 담으면, 유연성과 확장성이 좋아진다.

[삽화]

정보은닉이란 개념은 캡슐화 개념과 거의 비슷하되, 정보은닉 규칙을 준수하기 위해 캡슐화가 쓰이고 있다. 캡슐화를 지키면 정보은닉 규칙을 준수할 수 있다. 정보은닉은 외부에 필요없는 정보들을 노출시키지 않고 숨기는 것이다.

예를 들어 우리가 비행기 객체를 인식할 때 비행기를 구성하는 엔진, 전자제어장치 등의 복잡한 부품은 모른다. 다만 비행기로 ‘이동’ 할 뿐이다. 사용자 입장에서는 ‘복잡한 속성’보다는 ‘중요 기능’만 알면 된다. 보통 세상이 이러므로 객체지향 개발에서도 ‘복잡한 부품’은 외부에 노출하지 않고, 객체 외부에서 인식하기 편리한 ‘중요 정보’만을 외부로 노출시켜야 한다.

이런 정보은닉을 잘 지원하는 객체지향 요소가 인터페이스이다. 인터페이스의 기능 명세를 설계하고 그 기능 명세의 구현은 하위 클래스에 맞긴다. 클라이언트는 인터페이스에만 의존되어 있다. 그러면 클라이언트는 인터페이스에 명시된 ‘기능의 용도’만 알기 때문에 정보은닉을 지킬 수 있다. 이 설명에서도 ‘객체지향 보물지도’ 그림이 떠올라야 한다. ‘객체지향 보물지도’의 그림과 동일한 설명이다.

이렇게 캡슐화와 정보은닉을 잘 활용하면,
1. 정밀한 제어가 필요한 속성이 다른 객체의 조작에 의해 훼손되는 경우를 막을 수 있다.
2. 객체끼리 정말 필요한 정보들만 의존한다.
3. 변하는 기능은 캡슐화를 통해 별도의 틀로 구성하여 기능의 수정과 확장 요구에 유연하게 대처할 수 있다.
4. 그 결과 객체간의 응집도가 높고 결합도가 낮아져 유연성과 확장성이 높아질 것이다.

[삽화]

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오버로딩과 오버라이딩 - 수필 객체지향

산골 — Thu, 18 Feb 2010 08:35:32 +0900

오버로딩은 마치 맥가이버칼의 부속품과 같다. 같은 몸통(메소드 이름)에서 꺼내는 위치만 바꾸면(인자값) 다양한 기능이 발견된다. 오버로딩은 같은 이름의 메소드의 인자값(=시그네처)를 다르게 주어 개별적으로 개발자 입맛에 맞게 호출할 수 있는 방법이다.

내 경험으로 오버로딩은 생성자 호출에서 특히 많이 쓰인다. 처음 객체를 생성할때 오버로딩된 다양한 생성자들의 용도를 파악하여, 써야 되는 상황에 알맞게 해당 객체를 사용할 수 있다.

- 생성자 오버로딩 예제-병아리 부화 클래스
public static void main( String[] args ) throws Exception {
    …..
    Chick chick1 = new Chick(); // 1
    Chick chick2 = new Chick(“먹이”); // 2
    Chick chick3 = new Chick(“먹이", "물"); // 3
    …...
}

- 생성자 오버로딩 예제-병아리 예제 클래스
public class Chick {
    public Chick() {
        System.out.println("배가 고파요");
    }

    pulbic Chick(String food) {
        System.out.println(food+" 맛 있어요. 근데 목이 말라요");
    }

    pulbic Chick(String food, String water) {
        System.out.println(food+" 먹고 "+water+" 도 먹고");
    }
}

오버라이딩은 마치 진화하는 자동차 모델의 특징 변화와 같다. 예를 들어 유명한 자동차 소나타 시리즈는 소나타1에서 EF소나타, New EF소나타, NF 소나타, 그리고 현재 YF소나타로 진화하고 있다.

소나타 시리즈가 진화될 때마다(상속받을때는) 먼저 자동차 모델명이 조금씩 바뀐다.(자동차 모델명을 정하는 메소드가 오버라이드 된다.) 그외 자동차의 여러 성능이라던지 가격이라던지 자동차의 모든 특징과 기능들이 그대로인 것은 그대로 상속받고 바뀌는 것은 자식 클래스에서 다시 구현한다.

오버라이딩은 부모 객체에서 정의한 메소드를 해당 자식 객체의 입맛에 맞게 재구현하는 개념이다.

[그림 1.1.7-1, 소나타 객체 상속 구성도, 소나타1에 기본적으로 부가 서비스 시스템을 정의하는 serviceSystem 메소드가 존재한다. 소나타1에서는 일반 소파, 구식 라디오 등이 구비되어 있다. 소나타1을 이어받은(상속받은) EF소나타는 serviceSystem 메소드를 오버라이드 했다. 인체공학적 소파, CD플레이어등의 발전된 기능을 재정의 하였다. NF소나타도 역시 상위 클래스의 serviceSystem을 재 정의 하면서 더 발전된 기능을 제공하고 있다.]

오버라이딩 개념은 객체지향에서 중요하다. 객체지향의 장점을 누릴 수 있는 상속과 폴리모피즘, 인터페이스와 구상 클래스, 더 나아가 디자인패턴에서도 오버라이드를 통해 프로그램을 유연하고 확장성 높게 다룰 수 있다.

상속과 폴리모피즘(다형성) 개념, 부모 클래스를 상속받은 클래스들은 대부분 부모 클래스의 주기능을 오버라이드 하고 있다. ‘부모 클래스’와 ‘상속받은 클래스’를 묶어서 ‘객체 패밀리’라고 하고, ‘객체 패밀리’를 사용하는 다른 객체를 ‘클라이언트 객체’라고 이름지어 보겠다. 제대로 된 객체지향 기법을 사용한 객체 구성이라면 ‘클라이언트 객체’는 ‘객체 패밀리’의 ‘부모 클래스’에만 의존하고 있을 것이다. 이때 ‘클라이언트 객체’를 제어하는 ‘실행 클래스’ 가 ‘클라이언트 객체’에게 ‘객체 패밀리’의 ‘상속받은 클래스’ 중에 하나를 선택하여 인자값으로 넘겨준다. 이렇게 하면 유연하고 확장성 높은 전형적인 객체지향의 장점을 누릴 수 있는데, 이 상속과 폴리모피즘의 구현에 오버라이딩 개념이 중요하게 작용한다.

[그림 1.1.7-2, 상속과 폴리모피즘 개념도]

인터페이스와 구상 클래스, 인터페이스와 인터페이스를 구현하는 구상 클래스로 나눌때의 이로움은 상속과 폴리모피즘과 비슷하고 그 안에 장점이 포함되어 있다. ‘인터페이스를 쓰는 클래스’를 ‘클라이언트 클래스’라고 정의해 보겠다. ‘클라이언트 클래스’ 는 인터페이스에서 명시한 기능만 알고 그 구현 클래스(=구현 방법)은 전혀 모른다. ‘클라이언트 클래스’가 어떤 방식으로 인터페이스에 명시한 기능을 쓸 것인지는 ‘실행 클래스’가 결정한다. 덕분에 ‘클라이언트 클래스’는 오직 인터페이스 명시한 기능만 알고도 여러 구상 클래스를 교체 하거나 확장할 수 있어서 유연하고 확장성 높은 개발이 가능하다. 인터페이스를 구현한 구상 클래스는 기본적으로 인터페이스에 명시한 기능을 오버라이드 하기 때문에 인터페이스와 구상 클래스 에서도 오버라이딩 개념이 중요하게 작용한다.

디자인패턴의 가장 기본이 되는 객체 구성도는 상속과 폴리모피즘, 인터페이스와 구상 클래스 설명을 통해 그려지는 구성도와 같다. 이 객체 구성도를 바탕으로 파생된 다양한 패턴이 존재하는데 그 바탕에는 상속과 폴리모피즘, 인터페이스와 구상 클래스, 그리고 오버라이딩 개념 등을 중요하게 사용한다.

[삽화]

이렇게 오버라이드는 객체지향의 장점을 살려주기 위해 밑바닥에서 알게 모르게 중요하게 작동하는 개념이다.

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

인터페이스 - 수필 객체지향

산골 — Tue, 16 Feb 2010 19:24:00 +0900

인터페이스(Interface)는 산의 맑은 공기와 같다. 등산할때는 항상 맑은 공기를 마실 수 있지만, 맑은 공기의 고마움은 쉽게 인식하지 못한다. 등산을 마치고 도시속에 찌든 공기를 마시고 기침을 콜록일 때서야 그 고마움을 깨닫곤 한다.

인터페이스는 바다의 해삼과 같다. 해삼은 인간에게 가장 이로운 영양을 주는 해산물로, 해녀가 깊은 바닷속에 잠수해야 겨우 몇마리 건져올리는 해산물이다.

인터페이스는 산의 맑은 공기처럼 늘 객체지향 개발자와 함께 하는 존재이며, 무의식중에 쓰이는 존재이지만, 인터페이스의 고마움을 쉽게 인식하지 못한다. 개발을 마치고 어지럽기만한 코드를 디버깅 하다가 인터페이스 형식으로 리팩토링 해서야 그 고마움을 깨닫곤 한다.

인터페이스는 바다의 해삼처럼 객체지향 요소 중에서 개발자에게 가장 이로운 결과물을 주는 요소로, 객체지향 개발자가 깊이있게 생각해야, 모든 자식 클래스를 아우르는 추상 인터페이스로 겨우 건져올리곤 한다.

인터페이스는 산의 맑은공기와 바다의 해삼처럼 객체지향의 유익한 요소, 객체지향의 정수이며 객체지향의 꽃이다. 객체지향 개발과 모든 디자인 패턴의 핵심이 되는 존재이다.

개발자중에 누군가는 인터페이스 덕분에 객체지향 개발 효과를 충분히 얻는다. 또는 인터페이스 때문에 객체지향 개발을 포기한다. 또는 인터페이스를 모른체 객체지향의 탈을 쓴 개발을 한다. 인터페이스는 쉽게 알수도 있지만 쉽게 알기도 어려운 존재이다. 나는 3번째 경우처럼 인터페이스를 이해하지 모른체 객체지향의 탈을 쓴 개발을 하곤 했다. 인터페이스의 실체를 알고 사용하게 됐을때 나는 안도의 한숨을 내쉬었다.

인터페이스는 약속이다. 인터페이스는 나는 너희들에게 이러이러한 기능을 제공하겠다는 약속이다. 다른 모든 객체들은 인터페이스가 약속한 기능들을 믿고 인터페이스에 약속된 기능을 호출한다. 이때 인터페이스에 약속된 기능의 실제 구현은 ‘구상 클래스’ 에서 담당하게 된다. 인터페이스를 호출하는 ‘클라이언트’는 인터페이스에만 의존하고 있지만 실제로 할당된 객체는 ‘구상 클래스’ 이다.

[그림 1.2.1-1, 이 그림은 인터페이스를 활용한 전형적인 상속 클래스 다이어그램이다. 클라이언트는 휴대폰 인터페이스에만 의존하며, 휴대폰 인터페이스에서 약속한 기능을 호출한다. 지금 클라이언트는 휴대폰 인터페이스에만 의존하여 있지만 실제로 클라이언트에 할당된 객체는 블랙잭, 아이폰, 햅틱 객체중 하나가 될 것이다.]

[그림 1.2.1-2, 실행 클래스는 모든 프로그램이 시작되고 제어되는 부분인 main() 메소드를 포함한 클래스이다. 실행 클래스는 빨간 화살표처럼 프로그램을 구성하는 대부분의 클래스를 알고 있다. 실행 클래스는 클라이언트 객체를 생성할 때, 휴대폰 인터페이스의 기능을 실제로 구현한 클래스 블랙잭, 아이폰, 햅틱중 하나를 인자로 넘겨줄 것이다. ]

- 실행 클래스
public static void main( String[] args ) throws Exception {
    …..
    Clinet client1 = new Client(blackjack); // 1
    …...
}

- 클라이언트 클래스
public class Client {
    Handphone handphone = null; // 2
    public Client(Handphone handphone) {
         this.handphone = handphone; // 3
    }
    …..
}
[1. 실행 클래스에서 Client 객체를 생성하면서 핸드폰 관련 클래스중 어느 구상 클래스를 사용할지 인자로 넘겨준다.
2. Client 객체는 Handphone 인터페이스를 속성으로 가지고 있다.
3. 1.의 절차에 의해 휴대폰 구현 객체 blackjack이 생성자로 넘어왔으며 이 구현 객체가 handphone객체에 저장이 되었다.
이 그림과 코드는 인터페이스, 상속, 다형성 요소가 들어간 객체지향을 이해하는 핵심이 되는 부분이다. 앞으로 계속 설명되니 가능한 부분 까지 이해해도 좋을 것이다.]

내가 처음 겪었던 혼란은 프로그래밍을 해야 할 때, 복잡하게 생각할 필요 없이 하나의 클래스만 만들어 그곳에 기능도 선언하고, 그 기능에 해당하는 로직도 직접 구현하는것이 더 깔끔하게 프로그램 짜는것이 아닐까라고 생각했던 적이 있다. 왜 굳이 인터페이스와 클래스로 나누는가 라고 생각한적이 있다. 당시 나는 ‘클래스의 수만 적으면 깔끔’하다고 생각했던 것 같다.

[그림 1.1.3-3, 휴대폰 클래스 하나에 블랙잭, 아이폰, 햅틱, 기타 휴대폰 객체에 의존하고 관련 로직을 꾸역 꾸역 넣으면 어떻게 될까. 저 그림을 코드로 구현하면 얼마나 지저분할지 생각해보자. 코드의 확장성과 유지보수 관점에서 생각해볼만 하다.]

객체지향 개발에서 인터페이스를 쓰면, ‘인터페이스의 기능을 쓰려는 클라이언트’가 인터페이스에 정의된 ‘기능 명세’만 알고 내부는 어떻게 구현되었는지 의식할 필요가 없다는 것을 명확하게 알려주는 효과를 얻을 수 있다.

여러가지 지저분한 로직이 함께 포함된 클래스보다 좀더 ‘직관적’으로 ‘기능 명세’를 클라이언트에게 알려준다. 이점은 구현 클래스의 로직을 숨기는 효과도 있다. 구현 클래스와 구현 클래스의 로직을 숨길 때 얻는 효과는, 구현 클래스를 다른 클라이언트가 필요 이상으로 의존하고 조작하는 점을 막을 수 있다. 그래서 좋은 프로그램을 판단하는 기준인 ‘응집도를 높이고 결합도를 낮추는 효과’가 있다.

구현클래스와 구현 클래스의 로직을 숨기는 효과와 함께 다양한 구현 클래스와 로직을 쉽게 바꾸거나 확장 할 수 있기 때문에 ‘유연함’과 ‘확장성’을 높이는 효과가 있다.

클라이언트가 인터페이스만 알고 구현클래스는 모르는 상태이다. 이때 ‘클라이언트’와 ‘인터페이스’를 조작하는 ‘실행 클래스’가 ‘클라이언트’ 에게 어떤 ‘ 구현 클래스를’ 쓰게 할 것인지 선택할 수 있다.

예를들어 산골이라는 개발자가 객체지향을 공부하기 위해 책을 읽고 있었다. 그런데 개발자 산골이가 객체지향 책 인터페이스를 구현한 클래스에 직접 의존한다면, 개발자 산골이는 직접 의존한 책들만 읽을 수 있다. 개발자 산골이가 자신이 아는 책 말고 다른 책도 읽으려면 자신의 생각을 뜯어 고쳐야 하기 때문에(개발자 산골이 클래스의 내부 소스를 수정해야 하기 때문에), 개발자 산골이보고 다른 책도 읽어보라고 설득하기 어렵다.(기존 클래스의 소스 수정은 어렵고 위험한 적업이다.)

[그림 1.1.3-4, 객체지향 지식 습득에 문제가 있는 개발자 산골이]

그러나 객체지향 책 인터페이스 만을 참조한다면 어떤 책을 읽을것인지 프로그램이 실행 될때, 입맛에 맛게 고를 수 있다. 마치 개발자 산골이가 열린 생각으로 여러 책을 읽어보겠다는 긍정적인 마음과 같다.

[그림 1.1.3-5, 정상적인 객체지향 책 읽기 구성, 전형적인 인터페이스-상속-다형성을 활용한 클래스 구성이며 Strategy Pattern이기도 하다.]

그림 1.1.3-5처럼 인터페이스(또는 추상 클래스)를 활용하여 상속 객체를 만들고 상속 객체를 다형성을 이용하여 동적으로 객체를 생성하는 구성이야말로 객체지향의 효과를 볼 수 있는 전형적인 구성이다.

또한 Strateg Patter 이라는 디자인 패턴의 출발이 되며, 스프링 프레임워크의 IoC(Inversion Of Control, 제어 역행)기능에서도 항상 사용되는 클래스 구성이다.

이 클래스 구성의 중심에 인터페이스가 존재한다. 그래서 인터페이스는 객체지향의 정수이고 객체지향의 꽃이다.

인터페이스의 다른 특징으론 자바에서 다중 상속이 가능한 효과가 있다. 자바에서 클래스간의 상속은 여러 부모 클래스를 동시에 상속받는것이 금지되어 있다. 그러나 인터페이스를 쓰면 여러 특징을 가진 명세를 동시에 상속/구현하여 설계하려는 특색에 맞는 ‘클래스 패밀리’로 관계를 맺을 수 있다..

내가 처음 객체지향에 대해 배울때는 어려운 공학 이론 배우듯이, 객체란 무엇이고, 클래스란 무엇이고, 속성은 무엇이고, 이런 개념만 암기하려고 했기 때문에 제대로 활용하기가 어려웠다. 그러나 지금에 와서 느낀것은 무엇보다 객체 구성 요소를 골고루 알고 그중에 인터페이스의 정확한 뜻을 알고 그 용도를 이해해야만 객체지향 개발을 제대로 하는 밑거름이 된다는 것이었다.

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

어설픔의 독성

산골 — Mon, 15 Feb 2010 19:45:40 +0900

오랜만에 예전 회사 후배를 만나 많은 얘기를 나누었다. 너무할 얘기가 많아 대화 진행이 어려울 정도였다. 할 얘기가 없어 종동 대화 진행의 어려움을 느끼는 나는 이 상황이 신기했다. 그만큼 반가웠고 많은 얘기를 나누었다.

얘기중에 대화가 어떻게 흘러갔는지 '어설픔의 대가'란 비슷한 주제로 얘기를 나누었다. 근데 이 주제를 한번 블로그에 정리해도 좋을것 같다라는 생각을 했다.

예를들어 나한테 잘해주고 나를 생각해주는 듯 했던 사람이 있었다. 알고보니 그 사람은 알게 모르게 나에게 피해를 주는 사람이었다. 천부적으로 착한사람은 원래 좋은 사람이니 안심해도 좋고, 한눈에도 확실히 보이는 나쁜 사람은 미리 방어를 할수있기 때문에 걱정할 필요가 없다. 문제는 어설프게 착한척 하는 사람들이다. 이런 사람을 가려내지 못하면 심한 독에 서서히 노출되다가 심하게 중독되는 것과 같다. 엄청난 사람 스트레스에 시달릴 것이다.

문제는 나도 어설프게 착한척한 경험이 있다는 것이다. 언젠가 블로그로 봉사활동할수 있는 기회가 생겼다. 나는 블로그로 좋은일 할수 있다는데 열광하여 열심히 하리라 다짐하고 복지센터 방문도 하고 기사를 쓰기도 했다. 거기까지였다. 꾸준히 도움을 주어야 하는데 귀찮기도 하고 그곳의 분위기가 낯설었다. 특히 그 청년에게 미안했다. 그는 잘생기고 똑똑했지만 다리에 장애가 있었다. 그에게서 장애를 덮는 높은 자존심을 느꼈다. 근데 열심히 할것이라 얘기했던 블로거란 봉사자들이 맛 만보고 연락이 없다. 이사람들 역시 진정을 갖고 봉사하는 사람은 아니다. 착한척 하는 사람들이다. 라고 상처받았을 것이라 짐작했다. 미안하고 창피했다.

나의 회사 생활 롤 모델은 힘든 환경에서도 주변에 활기를 심어주는 에너지를 가진 '싱글벙글 개발자' 같은 사람이 되는 것이다. 이번에 새로운 사람들과 일하면서 나의 안 좋은 모습은 잘 감추면서, 더 나아가 싱글벙글 개발자가 되기로 했다. 이번 일터에서는 정말이지 나의 안 좋은 모습은 완벽하게 관리할수 있었다. 마치 착한 사이코패스 살인자 덱스터처럼 자신의 어둠을 잘 감추었다. 또한 싱글벙글 개발자 시도도 하곤 했다. 다소 차가움을 가진 동료한테 친한척하고 그 동료가 부탁하는일도 잘 하곤 했다.

그러나 내가 감당할 일 분량을 넘어서게 되었고 나는 점점 짜증이 나기 시작했다. 결국 그 동료와 이 일을 누가 할것인가를 놓고 대판 싸웠다. 사실 내가 적극적으로 싸운 이유는 위에서 이일은 그 동료가 하라고 지시했기 때문에 힘을 얻은 것으로, 나는 그 많은 일을 덜라면 싸워서라도 일을 덜어야했다.

결과 어설픈 싱글벙글 개발자는 일단 포기하기로 했다. 나의 최소한의 이익을 지키기 위해 때로는 잔인하기로 했다. 문제는 싱글벙글 개발자 행세하다가 갑자기 내가 강력하게 나오니 그 동료가 많이 당황했을 것으로 짐작한다. 나를 착하게만 본 동료에게도 미안했다.

내가 당한 경험 내가 했던 경험을 통해 나는 새삼 어설픔의 무서움을 깨달았다. 어설픔은 마치 조용히 몸을 장악하다가 한방에 치료 불가능으로 만드는 암과같다. 조용히 행성을 독으로 오염시키는 스타크래프트 저그의 마수 같다. 차라리 조금은 잔인한 사람이 되겠다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

객체지향을 이롭게 하는 5가지 특징, 수필 객체지향

산골 — Thu, 11 Feb 2010 08:00:00 +0900

+ 객체지향 생태계
우리는 객체지향 자연 속에 있다. 객체는 나무이며 애플리케이션은 숲이다. 낮은 해충(결합도)과 높은 영양(응집도)으로 유명한 객체지향 지역에 나무를 심고 울창한 숲을 기대한다.

땅은 객체지향 그 자체이다. 클래스 씨앗을 땅에 심는다. 씨앗이 생성자 통해 발아되어 객체가 되었다.

나무의 형태가 갖춰졌다. 속성은 줄기와 같다. 속성은 나무를 지탱하고 그 존재를 지키고 세상에 알리는 나무의 중심이다. 메소드는 가지와 잎과 꽃과 열매와 같다. 울창한 가지와 잎으로서 나무 자신과 산과 지구와 생물을 지켜주면서 자신의 존재를 뽐낸다. 이 나무들이 모이고 커져서 모든 생물을 이롭게 하는 거대하고 우람한 숲이 될 것이었다.

객체는 나무와 같아야하고 어플리케이션은 숲과 같아야 한다.

+ 객체지향을 이롭게 하는 5가지 특징
거대하고 우람한 숲을 가꾸기 위해 우리는 객체지향 방식을 선택했다. 객체지향 나무의 뿌리는 인터페이스와 같다. 뿌리가 튼튼하고 잘 뻗어 있을수록 나무는 우렁차고 나무의 생명력은 길며 나무가 전파하는 이로움은 크다.

메소드의 오버라이딩은 나무가 진화하고 나무의 도움으로 생물이 진화하는 과정과 같다. 나무들의 특징과 기능은 비슷하지만 땅과 기후에 적응하는 다양한 후손으로 생물들은 진화해왔다.

캡슐화와 정보은닉은 비처럼 은밀하게 다가와 숲을 안전하게 적셔준다. 그래서 산불을 막아주는 효과와 같다. 숲과 나무들의 고유 특징을 산불 같은 자연재해로부터 안전하게 지켜준다.

상속과 폴리모피즘은 태양의 에너지처럼 숲의 성장에 필요한 가장 근원적인 에너지로 발산된다. 상속과 폴리모피즘이란, 태양과 같은 기본적이면서 중요한 원리를 구현하지 않는다면 객체지향 숲이 존재할 이유가 없어진다.

상속과 구성은 인간의 인위적인 노력과 같다. 숲과 나무는 알아서 성장하지만 무서운 자연재해 앞에 그 성장이 더디기도 하다. 몇날며칠 비만 쏟아지고 해는 뜨지 않거나, 매서운 추위가 닥치거나, 숨막히는 산불이 숲과 나무를 위협한다. 상속과 구성은 이런 자연재해로부터 숲과 나무를 보호하는 인간의 인위적인 노력과 같다.

다시한번 객체는 나무와 같아야 하고 어플리케이션은 숲과 같아야 한다.

[삽화]

객체지향 세계는 숨겨진 보물이 가득찬 이상한 나라의 엘리스와 같다. 먼저 객체지향 세계의 인터페이스니, 오버라이딩이니,폴리모피즘이란 단어는 거부감이 든다. 한글로 풀어도 겨우 상속과 구성이라는 머리 아픈 단어로만 해석이 된다. 그래서 이 단어들은 이상한 나라의 엘리스의 괴물과 같다. 무엇보다 이상한 나라의 엘리스의 세계관을 이해하는데 한참 걸린다.

더 나아가 이상한 나라의 엘리스의 괴물도 이겨내고 세계관을 이겨내어 숨겨진 보물 찾기(유연성과 확장성)가 여간 힘든일이 아니다. 그러나 여기 ‘객체지향 보물지도’가 있다. 마치 구겨지고 누런 종이 쪼가리 속의 보물지도처럼 예쁘진 않지만 객체지향 세계를 이해하기 위한 중요한 단서들이 담겨 있는 지도이다.

[그림 1.2-1, 객체지향 보물지도]

위 그림을 머릿속에 저절로 그리는데 한참 걸렸던 것 같다. 이 그림이 그려질때가 되어서야 비로소 객체지향의 장점을 알고 쓰기 시작했다. 그 전에는 구구단 외우듯이 객체지향 특징을 공부했기 때문에 큰 그림을 그릴 수 없었다. 아마도 딱딱한 책 때문이었을 것이라는 핑계를 댄다.

우리가 객체지향을 공부하는 이유는 객체지향 시험을 잘보기 위해서가 아니다. 객체지향을 통해 좀더 나은 프로그램을 짜는 것이 목적일 것이다. 그렇다면 객체, 클래스, 상속의 사전적인 뜻만 외우지 말고 객체지향의 요소가 어떻게 뭉치고 상호작용하는지 ‘그림으로 그려야’ 한다.

객체지향 보물지도를 보면,
단서1. 인터페이스, 기본적으로 인터페이스나 추상 클래스를 선언한다.
단서2. 오버라이딩, 부모 인터페이스에서 정의한 기능을 상속 클래스마다 다르게 구현한다.
단서3. 캡슐화와 정보은닉, 각 클래스들의 중요 속성은 ‘높은 응집도와 낮은 결합도’를 위해서 안전하게 보호되어야 한다.
단서4. 상속과 폴리모피즘, 이 영역에 속한 클래스 다이어그램은 전형적인 상속 구성도를 나타내고 있다. 상속 클래스1,2,3 은 인터페이스에서 명시한 기능을 각각 다르게 구현하였는데, 이 클래스들은 부모 인터페이스만 의존하고 있는 ‘클라이언트’ 클래스에 동적으로 대입하게 될 것이다.
단서5. 상속과 구성, 클라이언트는 상속을 쓰지 않고 다른 4.영역 안에 있는 ‘객체 패밀리’에 의존하여 로직을 처리하고 있다. 이렇게 하면 프로그램 실행중에도 얼마든지 ‘상속 클래스’를 교체할 수 있다. 자유로운 교체와 확장이 가능하기 때문에 유연성이 높고 확장성이 높다.

이 다섯가지 요소가 객체지향 프로그램을 더욱 이롭게 만드는 기본적인 장점들이고, 이 장점들이 모이면 전형적인 ‘객체지향 보물지도’ 같은 패턴을 이루게 된다. 조만간 이 패턴은 곧 스트라테지 패턴으로도 불릴것이다. 객체지향의 핵심 개념을 이해하고 그 장점을 이해하기위해 이 그림을 머릿속에 그려놓고 시작하면 객체지향 보물을 발견하기 편할것이었다.

덧) 아직 고쳐쓰기가 덜 되었습니다. 예를 들면 도입부는 그럴듯하게 쓰다가 실제 설명부분에서는 풀어쓰는 부분이 덜 되었습니다. 어려운 용어의 풀어쓰기가 안되었습니다. 기타 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

속성, 메소드, 생성자 - 수필객체지향

산골 — Tue, 09 Feb 2010 08:00:00 +0900

+ 속성
속성을 찾는 일은, 보이지는 않지만 생물이 생존하는데 꼭 필요한 적혈구등의 요소를 현미경으로 관찰하는 생물학자와 같아야 한다.

속성은 객체 고유의 특징을 정의 할 수 있는 단어로 드러낸 것이다. 예를 들어 자동차에는 ‘움직일때의 빠르기’라는 속성을 속에 품고 있다. 만약 자동차를 객체로 모델링 한다면 기본적으로 ‘움직일때의 빠르기’라는 속성이 스며들어 있기 때문에 이 속성을 정의 할 수 있는 단어로 밖으로 드러내야 할 것이다. ‘움직일때의 빠르기’는 ‘속도’ 라는 단어로 정의 된다. 그래서 자동차 객체 모델링을 통해 ‘속도’라는 속성이 문서나 프로그램을 통해 드러나게 될 것이다.

객체의 속성을 찾는 일은 객체 안에 숨겨진 고유 특징을 찾아내는 일이기 때문에, 그 객체에 대해 잘 알고 있어야 한다. 그리고 그 객체의 중요하고 핵심적인 특징만 밖으로 추출할 수 있어야 한다.

그래서 속성을 찾아내는 일은 객체를 잘 ‘관찰’ 하고 객체의 주요 특징을 밖으로 ‘추상화’ 하는 사고 능력이 요구된다.

[삽화]

+ 메소드

메소드는 행동이라고 표현하고 기능이라고도 표현한다. 그런데 메소드의 의미는 그 객체가 다른 객체에게 제공하는 기능의 의미에 가까우므로 다른 객체에게 제공하는 ‘기능’으로 정의하는 것이 더 좋을 것 같다.

메소드는 객체 고유의 기능 또는 행동을 정의 할 수 있는 단어로 드러내고, 그 기능과 행동을 코드로 구현한 결과물이다.

메소드는 객체의 속성을 변경하는 통로이다. 객체지향의 효과를 얻고 객체지향의 관례를 따르면 속성은 외부로부터의 접근이 차단되어 있고 메소드를 통해서만 접근이 가능해야 한다. 그래서 메소드는 객체의 속성을 변경하는 통로가 된다.

만약 자동차의 속도를 증감 해야 하는데, 자동차 부품에 무리를 주지 않고 증감하려면 꼭 ‘속도 증감 제어 장치 메소드’를 통하게끔 구현이 되어 있다. ‘속도 증감 제어 장치’에는 자동차 객체의 속도를 객체 설계자 의도대로 변경하는 로직이 구현 되어 있다. 자동차의 속도라는 속성은 오직 ‘속도 증감 제어 장치’ 메소드에 의해서만 통제된다. 그래서 자동차 객체의 무결성, 안전성을 자동차 객체 사용자에게 보장할 수 있다.

메소드는 다른 객체와 상호작용하는 통로이다. 객체지향 세계는 객체와 객체간의 관계가 성립하고, 객체들끼리 주고 받는 메시지로 프로그램이 작동되고 결과물이 완성됨을 확인 할 수 있다. 객체들끼리 메시지를 주고 받는 도구가 메소드이다. 메소드를 통해 객체들끼리 상호 작용한다.

객체의 속성이 은밀하고 수동적이라면 메소드는 적극적이고 능동적이다. 다른 객체에게 ‘내가 제시한 기능을 쓰시오’라고 드러내놓고 노출하기 때문에 적극적이고, 객체들끼리 메시지를 주고 받으면서 자신이 속하는 프로그램의 결과물을 좌지우지하기 때문에 능동적이다.

객체의 메소드를 찾고 구현하는 일은 역시 객체 안에 숨겨진 고유 기능과 행동을 찾아내는 일이기 때문에, 그 객체에 대해 잘 알고 있어야 한다. 그리고 그 객체의 중요하고 핵심적인 기능과 행동만 밖으로 추출할 수 있어야 한다.

그래서 메소드를 찾아내고 구현하는 일은 객체를 잘 ‘관찰’ 하고 객체의 주요 기능과 행동을 밖으로 ‘추상화’ 하는 사고 능력이 요구된다.

[삽화]

+ 생성자

생성자는 식물이 씨앗을 벗고 발아하는 것과 병아리가 알을 깨고 부화하는 바로 그 순간에 해야하는 일과 같다. 생성자는 객체가 처음 생성될때 호출되는 메소드이다.

- 실행 클래스
public static void main( String[] args ) throws Exception {
    …..
    ExObject exObject = new ExObject(); // 1
    …...
}

- 예제 클래스
public class ExObject {
    public ExObject () { // 2
        // 객체 생성시 해야할 일
    }
    …..
}

위의 코드처럼 주석1, 실행 클래스가 예제 클래스를 생성하면, 주석2, 객체의 생성자가 호출 된다. 생성자는 객체가 최초에 생성될때 호출되는 곳이기 때문에, 객체가 처음 생성되었을 때 객체가 특별한일을 해야 한다면 생성자를 통해 편리하게 구현할 수 있다. 예를들어 병아리가 처음 세상에 나왔을 때 해야하는 일이 어미닭으로부터 먹이를 먹는 일이라면 생성자에 먹이 먹는 로직을 추가하면 된다.

객체가 처음 생성 되었을 때 해야하는 일이 있다면 생성자를 통해 편리하게 구현할 수 있다. 그리고 경우에 따라 여러 생성자가 필요하다면, 생성자의 ‘인자값’을 다르게 주어 같은 이름의 여러 생성자/메소드를 호출하는 객체지향의 ‘오버로딩’ 기법을 이용할 수 있다. 그래서 원하는 생성자를 호출할 수 있다. 또한 만약 생성자가 필요 없다면 생성자 코드를 아예 구현 하지 않아도 좋은데 이때 컴파일러는 기본적으로 아무 인자도 없는 ‘디폴트 생성자’를 기본적으로 구현하고 있다.

- 생성자 오버로딩 예제-실행 클래스
public static void main( String[] args ) throws Exception {
    …..
    ExObject exObject1 = new ExObject(); // 1
    ExObject exObject2 = new ExObject(“인자1”); // 2
    ExObject exObject3 = new ExObject(“인자1 “, “인자2”); // 3
    …...
}

- 생성자 오버로딩 예제-예제 클래스
    public class ExObject {
        public ExObject() { // 디폴트 생성자, 없어도 컴파일러에서 기본적으로 생성함
        }

        pulbic ExObject(String message1) {
            System.out.println(message1);
        }

        pulbic ExObject(String message1, String message2) {
            System.out.println(message1 + message2);
        }
    }

덧) 아직 고쳐쓰기가 덜 되었고, 삽화가 부족함을 이해해 주시길 바라며, 향후 책에 쓰일 원천 자료이기 때문에 펌은 불허, 링크 환영 합니다. 조언 부탁드립니다. ^ ^;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.