C와 C++ 경계선에 대한 궁금증요....

동감입니다.

그리고 printf()도 C++의 표준함수 입니다.
표준 함수중에 자신의 스타일에 사용하는 것은 아주 다반사 입니다.
C에서의 goto사용 문제와 같이...

<어떠한 역경에도 굴하지 않는 '하양 지후'>

ps. std::string만을 쓰기 위해 C++을 배운다고 해도 본전은 뽑는다고 생각합니다.

happycat, doldori님의 논리라면 JAVA 프로그래밍을 하면서, 자바는 클래서 시작부분만 선언을 하고, 나머지는 native code만을 사용하시는 것도 너그러이 용납이 가능하신것 같습니다...
이것도 코드 스타일 문제이겠지요.
저같은 경우는 코딩에 좀 편집증 적인 데가 없잖아 있습니다.
전 C를 할땐 C를 사용할 땐 C특징의 문법을 선호하고, C++을 사용할 땐 C++의 특징을 살린 문법을 선호하고, JAVA를 사용시에는 JAVA 특유의 문법을 사용할려 할 뿐입니다.
그렇지 않으면 각 특유의 언어는 존재 이유가 없지 않나 생각을 합니다.
속직히 class하나 선언 되지 않은 C++프로그래밍은 좀 황당하다고 생각을 할 뿐...ㅡㅡㅋ

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

이 얘기는 구현상의 차이니 크게 의미는 없는 것이고, 중요한 것은 printf()와 cout의
개념적인 차이입니다. cin/cout은 타입에 대해 안전한 반면 scanf()/printf()는
그렇지 않습니다. 다음 코드는 어디가 잘못일까요?

double d;
scanf("%f", &d);
printf("%f\n", d);

그리고 퀄리티라고 하면은 무슨 퀄리티를 얘기 하는건지?
시간대비 아웃풋인지?
실제 프로그램의 포퍼먼스인지?
시간대비 아웃풋이라면 팀구성원들이 C++ 문법에 익숙하다면 별 무리없이 C++로 가는게 맞겠지만, 실제 프로그래밍의 포퍼먼스가 중요하다면 무조건 0 1 입니다.

속직히 저는 아직도 C++의 최대 장점은 class를 이용한 좀 더 체계적인 소스 관리에 있다고 보는데...
뭐... 또 다른 관점에서 보시는 분들이 있겠죠.

함...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

class가 C++의 전부는 아니지만 가장 중요한 거 하나를 꼽으라면 단연 class가 꼽히겠죠. class를 안 쓰고 문제를 해결할 수도 있지만 C++ 쓰면서 class를 안 쓴다는 것은 망치로 못을 박는데 망치 대가리로 박는 게 아니라 망치 손잡이로 박는 거랑 비슷한 거라고 봅니다.

그리고, 사실 이제 OOP가 SP(Structured Programming)보다 낫다는 것은 어느 정도 입증된 바가 아니던가요? SP의 문제점을 해결하고자 나온 개념이고 이미 많은 곳에서 그 가치가 입증된 바 있기에 C를 쓰더라도 OOP에 가깝게 하려고 노력하는 사람들이 있는 것이죠. 그런데 OOP를 지원하는 언어를 쓰면서 OOP적으로 코딩하지 않는다면 좋은 프로그래머라고 하기 어렵겠죠.

OOP가 좋다는 것은 이미 80년대 중반에 끝난 이야기이지만 그 좋다는 OOP에 어떻게 도달할 것인가에 대한 논의는 90년대 중반까지 큰 진전이 없었습니다. 그런데 자바 진영이 성장하면서 그 "어떻게"가 급속하게 발전했죠. OOP를 지원하는 언어가 다양하고 C++은 오랫동안 사용되어 왔음에도 불구하고 이런 논의가 자바 진영에서 발전하게 된 것은 아마도 class를 쓰지 않고는 아무 것도 할 수 없게 만든 자바 문법의 영향이 아닐까 하는 생각이 듭니다.

전 이제 OOP가 지원 안되는 언어는 다시 들여다보고 싶은 생각이 들지 않습니다. 사실 C++도 OOP에 좋은 언어라고는 할 수 없죠. class 하나 만드는 부담이 작을 수록 OOP하기 좋은데 C++은 class 하나 만드는데 들어가는 노력이 자바나 파이썬, 루비 등에 비하면 상당히 큰 편이죠.

대형마트에가면 이것저것 여러가지가 있더군요..
그냥 대~~~~충.. 이것저것 생각없이 구경하다 맘에드는것 있으면
골라잡고 싶을때 거기갑니다.
그런데 뭐좀 전문서적이나 부품 등을 구할때는 설사 거기(대형마트)에서 구할수 있다해도 잘안갑니다. 같은거리면 전문점을갑니다.

좀비약하지면..ㅎㅎ:
뭐든지 다한다.. => 뭐하나재대로하는게 없다..뭐그런뜻과도..
통한다나..뷁.뷁.

근데 또 반대로 보면은 현재 C의 존재 의의는 ... ?
단지 C를 애호하는 애호자들을 위한 써비스일 뿐인가?
이미 C++에서 C의 대부분의 기능이 들어 있는데 굳이 C를 사용하는건 C++프로그래머의 입장에서 매너리즘으로 밖에 보이지 않나요?
이 부분도 궁금하군요.

그리고 C++에서의 멀티 패러다임의 정의도 아주 금궁하군요.
전 이 쓰레드에서 처음 보는 용어 같은데 ㅡㅡㅋ
위에도 몇 분이 언급을 하시는 군요.

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

추신_근데 이 C와 C++의 논쟁 언제해도 끝이 없군요.

C++로 프로젝트를 하면서 class하나 없이 작업을 하시는 분들은 C++하면 "CLASS"를 외치시는 분들이 어떻게 보이시나요?
하등 별로 아는것도 없는 놈이 들은 거는 있어서 그러는 구나 그렇게 생각을 하시겠군요. ㅡㅡㅋ
단지 class를 사용하는 사람은 단지 자기 만족에 의해서 하는 구나 라고 생각을 하시는 경향이 있는듯 하군요.
항상 C++에서 class를 강조하는 스트뭐시기뭐시기 라는 사람도 아주 난감하게 보이시겠군요.
그리고 C++의 모태가된 class가 단지 하나의 기능일 따름 이었군요 ㅡㅡㅋ
전 여태까지 C와 C++의 정말 큰 차이는 class개념이라고 생각을 했으나 이 얘기또한 우스운 얘기가 되어 버리는 군요 ㅡㅡㅋ

하...

결국은 (C++ == C)라고 주장을 하고 싶으신 건지?

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

추신_php에도 class있지만 보통은 하나의 기능을 파일단위로 나눠서 하는데 굳이 class를 나누는건 아주 특이한 경우가 아닐까 생각을 합니다. ㅡㅡㅋ
뭐... 이렇게 따지면 C++도 그렇게 할 수 있지만 서도 ㅋㅋ

C++의 탈을 쓴 C라는 말의 의미는 그 코드가 C++에서 컴파일되고 C++의 기능을 일부 쓰긴 하지만 C코드랑 별 차이 없고 C++의 중요한 장점을 활용하지 못했으므로 삽질이다...이런 뜻이겠죠. 그런데 어쨋든 C++의 기능을 썼으니까 그것도 C++이지 뭐..하는 식으로 접근하면 좀 곤란하죠. 젓가락은 포크에 비하면 아주 멀티 패러다임 식사 도구죠? 그런데 젓가락으로 햄을 집어 먹는 게 아니라 포크처럼 찍어서 먹는다면 저건 젓가락의 탈을 쓴 포크야..라고 말해도 별 무리가 없겠죠. 마찬가지로 C++에서도 C++의 가장 중요한 장점을 활용하지 않았다면 C의 탈을 쓴 C++이라는 비난을 받아도 할 말이 없지 않겠습니까.

그럼 C++의 가장 중요한 장점이 뭐냐. 하나 꼽으라는데 class 말고 딴 거 꼽으실 분이 있나요?

그리고 유독 kldp에서는 OOP나 SP나 선택의 문제인양 말씀하시는 분들이 많은데 이건 거의 끝난 논쟁이라고 봅니다. 당연히 OOP가 훨씬 좋죠. SP가 나은 경우도 있다? 글쎄올시다. SP도 이미 복잡성 때문에 모듈화를 하는 것이고 OOP와의 차이는 함수로 모듈화를 하느냐, 객체로 모델링하느냐의 차이 뿐인데 과연 함수로만 쓰는 게 더 쉬울까요?

모든 것의 클래스화가 좋은가..하는 의문이 생기는 것 자체가 좀 비 OOP적이라고 할 수도 있겠습니다. 사실 OOP는 무언가를 일부러 클래스로 만드는 것이 아니라 프로그램해야할 대상을 그대로 코드로 옮기는 것입니다. 그런데 그 대상을 먼저 SP적 사고로 옮긴 다음 이걸 OOP로 다시 옮기려고 하니까 이게 부담스럽게 느껴지는 것이죠. 제가 가끔 하는 얘기 중에 code for human, not for programmer라는 말이 있는데 SP가 code for programmer라면 OOP는 code for human이죠. 사실 오히려 프로그래밍에 무지한 초보자를 가르쳐보면 OOP를 훨씬 더 쉽게 받아들이고 SP보다 더 빨리 한 사람 몫을 하게 됩니다. 그만큼 인간에 더 가까운 방식이라는 얘기겠죠.

머 어쨋든 OOP가 SP보다 낫기는 하지만 다른 OOP 언어에서는 안 나오는 이런 이야기들이 유독 C++에서만 나오는 것은 C++에서 클래스를 만드는 부담이 꽤 크기 때문입니다. C++은 이미 잘 만들어진 클래스 라이브러리를 가져다 쓰기는 아주 편리합니다만 그 클래스 라이브러리를 만들고 조직화하는 것은 다른 OOP 언어에 비해 아주 불편합니다. 그래서 사실 C++에 한해서만큼은 class 사용이 나쁠 수도 있다는 말들이 나오는 것입니다. 이로 인해서 OOP 자체가 SP보다 못할 수도 있다는 생각으로 연결되지는 말았으면 합니다.

사실 C++ alternative에 대해서는 시장의 요구도 적지 않습니다. 시스템 프로그래밍의 범위를 커버하면서 객체지향을 지원하는 언어가 C++ 외에는 그리 popular한 것이 없기 때문에 여기저기서 논의가 많았었죠. 자바도 C++ alternative로 이야기되곤 합니다만 커버하는 범위가 좀 다르다는 생각입니다.

머, 어쨋든 class 안 쓴다면 C의 탈을 쓴 C++이라는 말을 들어도 항변하기 좀 어려울 것 같군요.[/b]

offtopic 입니다. 함수 단위의 랩퍼이면서 기능셋에 따라 정리를 하고 싶은데 global에서 중복되는게 싫다면 네임스페이스를 사용해 모듈로 정리하는 쪽이 낫지 않을까 생각됩니다. 객체를 사용하겠다면 싱글턴 패턴쪽도 좋겠구요.. global 선언에 비해 몇 가지 장점이 있습니다.

ps. global을 개인적으로 싫어하긴 하지만, 역시나 필요에 따라서 사용하는 데에 반대하지는 않습니다 ^^;; 싱글톤 사용하는 게 너무 거창하면 저도 종종 사용합니다.;;

OOP의 장점이 재사용성에 있다는 것은 90년대까지의 이론이고 CBD의 배경이 되었던 이론이죠. 하지만 CBD는 이제 역사의 저편으로 사라져가고 현재는 코드의 재사용에 대한 미련-_-을 다들 버려가는 추세입니다. 어차피 비즈니스는 계속 변하므로 재사용의 의미가 크지 않다는 거죠. 그래서 요즘은 변화에 빨리 대처할 수 있도록 코드를 금방 금방 바꿀 수 있는 유연성이 강조됩니다. OOP는 오히려 이런 면에서 강점을 보입니다. 같은 정도의 변화를 가져오기 위해 소스 코드를 더 적게, 그리고 더 human readable하게 수정할 수 있기 때문이죠. 다른 말로 리팩토링의 영역이 더 넓다는 이야기도 됩니다.

class에 넣는 것보다 global function에 넣는 것이 더 재사용성이 높은 경우? 과연 그런 경우가 있기는 할까요? class에 포함될 경우 다형성, 상속 등의 이점을 누리기 때문에 훨씬 확장성이 좋습니다. 당연히 재사용성도(그 실체가 의문시되긴 하지만) global function보다 더 높죠. 사실 이 둘을 비교 대상으로 놓는 것 자체가 이상합니다. class는 data+method(function)이고 function은 그냥 function인데 어떤 것을 class로 만들까 global function로 만들까 고민한다는 것 자체가 이상하죠. OOP에서는 대부분 data와 method가 같이 움직이니까요. 그래서 위에 저런 말을 한 것이죠.

물론 클래스 없으면 아무 것도 못하는 자바에도 static method가 있어서 global function의 역할을 합니다. 이 경우의 클래스는 단순히 namespace 이상의 역할을 하지 않죠. 근데 이렇게 쓰는 것은 재사용성이 때문이 아니라 구현하려는 기능이 어떤 object에 속한다고 보기 힘들기 때문입니다. 주로 유틸리티 클래스들이 이런 식으로 작성되죠. 이런 메쏘드들은 만들기도 쉽고 사용하기도 편하지만 재사용성은 떨어집니다. STL에서 method와 global function의 구분도 주로 이런 기준으로 되어 있습니다.

이런 식으로 그 말을 해석하신다면, 말씀하신 결론을 도출하는데 아무런 문제가 없겠으나, 문제는 이 말은 일종의 '비난'이라는 것입니다.

C syntax만을 사용해서 (물론 C++의 다른 feature를 사용하고) C++ compiler에 돌린다고 해서 비난받을 만한 일일까요?

오히려, 요즈음 같이 언어들이 한결같이 OOP를 지향하고, 빠르게 발전하는 상황에서, 특징적인 syntax 만으로 언어를 선택한다는 것이 더 이상할 수도 있습니다. 실제로는 오히려, 문제 도메인에 적합한 라이브러리/프레임워크나, 사용 가능한 인력, 언어의 개발/실행 환경 등의 실리적인 요건들에 더 영향을 받는다고 얘기할 수도 있습니다. 다 같이 OOP를 지향하는 문법도 비슷비슷한 high level language임에도 불구하고, java, php, python 등은 그 어플리케이션이 충분히 분화되어있습니다. 왜 그럴까요?

OOP도 modular programming에서 분화된 것입니다. object는 algorithm+data라는 관점이 있죠. 그렇다면, 하나의 data에 관한 algorithm을 하나의 파일에 잘 분리해둔 pascal 프로그램도 OOP를 한 것인가요? 그 파일과 class의 차이는 무엇일까요?

procedural programming과 object-oriented programming의 큰 차이중 하나는 control의 분배에 있다고 봅니다. procedural의 경우에는 hierarchical한 control 구조를 가지는 반면에, OOP에서는 각각의 object가 autonomous한 존재로 잘게 쪼개진 작은 control을 가지고 있죠. (이러한 면에서 Controller/Manager 역할을 하는 object 모델링은 흔히 잘못되었습니다.)

저는 문제 도메인에 따라서 이러한 두가지 방식은 적절할 수도 적절하지 않을 수도 있다고 생각합니다.

예를 들어, 장인이 나무 조각품을 만드는 과정을 모델링한다고 생각해봅시다. 장인은 나무를 고르고, 여러가지 도구를 사용해서, 대략의 모양새를 만듭니다. 그 다음에는 좀 더 세부적인 조각을 합니다. 그 다음에는 색상을 입힙니다. 칠이 충분히 마르면 광택제를 바르고 다시 말립니다.
이 과정을 Object들로 나타내봅시다. 장인과, 나무 조각품, 여러가지 도구들. 뭔가 상당히 부족하지 않습니까? 왜냐하면 나무 조각품을 만드는 과정에서는 control이 여러 object로 분배될 여지가 거의 없기 때문입니다. 장인의 role에 따라 object를 나눌 수는 있겠지만, hierarchical한 job들로 나타내는 것보다 어떤 점에서 더 나을까요?
반대로, 흔히 OO modeling의 예로 등장하는 월급 주기 시스템을 생각해보죠. 월급을 주는 사장, 회사의 경리 담당자, 월급을 받을 노동자, 은행 시스템, 기록자 여러 사람들에게 control은 분배되어있고, 이를 hierarchical하게 표현하는 것은 문제 분석가에게 상당히 괴로와 보입니다.

이렇게 문제의 성격에 따라 OOP를 선택할 지, PP를 선택할 지는 달라질 수 있다고 생각합니다. 하드웨어 부문과 같이 소수의 controller가 이런 저런 책임들을 가지고 있는 곳은 일부러 object로 모델링해서 떼어내는 것보다는 PP가 효율적이라고 생각합니다. 반대로, 인간 사회의 complexity를 반영하는 문제일 수록 OOP가 더욱 어울린다고 생각합니다.

덧붙여, OOP가 인간의 생각을 잘 반영한다는 얘기를 많이 합니다. 하지만 저는, OOP가 우주나 사회와 같은 거대한 complex system에 관한 인간의 생각을 잘 반영하긴 하지만, 인간의 모든 생각을 완전히 반영하는 것은 아니라고 생각합니다. 의외로 인간은 중앙 집중식의 조직이나 생각에도 익숙하죠.

음, 이 글타래 여는 글은 비교적 가볍게 시작했지만, 내용이 갈수록
진지해지는군요 :D

저는 아는 바가 별로 없어서, 매우 조심스러워집니다만,
이 글타래에서 이상하게 느낀건 printf와 cout을 섞어쓸수
있다는 것을 용인하는 분위기였습니다.
뭐 가능이야 하죠.
하지만, 정말 그러면 그게 cpp인거냐를 놓고보면, 그 사소한부분에서도
좀 갈리지 않나 싶은게 제 생각입니다.

저는 일단 creativeidler님 말씀에 동의합니다.
kldp에서 이미 결론난것처럼 보이는 이야기가 역전되서 보이듯하는
현상은 어쩌면 system engineer들이란 점과 최적화라는 것이
맞물려져 생기는 현상인건 아닌가 싶긴 합니다.
언어 자체의 이해문제는 차치하고 말이죠.

대개의 실무에서 사용하는 cpp코드를 보면, class설계, 사용의 엄격함은 어디론가로 사라지고, 저게 cpp인걸까 싶은 구석은
단지 cc, hh파일로 분화시켜놨다는 것일 뿐, 여기저기서 마구잡이식으로
struct사용하듯이 써버린 코드들이 제법 있었습니다.
시작은 "class"부터 타이핑했으되 종국엔 c코드가 되어버리는 겁니다.

정말이지, cpp는 class를 제대로 설계하기가 쉽지 않습니다.
아니 그보다는 과제의 진행에 맞추어 class를 수정발전시켜나가기가
쉽지 않다고 해야 맞는 말 같습니다.

JosephJang님은 분명 상당한 경험과 연륜을 갖추신 분이실것 같습니다.
제 주위에도 JosephJang님과 같은 생각을 갖고 계신 분들이
제법 계시죠.
그러면 그분들에게 왜 c코드처럼 cpp를 사용하냐고 물어보냐하면
그러지 않습니다. 아니 못한다고 봐야겠죠.
적어도 시스템은 잘 돌거든요.
하지만, 어떤 분같은 경우, 그분에게 있어 class란 function pointer를
갖는 struct이상이 아닐정도의 의미밖에는 아닌것처럼 보이는 양반도 있습니다.(덧붙여 갖다 쓰기 쉬운 library들^^;)

하지만 구분지을건 확실히 구분지어야지 않겠습니까?
cpp compiler로 compile되는 코드라고 해서 그게 cpp code인거냐
하면, 그건 아니라고 봅니다.
그럴바엔 차라리 과제를 c part, cpp part로 나눠서 설계하는것이 맞다고 생각합니다.

덧붙여, 저는 요즘 python을 공부하는 중인데, java, python, php등을
용도라는 측면에서 분화되었다고 하기엔 무리가 있지 않을까 싶습니다.
제가 oop라는 학문 자체를 체계적으로 공부해본 경험과 깊이가
적어서이기도 하겠지만, cpp는 과제를 진행하는데 너무 burden이
많은 언어였다는걸 새삼 깨닫곤 합니다.(즉, 전 cpp예찬론자(?^^)는
아니란 뜻입니당.)

두서없이 길어져버렸군요^^;

제생각엔 언어가 그냥 도구이기만 한건 아닌것 같습니다 :D

논의가 매우 길어졌군요. OP의 원래 질문에 대해서 제 생각을 말씀드리면...

다른 얘기지만, 이왕 배우시는 거라면 재미있게 배우시면 좋겠습니다. 클래스를 반드시
써야 한다는 강박관념 같은 것은 떨쳐버리시고요. 자신에게 쓸모있는 것, 이해하기 쉬운
것부터 조금씩 배운다면 언제부턴가 C++ 프로그래밍이 즐거워질 것입니다.

1. 타입 안전성: 위에서 예를 들었습니다. 입출력 서식이 잘 정의되어 있다는 점도
해결책이 되지는 못합니다.

2. 예외 안전성

void f()
{
    FILE* fp = fopen("myFile", "r");
    // an exception is thrown here
    fclose(fp);
}

3. 유연성
printf()을 템플릿에 사용하는 것은 불가능합니다.

template<typename T>
void print(const T& value)
{
    printf(???, value);
}

4. 확장성과 유연성이 좋은 C++의 locale은 FILE과 맞지 않습니다.

요약하면 FILE은 C++의 다른 특징들과 결합해서 사용하기에는 무리가 있습니다.

좀 다른 이야기인 것 같습니다. 그건 interface와 implementation의 분리 문제이지 global function이냐 method냐의 문제는 아닌 것 같군요.

자바의 Collection들과 java.util.Collections, java.util.Arrays 클래스의 역할 차이를 생각해보시면 될 것 같습니다. 제가 보기에 STL도 이런 관점에 상당히 가깝습니다.

스펙이 좀 덜 상세하긴 하지만 두 케이스 모두 OOP로 아주 쉽게 모델링할 수 있는 예제인 듯 보입니다. 전자의 경우를 예로 든다면 여러 가지 도구 객체에 기능을 분배하고 장인 객체에서 composition을 하면 간단한 문제가 되겠죠.

OOP라고 해서 꼭 실세계를 그대로 object로 만들어야하는 것은 아닙니다. 어떤 data에 종속되는 process가 아니라면 위에서도 언급한 것처럼 유틸리티 클래스나 global function으로 구현될 수도 있고 이런 부분이 들어간다고 OOP가 아닌 것도 아닙니다. 필요한 부분에 필요한 것을 쓰는 것은 OOP라고 해서 다르지 않습니다. 하지만 정작 코딩하다보면 이런 필요성이 그리 크지 않습니다. 객체의 메쏘드를 이용하는데 드는 비용을 줄이기 위한 단축 메쏘드, 유틸리티성 메쏘드들을 제외한 실제 모델링 대상은 data에 종속되지 않는 경우가 많지 않습니다.

시스템 프로그래밍에서 OOP가 덜 쓰이는 것은 OOP가 적합치 않기 때문이라기보다 역사적인 이유가 더 큽니다. 전통적으로 시스템 프로그래머들은 OOP에 익숙치 않고 또 critical한 부분에서 C 스피드를 내는 OOP 언어가 없기 때문이죠. 그래서 요즘은 덜 critical한 부분에서는 C++이 많이 쓰이는 것이구요. 요즘 다시 임베디드 시스템, 하드웨어 디자인, 하드웨어와 소프트웨어의 연계 등을 공부하고 있는데 보면 볼수록 OOP가 가능하다면 정말 행복할 텐데 하는 생각이 많이 듭니다.

OOP가 비효율적이라고 느끼는 경우를 보면 대체로 top down 모델링을 합니다. UML 기반 방법론들에서도 이런 방식을 제시하죠. 하지만 이것이 바로 OOP를 비효율로 이끄는 길입니다. OOP가 실세계를 표현하기 좋다지만 그렇다고 실세계를 그대로 OOP로 모델링하려고 하는 것은 좋은 방법이 아닙니다. 왜냐하면 실세계 자체가 쉽게 추상화할 수 있을 정도로 단순하지 않기 때문에 인간이 이것을 추상화해서 OOP 모델로 만드는 것이 쉽지 않기 때문이죠.

이런 상황에서 OOP로 가는 길을 명쾌하게 제시해주는 것이 바로 TDD와 리팩토링이 아닐까 합니다. 처음부터 class를 디자인해놓고 코딩하는 것이 아니라 코딩하면서 중복을 제거하는 과정에서 자연스럽게 class가 분화해나가는 것이죠. 이렇게 하다보면 어느 새 실세계가 아주 자연스럽게 추상화되어 있는 경우가 많습니다.

그래서 전 사실 OOP 자체를 따르는 것보다 TDD를 하는 것이 더 중요하다고 봅니다. OOP에 부정적인 경험을 갖고 있는 분들은 TDD를 한 번 해보시기 바랍니다. TDD에 익숙해지면 OOP 안되는 언어는 쳐다보기 싫어질 겁니다.

급여 이달급여 = new 급여(new Date());
for 사원:
    급여.줘(사원);

제가 코딩에서 가장 중요하게 생각하는 가치는 얼마나 빠르게 만들 수 있는가, 그리고 얼마나 읽기 좋은가 두 가지입니다. 다른 부분을 제하고 이 부분만 놓고 볼 때도 SP가 OOP보다 나은 경우가 있다고 생각하십니까?

제가 볼 때는 SP가 OOP보다 나은 점은 컴파일러 최적화가 좀더 쉽고 그래서 시스템 프로그래밍이나 임베디드 같은 critical한 환경에서 성능 면에서 장점을 가질 수 있다는 것, 그것 밖에 없는 것 같습니다. 혼자 만드는 장난감 프로그램이 아닌 바에야 생산성, 가독성에서 SP가 OOP를 앞설 수 있는 경우는 거의 없다고 봅니다.

그리고 설령 전체적인 코드량이 줄어들지 않더라도 프로그래머가 생각해야하는 코드량은 줄어듭니다. 위에도 적은 것 같은데 흔히 OOP 코드를 이해하기 어렵다고 말하는 이유는 코드를 따라가면서 이해하려고 하기 때문입니다. 간단한 예를 들어 보자면,

PermissionResolver resolver = new PermissionResolver();
resolver.getRequiredPermission(request);

사실 이건 OOP에 대한 많은 연구에서 이미 드러난 것이 아니던가요. Python이 C보다 10분의 1의 코드로 같은 일을 할 수 있다는 이야기는 이미 새로운 것도 아니잖습니까. 물론 그것이 순전히 OOP 때문만은 아니지만 클래스를 제외한 문법에서 C와 별 차이 안 나는 Java도 C에 비해 3분의 1 정도의 코드로 같은 Function Point를 소화할 수 있다는 점을 생각해본다면 OOP야말로 적은 코드를 만드는 일등 공신이 아닐까요?

얘기를 하다보니 논점이 흐려진 감이 있군요. 원래는 OOP와 SP가 선택의 문제 조차도 되지 않는다는 말씀때문에 처음 답글을 단 것입니다. 즉, 저는 단지 "거의"라는 말을 듣고 싶었던거죠.

또한 일반적으로 FP,SP,PP 는 서로 비슷한 특성을 지니고, OOP와는 완전히(??) 다른 특성을 지니 때문에, FP,SP,PP를 거의 하나로 보게 되는 경우도 많습니다. (제 경우만 그렇다고 생각하신다면.. 머 그럴수도 있습니다..)
혹시 PP, SP, FP, OOP의 명확한 개념적인 구분을 설명해 주실수 있으실런지요. 또한 개념적으로 서로 상호배타적이다 라고 자신있게 주장하실 수 있는지요.
PP, SP, FP 는 C 와 같은 언어가 주류를 이루던 시대에 만들어진 방법론 입니다. 그렇기 때문에 PP, SP, FP 를 서로 비슷하게 보는 경향이 많구요. 실제로 프로그램을 짜면서, PP 적으로만, 혹은 SP 적으로만, FP 적으로만 짤 수 있는것도 아닙니다. 그때그때 필요에 따라 서로 섞어 써야 겠지요...
OOP의 경우에는 이후에 갑자기 대두되었다고 생각합니다. (물론 그 이전에도 OOP적 프로그램 방법론이 있었고, OOP를 지원하는 언어가 있었다고 생각할 수 있겠지만, 아무래도 유명세를 타기 시작하면서, 대두가 된 것은 좀 이후라고 봅니다.) 또한 OOP 의 경우에 operation/function 이외에 data를 한데 묶어 하나로 다루는 특성으로 인해, 다른 방법론과는 좀 다른 특징을 가지게 됩니다.
그렇기 때문에 PP,SP,FP를 OOP와 대조해가며 비교하는게 보통입니다. 여기서의 논쟁의 취지도 _P 와 OOP와의 비교에 있지 않나 생각합니다만...

제가 생각하기에 OOP가 가장 좋은 개발방법론 이다라고 생각하지는 않습니다.
경우에 따라 OOP가 좋은곳도 있고, PP, SP, FP 가 좋은곳도 있다 라고 생각합니다.
"어떤방법이 최고다"라고 하는 일종의 신봉과 같은 것에 적대적인 반감이 드는것은 어쩔수 없나 봅니다...
그때그때에 따라 OOP가 주는 잇점과, OOPL이 주는 언어적인 편리함이 아무래도 OOP를 선호하게 하지 않나 생각합니다.
하지만 역시 전체적인 관점에서 볼때 위의 4가지 방법론을 모두 섞어 쓰고 있네요...
모든것을 OOP로 할 수 있나요 ? 정말 ???
혹시.. (요즘 재밌게 대두되고 있는) factor혹은 sin/cos 등과 같은 것 조차 OOP로 깔끔하게/잘(!!) 짤 수 있으신지요...
그렇다면, 그런분을 신(??)으로 모시겠습니다. ㅋㅋ

PS:
틀린부분 있으면 과감히 지적해 주시기 바랍니다. ^^;

kane님과 creativeilder님이 비슷한 말을 해주셔서 같이 답변을 합니다.

예를 들어 Vector와 List를 만든다면 객체지향적인 시야에서는 이 둘에 sort 메소드를 넣어야 할 것입니다. STL의 방법은 저자가 자신이 GP에 초점을 맞추었다는 말 대로 OOP의 입장에서는 거리가 있을 것입니다. 이 sort를 추상화 할 방법은 다중 상속이나 (자바 언어 등의) 인터페이스를 이용하는 방법으로 인터페이스를 분리시켜야 할 것입니다. 그렇다고 하더라도 구현자체는 Vector와 List모두에게 있을 것입니다. sort를 다형성의 대상으로 두어 구현을 분리시키는데 성공했다고 볼 수도 있겠지만 다른 시점으로 본다면 같은 알고리즘이 다른 대상에 적용된다고 해서 또 다시 만든 것입니다. 객체지향의 다형성이란 것이 대상 자체의 "모델링"을 본다면 추상화에 따라 코드가 줄어들고 나중에 변경해야할 코드가 줄어든다고 볼 수 있겠습니다. 하지만 지나치게 "모델링"에게 초점을 맞추었기 때문에 더 간략한 프로그래밍을 만들 수 있는 방법을 찾지 못했다고 생각합니다. 이 경우에는 대상의 추상화가 아닌 알고리즘 자체를 보다 추상적으로 접근했다면 더 많은 이득을 얻을 수 있었을 것입니다. 게다가 객체지향적인 시야는 일반적으로 relation과 part에 대해서 혼용하는 모습을 보이고 있습니다. 환자에게 다리는 part이지만 의사는 relation일텐데 객체지향적인 시각에서는 이것 모두가 사실은 동일한 관점으로 보고 있습니다. 그래서 다른 관점으로 접근했을때 더 가볍게 만들 수 있는 방법을 객체지향은 두꺼운 레이어를 만들 수 밖에 없습니다.

따라서 객체지향이 모든 상황에서 SP의 대안이 된다고 생각하기 힘듭니다. 복잡한 문제이기 때문에 보다 쉽게 모델링이 가능한 상황에서는 객체지향이 훌륭한 답이 될 수 있지만 모델링이 부차적인 문제에서도 OOP가 훌륭하다고 말하는 것은 실용주의 적인 입장은 아니라고 봅니다.

장인의 정신이라...

솔직히 말씀드리면, 제가 우려하는 바는 바로 이점입니다.
밑의 cpp와 java분류의 비유는 본 쓰레드개설의 분류점과는
사뭇 달라 논외로 하겠습니다.

경력자들의 경우, 한가지 언어, 한가지 직무로만 커리어를 쌓아가는
사람이 드뭅니다. 개인의 노력으로 그렇게 다른 직무, 분야를
찾아가기 위해 노력하는 경우도 있지만, 회사의 업무분장의 변화등
타의적인 이유로 그렇게 되는 이유도 크죠.

어찌되었든간에, 제가 본 개발자들의 유형은 기존에 자신이 체득한
정보들을 기반으로 새로운 업무를 수행하게 되는데, 이때 언어가
가지는 패러다임같은것을 바꾸기가 쉽지 않더라는 겁니다.

쉽게 패러다임이니, 앞에 멀티라는 수식어를 붙이니 하지만,
이 패러다임이란거 정말 중요한거고, 쉽게 바뀌지 않는겁니다.
사고체계와 관점을 바꾸기가 그렇게 쉽나요?

c문법에 맞추어 프로그램한다고 해서 c프로그래머라고 하거나,
cpp문법에 맞추어 프로그램한다고 해서 cpp프로그래머냐인데,
이 쓰레드는 그 분기점에 대한 기준을 세우는데 필요한 고민을
할수 있는, 나쁘지 않은 단초를 제공했다고 봅니다.

전 솔직히 "장인의 정신"이란 말 별로 좋게 안봅니다.
경력이 올라갈수록 "장인의 정신"이란걸로 무언가를 위장하고
있는건 아닌지 고민해봤으면 좋겠습니다.

논외입니다만..
creativeidler님께서는 stl의 각 container/collection 들이 가지는 여러가지 물리적인 장점에 대해서 좀 알아보시는게 나을듯 해 보입니다.
STL 매우 잘 만들어진 라이브러리 입니다.
OOP적인 측면에서 볼 때(이렇게 봐두 되나요.. ?) 어떠한 virtual function도 가지지 않고, 어떠한 추상 상속관계도 가지지 않습니다.
다만, namespace로서의 특성만을 취하고 있습니다.
하지만, 메모리효율로 볼때 매우 compact하게 되어있고, 실행효율 또한 매우 훌륭합니다. 그 확장성 면에서도 그렇구요..
만약 OOP에서의 추상화만을 추구하신다면 STL의 container를 사용하지 말고, pure virtual function들로만 이루어진 collection이라는 추상객체로부터 상속받은 list,array,set,map 등과 같은것을을 함 사용해 보시거나, 직접 작성해 보시기 바랍니다.
속도문제는 해결한다고 치더라도, 그 메모리 비효율성에 대해서 이해하실 수 있으실런지...

재밌군요. 저는 할 얘기는 다 해서 눈팅 중입니다만.. 사실 결론을 기대하기 보다는 이야기 중간 중간 나오는 지식들의 꾸러미가 상당히 흥미를 유발 시킵니다. :)

학교에서 글을 적었더니 로그인이 튕겨버리는 군요. 위에 글을 적은 사람은 CN입니다.

to CN:
흠냐. 참고로 제가 포팅했던 C++의 AES 암호화 변형은 지금 논란 거리인 바로 그 "무늬만 C++"인 코드였습니다-_- 이걸 자바로 바꾸는 과정에서 소스 코드의 양이 줄어들 여지는 정말 거의 없었습니다. 굳이 C vs C++의 비교를 끌어오지 않더라도 될 것 같은데요. Java가 객체지향이라해도 OOP로 하지 않고 SP로 한다면 결국 다루는 자료형은 C나 Java나 큰 차이 없고 control logic은 어느 언어나 비슷하죠. String이 자바가 훨씬 유리할 것 같지만 기억해야할 게 자바 쪽이 좀 적을 뿐 실제 코드로 써보면 C 코드가 더 많이 나오는 것도 아닙니다. 오히려 C에서 코드를 단축시킬 수 있는 부분도 있죠. 물론 import와 include의 차이는 무척 큽니다만 한 파일에 다 몰아넣고 비교하는 거라면 그것도 무의미하죠. 실제 포팅해보면 거의 라인 단위로 대응이 되는데 오히려 포인터 쓰는 부분에서 Java 코드의 양이 더 늘어나기도 합니다.

그리고 두꺼운 레이어에 이토록 거부감을 가질 필요가 있는지도 의문입니다. 레이어가 한 단계 늘어난다는 것은 반대로 이 인터페이스를 사용하는 사람은 보다 더 적은 코드를 봐도 된다는 것을 의미합니다. 레이어가 늘어나서 가독성이 높아지고 중복 코드를 효과적으로 제거할 수 있다면 레이어가 늘어나는 게 무슨 문제겠습니까? "더 얇게"라는 가치가 "더 읽기 쉽게", "더 적은 코드"보다 중요한가요?

젓가락의 탈을쓴 포크..
예가 너무나 참신합니다. 전 얘기를 잘 못하는 편인데, 참 부럽습니다.

순수 객체지향적인 방법으로의 처리는 불가능 한가요? 음. 원래 OOP 자체가 객체 자신의 상태를 속성으로 갖고 있는 것입니다. class란 것도 따지고보면 자신의 갖고 있는 속성들의 종류에 따라 구분하는 type에 지나지 않습니다. string을 예로 들어본다면 string이라는 class는 문자열이라는 것을 속성으로 갖는 타입이고 그 속성으로 "abc"를 가질 수도 "aaa"를 가질 수도 있다고 보는 것이죠. 사람 class를 남자 class, 여자 class로 나눌 수도 있지만 성별에 따른 다형성이 필요하지 않다면 그냥 이건 사람 class의 속성으로 정의해도 이것 역시 순수 OOP입니다.

실용을 말씀하시는데 전반적으로 21세기의 OOP 이론의 발전의 중심에는 실용주의가 있습니다. "무엇이 실용이냐"를 좀더 생각해보십시오. 투명성이라는 것은 그 자체가 추구 대상인 것이 아니라 더 코드를 잘 이해하기 위한 것이죠? 투명하게 해줘서 프로그래머가 전부를 다 이해할 수 있게 해주는 것이 CN님의 관점이라면 OOP의 관점은 세부 구현은 들여다보지 않아도 인터페이스만 보고 잘 할 수 있게 만들자는 것입니다. 물론 필요한 경우는 필요한 레벨까지만 내려가서 볼 수 있게 하기도 하죠. 자바 프로그래밍하면 보통 javadoc 문서를 보고 쓰지 안에 구현이 어떤지 소스 들여다보면서 하진 않습니다. 그러다 그 class의 세부 구현을 좀더 알아야하는 경우에는 그 class의 소스를 들여다보죠. 그래도 안되면 또 그 class에서 쓰는 다른 class보고. 그런 식입니다. 대부분은 javadoc 레벨에서 끝납니다. 자바 개발하면 보통 jakarta 프로젝트의 여러 가지 것들을 꼭 쓰게 되는데 이런 소스들이 다 오픈소스로 되어 있지만 소스 들여다봐가면서 개발하진 않습니다. API만 알아도 잘 만들 수 있다, 중요한 건 내가 만드는 코드다..이런 거죠.

이렇게 구현을 안 봐도 되게 만들면 개발자는 자신이 코딩하는 부분에만 집중할 수 있습니다. 그러면 그 코드는 좀더 높은 품질을 만들 수 있죠. 결국 요는 집중해야할 부분에만 집중하게 해줘서 그 부분의 품질을 높여 전체적인 품질 향상을 이끈다는 것입니다.