오랜 경험을 가진 프로그래머 일 수록 레퍼런스를 모른다???
정말 아이러니 한 말이지만 사실 맞는 말이기도 합니다.
오래된 프로그래머 일 수록... 4GL언어의 사용을 오래 한 사람일 수록 레퍼런스를 모르고 사용하는 사람이 많습니다.
사실 C++나 Java 부터 프로그래밍을 사용한 사람들은 레퍼런스 모르고 어떻게 프로그래밍을 하지? 라고 이야기 하는 분들이 많습니다.
그만큼 객체 지향이 강력한 개발 방법론 이기 때문입니다.
그런데 왜 객체지향방법론이 강력한 개발 방법론 이라고 이야기 하는 걸까요?
왜 요즘 MVC, MVVM, MVP등등 이런 모델 들이 대두 되고 라이브러리 화 되어 개발자들에게 이런 모델을 따르라고 강요 하고 있을까요?
따지고 보면 어떠한 방법론을 따르던 따르지 않던 프로그램은 안정적으로 실행 되고 오류만 나지 않으면 장땡 이라고 생각 할 수 있습니다.
수 많은 IT 개발 관련 서적들을 보면 OOP를 이야기 하고 OOP 개발 방법론에 따라 개발을 하면 유지 보수 하기 쉽고 뭔가 새로운 요구 사항이 발생 하였을 때 기능의 추가 및 변경이 쉬운 방법론은 OOP라고 이야기 합니다.
얼마나 많은 개발자들이 OOP를 이해 하고 레퍼런스를 이해 하고 있을까요?
일단 저 부터도 제가 얼마나 많이 OOP를 이해 하고 있는지 되돌아 보며 자문해 보기도 합니다. 늘 자답은 절망적입니다. 언제쯤 제대로 알고 사용할 수 있을지.... 늘 고민하게 되는 질문이기도 합니다.
Microsoft Visual C++의 프로그래밍 골격을 보면 예전 부터 View와 Frame과 Document 클래스를 구분해 놓고 MVC아닌 MVC 모델을 선구 했다고 봐도 무방합니다.
예전 알바 시절 만났던 모 전산실 모 개발자 분께서... 그 전산실은 모든 솔루션이... Visual Basic 6로 구현 운영되고 있는 기업 이었습니다.
도대체 문법서가 설명 하고 있는건 알겠는데... 도대체 왜 객체를 써야 하냐... 이게 뭐가 좋은거냐 라고 물어 보시는데.... 정말 마땅히 설명을 할 수 없겠더군요.. 이렇게 물어 보시니 그냥 문법서를 보라고 말씀 드릴 수 밖에 없는... 정말 어려운 질문 이었습니다.
제 나름대로 설명 할 수 있었던 것은
사실 OOP의 가장 근본적인 이론은 "내가 필요한 것은 나만 가지고 있으면 된다." 에서 부터 시작 합니다.
내가 가지고 있는 기능을 다른 객체가 가지고 있을 필요가 없다는 뜻이며, 어플리케이션이 무엇인가 행위를 하여야 할때 그 기능을 가지고 있는 객체에 실행을 위임하면 된다는 것이죠!(모든 소프트웨어공학의 정답은 인다이렉션이다 라는 이야기도 있습니다.)
이렇게 생각해 보았을 때의 OOP의 요지는 "가장 구린내 나는 코드는 여기 저기 중복 코드가 산재해 있는 코드가 가장 구린내 나는 코드다" 라는 겁니다.
다른 측면에서 보면 크게 보았을 때 어플리케이션의 구성 요소는 데이터와.. 현재 프로그램의 상태라는 두가지 구성 요소로 귀결 된다고 볼 수 있습니다.
사용자에 의거 하여 어플리케이션의 상태가 변경(이벤트의 발생) 되었을 때 이 상태를 어떻게 객체에 전달 하여, 객체가 가지고 있는 데이타를 변형하고, 변형된 데이타를 어떻게 출력 장치에 표현할 것인가? 라는 문제이죠.
때문에 객체간 이벤트의 전달 및 객체간 데이타의 전달이 어떻게 구성되고 이루어져야 하는지에 대한 설명이 가장 큰 핵심이라고 볼 수 있습니다.
결국 값 형식의 자료형과 레퍼런스 형식의 자료형을 어떻게 전달 하며, 전달이 이루어 졌을 때 어떻게 기능을 위임하여 처리 할 것인가가 모든 설명의 요지 입니다.
이렇게 함으로써 중복 코드의 방지가 이루어지고 중복 코드가 방지 되면 기능의 변형 및 수정이 용이 하고 이렇게 함으로써 프로그램의 유지 보수 관리가 쉬워 진다는 것입니다.
이 때문에 클래스를 사용하고 레퍼런스를 사용하는 것입니다.
결국 "어떻게 클래스를 만들어서 레퍼런스로 전달 하여.. 처리를 위임할 것인가?" 의 문제 입니다.
정말 수 많은 모델이며 방법론들 DCOM, COM, CORBA, WCF...... 등등등... 정말 많은 것들이 전부 사실 보면 데이터와 기능(코드)를 분산 집중 하는 방법인 겁니다.
어떤 기능과 데이타가 어떤 객체에 위치할 것인가의 고민이 어느 지역 어느 서버 어느 클라이언트에 위치하여 사용할 것인가의 문제로 확대된 것이기는 하나 원리는 그렇습니다.
그래서 리팩토링을 보면 재 활용성을 높이기 위하여 가장 먼저 실천에 옮겨야 하는 것이 "기능 구현시 코드를 쪼갤 수 있는 만큼 쪼개라, 이것이 재활용성을 높이는 발판이 될 것이다." 입니다.
이것이 중복 코드를 제거하는 지름길이며, 이것이 분산 집중 방법의 초석이 됩니다. 여기서 부터 시작인 겁니다.
이것이 왜 OOP를 써야 하는지 왜 레퍼런스를 써야 하는지에 대한 설명 입니다.
이것에 덧 붙여 OOP를 사용하고 있는 많은 개발자들이 4GL언어를 쓰고 있는 오래된 개발자들이 저지르고 있는 첫번째 실수를 무엇이라고 생각하냐 하면... 우리의 구루중 한명이신 찰스 펫졸드 아저씨도 말씀하고 계신 내용으로 "전역변수의 사용을 남발하지 말라!" 입니다.
전역 변수를 사용 이 객체 저 객체에서 공유하게 되면 각각의 객체가 가진 상태에 따라 데이타의 가공이 이루어져야 하는데 이 때문에 하나의 객체에서 데이터를 가공하게 되면 다른 객체에 영향을 주게 되고 이것은 어플리케이션의 안전성에 치명적인 악영향을 끼치게 된다는 것입니다. 이 치명적 악영향을 돌아가기 위해 객체는 또 각각의 객체가 다시 상태를 분석하여 처리하기 위한 쓸데없는 코드가 생성 되고 이것으로 코드는 점점 더 스파게티가 되고 유지 보수 하기 어려워지는 단점으로 전역 변수의 사용의 자제를 권장 합니다.
바로 이러한 이유 때문에 리팩토링을 하여야 하며, OOP 방법론의 코딩을 권장 하는 것입니다.
'Functional World > 리팩토링' 카테고리의 다른 글
| 리팩토링(Refactoring) 이란? (0) | 2013.11.01 |
|---|
WhatsNewNET45-en.zip
