출처 : http://blog.naver.com/seogi1004?Redirect=Log&logNo=110076487990
개발자라면 OOP라는 것을 최소한 한번은 들어봤을 것이다.
이 OOP라는 개념이 나온지가 거의 수십년이 되었고 하나의 트렌드로 잡혀서 실제 프로그래밍에 적용된지도 20년 가까이 되었다.
객체지향프로그래밍을 적극 반영한것이 Java, C++, Object pascal, PHP등등..
이젠 OOP를 언어차원에서 지원하지 않으면 안되는 세상이 됐다.
물론 OOP보다는 절차적 프로그래밍이 중요하게 사용되는 부분도 여전히 많기는 하지만 어쨌든 한참 예전부터 대세는 OOP였다.
그런데 이런때 일반 상식이 된 OOP를 들먹이는 이유가 있다.
OOP를 못하는 개발자자는 개발자의 적이다.
coding의 기본 틀은 빠른 속도? 짧은 코드? 아니다. 다른 개발자가 보기 쉽고 깔끔하게 정형화된 규칙으로 모듈화 된 것이다.
타인이 얼마나 빠른 속도로 이미 짜여진 코드에 빨리 적응할 수 있느냐가 그 코딩이 잘되어 있느냐 못되어 있느냐를 결정짓는다.
근데 OOP가 아닌 절차적 프로그래밍이나 OOP를 잘 지키지 못한 소스의 경우 개발한사람도 유지보수때 힘들겠지만
이후 유지보수에 들어가는 다른 개발자들은 정말 죽고싶은 충동이 날정도로 힘들게 만들어버린다.
기능 하나 추가 하려면 여기저기 다 뜯어 고쳐야 하고, 버그 하나 수정할때마다 사방에서 발생하는 side effect를 처리 해야 하고
아무리 잘된 문서가 있더라도 소스를 이해 하기 힘들다.
짜놓은 개발자 조차도 결국은 수정 못하고 다 뒤집어 엎기도 한다.
유지보수와 프로젝트 후반부에 가서는 OOP가 아닌 개발방법론은 개발자에게 독이되어 돌아오고 수많은 유지보수 이슈와 요구사항변경을 땜질하기 힘들어져서 개발자를 지치게 만든다.
아직도 많은 개발자들이 OOP에 대해서 많은 오해를 하고 있다.
몇가지 예를 들고 설명해보고자 한다.
1. 무조건 class만 사용하면 OOP이다.
OOP란 하나의 프로그래밍 방법론이다. 문제를 얼마나 효율적인 단위로 객체(모듈)화해서 개발자로 하여금 좀더 개발하기 쉽게
만들고 문제가 발생했을때 그 문제의 해결 범위를 축소시켜 기타 side effect를 최소화 하는 것이다.
그렇게 본다면 자바나 C++등의 class라는 예약어를 사용한다고 해서 무조건 OOP일까? 절대 아니다.
필요 없는 부분까지 class로 만들고 함수 한두개만 만들면 되는 상황인데 OOP랍시고 무조건 class로 만들고 객체를 생성시키게
만든다면 전혀 의미가 없다. 또한 효율적인 객체단위로 나뉘지 않고 이문제 저문제가 한꺼번에 다 들어있는 객체, 혼합되어
어떤 부분에 쓰일지 알수 없는 class등은 절대 객체지향이 아니다. 오히려 그런 class하나때문에 다른 많은 부분까지 수정을 해야 할
수도 있다. 착각하지 마라. class썼다고 자신이 OOP를 잘하고 있다는 생각은 위험하다.
"class란 OOP의 가장 기본적인 단위이며 Data와 Method(Function)의 집합체이다." 이걸 꼭 기억하자.
2. C언어 등에서는 OOP가 사용불가능하다.
OOP의 의미를 모르는 사람들이 하는 소리다. OOP란 기능이나. 절차를 모듈화하는 것이다. 다시 말해서 구현 범위를 기능 단위로
쪼개서 나눠 놓고 문제의 발생 범위를 축소 시키는 것이다. 쉽게 자동차 생산을 생각하면 될것이다. 조향장치, 전체 프레임, 엔진, 배기
시스템, 연료 공급부분 등 자동차에 고장이 발생했을 경우 해당 부품만 교환하거나 고치면 차는 문제 없이 작동한다.
소프트웨어 또한 마찬가지다. 그렇게 본다면 C언어를 통해서 개발할때도 이런 식으로 나눠놓는다면 OOP가 안되겠는가?
3. OOP를 하면 개발 속도가 늦춰진다.
초기 가시적인 개발 속도는 OOP가 늦다고 할 수도 있다. 하지만 구조적 프로그래밍을 하면서 초기에 빨리빨리 개발 되는 것처럼 보이
지만 OOP의 초기 모듈화 구축 단계를 넘어가게 되면 OOP가 훨씬 빠르다. "잘 개발된 프레임웍 한개, 열 코더 안부럽다" 라는 말을 하
고 싶다. 구현하는 곳마다 똑같은 일을 반복해서 구현 해줘야 하는것과 초기에 한번 잘 구성해놓고 이후부터는 엔진단에서 자동으로
작동한다면 어디가 더 빠르겠는가? 개발 후반부에 요구사항이 추가되거나 수정되면 그것을 적용할때 구조적 프로그래밍은 그걸 반영
하기 너무 어렵거나 아예 불가능 할 수도 있다. 하지만 OOP는 간단하다. 심지어는 구조적 프로그래밍의 경우 3일 걸릴것 3분만에 끝낼
수도 있다. 소프트웨어 개발의 대세는 유지보수의 편리성이다.
4. OOP를 하면 프로그램 크기가 커진다.
아니라고 할수도 없고 꼭 그렇다고 할 수도 없다.
만약 정말 작은 기능을 하는 프로그램이 있다면 굳이 OOP의 구현 프레임웍을 얻는 것보다 차라리 구고적 프로그래밍으로 하는 것이
프로그램 크기는 작아 질것이다. 하지만 프로그램이 일정 범위이상 넘어가게 된다면 애기는 완전히 틀려진다. 100개의 Page를 개발하
는 프로젝트에서 OOP로 하지 않는다면 100개 모두에 같은 동작을 코드로 넣는다면 OOP의 프로그램크기가 훨씬 작다.
6. OOP를 하면 프로그램 속도가 늦다.
처리 단위를 함수 하나로 하고 switch case문으로 처리 하는 것에는 당연히 함수 포인터가 이리저리 불리고 하는 OOP보다는 빠를 것
이다. 하지만 이미 시스템이 고속화 되고 폰에서도 3D게임이 돌아가는 현실에서 사용자가 체감하지 못하는 그 작은 속도의 차리때문에
인력과 시간을 낭비할 필요는 없다고 본다. 결론은 그런식의 처리보다야 약간 늦기는 하다.
7. OOP를 사용하려면 엄청난 설계 기술이 있어야 한다.
사고를 어떻게 하느냐다. 문제를 보고 문제의 세부 구현 단위를 작게 쪼게서 볼수 있느냐와
뭉퉁그려서 한번에 그 모든것을 한곳에서 다 처리 해야 한다는 것의 차이이다.
개념만 살짝 바꾸면 전혀 어렵지 않다.
8. 상속깊이가 깊으면 멋진 OOP이다.
OOP를 처음 배우는 개발자들의 일반적인 오류인데 절대 그렇지 않다. 한때 프레임웍들의 상속구조가 깊고
복잡한것이 유행했었다. 하지만 그렇게 될경우 개발자들이 그 프레임웍을 이해하는데 오래 걸리고 쉽고 유
연하게 사용하기 힘들다. 상속이 너무 두꺼울 경우 수정 이슈가 있을때 수정하기 어렵고, 작은 기능을 하나
수정하기 위해서 많은 이해를 필요로 한다. 필요한 부분들만 간결하게 Class화하고 상속또한 가볍게 한것
이 멋진 OOP라고 할 수 있다.
