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

kknd345의 이미지

요즘에 한창 C++ 배우고 있는 학생입니다.

그런데 보통 제 친구들 경우 C와 C++ 의 경계선을 두고 있는 것 같습니다. 전 실무 경험 있는 선배한테 듣기로 C와 C++ 을 구지 구분 할 필요가 없다고 들었는데요.

친구들 이야기 하는 거 들어보면 조금 갑갑하기도 합니다. 클래스에서 printf 썻다고 C++탈을 쓴 C라면서 머라고 하는데.....

여러분 의견은 어떤가요?

그리고 정컴에서 모든걸 클래스화 하려는 경향이 강한데... 학년이 낮아서 그런지는 몰라도 실제로 모든 걸 클래스화 하는 버릇이 좋은건가요?

JosephJang의 이미지

C와 C++의 경계선

프로그래밍 언어는 도구일 뿐입니다. 말그대로 도구일 뿐이기 때문에, 장인이 그 도구를 어떻게 사용하든, 큰 문제는 없다고 봅니다.

예를 들어, C로도 OOP를 할 수 있고, C++로도 structured programming이 가능합니다. 다만 언어가 특정 programming paradigm을 얼마나 지원하느냐의 문제는 다른 얘기죠.

분명히 그 도구를 좀 더 효율적으로 사용하는 법은 존재하겠죠. 그것은 그 도구를 만든 목적을 보면 알 수 있습니다.

결론부터 말하면, C는 structured programming에 적합한 언어로 설계되었고, C++은 (흔히, OOP 언어로 지칭되지만) 여러가지 programming paradigm을 지원하도록 설계되었습니다.

C로 OOP를 하는 것은 가능은 하지만 힘듭니다. 그리고 C++은 설계 철학 으로부터 C와의 호환성을 염두에 두고 있기 때문에 C++에서 structured programming style을 사용하는 것은 별로 문제가 없습니다.

OOP에 전혀 경험이 없는 사람이 중요한 프로젝트를 수행할 때, C++을 이용해 굳이 OOP를 할려고 노력할 필요는 없습니다. 그냥 structured programming을 사용하면 됩니다. (배우는 목적이라면 얘기가 달라지겠지만요.)

printf와 C++

structured/procedureal 과 OO의 차이는 기본적으로는 문제의 해결 방법을 어떻게 decompose하느냐에 달려있습니다. 중요한 것은 어떤 식으로 모듈을 나누느냐 (그 module의 단위는 파일일 수도, 함수일 수도, 클래스일 수도)에 달려있지, printf를 쓰느냐, C++ stream을 쓰느냐와 같은 지엽적인 문제가 아닙니다.

물론, OOP를 사용하고 있고, console에 출력을 하는 부분이 매우 중요한 객체(object)로 부각되어야 하는 상황이라면 분명 printf를 사용하는 것은 문제가 있을 수 있습니다.

하지만, 많은 학생 내지 아직 경험이 부족한 분들은, 왜 C++ stream을 사용하는 것이 printf에 비해서 나은가 에 대해서 한번도 생각해보지 못한 경우가 대부분입니다.

프로그래밍은 대체로 문제 해결 과정이고, 어떠한 문제의 여러 대안들 중 특정 대안을 선택할 합리적인 근거를 도출해내고, 결정하는 과정입니다. 하지만, "C++에서는 C++ stream만 사용해야한다"와 같은 단편적인 사실에만 매달리고, "왜"라는 질문을 이해하지 못하는 경우가 많은 것 같습니다. 더 큰 문제는, 그러한 "왜"라는 질문을 이해하기 위해서 공부하는 사람이 별로 없다는 것입니다. 그냥 그렇구나 하고 넘어가버리는 사람이 많죠.

"printf를 썼다고해서 C++의 탈을 쓴 C"라는 주장은 틀렸을 가능성이 크다고 생각합니다. programming paradigm에 대한 몰이해, programming language의 철학에 대한 몰이해 등이 섞여있죠. 앞으로 여러분이 젠체할 일이 생긴다면, "이 C++ 프로그램의 객체들은 C의 module들을 class로 덮어씌운 것에 지나지 않는 군. C++의 탈을 쓴 C야."라고 얘기하십시오.

모든 것은 클래스?

클래스의 경우에도 마찬가지 입니다. 클래스는 OOP를 돕기 위해서 C++이라는 언어가 제공하는 도구입니다. 클래스가 없어도 OOP가 가능하긴 하지만, 언어가 제공하는 클래스를 사용하면 같은 생각을 더 쉽게 표현할 수 있는 것입니다. 그리고, OOP를 사용하지 않기로 결정했다면, C++을 사용하더라도 class를 전혀 안써도 무방한거죠.

"모든 것을 클래스로 나타낸다"는 말은 "모든 것은 객체"다라는 OOP의 중요한 원리와 비슷하군요. 하지만, 약간의 오해의 소지가 있습니다. 여기서 "모든 것"이란 해결할 문제에 나타나는 중요한 사람/사물이나 역할 등을 표현하는 것입니다. 아무렇게나 클래스로 이름 짓는다고 모두 OOP가 되는 것은 아니죠. 주의할 필요가 있습니다.

간단한 답변 글에 모든 얘기를 할 수는 없습니다. 조금이라도 의심이 가거나, 궁금한 것들은 공부를 하십시오. 그것이 진정한 프로그래머가 되는 길입니다.

fromdj의 이미지

c++는 c의 슈퍼셋이니까..뭐든 쓸수 있는거죠
cout 도 내부적으론 printf와 같을 거니까..
c++라고 해서 반드시 클래스만을 써야한다는것은
오히려, 강박관념인것 같아요~

전 goto 도 유용하게 쓰고있습니다. ㅋㅋ

^^ be cool ~
http://fromdj.pe.kr

only2sea의 이미지

JosephJang wrote:
C와 C++의 경계선
하지만, 많은 학생 내지 아직 경험이 부족한 분들은, 왜 C++ stream을 사용하는 것이 printf에 비해서 나은가 에 대해서 한번도 생각해보지 못한 경우가 대부분입니다.

프로그래밍은 대체로 문제 해결 과정이고, 어떠한 문제의 여러 대안들 중 특정 대안을 선택할 합리적인 근거를 도출해내고, 결정하는 과정입니다. 하지만, "C++에서는 C++ stream만 사용해야한다"와 같은 단편적인 사실에만 매달리고, "왜"라는 질문을 이해하지 못하는 경우가 많은 것 같습니다. 더 큰 문제는, 그러한 "왜"라는 질문을 이해하기 위해서 공부하는 사람이 별로 없다는 것입니다. 그냥 그렇구나 하고 넘어가버리는 사람이 많죠.

"printf를 썼다고해서 C++의 탈을 쓴 C"라는 주장은 틀렸을 가능성이 크다고 생각합니다. programming paradigm에 대한 몰이해, programming language의 철학에 대한 몰이해 등이 섞여있죠. 앞으로 여러분이 젠체할 일이 생긴다면, "이 C++ 프로그램의 객체들은 C의 module들을 class로 덮어씌운 것에 지나지 않는 군. C++의 탈을 쓴 C야."라고 얘기하십시오.

동감입니다.

서지훈의 이미지

kknd345 wrote:
요즘에 한창 C++ 배우고 있는 학생입니다.

그런데 보통 제 친구들 경우 C와 C++ 의 경계선을 두고 있는 것 같습니다. 전 실무 경험 있는 선배한테 듣기로 C와 C++ 을 구지 구분 할 필요가 없다고 들었는데요.

친구들 이야기 하는 거 들어보면 조금 갑갑하기도 합니다. 클래스에서 printf ㅤㅆㅓㅅ다고 C++탈을 쓴 C라면서 머라고 하는데.....

여러분 의견은 어떤가요?

그리고 정컴에서 모든걸 클래스화 하려는 경향이 강한데... 학년이 낮아서 그런지는 몰라도 실제로 모든 걸 클래스화 하는 버릇이 좋은건가요?


일단은 프로그래밍을 함에 있어 지금 자신이 사용하는 언어가 무엇인지 생각을 되새겨 보시길...
하나의 예로 지금 회사에서 분석중인 프로그램이 있는데, 분명 확장자는 cc이지만 내용은 99%가 C입니다.
정말 이런 코드는 보는거 만으로도 짜증이 좀 납니다.
단순히 C++내의 몇가지 기능(overloading, STL, ...)을 사용하기 위해 이런 무모한 코드를 사용했다는 거에 좀 황당도 하고...
이런 정체성 없는 코드는 지양을 해야 할것 같습니다.

'클래스화 하려는 경향' C++ 를 사용하면서 이건 당연한 겁니다.
C++를 사용하면서 class화 하지 않는다면 C++은 왜 쓰는지 자신에게 되물어 보세요...
이건 C에서 함수를 사용하지 않고 하나의 main()에 통채로 지워 넣어 프로그래밍 하는거랑 별단 다르지 않을것 같군요.
단지 C에서 C++를 불러 쓴다라는 느낌이랄까?

근데... C++ 에서 단순히 printf()와 같은 C++표준 함수를 불러 쓰는데 거부감을 가진다면 이 또한 그사람의 하나의 고집이 아닐지...
절대 강요할 건 아니고 자신의 스타일 고집으로 하는 방식일 뿐이지 C++의 표준함수인 printf()를 C++에서 쓰는것을 지양하자는건 이 또한 약간의 당혹감을 주지 않을지?
단지 C의 함수와 같은 이름이라는 이유때문에...
그분은 주석 사용할 때 "/* */" 없이 "//" 만으로 사용치는 않을듯 한데 ㅡㅡㅋ

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

익명 사용자의 이미지

C와 C++의 경계는 제일 중요한 특징은 객체지향인가 그렇지 않은가 입니다.

doldori의 이미지

서지훈 wrote:
단순히 C++내의 몇가지 기능(overloading, STL, ...)을 사용하기 위해 이런 무모한 코드를 사용했다는 거에 좀 황당도 하고...
이런 정체성 없는 코드는 지양을 해야 할것 같습니다.

근데... C++ 에서 단순히 printf()와 같은 C++표준 함수를 불러 쓰는데 거부감을 가진다면 이 또한 그사람의 하나의 고집이 아닐지...
절대 강요할 건 아니고 자신의 스타일 고집으로 하는 방식일 뿐이지 C++의 표준함수인 printf()를 C++에서 쓰는것을 지양하자는건 이 또한 약간의 당혹감을 주지 않을지?


모순이라고 생각하지 않으시는지요? 오버로딩이나 STL만을 사용하는 것은 정체성이
없는 것이고, C++의 stream 대신 printf()를 사용하는 것은 스타일이라고 하시니...

JosephJang님이 좋은 말씀을 많이 해주셨습니다. C++에서는 유연한 사고 방식이
매우 필요합니다. 절차적 프로그래밍, OOP, GP(generic programming) 등 여러
방식을 지원하니까요.

서지훈의 이미지

doldori wrote:
서지훈 wrote:
단순히 C++내의 몇가지 기능(overloading, STL, ...)을 사용하기 위해 이런 무모한 코드를 사용했다는 거에 좀 황당도 하고...
이런 정체성 없는 코드는 지양을 해야 할것 같습니다.

근데... C++ 에서 단순히 printf()와 같은 C++표준 함수를 불러 쓰는데 거부감을 가진다면 이 또한 그사람의 하나의 고집이 아닐지...
절대 강요할 건 아니고 자신의 스타일 고집으로 하는 방식일 뿐이지 C++의 표준함수인 printf()를 C++에서 쓰는것을 지양하자는건 이 또한 약간의 당혹감을 주지 않을지?


모순이라고 생각하지 않으시는지요? 오버로딩이나 STL만을 사용하는 것은 정체성이
없는 것이고, C++의 stream 대신 printf()를 사용하는 것은 스타일이라고 하시니...

JosephJang님이 좋은 말씀을 많이 해주셨습니다. C++에서는 유연한 사고 방식이
매우 필요합니다. 절차적 프로그래밍, OOP, GP(generic programming) 등 여러
방식을 지원하니까요.


몇 만 라인중에 몇 라인 C++의 STL이나 귀차니즘에 의한 overloading은 좀 너무 과하지 않나 생각을 합니다.
이건 단지 strcat을 사용하지 않기 위한 이유로 C++을 사용하는거랑 별반 차이가 없지 않나 생각을 하는 것입니다.
처음에 볼 때는 완전히 C++이지만 몇 백, 몇 천 라인에 하나씩 보이는 C++들 ㅡㅡㅋ

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

happycat의 이미지

몇 줄의 STL을 사용하기 위해 C++을 사용하는 것도 좋지 않나요..?

C와 C++이 대단히 차별되는 것 중 하나가 STL의 존재라 생각하는데요..

Structual하게 프로그래밍 하면서 STL을 사용하고 싶다는 상황은 충분히 존재할 수 있는 상황이라 생각합니다. 얼마나 편합니까~. STL 쓰다가 C 쓰려면 바닥부터 새로 짜야 하니 골치 아파 버립니다. 물론 보신 코드들의 다른 부분들이 짜증을 유발할 수도 있겠습니다만, 어쨌던 STL + C 스타일 코딩은 아무 문제가 없다고 봅니다.

doldori의 이미지

서지훈 wrote:
몇 만 라인중에 몇 라인 C++의 STL이나 귀차니즘에 의한 overloading은 좀 너무 과하지 않나 생각을 합니다.
이건 단지 strcat을 사용하지 않기 위한 이유로 C++을 사용하는거랑 별반 차이가 없지 않나 생각을 하는 것입니다.
처음에 볼 때는 완전히 C++이지만 몇 백, 몇 천 라인에 하나씩 보이는 C++들 ㅡㅡㅋ

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


제 말뜻이 printf()를 쓰면 안된다는 것은 아님을 이해하시리라 믿습니다.
또한 C++에서"만" 사용할 수 있는 기능을 얼마나 많이 썼는가로 좋고 나쁨을
판단할 수 없다는 점에는 동의하시리라 믿습니다.
다만 STL이나 오버로딩만을 쓰면 귀차니즘, 과한 것이고 printf()를 쓰면
스타일이라고 하는 것은 편향된 시각임을 말씀드리고자 했습니다.

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

ed.netdiver의 이미지

저, 잘 몰라서 여쭙겠습니다.
그러면, 처음 글로 돌아가서, printf와 cout처리가 똑같다는 말씀들이신건지요?
printf는 단지 가변인자를 처리해서 iostream에 넘겨주는 기능을 하는것인가요?

뭐랄까, c와 cpp을 비교한달지 하면, 다 그게 그거고 그냥 툴이다라는 접근을
많이 하십니다만, 또 한편으로는 보다 근본적인걸 알아야 한다고 하십니다만,
다분히 추상적이고 직접적으로 와닿지 않는건 사실이군요.
뭐, 이것도 직접 찾아보고 공부하란 것이 정답이겠지만 말입니다.

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

서지훈의 이미지

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

ssif의 이미지

어느 개발자 싸이트를 가도 이런 이야기를 해주시는 분들이 많습니다.

"프로그래밍 언어는 단지 도구일 뿐이다."

그말을 3년째 곱씹어 보고 있습니다.그런데 문득 이 글을보기전에 아침에 문득 이런생각이 들었습니다.

"라면을 먹는데 수저로 먹는게 편할까?젓가락으로 먹는게 편할까?아니면 중간 형태인 포크로 먹는게 좋을까?

스프를 먹는데 수저로 먹는게 좋을까?스푼으로 먹는게 좋을까?아니면 젓가락으로 먹을까?"

'각자의 언어는 그 언어만의 고유한 철학을 가지고 있으며 어딘가에 특성화된 부분이 있다.그리고 그걸 사용하는 사람들은 적절한 상황에 사용하면 된다.다만 배우는 과정이 힘들고 시간이 많이 걸리긴 하지만 현재의 상황에 적절히 대응할수 없는 언어를 사용함보다 상대적으로 좋은 효과(시간,물질적,정신적,기타등등으로써)를 얻을수 있을 것이다.'

이런 생각이 들었습니다.

봄들판에서다

doldori의 이미지

qed wrote:
그러면, 처음 글로 돌아가서, printf와 cout처리가 똑같다는 말씀들이신건지요?
printf는 단지 가변인자를 처리해서 iostream에 넘겨주는 기능을 하는것인가요?

printf()가 내부적으로 C++ stream을 쓰는 구현도 가능은 하겠지만 실제로 그렇게
구현하지는 않을 것입니다. C++ 컴파일러는 C 컴파일러로도 쓸 수 있는 것이 일반적이고
C 표준 라이브러리는 공유하는 것이 보통입니다. 따라서 printf()가 C에서도 쓰일
수 있으려면 내부에서 iostream 클래스를 쓸 수는 없습니다. 만약 C용 라이브러리와
C++용 라이브러리가 따로 제공되면 가능하겠지요. 그 반대로 stream 클래스에서
printf()를 쓰는 구현은 봤습니다.

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

double d;
scanf("%f", &d);
printf("%f\n", d);
happyjun의 이미지

JosephJang wrote:
결론부터 말하면, C는 structured programming에 적합한 언어로 설계되었고, C++은 (흔히, OOP 언어로 지칭되지만) 여러가지 programming paradigm을 지원하도록 설계되었습니다.

맞는 말씀입니다. C++은 OOP 만을 위한 언어가 아닙니다.

GP 관점에서 template을 사용하지 않는 C++ 코드를 보는 것과 같이, C++로 구현된 프로젝트에서 class 가 없다고 비난할 수는 없습니다.

뭐라 할 수 있는 부분은 코드의 퀄러티라고 생각합니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

서지훈의 이미지

happyjun wrote:
JosephJang wrote:
결론부터 말하면, C는 structured programming에 적합한 언어로 설계되었고, C++은 (흔히, OOP 언어로 지칭되지만) 여러가지 programming paradigm을 지원하도록 설계되었습니다.

맞는 말씀입니다. C++은 OOP 만을 위한 언어가 아닙니다.

GP 관점에서 template을 사용하지 않는 C++ 코드를 보는 것과 같이, C++로 구현된 프로젝트에서 class 가 없다고 비난할 수는 없습니다.

뭐라 할 수 있는 부분은 코드의 퀄러티라고 생각합니다.


C++와 C의 차이점이 뭐냐고 주변사람들에게 물으면 10이면 아홉은 class라고 할 것입니다.
그런데 class를 사용하지 않는데 굳이 프로젝트 진행에 C++를 채택해서 진행을 한다면 이건 좀 문제가 있지 않나 생각을 합니다.

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

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

함...

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

ed.netdiver의 이미지

그런데요, cpp가 oop만을 위한 언어가 아니다라는 말보다는,
cpp compiler가 oop에 맞추어진 코드외의 것들도 compile할수 있다.가 맞지 않나요?
라이브러리 링크가 가능하달지...
뭐 두개가 같은 말같기도 합니다만...

printf만 보더라도, 시스템에서 제공하는 표준출력으로 data를 보내주는
기능을 하는것이라는 측면에서 보면야 cout과 같은것일수도 있습니다.
하지만, doldori님께서 말씀하신 바와 같이, stream처리, type관리의 엄격함같은
cpp의 기본적인 부분(?)을 무너뜨리면서라도 사용할수는 있다는 정도지,
그것이 cpp라는 언어가 기본적으로 지향하는 바는 아니지 않냐는 겁니다.

그러니, cpp로도 c적인 코드를 만들수 있다는 의미인거지, 그걸 실제 사용한다는건
답이 아니라고 본다는 겁니다.
물론, 오로지 cpp적인 코드를 생산하는것도 정말 어려운 일이기도 하구요.^^;

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

익명 사용자의 이미지

말그대로 멀티 패러다임 언어죠.
어떻게 쓰던 상관없이 모두 C++ 입니다.

c++ 코드에 OOP 안썼다고 c++ 아니라고 할수는 없다고 생각합니다. C 와 C++ 에 경계를 두는것보다는 절차적 프로그래밍과 OOP 의 경계를 따지는게 맞다고 봅니다.

kcando의 이미지

Quote:

Bill Venners: In an interview, you said, "The C++ community has yet to internalize the facilities offered by standard C++. By reconsidering the style of C++ use, major improvements in ease of writing, correctness, maintainability, and efficiency can be obtained." How should C++ programmers reconsider their style of C++ use?

Bjarne Stroustrup: It's always easier to say what not to do, rather than what to do, so I'll start that way. A lot of people see C++ as C with a few bits and pieces added. They write code with a lot of arrays and pointers. They tend to use new the way they used malloc. Basically, the abstraction level is low. Writing C-style code is one way to get into C++, but it's not using C++ really well.

I think a better way of approaching C++ is to use some of the standard library facilities. For example, use a vector rather than an array. A vector knows its size. An array does not. You can extend a vector's size implicitly or explicitly. To get an array of a different size, you must explicity deal with memory using realloc, malloc, memcpy, etc. Also, use inline functions rather than macros, so you don't get into the macro problems. Use a C++ string class rather than manipulating C strings directly. And if you've got a lot of casts in the code, there's something wrong. You have dropped from the level of types, a high level of abstraction, down to a level of bits and bytes. You shouldn't do that very often.

...


(출처: http://www.artima.com/intv/goldilocks.html)

개인적으로 많은 깨달음을 얻은 글입니다. 읽어보실 것을 적극 추천합니다.

creativeidler의 이미지

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 하나 만드는데 들어가는 노력이 자바나 파이썬, 루비 등에 비하면 상당히 큰 편이죠.

cinsk의 이미지

요즘에 한창 C++ 배우고 있는 학생입니다.

그런데 보통 제 친구들 경우 C와 C++ 의 경계선을 두고 있는 것 같습니다. 전 실무 경험 있는 선배한테 듣기로 C와 C++ 을 구지 구분 할 필요가 없다고 들었는데요.

친구들 이야기 하는 거 들어보면 조금 갑갑하기도 합니다. 클래스에서 printf ㅤㅆㅓㅅ다고 C++탈을 쓴 C라면서 머라고 하는데.....

여러분 의견은 어떤가요?

그리고 정컴에서 모든걸 클래스화 하려는 경향이 강한데... 학년이 낮아서 그런지는 몰라도 실제로 모든 걸 클래스화 하는 버릇이 좋은건가요?
C++ 언어를 배우는 입장에서는 나쁜 버릇이 아닙니다. 오히려 여러 가지를 익힐 수 있으니 권장할 만 합니다.

그러나, 실제 어떤 일을 하는 프로그램을 만들겠다라고 하면 생각해 두어야 할 것이 좀 달라질 수 있습니다. 제 경험상으로 보면,

1. 어디까지 class로 구현할 것인가? 실제로 웬만한 덩치의 프로그램을 작성하면서 class로 만들 수 있는 것들은 한계가 있습니다. 물론 좀 그럴 듯하게 말하면, reusabilty가 커버할 수 있는 범위가 어디까지인지를 정하는 것일지도 모릅니다. 또한 이 프로그램 이외에서 쓸 수 있는 가능성이 있을 때, 그 프로그램까지 고려해서 설계할 것인가?도 중요하며 (무조건 reusability가 높은 코드가 좋은 코드는 아닙니다.), 이 프로그램 내부에서 공통적으로 쓰이지 않는 부분에 대해서는 어떻게 할 것이며, 공통적으로 쓰이는 부분은 어떻게 만들 것인가?
template을 고려해서 만들 것인가? policy template를 이용할 것인가?

2. printf()이냐, cout()이냐 하는 것은 좀 더 넓은 범위에서, FILE stream library를 쓸 것인지, iostream을 쓸 것인지를 말하는 것입니다. 선택하는 기준은 매우 다양합니다. 프로그램이 정해진 기간에서 원하는 성능이 나와야 하는 것이 목적일때, 대부분 프로그래머들이 iostream을 잘 모른다면, iostream library를 쓸 이유가 전혀 없습니다. 제 프로그램의 입출력을 위해 low-level I/O (file descriptor)를 써서 만든, non-template stream library를 만들어 씁니다.

3. C++은 아직도 계속 변하고 있는 언어이고, 역사가 짧아서 ISO C++ Standard를 지원하는 컴파일러가 넓게 퍼져있지 않습니다. 따라서 target system이 뭐냐에 따라서 C++ 컴파일러의 능력이 결정되고, 또 이 컴파일러가 얼마나 표준을 지원하느냐에 따라서, 여러분의 프로그램에 template를 쓸 수 없을 수도 있습니다. 즉, C++이 제공하는 모든 기능을 골고루 잘 써서 프로그램을 작성할 수 없을 수 있습니다. 즉, 시스템이 지원하는 C++ 컴파일러의 능력을 참고로 해야 합니다.

4. 작성하는 코드가 C++을 설명하기 위한 것인지, 아니면 C++ 기능을 써서 성능 좋은 프로그램을 작성하는 것인지 생각해보기 바랍니다.

5. 최종적으로 만들어 낼 것이 실행 가능한 프로그램인지, 라이브러리인지에 따라서도 1번의 기준에 많은 영향을 미칩니다.

언어에서 제공하는 기능이 있는데도 안쓰는 것은 상관없습니다. 나름대로 이유가 있을테니까요. 그런데 언어에서 제공하는 기능을 몰라서 따로 만들어 쓰는 것은 문제가 됩니다.

"언어는 도구일 뿐이다."란 말은 모든 사람에게 적용될 수 있는 말은 아닙니다. ssif님이 아주 좋은 비유를 하셨는데, 정교한 도구를 만드는 사람에게는 도구 이상이 될 수도 있습니다. 칼잡이가 칼 쓰는 연습을 소홀해서는 안되겠지만, 칼 자체에 대해 아는 것이 도움이 되었으면 되었지, 나쁘지는 않습니다. 또 여러분이 하는 역할이 칼잡이가 될지, 대장장이가 될 지는 상황에 따라서 다릅니다. 라이브러리 설계자라면 대장장이처럼 언어를 대하는 것이 오히려 더 나을 거라고 생각합니다.

그리고 "언어는 도구일 뿐이다."란 말... 개인적으로 매우 싫어합니다. :evil: 야구 선수나 배트 만드는 사람에게 몽둥이 하나 가지고 뭘... 이라고 말하면.. 반응이 어떨까 궁금합니다.
:wink:

익명 사용자의 이미지

1. 경계선
C++는 C를(거의) 그대로 수용하고 있지만 OO를 비롯 GP, FP, MP(Metaprogramming)의
다양한 패러다임을 지원하는 언어이므로 뭐 비슷해보이지만 전혀 다른
언어라고 보는게 옳을거 같습니다.
그런데 C++의 멀티패러다임은 결국 어느것도 제대로 하는게 없다는것과 같다는 말씀을 하시는 분도 있더군요 --;
(그래서 확연한 경계선이 있다는게 제생각입니다)

2. 모든것의 클래스화
무조건 클래스로 만드는 것보다는 잘 디자인하려는 노력은 매우 중요한 것 같습니다.
실무에서 우려되는 점은 풀어야하는 문제가 주어진 시간에 비해서 디자인의
variation 이 너무 많은 이유로, 시간이 너무 많이 들거나
잘못된 디자인을 하기 쉽다는 점입니다. (잘못 디자인된 클래스는 차라리 없는게
낫죠, 그런데 막상 프로그램을 하다보면 너무나 자주 잘못 디자인을 하게 되더군요..)
그래서 정교하게 클래스간의 관계를 표현못하더라도 코드를 관리하기 좋게 작성했다면
충분히 훌륭한 C++코드라 할 수 있겠습니다..
C++를 한참공부하는 사람이거나 아니면 C++의 새부적인 문법에 편집증이 있어 극도의
세련됨을 추구하는 사람은 팀 프로그램시 여러가지 이유로 문제가 되는 경향이
많은거 같습니다.

이런 이유로 STL이나 boost라이브러리처럼 여러 사람들이 사용해야할 범용 라이브러리
를 개발해야 한다면 14882:2003 문서를 줄줄외면서 최대한의 성능과 확장성있는
디자인을 위해 노력해야할것이고
여러 사람이 주어진 시간내에 프로그램을 해야하는 상황이라면 이미 위에서 말한것과
같은 잘 만들어진 라이브러리를 사용하면서 쉽게 쉽게 단순하고 멍청하게 빨리 프로그램을
하는것이 좋을 듯 합니다. (그래서 모든것의 클래스화는 상황에 따라 다르다는게 제 생각입니다.)

kknd345의 이미지

여러가지 이야기 도움 많이 되었습니다.

특히

"왜"라는 질문을 이해하지 못하는 경우가 많은 것 같습니다. 솔직히 말해서 저도 그랬던것 같습니다. printf()와 cout()이 따로 있는 이유가 있을거라고 추측은 했는데... 아직도 왜 다른지 정확히는 모릅니다. 물론 차차 공부하다보면 자세히 알겠지만 학생 입장에서 이런걸 바로 어디서 알아내기란 쉽지가 않더군요.( C++책도 기본적인 것만 봤던터라.... 대충 감만....)

이 C++ 프로그램의 객체들은 C의 module들을 class로 덮어씌운 것에 지나지 않는 군. C++의 탈을 쓴 C야.

그리고 두번째 부분인데... 제가 말했던 정컴 학생들의 클래스화 하려는 경향을 대변하는 말 같습니다. 분명히 코드는 C의 모듈들인데 그냥 막연히 클래스로 덮어버리는 사람들이 주변에 많습니다. 전 프로그래밍 할때 이부분은 진짜 클래스가 되겠다고 생각되면 그 부분은 클래스로 짜고 나머지는 그냥 C로 짜버리고 있습니다. 아직 경험부족이라 그런지... 전부다 클래스화하는게 어렵더라구요.

그리고 다른 분들 말씀도 도움 많이 되었는데.... 아직 확고한 프로그래밍에 대한 개념이 없어 누가 옳은지는 잘 모르겠습니다. 아무래도 자신이 옳다고 믿는것이 정답이 아닐까 합니다만 ^^;;

답변 달아 주셔서 고맙습니다. ^ __ ^

1%의 가능성이면 충분하다!
최선을 다하자!

익명 사용자의 이미지

kknd345 wrote:
요즘에 한창 C++ 배우고 있는 학생입니다.

그런데 보통 제 친구들 경우 C와 C++ 의 경계선을 두고 있는 것 같습니다. 전 실무 경험 있는 선배한테 듣기로 C와 C++ 을 구지 구분 할 필요가 없다고 들었는데요.

친구들 이야기 하는 거 들어보면 조금 갑갑하기도 합니다. 클래스에서 printf 썻다고 C++탈을 쓴 C라면서 머라고 하는데.....

여러분 의견은 어떤가요?

그리고 정컴에서 모든걸 클래스화 하려는 경향이 강한데... 학년이 낮아서 그런지는 몰라도 실제로 모든 걸 클래스화 하는 버릇이 좋은건가요?


ttt
죠커의 이미지

모든 일에는 이해가 선행되어야 합니다. C++에서 prinf를 사용하는게 유리하다고 이해했다면 쓰면 되고 안 사용하는게 유리하다고 이해했으면 안 쓰면 됩니다.

이해하지 못할 경우에는 두가지 방법이 답입니다. 이해할때까지 무시하거나 이해하기 위해 노력하는 것입니다. C++에서 printf를 쓰는게 전자이고 iostream에 대해서 깊게 공부해 보는게 후자일 것입니다.

전자와 후자 그 중에 어떤 것을 할 것인지. 그 선택은 kknd345님의 몫입니다. 모든 design은 선택에 있는 것이지 정답이 있는 것이 아니니깐요.

ㅡ,.ㅡ;;의 이미지

doldori wrote:
...........

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

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

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


----------------------------------------------------------------------------

지리즈의 이미지

Anonymous wrote:
말그대로 멀티 패러다임 언어죠.
어떻게 쓰던 상관없이 모두 C++ 입니다.

c++ 코드에 OOP 안썼다고 c++ 아니라고 할수는 없다고 생각합니다. C 와 C++ 에 경계를 두는것보다는 절차적 프로그래밍과 OOP 의 경계를 따지는게 맞다고 봅니다.

심히 공감가는 군요...

그렇다면,
C++이라는 테두리 안에서
절차적 프로그래밍 = C
OOP=C++
이라는
공감대가 형성되어야만 논의가 진행되겠습니다.

다른 언어들과 달리 별도의 언어(C)를 포함하고 있는
C++에서만 논의될 수 있는 특성이기 때문이겠지요?

이런 공감대 없이는 그 다지 의미있는 논의가 아닐 듯 싶습니다.

There is no spoon. Neo from the Matrix 1999.

서지훈의 이미지

지리즈 wrote:
Anonymous wrote:
말그대로 멀티 패러다임 언어죠.
어떻게 쓰던 상관없이 모두 C++ 입니다.

c++ 코드에 OOP 안썼다고 c++ 아니라고 할수는 없다고 생각합니다. C 와 C++ 에 경계를 두는것보다는 절차적 프로그래밍과 OOP 의 경계를 따지는게 맞다고 봅니다.

심히 공감가는 군요...

그렇다면,
C++이라는 테두리 안에서
절차적 프로그래밍 = C
OOP=C++
이라는
공감대가 형성되어야만 논의가 진행되겠습니다.

다른 언어들과 달리 별도의 언어(C)를 포함하고 있는
C++에서만 논의될 수 있는 특성이기 때문이겠지요?

이런 공감대 없이는 그 다지 의미있는 논의가 아닐 듯 싶습니다.


딴지 같지만 이해하기가 어렵군요.
C++안에서의 절차적 프로그래밍 이라 ...
결국 이말은 C++ 의 최대 장점인 class를 버리고 옆에 붙어 있는 자신에게 편리한 기능만 따다가 사용하겠다는 것이군요.
그러면 C의 기본 함수에 class를 제외한 부분을 구현하면(현재 누구나 가능하나 귀찮아서 안하고 있을 뿐이지만), C++은 또 그냥 언어가 아니라 UML처럼 설계 언어로 전락을 해버리겠군요. ㅡㅡㅋ
그럼 C++진영에서는 절대 C 표준화 중에 C++의 기능이 들어 가는 것을 막것에 존재의 의의를 둘 수 밖에 없을 듯도 하군요.
이런 극단적인 얘기도 충분히 가능 하군요.

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

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

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

익명 사용자의 이미지

서지훈 wrote:
딴지 같지만 이해하기가 어렵군요.
C++안에서의 절차적 프로그래밍 이라 ...
결국 이말은 C++ 의 최대 장점인 class를 버리고 옆에 붙어 있는 자신에게 편리한 기능만 따다가 사용하겠다는 것이군요.
그러면 C의 기본 함수에 class를 제외한 부분을 구현하면(현재 누구나 가능하나 귀찮아서 안하고 있을 뿐이지만), C++은 또 그냥 언어가 아니라 UML처럼 설계 언어로 전락을 해버리겠군요. ㅡㅡㅋ
그럼 C++진영에서는 절대 C 표준화 중에 C++의 기능이 들어 가는 것을 막것에 존재의 의의를 둘 수 밖에 없을 듯도 하군요.
이런 극단적인 얘기도 충분히 가능 하군요.

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

PHP도 4대면 허접하긴 해도 OOP로 작성할 수 있죠..

그런데 PHP에서 class라는 것이 비교적 필수가 아니라,
PHP를 OOP라고 부르는 사람은 거의 없습니다.
하지만, 자바나 다른 언어에 익숙한 사람들이
많이 PHP에 유입되면서 비교적 OOP라고
불릴많한 라이브러리들이 나오기 시작했죠...

PHP5대가 되면서 OOP적 기틀이 잡혔죠...

그래도 전에 처럼 Class 하나없이 작성해도
PHP라고 불릴 겁니다.

좀 사용자가 드믈어서 그런데..
Visual Basic(.net 말고 6이전)도 좋은 예입니다.
Visual Basic도 자바 수준의 개체지향을 지원하는 언어입니다.
사실 자바와 개체지향 모델이 가장 유사한 언어를 뽑으라면
전 Visual Basic을 뽑습니다.

그런데 VB를 가지고 자바만큼의
개체지향프로그래밍을 하는 사람은 못봤습니다.
그래도 VB라고 하죠.

만약 애초에 C가 없었고 C++만 있다면,
이론 논쟁의 애시당초 의미가 없습니다.
어떻게 코딩을 하던 C++이라고 할테니깐요...

하지만, C++은 C라는 것이 포함되어 있기 때문에
이런 논쟁이 발생합니다.

결국은 C++이 탄생하게된 배경과 목적에
부합하는 코딩방식이야 말로 C++다운 것이라고
말할 수는 있지만, 그렇지 않더라도,
C++이 아니라고 말할수도 없다고 생각합니다.

개발에 있어서 다양한 목적과 방식이 있기때문에
어떤 방법론이 가장 좋은 방법이라고 말하긴 어렵다는
생각이 듭니다.

특히 GUI를 가지는 운영체제와 같은 것은
많은 부분이 C++로 작성되었더라도,
C없이는 구축되기 어렵죠.

따라서 단순히 매너리즘이다 어쩌다 이렇게
말할 성질의 것은 아니라고 봅니다.

기술적인 필요성,개발비용/유지비용에 의해
선택될 뿐이라고 생각됩니다.

참고로 규약은 필요로 의해 탄생된 것이지,
규약이 모든 것에 시작은 아니라고 봅니다.

서지훈 wrote:

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

멀티 패러다임이란 철학(혹은 사회과학)적인 용어죠...

누가 처음 사용했는지는 몰라도 C++을 보면
정말 정확한 표현갔습니다.

그리고 패러다임과 패러다임은 언제나 서로 충돌하기 마련인데,
그 모습이 딱 이런 분위기입니다.

익명 사용자의 이미지

OOP 가 꼭 절차적인 밥법보다 좋다고는 할수 없습니다.
적당한때 쓰는 OOP 라면 몰라도, 단순히 포매팅된 스트링을 찍기 위해서 printf 를 버리고 iostream 을 써야 한다고 강요하는건 말도 안되죠. iostream 은 분명히 printf 에 비해 기능이 많고 안전하지만 쓰기 불편합니다. 게다가 숨어있는 코드(조상 클래스들에 정의된 함수들, 수많은 생성자들, iostream만이 아니고 일반적인 클래스의 경우입니다.)들이 많은 class 들은 정확히 알기 전에는 쓰면 오히려 위험하거나 비효율적이죠.

이렇게 OOP 에 얽매이지 않고, 원하는대로 아는만큼의 것들을 이용해서 코딩하는게 c++ 의 장점이라고 생각합니다. OOP 를 싫어하시는(또는 잘 모르시는) 분들은 stl 이 제공하는 최소한의 기능들만 써서 C 처럼 짜시겠죠.. OOP 좋아하시는 분들은 부모자식 따져서 class 설계를 하실테고, 좀더 고수들은 템플릿 써서 type 자체를 대상으로 코딩을 하시거나, 함수형으로 짜볼려고 노력을 하겠죠.

즉 위의 어느방법을 써도 c++ 이라는 거죠.
여러가지 방법을 제공하는 언어를 쓰면서, 그중 한가지를 쓰지 않는다고 잘못됐다고 말하는건 잘못됐다고 봅니다.

익명 사용자의 이미지

위에 추가해서..OOP 처음 쓰시는 분들은 절차적으로 짠 함수들을 단순히 모듈화할때 class 를 쓰고 OOP 라고 생각하시겠죠.. 쩝

OOP 정말 어렵습니다.
c 의 탈을 쓴 c++ 어쩌구 하는 사람들중에 oop 제대로 쓰는 사람 얼마 안될겁니다. OOP 를 강요하지 않는 c++ 정말 나이스입니다.

서지훈의 이미지

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

하...

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

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

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

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

죠커의 이미지

서지훈 wrote:
딴지 같지만 이해하기가 어렵군요.
C++안에서의 절차적 프로그래밍 이라 ...
결국 이말은 C++ 의 최대 장점인 class를 버리고 옆에 붙어 있는 자신에게 편리한 기능만 따다가 사용하겠다는 것이군요.
그러면 C의 기본 함수에 class를 제외한 부분을 구현하면(현재 누구나 가능하나 귀찮아서 안하고 있을 뿐이지만), C++은 또 그냥 언어가 아니라 UML처럼 설계 언어로 전락을 해버리겠군요. ㅡㅡㅋ
그럼 C++진영에서는 절대 C 표준화 중에 C++의 기능이 들어 가는 것을 막것에 존재의 의의를 둘 수 밖에 없을 듯도 하군요.
이런 극단적인 얘기도 충분히 가능 하군요.

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

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

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

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

C는 "이식 가능성"과 자체의 "논리성", 패러다임의 "간결함"을 추구하고 있습니다. class를 도입하는 것은 그저 키워드 하나의 추가가 아닌 다른 패러다임을 도입하는 것이기 때문에 C언어에서 추가 되지 않을 것입니다.

C++은 처음에 c with classes라며 객체지향을 무기로 시장에 나왔습니다만 그 객체지향은 Objective C에 비해서 열등하다고 생각합니다. C++이 시장에서 먹힐 수 있었던 것은 두가지 이점이 있었다고 봅니다. 시장을 선점한 것과 다 패러다임이었다는 것입니다.

C++ 표준 라이브러리를 객체지향 적인 면에서만 본다면 비판할 여지가 많을 지도 모릅니다만 실용적인 입장에서 본다면 일반화 프로그래밍(Generic Programming)의 템플릿과 객체의 혼합이 편리하게 느껴집니다. 사실 어떤 면에서는 객체는 템플릿을 위한 도구 처럼 사용했다는 생각도 듭니다. 객체 지향이 아니라 GP의 도구란 느낌도 들죠.

물론 객체 지향을 제외한 개별 항목들도 그 자체가 우수한지는 의문이 듭니다. GP는 다른 언어에 비해서 우수하지 못할 지도 모릅니다. 가장 큰 단점은 Compile Time에서만 템플릿이 영향권을 가진다는 점입니다. 그리고 C++의 구조화 프로그래밍은 함수내의 함수 정의가 불가능한 점 등의 단점도 많이 존재합니다. 하지만 역시나 실용적인 이유로 템플릿을 사용하거나 객체를 사용하거나 구조화 프로그래밍을 하기에는 무리가 없습니다.

비얀 스트로스트럽는 실용성을 가장 큰 가치로 생각할 것 같습니다.

doldori의 이미지

서지훈 wrote:
C++로 프로젝트를 하면서 class하나 없이 작업을 하시는 분들은 C++하면 "CLASS"를 외치시는 분들이 어떻게 보이시나요?

저는 라이브러리의 클래스를 갖다쓰는 것을 제외하면 제가 직접 작성한 클래스 없이
작업한 적 많습니다. 저는 OOP를 외치는 분들을 보면 그냥 "OOP를 좋아하는구나"고
생각할 뿐 특별히 다르게 보지는 않습니다. 그러나 클래스 없이 작업하는 사람들을 보고
짜증을 내거나 황당해하는 분들은 이상해 보입니다.

서지훈 wrote:
항상 C++에서 class를 강조하는 스트뭐시기뭐시기 라는 사람도 아주 난감하게 보이시겠군요.
그리고 C++의 모태가된 class가 단지 하나의 기능일 따름 이었군요 ㅡㅡㅋ
전 여태까지 C와 C++의 정말 큰 차이는 class개념이라고 생각을 했으나 이 얘기또한 우스운 얘기가 되어 버리는 군요 ㅡㅡㅋ

저는 BS의 말을 주의깊게 경청합니다. 그가 클래스를 중요하게 생각한다는 것도
압니다. 하지만 그가 C++ 프로그램에서는 반드시 클래스를 써야 한다고 말했다는
얘기는 들은 적이 없습니다.
서지훈님이 C와 C++의 큰 차이가 클래스라고 생각하시는 데에는 저도 이견을 달
생각이 없습니다. 그러나 다른 방식으로 프로그래밍 하는사람들을 업신여기거나
비난하지는 마십시오.
익명 사용자의 이미지

서지훈 wrote:
C++로 프로젝트를 하면서 class하나 없이 작업을 하시는 분들은 C++하면 "CLASS"를 외치시는 분들이 어떻게 보이시나요?
하등 별로 아는것도 없는 놈이 들은 거는 있어서 그러는 구나 그렇게 생각을 하시겠군요. ㅡㅡㅋ
단지 class를 사용하는 사람은 단지 자기 만족에 의해서 하는 구나 라고 생각을 하시는 경향이 있는듯 하군요.
항상 C++에서 class를 강조하는 스트뭐시기뭐시기 라는 사람도 아주 난감하게 보이시겠군요.

꼭 그렇게 비관적인 눈으로 보지는 않을 듯 합니다.
그렇게 짜는 사람 이렇게 짜는 사람 있구나 정도이겠지요.

서지훈 wrote:

그리고 C++의 모태가된 class가 단지 하나의 기능일 따름 이었군요 ㅡㅡㅋ
전 여태까지 C와 C++의 정말 큰 차이는 class개념이라고 생각을 했으나 이 얘기또한 우스운 얘기가 되어 버리는 군요 ㅡㅡㅋ

정확히 말하면 class도입으로 인한 개체지향성의 강화정도이겠지요...
그렇니까 STL, 템플릿등과 더불어 Class는.. C++의 한 기능이면서도 C와 C++을 구분짓게 할 수 있는 큰 방향 중에 하나겠지요.

서지훈 wrote:

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

그건 아닙니다.
C++은 C를 포함하기 때문에
C소스 코드는 C++의 소스코드로 볼수도 있다는 관점이
존재할 수도 있다는 점이지요.

물론 역은 성립안돼죠.

서지훈 wrote:

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

요즘 프레임을 기피하는 경향이 많이지고,
규모가 커지고 작업자가 많아지면,
class가 매우 유용하게 사용됩니다.

일단 function이나 여러 global한 변수들은
중복선언이 될 수도 있거든요.

이런 것은 코드의 재사용성에도 제한이 많이 따릅니다.

개체지향이 가지는 잇점을 어느정도 php에서도
얻을 수 있습니다.

특정 라이브러리에 관련된 함수들을
특히 디비관련 함수들을 랩핑하는 class를 이용하면,
나중에 포팅할 때 많은 도움이 됩니다.

물론 function단위로 랩퍼를 만들 수 있지만,
그것보다는 class단위로 묶어서 사용하는 것이
체계적으로 관리가 가능합니다.

단, global로 개체를 선언해하는 것은
function보다는 불편한 점이긴 하지만요.

creativeidler의 이미지

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]

죠커의 이미지

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

끝난 논쟁이라고 생각하지 않습니다. GUI 프로그래밍을 할때를 제외하고는 객체지향이 필요 이상으로 두꺼운 레이어를 만드는 경향이 있지 않습니까? 두꺼운 레이어를 만드는 사람이 컴파일러가 아니라면 SP가 여전히 쓰여야 할 이유도 있는 것일 것입니다.

happycat의 이미지

Anonymous wrote:

요즘 프레임을 기피하는 경향이 많이지고,
규모가 커지고 작업자가 많아지면,
class가 매우 유용하게 사용됩니다.

일단 function이나 여러 global한 변수들은
중복선언이 될 수도 있거든요.

이런 것은 코드의 재사용성에도 제한이 많이 따릅니다.

개체지향이 가지는 잇점을 어느정도 php에서도
얻을 수 있습니다.

특정 라이브러리에 관련된 함수들을
특히 디비관련 함수들을 랩핑하는 class를 이용하면,
나중에 포팅할 때 많은 도움이 됩니다.

물론 function단위로 랩퍼를 만들 수 있지만,
그것보다는 class단위로 묶어서 사용하는 것이
체계적으로 관리가 가능합니다.

단, global로 개체를 선언해하는 것은
function보다는 불편한 점이긴 하지만요.

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

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

서지훈의 이미지

함...
여기서 계속 토론을 하다 보니 제가 알고 있든것 들이랑 많이 틀린 부분이 있어 좀 당황 스럽기는 하군요.
저의 생각이 짧아서 인지 몰라도 전 class가 들어가는 곳이 아니라면 그냥 편하게 C로 간다는 주의 인데 ㅡㅡㅋ
지금 말씀 하시는 분들 중 상당수는...
C++도 OOP가 아니라 단지 편하게 C에서 없는 기능을 사용키 위해 C++을 사용한다는 개념이 아닌지요?
뭐.. 이것도 하나의 C++이라고 볼수도...
이런 서로의 생각의 차이 때문에 계속해서 맴도는듯 하군요.
앞에서도 이런 얘기 몇 번 언급을 한것 같은데...
다시 처음으로 회귀하는 듯...

그리고 저도 BJ씨가 class를 꼭 써야한만 한다는 문구는 본적이 없습니다.
그저 C++를 만들 때 부터 class에 상당히 주안점을 둔것으로 알고 있습니다. 누구나 C++하면 얘기하는 대표적인 기능이기에...

Quote:

http://www.research.att.com/~bs/bs_faq.html

C++ is not a descendant of C99; C++ and C99 are siblings

initially called "C with Classes"


Quote:

Is C++ an Object-Oriented language?

C++ is a multi-paradigm programming language that supports Object-Oriented and other useful styles of programming. If what you are looking for is something that forces you to do things in exactly one way, C++ isn't it. There is no one right way to write every program - and even if there were there would be no way of forcing programmers to use it.

That said, writing C-style programs in C++ is for most applications not an optimal use of C++. To be a really effective C++ programmer, you must use the abstraction mechanisms and the type system in a way that fits reasonably with their intent. Trying to ignore or defeat the C++ type system is a most frustrating experience.

Writing Smalltalk-style in C++ can be equally frustrating and sub-optimal as writing C-style code in C++.

For a more detailed discussion see any of my overview or style papers from my bibliography. In particular, see my OOPSLA paper "Why C++ isn't just an Object-Oriented Programming Language".


Quote:

What is the difference between C and C++?

C++ is a direct descendant of C that retains almost all of C as a subset. C++ provides stronger type checking than C and directly supports a wider range of programming styles than C. C++ is "a better C" in the sense that it supports the styles of programming done using C with better type checking and more notational support (without loss of efficiency). In the same sense, ANSI C is a better C than K&R C. In addition, C++ supports data abstraction, object-oriented programming, and generic programming (see The C++ Programming Language (3rd Edition)"; Appendix B discussing compatibility issues is available for downloading).

I have never seen a program that could be expressed better in C than in C++ (and I don't think such a program could exist - every construct in C has an obvious C++ equivalent). However, there still exist a few environments where the support for C++ is so weak that there is an advantage to using C instead.

For a discussion of the design of C++ including a discussion of its relationship with C see The Design and Evolution of C++.

Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings. C99 introduces several novel opportunities for C/C++ incompatibilities.


Quote:
What's a good certification for C++ programmers?

To the best of my knowledge, there isn't a good certification program for C++ programmers. That's a pity. A good certification program would be most useful. However, C++ lacks the central organization that would produce a solid certification program, and a certification program without authority or that focussed on syntax would be worse than useless.

이 글들을 보면은 이 사람도 제대로 결론을 못 내고 있다.
너무 피해다닌다라고나 할까...

근데 제가 말하는 투가 좀 비꼬거나 공격적이었다면 죄송하고, 앞으로도 이에 대한 좋은 토론이 되었으면 합니다.

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

추신_BJ홈페이지에서 이거 저거 뒤져봐도 명확한 결론은 어렵군요.
모두가 납득할 결론을 내면 그사람에게 또 다시 linux와 windows의 논쟁에의 결론을 부탁해야 할 듯...

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

익명 사용자의 이미지

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

헠 php에 namespace와 singleton이 있었군요...

구글신이시여 구글신이시여~

happycat의 이미지

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

ㅤㅎㅓㅋ php에 namespace와 singleton이 있었군요...

구글신이시여 구글신이시여~

아.. C++인 줄 알았습니다. (죄송합니다;; )

singleton은 PHP에서 구현(흉내?)해서 사용 가능합니다. ㅎㅎ;;

익명 사용자의 이미지

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

헠 php에 namespace와 singleton이 있었군요...

구글신이시여 구글신이시여~

php에서도 static 키워드가 있었군요..

당연히 singleton은 가능하고...

php에서 namespace는 어떻게 사용하죠?
www.php.net에는 없던데....

creativeidler의 이미지

Quote:

끝난 논쟁이라고 생각하지 않습니다. GUI 프로그래밍을 할때를 제외하고는 객체지향이 필요 이상으로 두꺼운 레이어를 만드는 경향이 있지 않습니까? 두꺼운 레이어를 만드는 사람이 컴파일러가 아니라면 SP가 여전히 쓰여야 할 이유도 있는 것일 것입니다.

그것이 끝나지 않았다는 이유라면 동의하기 힘들군요. 요즘의 OOP에서는 간결함과 실용성에 높은 가치를 두고 있기 때문에 그런 경우는 보기 힘든 것 같습니다. 굳이 말하자면 OOP라서가 아니라 OOP를 제대로 배우지 못했기 때문이겠죠. 총 쏘는 법을 다 배우지 않은 군인이 과녁을 못 맞힌다고해서 총이 칼보다 비효율적인 무기라고 할 수는 없지 않겠습니까.

그리고 정말 '필요 이상'으로 두껍다면 문제겠지만 대체로 레이어가 두꺼워지면 사람이 이해하기는 좋아집니다. 간혹 OOP 코드가 "따라가기 어렵다"라고 말하는 사람을 볼 수 있는데 OOP 코드는 읽을 때도 OOP적으로 읽어야 이해하기 쉽습니다. 따라가려 하지 않고 그대로 이해하는데 초점을 두면 두꺼운 레이어에 고마워하게 되는 경우가 많죠.

익명 사용자의 이미지

offtopic 입니다

happycat wrote:

아.. C++인 줄 알았습니다. (죄송합니다;; )

singleton은 PHP에서 구현(흉내?)해서 사용 가능합니다. ㅎㅎ;;

아 ~ 예 :wink:

하지만 덕분에 singleton은 건젔네요.

happyjun의 이미지

Quote:
모든 것의 클래스화가 좋은가..하는 의문이 생기는 것 자체가 좀 비 OOP적이라고 할 수도 있겠습니다.

OOP의 장점은 재사용성에 있습니다. 하지만 잘못 설계되거나 dependancy가 많으면 재사용 될 수 없습니다. class에 넣지 않고 global function으로 만들면 재사용성의 높아지는 경우에는 class에 넣지 않는 것이 좋습니다.

STL만 보더라도 많은 Generic Programming관점의 template화된 global function들이 있습니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

creativeidler의 이미지

Quote:
OOP의 장점은 재사용성에 있습니다. 하지만 잘못 설계되거나 dependancy가 많으면 재사용 될 수 없습니다. class에 넣지 않고 global function으로 만들면 재사용성의 높아지는 경우에는 class에 넣지 않는 것이 좋습니다.

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의 구분도 주로 이런 기준으로 되어 있습니다.

죠커의 이미지

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

왠지 일반적인 STL의 관점과는 반대인 것 같습니다.

STL에서는 추상화된 접근으로 모든 컨테이너에서 동일한 방식으로 접근을 하되 성능상의 이유로 구체화된 구현을 담은 컨테이너라는 이야기를 종종 하죠.

결과는 같지만 과정의 생각이 다른 것 같습니다. :-)

JosephJang의 이미지

creativeidler wrote:
C++의 탈을 쓴 C라는 말의 의미는 그 코드가 C++에서 컴파일되고 C++의 기능을 일부 쓰긴 하지만 C코드랑 별 차이 없고 C++의 중요한 장점을 활용하지 못했으므로 삽질이다...이런 뜻이겠죠.

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

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

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

Quote:

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

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에 관한 인간의 생각을 잘 반영하긴 하지만, 인간의 모든 생각을 완전히 반영하는 것은 아니라고 생각합니다. 의외로 인간은 중앙 집중식의 조직이나 생각에도 익숙하죠.

pool007의 이미지

Quote:
클래스에서 printf 썻다고 C++탈을 쓴 C라면서 머라고 하는데.....

printf와 << 의 차이점은 분명히 있습니다.

printf는 출력 포멧을 출력할 때 마다 지정하는 것이지만, << 의 경우에는 단지 넘겨주기만 할 뿐 출력 포멧 그 자체는 연산자의 오버로딩 된 규칙을 따르겠다는 것입니다.

하지만 만약에

int a=3;
printf ("%d", a); // (1)
cout << a; // (2)

와 같은 코드에서 (1)과 (2)의 차이점을 따진다면 없다고 봐야겠죠..

가령 이와같은 경우를 생각해볼 수 있습니다. 처음에는 메시지를 A라는 포멧으로 화면에 출력하기로 했습니다. 그런데 나중에가서 B라는 포멧으로 출력하고자하면 코드를 일일히 뒤져가면서 printf의 양식을 변경해야겠죠. 그러나, "<<"를 사용했다면 연산자 오버로딩만 고쳐주면 될 것입니다. [/code]

--
Passion is like genius; a miracle.

ed.netdiver의 이미지

JosephJang wrote:

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

Quote:

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

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 모델링은 흔히 잘못되었습니다.)

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

음, 이 글타래 여는 글은 비교적 가볍게 시작했지만, 내용이 갈수록
진지해지는군요 :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

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

happycat의 이미지

qed wrote:

제가 oop라는 학문 자체를 체계적으로 공부해본 경험과 깊이가
적어서이기도 하겠지만, cpp는 과제를 진행하는데 너무 burden이
많은 언어였다는걸 새삼 깨닫곤 합니다.(즉, 전 cpp예찬론자(?^^)는
아니란 뜻입니당.)

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

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

저는 역으로 cpp 예찬론자이고, cpp를 아주 좋아합니다. 언어적인 디자인으로 따지면 파이썬과 ML을 좋아합니다만, 실용적인 관점에서 cpp를 좋아하고, 유용하게 사용하고 있습니다. 그리고 사실 함수 + 포인터 + 스트럭쳐로 도배된 C코드(이런 코드가 잘못되었다기 보다 C에 활용할 수 있는 게 저거 뿐이죠;; )를 보면 머리가 지끈지끈 아파 옵니다.. 그렇지만 저는 C++에서 클래스 말고도 상황에 맞는 도구를 선택해 쓸 수 있다고 생각합니다. 심지어 싫어해 마지 않는 포인터 도배 함수조차도 말이죠..

이건 결코 C++에서 클래스가 가지는 중요성을 부인한다거나, 클래스의 존재 목적을 부인하는 것이 아닙니다. 오히려 어떻게 해야 OOP적인 관점에서 class를 잘 설계할 것인가.. 어떻게 클래스를 디자인 해야 좋은 클래스가 나오는 것인가.. 함수를 사용할 때와 차이가 무엇인가.. 이런 걸 진지하게 고민했을 때 나오는 결론입니다. 즉 '클래스가 정말 잘 들어맞는 모델을 클래스를 사용하여 잘 디자인 하고 싶을 때' 그 외 모델들에 대해서는 클래스를 사용하지 않는 게 나은 경우도 있다는 걸 인정 하는 것입니다. 클래스를 사용하는 게 잘 맞을 때와 잘 맞지 않을 때에 대해서는 JosephJang님께서 좋은 말씀을 많이 해 주셨고, 저도 이 글타래를 통해 많이 배우게 되는군요 :)

즉, 클래스를 몰라서 클래스를 안 쓰는 것과, 클래스를 잘 알면서 그 외 도구들의 사용에 제한을 두지 않는 것은 차이를 두어야 합니다. 전자의 경우는 어떻게든 클래스를 사용해 보면서 감을 익히는 것이 좋을테고, 후자의 경우는 상황에 맞는 걸 취사선택하는 능력이 있다는 소리겠지요. 서지훈님의 경우 전자를 규탄하는 말씀이라 생각하고, JosephJang님의 경우는 후자의 관점을 이야기하는 것이라 봅니다. (개인적으로도 JosephJang님을 알고 있습니다만, C++과 클래스를 정말 잘 사용하시는 분입니다.)

doldori의 이미지

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

kknd345 wrote:
그런데 보통 제 친구들 경우 C와 C++ 의 경계선을 두고 있는 것 같습니다. 전 실무 경험 있는 선배한테 듣기로 C와 C++ 을 구지 구분 할 필요가 없다고 들었는데요.

저는 반대로 구분할 필요가 있다고 생각합니다. 특정 문법을 썼느냐의 문제가 아니라
프로그래머의 의도로 구분된다는 뜻입니다. 예를 들어 저는 C++로 코딩할 때는 C에서도
쓸 수 있는 문법만을 쓰더라도 <math.h>가 아니라 <cmath>를 #include 합니다.
그럼으로써 이 코드는 C++이며 차후 변경이 있을 때 C 컴파일러로 컴파일하는 것을 고려하지
않겠다는 의도를 나타내는 것입니다. 제 경험상 C와 C++ 모두를 타겟으로 하는 코드는
나중에 문제를 일으킬 가능성이 높은 것 같습니다. 이 둘 사이에는 미묘한 차이점이 많아서
같은 코드라도 다르게 해석되는 경우가 있습니다.

kknd345 wrote:
친구들 이야기 하는 거 들어보면 조금 갑갑하기도 합니다. 클래스에서 printf 썻다고 C++탈을 쓴 C라면서 머라고 하는데.....

printf()를 썼다는 이유만으로 이런 얘기를 한다면 그리 신경쓰지 마십시오. 그렇지만
C++을 쓰신다면 iostream 클래스를 알아둘 필요는 있습니다. 타입 안전성, 예외 안전성,
유연성, 확장성 면에서는 FILE 구조체보다 월등히 낫습니다. 속도 면에서는 FILE이
확실히 빠르고 타이핑도 덜 하게 되는 장점이 있습니다만, 저는 iostream의 단점이
장점보다 커서 FILE을 택해야 했던 경험은 없었습니다.

kknd345 wrote:
그리고 정컴에서 모든걸 클래스화 하려는 경향이 강한데... 학년이 낮아서 그런지는 몰라도 실제로 모든 걸 클래스화 하는 버릇이 좋은건가요?

문제를 해결하는 과정에서 추상화에 대한 고민을 한 번쯤 해보는 것은 참 좋은 습관이라고
생각합니다. 그게 아니라 모든 문제를 기계적으로 클래스로부터 시작하려 한다면 별로
바람직하지는 않겠습니다.

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

nohmad의 이미지

C++에 cstdio 같은 라이브러리들이 포함된 데는 나름의 이유가 있다고 생각합니다.
C++의 IO 클래스는 사용하기가 그리 쉬운 편은 아닙니다. printf에 익숙한 사람이
C++의 IO 클래스를 익혀서 printf 처럼 익숙하게 사용하려면 아무래도 많은 노력이
필요합니다. 하지만 꼭 그렇게 힘들게 노력해야 할 필요가 있는지는 의문입니다.
printf에 사용되는 포맷지정자는 잘 정의된 규칙들을 가지고 있고, 자바, 파이썬,
펄, 루비, php 같은 언어에서도 비슷한 포매팅 규칙이 존재합니다. 중요한 것은 이
포매팅 규칙을 잘 사용해서 원하는 목표를 이루는 것이지, 메쏘드로 존재하느냐
함수로 존재하느냐는 상대적으로 부차적인 문제입니다.

printf 대신에 System.out.printf를 쓰는 것이 얼마나 큰 차이가 있나요? 제가
생각하기에 C++이 갖는 미덕은 C가 확립한 범용성을 그대로 포용할 수 있었다는
점입니다. 타이거 이전의 자바에서 printf를 쓰지 못해 불편하다고 생각한 적이
있는 자바 프로그래머들이 적지 않을 거라고 생각합니다. OOP의 순수성(?) 때문에
그런 건지는 모르겠지만 printf도 없는 자바보다는 필요하면 C에서 쉽게 가져다 쓸
수 있는 C++의 편리성이 프로그래밍 언어의 관점에서 더 추구할 만한 가치가 있다고
생각합니다.

doldori의 이미지

nohmad wrote:
C++에 cstdio 같은 라이브러리들이 포함된 데는 나름의 이유가 있다고 생각합니다.
C++의 IO 클래스는 사용하기가 그리 쉬운 편은 아닙니다. printf에 익숙한 사람이
C++의 IO 클래스를 익혀서 printf 처럼 익숙하게 사용하려면 아무래도 많은 노력이
필요합니다. 하지만 꼭 그렇게 힘들게 노력해야 할 필요가 있는지는 의문입니다.

printf()를 잘 쓰는 사람이라면 iostream을 배우는 것이 그리 어렵지 않을 것이라고
봅니다. 정확히 기억이 나지는 않지만, 저는 cout을 배울 때 printf()를 배우는 딱
그 정도의 노력을 한 것 같습니다.
FILE과 iostream의 차이를 물으시니 몇 가지만 예를 들어보겠습니다.

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

2. 예외 안전성

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

이 코드에서 예외가 발생하면 리소스 릭이 생깁니다. FILE을 쓸 때마다 수동으로
롤백을 해주는 것은 꽤나 피곤한 일이고, 이를 해결하기 위해서 RAII를 적용할 수도
있지만, fstream은 보다 직관적으로 리소스의 해제까지 해줍니다.

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

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

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

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

hey의 이미지

제가 신경쓰이는 부분은 iostream에는 gettext 적용이 어렵다는거 ..


----------------------------
May the F/OSS be with you..


creativeidler의 이미지

Quote:

STL에서는 추상화된 접근으로 모든 컨테이너에서 동일한 방식으로 접근을 하되 성능상의 이유로 구체화된 구현을 담은 컨테이너라는 이야기를 종종 하죠.

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

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

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

그렇습니다. 그래서 제 주장은 그 비난이 나름대로 합당한 근거가 있는 비난이라는 것입니다. 물론 그렇다고 그 비난을 할 것이냐 말 것이냐는 또 다른 문제겠지요.

Quote:
그렇다면, 하나의 data에 관한 algorithm을 하나의 파일에 잘 분리해둔 pascal 프로그램도 OOP를 한 것인가요? 그 파일과 class의 차이는 무엇일까요?

아주 좋은 예를 들어주셨습니다. 이런 경우라면 그 pascal 프로그램도 상당히 OOP적으로 만들어졌다고 할 수 있겠습니다. 하지만 C++에서 그런 식으로 코딩한다면 얘기가 다르죠. 똑같은 걸 하면서 class를 쓰면 훨씬 편한데 안 쓰고 빙 둘러가는 거니까 말입니다.

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

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

스펙이 좀 덜 상세하긴 하지만 두 케이스 모두 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 안되는 언어는 쳐다보기 싫어질 겁니다.

JosephJang의 이미지

Quote:

아주 좋은 예를 들어주셨습니다. 이런 경우라면 그 pascal 프로그램도 상당히 OOP적으로 만들어졌다고 할 수 있겠습니다. 하지만 C++에서 그런 식으로 코딩한다면 얘기가 다르죠. 똑같은 걸 하면서 class를 쓰면 훨씬 편한데 안 쓰고 빙 둘러가는 거니까 말입니다.

글쎄요, 저는 반대로 algorithm과 data를 모아놨다고 항상 object가 된다고는 생각하지 않습니다. procedural approach를 취했을 때 나오는 module을 object로 전환하기 어려운 것과 비슷하다고 생각합니다. (많은 사람들이 그렇게 OOP 언어를 사용하지만..)

Quote:

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

가능하긴 하겠죠. 하지만, 제가 말한 얘기와 어느 정도 동떨어진 프로그램이 되어버리지 않습니까? procedural approach를 취했을 때, 오히려 제가 말한 user story에 더 들어맞는다고 생각하시지 않나요?
말씀하신대로 role 단위의 object를 찾아내는 것보다 제가 말로 설명한 것들을 그대로 task 단위의 procedure들로 쪼개는 것이 훨씬 간단한 솔루션이라고 생각하시지 않는지요? 제가 얘기한 작업이 시간 순서대로 나열되어있고, 이것이 그대로 프로그램에 반영되는 것이 이해하기에도 훨씬 낫다고 생각하시지 않으시나요?
OO practice에서도 여러가지 abstraction을 표현하기 위한 방법들을 만들어내고 이를 패턴으로 보편화 시켜놓았지만, 어떤 때는 그냥 procedural을 사용하는 것이 오히려 자연스러운 경우가 있다고 봅니다.

Quote:

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

역사적인 이유라는 점에는 동감입니다. 소프트웨어는 하드웨어 또는 OS의 서비스를 사용하는 경우가 대부분이므로, procedural이 적합한 게 아닐까 하는 생각을 해봅니다. 하지만, 하드웨어 자체가 중앙 집중적인 hierarchy 구조를 가지고 있는데 (controller, controler, ...), 하드웨어 컴포넌트가 object로서 적합한지가 의문입니다. 그렇다면 하드웨어 컴포넌트가 object로서 설계된다면?
물론 가능하겠죠. 하지만 그럴만한 "필요"가 있을까요? 얻는 이점이 얼마나 클까요?
OS를 포함한 소프트웨어 수준에서 OO 방식의 API를 제공하고 소프트웨어 개발자들이 이를 활용하는 방향 정도가 적당하겠죠.

Quote:

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

중복의 제거나 abstraction, 전부 modular programming의 practice 일 뿐이지, OOP만 그 혜택을 보는 것은 아니라고 봅니다.

Quote:

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

OOP에 대한 '반대 비슷한' 의견을 계속 늘어놓았지만, 개인적으로는 OO의 열렬한 팬입니다. 하지만, OOP가 모든 문제에 대해 절대적으로 더 나은 솔루션이라는 점에는 의문을 제기할 수 밖에 없습니다. 제 자신을 설득할 자신이 없습니다.
어쩌면, 어떤 문제에 대한 '절대적인' 솔루션이라고 하는 것들이 워낙 사기들이 많았기 때문에, 선입견적인 불신이 싹트는 지도 모르겠습니다. ;-)
creativeidler의 이미지

Quote:
하지만, OOP가 모든 문제에 대해 절대적으로 더 나은 솔루션이라는 점에는 의문을 제기할 수 밖에 없습니다. 제 자신을 설득할 자신이 없습니다.
어쩌면, 어떤 문제에 대한 '절대적인' 솔루션이라고 하는 것들이 워낙 사기들이 많았기 때문에, 선입견적인 불신이 싹트는 지도 모르겠습니다

절대적인 솔루션....은 물론 아니겠죠. 제 주장은 OOP가 SP보다는 거의 항상 나은 솔루션이라는 것입니다. SP와의 상대적인 비교를 넘어선 절대적인 가치 문제로 확대되지 않았으면 하는 바램입니다.

Quote:

중복의 제거나 abstraction, 전부 modular programming의 practice 일 뿐이지, OOP만 그 혜택을 보는 것은 아니라고 봅니다.

물론 그것이 SP라고 가능하지 않은 것도 아니고 흑백을 가르려는 생각도 없습니다. 다만 OOP에서 그 혜택을 100만큼 본다면 SP는 채 10도 안된다는 것이지요. 이것도 아니라고 생각하십니까?

Quote:
하지만, 제가 말한 얘기와 어느 정도 동떨어진 프로그램이 되어버리지 않습니까?

어떤 면에서 동떨어진다는 뜻인지 잘 모르겠으나 님이 들어주신 예, 그리고 Controller/Manager에 대한 논의를 바탕으로 생각해볼 때 님은 좋은 OOP의 object는 실세계의 object와 대응이 잘 되어야한다고 생각하시는 듯 합니다. 제 생각은 그것과 좀 다릅니다. OOP 코드에서는 실세계에는 실체로 존재하지 않는 중간 단계의 object들이 많이 생길 수 있고 그것이 오히려 바람직한 것입니다. 월급 주는 시스템의 경우 사장 객체, 경리 객체, 은행 객체 등으로 나타난다기보다 그 시스템 자체가 급여 객체로 나타날 것입니다. 이를테면 다음과 같은 식이 되겠죠.
급여 이달급여 = new 급여(new Date());
for 사원:
    급여.줘(사원);

이 급여라는 객체는 실세계에서는 프로세스로 존재하는 것이지만 이 프로세스 자체도 object가 될 수 있습니다. 꼭 실세계의 object가 코드의 object로 대응되는 것은 아니죠. Controller/Manager가 OOP 개념에 대한 이해 부족에서 나오는 경우도 많지만 정말 그것이 추상적이나마 존재하는 개념이기 때문에 object로 모델링되는 경우도 많습니다. 이를테면 DB 커넥션 풀 관리자의 경우도 커넥션 풀 객체와 별도로 관리자 객체가 존재하며 상태도 가집니다. 사용자의 입장에서보면 커넥션을 리턴하는 프로세스만 갖고 있는 것처럼 보일 수도 있지만 각종 설정에 대한 상태를 보관하고 있어야하기 때문에 object의 자격이 있는 것이고 이렇게 디자인하는 것이 더 쉽기도 하죠. 딱히 상태+프로세스가 항상 object가 되어야한다기보다 object로 만드는 것이 편하고 쉽다고 말하고 싶습니다.

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

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

죠커의 이미지

creativeidler wrote:
Quote:

STL에서는 추상화된 접근으로 모든 컨테이너에서 동일한 방식으로 접근을 하되 성능상의 이유로 구체화된 구현을 담은 컨테이너라는 이야기를 종종 하죠.

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



글을 너무 대충 적었나 봅니다. 대부분의 컨테이너에서 사용할 수 있는 sort가 있지만 몇몇 컨테이너는 별개로 sort를 내장하고 있다는 것입니다. 알고리즘 자체의 추상화된 접근을 통해서 범용으로 사용가능한 sort를 만들었지만 성능상의 문제로 일부 컨테이너에 메소드의 형태로 고성능 sort를 구현하고 있다는 것입니다.

이런 관점은 creativeidler님이 이야기한 것과 결과는 같지만 사고의 단계는 다른 것이 재밌다고 적었습니다. 반대로 생각했지만 같은 결과물이 나온 것이지요.

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

일반적으로 OOP는 문제의 모델링 자체는 쉽지만 상대적으로 두꺼운 레이어가 구성됩니다. 모델링이 쉬운 점이 복잡한 GUI 환경의 Application을 만드는 것에는 뛰어난 방법이지만 대부분의 환경에서 모델링 자체를 위해 두꺼운 레이어를 감안해야 할 정도로 우수한 방법론 인지 의문의 여지가 남습니다. 두꺼운 레이어는 많은 코드를 만들고, 많은 코드는 프로그래머가 이해하기 어렵고, 이해하기 어려운 코드는 버그를 만듭니다.

creativeidler의 이미지

Quote:
두꺼운 레이어는 많은 코드를 만들고, 많은 코드는 프로그래머가 이해하기 어렵고, 이해하기 어려운 코드는 버그를 만듭니다.

흠. 전 이것이야말로 OOP에 대한 오해의 주범이라고 봅니다. 두꺼운 레이어는 더 많은 코드를 만들지 않습니다. 오히려 공통 부분을 일반화시켜 더 적은 코드를 만들 수도 있죠. 오히려 같은 Function Point에 대해 OOP에 가까운 언어일수록 더 적은 코드로 같은 일을 수행합니다.

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

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

이런 코드를 절차적으로 이해하려 들면 resolver.getRequiredPermission이라는 메쏘드의 내용이 뭔지 들어가서 코드 따라가면서 이해하려고 하게 되죠. 실제 많은 프로그래머들이 이런 식으로 코드를 읽습니다. 그러면 당연히 레이어가 두꺼울수록 깊이 들어가야되니까 복잡해지고 이해하기 어려워지죠. 하지만 OOP적으로 이해하는 경우 그냥 저 문장의 뜻만 취하고 내부 구현에는 관심 갖지 않습니다. 그러면 이해해야하는 내용은 단 두 줄로 줄어들고 저 코드에는 버그가 생길 여지가 훨씬 줄어들죠. 그래서 좋은 OOP 코드가 되려면 naming에 신경을 많이 써야합니다. 리팩토링에서 rename을 중요하게 생각하는 이유도 여기에 있죠. 결국 OOP는 이해해야하는 코드의 단위를 SP보다 더 잘게, 그리고 더 이해하기 쉬운 단위로 쪼개주기 때문에 더 적은 버그를 만듭니다.

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

kane의 이미지

CN wrote:
일반적으로 OOP는 상대적으로 두꺼운 레이어가 구성됩니다. 이런 점이 GUI 환경의 Application을 만드는 것에는 뛰어난 방법이지만 대부분의 환경에서 우수한 방법론 인지 의문의 여지가 남습니다. 두꺼운 레이어는 많은 코드를 만들고, 많은 코드는 프로그래머가 이해하기 어렵고, 이해하기 어려운 코드는 버그를 만듭니다.

레이어가 두터워지면 이해하기 어렵다는데 동의합니다. (레이어가 두터워진다고 더 많은 코드가 만들어진다는 점은 의문이군요.)
하지만 GUI나 기본 라이브러리 외에 그만큼 두터운 레이어를 가지고 있는/가져야 하는 것들이 얼마나 있는지 모르겠네요. 상속을 과용해서 불필요한 레이어를 만들어낸 것은 아닐까요. 라이브러리 디자이너가 아니라면, 간략한 계층 구조로 (혹은 계층 구조 없이) 디자인하는 것이 바람직할 겁니다.
전 두꺼운 레이어가 OOP의 잘못이 아니라 사람의 잘못이라고 생각합니다.
JosephJang의 이미지

creativeidler wrote:

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

creativeidler wrote:

절대적인 솔루션....은 물론 아니겠죠. 제 주장은 OOP가 SP보다는 거의 항상 나은 솔루션이라는 것입니다. SP와의 상대적인 비교를 넘어선 절대적인 가치 문제로 확대되지 않았으면 하는 바램입니다.

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

creativeidler wrote:

Quote:

중복의 제거나 abstraction, 전부 modular programming의 practice 일 뿐이지, OOP만 그 혜택을 보는 것은 아니라고 봅니다.

물론 그것이 SP라고 가능하지 않은 것도 아니고 흑백을 가르려는 생각도 없습니다. 다만 OOP에서 그 혜택을 100만큼 본다면 SP는 채 10도 안된다는 것이지요. 이것도 아니라고 생각하십니까?

문제 도메인에서 abstraction을 찾아내도록 유도한다는 의미에서 그런 것인가요?

Quote:

Quote:
하지만, 제가 말한 얘기와 어느 정도 동떨어진 프로그램이 되어버리지 않습니까?

어떤 면에서 동떨어진다는 뜻인지 잘 모르겠으나 님이 들어주신 예, 그리고 Controller/Manager에 대한 논의를 바탕으로 생각해볼 때 님은 좋은 OOP의 object는 실세계의 object와 대응이 잘 되어야한다고 생각하시는 듯 합니다. 제 생각은 그것과 좀 다릅니다. OOP 코드에서는 실세계에는 실체로 존재하지 않는 중간 단계의 object들이 많이 생길 수 있고 그것이 오히려 바람직한 것입니다.

'실체'로 나타나야한다고는 생각하지 않습니다. 문제 도메인에 즉, 제가 스펙으로 제시한 것과 같은 user story에 있는 것이 (그것이 실체든 추상적인 것이든) 프로그램에도 잘 반영되어야 한다고 생각합니다. 그래야, 이해하기 쉽고, 유지보수하기도 편한 코드가 만들어진다고 생각합니다. "급여"라는 것도 문제 도메인에서 상당히 중요한 개념이기 때문에 역시 중요한 object로 취급된 것이겠죠.
마찬가지로, 장인이 목각품을 만드는 과정의 특징, 장인이 거의 모든 중심적인 control을 가지고 있다는 도메인의 특징, 시간적인 흐름, 즉 sub-control 간의 정해진 순서를 가지고 있다는 도메인의 특징이, procedural로 나타낼 때, 약간은 더 적은 노력을 필요로 한다고 생각합니다. (대단히 큰 차이가 있다고는 생각하지 않습니다.)
덧붙여, 문제 도메인에 대한 성격에 따라, OOP보다 PP가 나을 수 있다는 생각은, 이 논의를 통해서 처음으로 해본 것이고, 저도 그다지 자신이 있는 편은 아닙니다. :-) (예로 든 것도 허름하고...) 시간을 두고 좀 더 생각을 해봐야할 것 같습니다. creativeidler님은 좋은 논쟁 상대인 것 같습니다.
Quote:

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

SP가 OOP보다 그 자체로 어떤 나은 점이 있다는 식으로 얘기가 진행되어왔는데요.
SP와 OOP는 선택의 문제인가/아닌가 하는 원래의 문제로 돌아오면, 실제로 OOP가 SP보다 모든 측면에서 모든 경우에 좋더라도, 이러한 환경적인 문제도 실제로는 결코 무시할 수 없는 요인이 되는 거겠죠.
creativeidler님이 예외적인 환경 조건으로 든 것 외에, 한가지 더 예를 들면, 스킬의 성숙도 문제가 있겠죠. 프로젝트 초기에 가능한 인력이 procedural programming이 가능한 senior 5명과 object-oriented programming이 가능한 junior 1명이 있다면, 그 프로젝트는 procedural로 선택하는 것이 "당연"한 거죠.
익명 사용자의 이미지

creativeidler wrote:

하지만 OOP적으로 이해하는 경우 그냥 저 문장의 뜻만 취하고 내부 구현에는 관심 갖지 않습니다. 그러면 이해해야하는 내용은 단 두 줄로 줄어들고 저 코드에는 버그가 생길 여지가 훨씬 줄어들죠.

이건 이상적인 경우라고 생각이 되네요.
내부구현을 보지 않고 겉모양만 본다는 것은 그 라이브러리를 완전히 신뢰할때나 가능한데, 이런 경우는 그다지 많지 않죠. 또한 자신이 완전히 신뢰할수 있는 클래스를 짜는것도 어렵구요. oop 코드중 정말 이렇게 아릅답게 도는 코드가 얼마나 있을까요.

만약 이렇게 쓰다가 클래스 내부에서 문제가 발생했을 경우에 그걸 추적하고 수정하는게 SP 보다 월등히 쉽다고 생각되지도 않구요. 클래스 상속구조 등을 모른상태에서 수정을 가하다 보면 모양이 망가지고, 그 후에 그 코드를 보는 사람은 깔끔한 oop 를 기대하면서 봤다가 좌절하게 되겠죠.

쩝 OOP 나 SP 나 그냥 방법론중의 하나인데, OOP 좋아 하시는분들이 SP 를 저급으로 보는일은 없었으면 하네요. 생산성같은 경우도 OOP 냐 SP 라는것보다는 개인능력이 더 중요한 요소일테구요.

그리고 python 이나 java 가 C 보다 생산성이 월등한것은 최신의 언어라서, OOP 를 지원해서 라는 점도 있지만, 결정적인 것은 자체 제공하는 라이브러리들이 풍부하다는것 때문이 아닐까요. python 이나 java 도 라이브러리 지원이 C/C++ 수준이었다면 널리 쓰이지도 않았겠죠.

creativeidler의 이미지

Quote:
이건 이상적인 경우라고 생각이 되네요.

그 이상적인 상황을 저는 참 많이 봤답니다.

Quote:

그리고 python 이나 java 가 C 보다 생산성이 월등한것은 최신의 언어라서, OOP 를 지원해서 라는 점도 있지만, 결정적인 것은 자체 제공하는 라이브러리들이 풍부하다는것 때문이 아닐까요. python 이나 java 도 라이브러리 지원이 C/C++ 수준이었다면 널리 쓰이지도 않았겠죠.

자바와 파이썬 모두 초창기에는 C/C++에 비해 라이브러리가 훨씬 부족했습니다. 그럼에도 불구하고 점점 사용자가 늘어나서 지금의 모습이 된 것이죠.

Quote:

쩝 OOP 나 SP 나 그냥 방법론중의 하나인데, OOP 좋아 하시는분들이 SP 를 저급으로 보는일은 없었으면 하네요. 생산성같은 경우도 OOP 냐 SP 라는것보다는 개인능력이 더 중요한 요소일테구요.

가끔 상대주의가 발전에 대한 부정으로 나타나는 것을 보면 안타까움을 느낍니다. 개인 능력? 물론 중요하겠지만 그게 지금 이 문제랑 대체 무슨 상관입니까? SP를 OOP보다 저급으로 보면 안되는 이유는 무엇인지요?
ssif의 이미지

creativeidler wrote:

가끔 상대주의가 발전에 대한 부정으로 나타나는 것을 보면 안타까움을 느낍니다. 개인 능력? 물론 중요하겠지만 그게 지금 이 문제랑 대체 무슨 상관입니까? SP를 OOP보다 저급으로 보면 안되는 이유는 무엇인지요?

저....주제는 c 와 c++의 경계는 무엇인지에 대하여입니다.'저급'이냐 '고급'이냐 에 대한 토론은 다음 기회에 하시는 것이 좋을것 같습니다. :oops:

봄들판에서다

creativeidler의 이미지

Quote:
저....주제는 c 와 c++의 경계는 무엇인지에 대하여입니다.'저급'이냐 '고급'이냐 에 대한 토론은 다음 기회에 하시는 것이 좋을것 같습니다.

허허. 주제는 말씀처럼 C와 C++의 경계가 무엇인지가 맞죠. 그리고 그 경계의 기준이 class의 사용이냐 아니냐로 논점이 되었죠? 그리고 OOP가 좋은 것이므로 class를 사용하는 게 좋다는 주장이 제기되었고 그에 대한 이야기가 오가는 중입니다. 그러니 OOP가 SP보다 고급이냐 아니냐는 당연히 주제와 밀접한 관련이 있는 것이랍니다.
creativeidler의 이미지

Quote:
마찬가지로, 장인이 목각품을 만드는 과정의 특징, 장인이 거의 모든 중심적인 control을 가지고 있다는 도메인의 특징, 시간적인 흐름, 즉 sub-control 간의 정해진 순서를 가지고 있다는 도메인의 특징이, procedural로 나타낼 때, 약간은 더 적은 노력을 필요로 한다고 생각합니다.

먼저 용어에 대한 합의를 봐야할 것 같습니다. JosephJang님은 몇 군데에서 PP를 OOP에 대비되는 개념으로 쓰시고 있으신데 그것이 Procedural Programming을 의도하신 거라면 조금 범주가 다른 이야기가 아닐까 싶습니다. Procedural Programming은 Functional Programing과 대비되는 개념이고 제가 문제 삼고 싶었던 것은 SP(Structured) vs OOP입니다. 둘다 PP일 수도 있고 FP일 수도 있죠. C는 PP이면서 SP이고 SQL은 FP이면서 SP, Lisp는 FP이면서 OOP, Java는 PP이면서 OOP라고 할 수 있을 것입니다. 즉, OOP는 PP를 부정하지 않기에 말씀하신 예에서 procedural로 나타난다해도 그것이 OOP냐 아니냐는 또 다른 문제라는 것입니다.

그래서 여기서 따져봐야할 것은 procedural하게 구현할 것이냐 OOP로 구현할 것이냐라기보다 과연 장인 object 같은 걸 만들고 process를 장인 object의 메쏘드로 만드는 것이 좋은가, 아니면 그냥 function으로 해결할 것이가의 문제로 보아야할 것입니다. 이런 각도에서 볼 때 JosephJang님은 그냥 function으로 해결하는 것이 더 적은 노력을 필요로 한다고 생각하시는 것인가요?

저는 이런 경우 장인이 한 종류라면 function으로 만드나 장인 object의 메쏘드로 만드나 큰 차이는 없을 거라는데 동의할 수 있습니다. 그러나, 굳이 선택하라면 그래도 장인이 도구도 가져야하고 작업장도 가져야한다는 점, 즉 상태를 갖는다는 점을 생각한다면 역시 장인 object에 손을 들어주고 싶습니다. 거기다가 두 종류로 늘어난다면 차이가 확 드러나기 시작하겠죠.

Quote:
프로젝트 초기에 가능한 인력이 procedural programming이 가능한 senior 5명과 object-oriented programming이 가능한 junior 1명이 있다면, 그 프로젝트는 procedural로 선택하는 것이 "당연"한 거죠.

그렇습니다. procedural을 SP로 바꾼다면 거의 완전히 동의할 수 있습니다. 그러나, 상황을 살짝 바꿔서 프로그래밍 입문자 5명과 SP, OOP 모두 익숙한 senior 한 명이 있다면 어떻게 하시겠습니까? 어차피 SP든 OOP든 5명에게 가르치면서 해야하는 상황이라면 말입니다. 저라면 언어가 일단 OOP 가능 언어로 선택되었다면 바로 OOP로 갈 것 같습니다. TDD라는 너무나 쉽고 강력한 무기가 있으니까요.
익명 사용자의 이미지

creativeidler wrote:
Quote:

이런 코드를 절차적으로 이해하려 들면 resolver.getRequiredPermission이라는 메쏘드의 내용이 뭔지 들어가서 코드 따라가면서 이해하려고 하게 되죠. 실제 많은 프로그래머들이 이런 식으로 코드를 읽습니다. 그러면 당연히 레이어가 두꺼울수록 깊이 들어가야되니까 복잡해지고 이해하기 어려워지죠. 하지만 OOP적으로 이해하는 경우 그냥 저 문장의 뜻만 취하고 내부 구현에는 관심 갖지 않습니다.

제일 접하기 쉬운 예로 mfc와 api를 예로 들어보면,
mfc소스를 참조해야할 일이 있습니다.
책에 나와있는거나 메뉴얼같은 걸로는 부족합니다.

그냥 책에 나와있거나 쉬운 부분은 이름보거나,책만 참고해도 씁니다.
그러나 제대로 짤려면 소스 참조하지 않고는 불가능합니다.

atie의 이미지

JosephJang wrote:
...
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 모델링은 흔히 잘못되었습니다.)

...


SP에서는 operation을 중심으로 data를 어떻게 취급할 것인가를 다루는 반면에, OOP에서의 구조는 data에 의해 조직화된다는 서로 상반된 접근 방법이라는 점을 간과하시는 듯 합니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

htna의 이미지

creativeidler wrote:
그렇습니다. procedural을 SP로 바꾼다면 거의 완전히 동의할 수 있습니다. 그러나, 상황을 살짝 바꿔서 프로그래밍 입문자 5명과 SP, OOP 모두 익숙한 senior 한 명이 있다면 어떻게 하시겠습니까? 어차피 SP든 OOP든 5명에게 가르치면서 해야하는 상황이라면 말입니다. 저라면 언어가 일단 OOP 가능 언어로 선택되었다면 바로 OOP로 갈 것 같습니다. TDD라는 너무나 쉽고 강력한 무기가 있으니까요.

제가 보기에는 TDD 는 OOP와는 별개의 방법론으로 알고 있습니다.
혹 creativeidler님 께서는 Refectoring도 OOP에 밀접한 관련이 있다 라고 생각하지 않을까 추측을 합니다만.
TDD와 Refectoring은 OOP와는 별개의 방법론이고, 다만 많은 설명과 방법적인 세부사항들을 OOP적인 관점에서 해석하고 예를 들고 있다 라고만 생각하고 있습니다.
TDD와 Refectoring을 주 무기로 내세워서 OOP를 PP/SP 보다 월등히 낫다라고 두둔하지 않으셨으면 합니다.

creativeidler wrote:
먼저 용어에 대한 합의를 봐야할 것 같습니다. JosephJang님은 몇 군데에서 PP를 OOP에 대비되는 개념으로 쓰시고 있으신데 그것이 Procedural Programming을 의도하신 거라면 조금 범주가 다른 이야기가 아닐까 싶습니다. Procedural Programming은 Functional Programing과 대비되는 개념이고 제가 문제 삼고 싶었던 것은 SP(Structured) vs OOP입니다. 둘다 PP일 수도 있고 FP일 수도 있죠. C는 PP이면서 SP이고 SQL은 FP이면서 SP, Lisp는 FP이면서 OOP, Java는 PP이면서 OOP라고 할 수 있을 것입니다. 즉, OOP는 PP를 부정하지 않기에 말씀하신 예에서 procedural로 나타난다해도 그것이 OOP냐 아니냐는 또 다른 문제라는 것입니다.

PP, SP, FP, OOP 프로그램 방법론이지 어떤 언어는 OOP이고 어떤언어는 OOP가 아니다 라고 말 할 수 없습니다.
제가 학부 졸업한지 시간이 그래도 몇년 이상이 지났기 때문에 많은 부분에서 개념적으로 좀 흔들릴 수 있습니다만...
어떤 language는 OOP 이고 어떤 language는 PP이고... 등의 주장은 설득력이 적어 보입니다.
아시다시피, OOP 는 Object Oriented Programming 입니다. Object 관점에서 프로그램을 하는것이죠. 역시 아실것이라 생각합니다만, C로도 OOP를 할 수 있습니다. 이 문제에 대해서 OOP적으로 프로그램 하는 것이다라고 주장하신다면.. ㅎㅎ 별 할 말이 없을것으로 압니다. OOP 다 OOP 적이다 라는 관점이 어느 경계를 지니는지 다시 생각해 봐야 할 테니깐요...

또한 일반적으로 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:
틀린부분 있으면 과감히 지적해 주시기 바랍니다. ^^;

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

JosephJang의 이미지

atie wrote:
JosephJang wrote:
...
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 모델링은 흔히 잘못되었습니다.)

...


SP에서는 operation을 중심으로 data를 어떻게 취급할 것인가를 다루는 반면에, OOP에서의 구조는 data에 의해 조직화된다는 서로 상반된 접근 방법이라는 점을 간과하시는 듯 합니다.

"차이가 없다"는 얘기가 아니라, 그런 접근에 따라 "차이가 있을 수도 있고, 없을 수도 있다"는 것을 얘기할려고 했습니다만 애매하게 보이긴 하는군요.

아래 글도 보셨다면 이런 말도 볼 수 있으셨겠죠.

JosephJang wrote:

글쎄요, 저는 반대로 algorithm과 data를 모아놨다고 항상 object가 된다고는 생각하지 않습니다. procedural approach를 취했을 때 나오는 module을 object로 전환하기 어려운 것과 비슷하다고 생각합니다. (많은 사람들이 그렇게 OOP 언어를 사용하지만..)

그리고 object는 data보다는 behavior에 따라 정의되어야 생각합니다만... data 자체는 수동적인 entity이므로, data를 기준으로 modeling하다보면, SP가 되기 쉽다고 봅니다.

죠커의 이미지

kane wrote:
CN wrote:
일반적으로 OOP는 상대적으로 두꺼운 레이어가 구성됩니다. 이런 점이 GUI 환경의 Application을 만드는 것에는 뛰어난 방법이지만 대부분의 환경에서 우수한 방법론 인지 의문의 여지가 남습니다. 두꺼운 레이어는 많은 코드를 만들고, 많은 코드는 프로그래머가 이해하기 어렵고, 이해하기 어려운 코드는 버그를 만듭니다.

레이어가 두터워지면 이해하기 어렵다는데 동의합니다. (레이어가 두터워진다고 더 많은 코드가 만들어진다는 점은 의문이군요.)
하지만 GUI나 기본 라이브러리 외에 그만큼 두터운 레이어를 가지고 있는/가져야 하는 것들이 얼마나 있는지 모르겠네요. 상속을 과용해서 불필요한 레이어를 만들어낸 것은 아닐까요. 라이브러리 디자이너가 아니라면, 간략한 계층 구조로 (혹은 계층 구조 없이) 디자인하는 것이 바람직할 겁니다.
전 두꺼운 레이어가 OOP의 잘못이 아니라 사람의 잘못이라고 생각합니다.

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

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

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

죠커의 이미지

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

이 부분은 객체지향의 공이라고 생각하기는 힘듭니다. JAVA와 Python은 언어자체가 C/C++보다 경제적입니다. 객체를 배제한 Python 역시 경제적이며 하나의 클래스 속에 모든 것을 넣은 Java 프로그래밍 역시 C/C++에 비해서 경제적입니다.

atie의 이미지

JosephJang wrote:
atie wrote:
JosephJang wrote:
...
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 모델링은 흔히 잘못되었습니다.)

...


SP에서는 operation을 중심으로 data를 어떻게 취급할 것인가를 다루는 반면에, OOP에서의 구조는 data에 의해 조직화된다는 서로 상반된 접근 방법이라는 점을 간과하시는 듯 합니다.

"차이가 없다"는 얘기가 아니라, 그런 접근에 따라 "차이가 있을 수도 있고, 없을 수도 있다"는 것을 얘기할려고 했습니다만 애매하게 보이긴 하는군요.

아래 글도 보셨다면 이런 말도 볼 수 있으셨겠죠.

JosephJang wrote:

글쎄요, 저는 반대로 algorithm과 data를 모아놨다고 항상 object가 된다고는 생각하지 않습니다. procedural approach를 취했을 때 나오는 module을 object로 전환하기 어려운 것과 비슷하다고 생각합니다. (많은 사람들이 그렇게 OOP 언어를 사용하지만..)

그리고 object는 data보다는 behavior에 따라 정의되어야 생각합니다만... data 자체는 수동적인 entity이므로, data를 기준으로 modeling하다보면, SP가 되기 쉽다고 봅니다.


주제에서 벗어난 지엽적인 것으로 토를 다는 것 같아 미안하지만, 제 의도는 "예를 들어 Account라는 클래스를 만들 때, Money라는 data를 저장하기 위해 int balance라는 attribute를 먼저 정의하고, 이 attribute에 대한 클래스의 서비스들을 예를 들어 withdraw(int amount), deposit(int amount), int getBalance() 같은 method(behavior)들로 제공하는 것이 OOP 접근 방법"이라는 뜻이었습니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

yasoo의 이미지

어떤놈을 쓰건간에...

장인의 정신? <- 여기 한표 드리고 싶네요 ㅋ

그 정신만 있다면....

C 와 C++ 을 나눈다는것 자체가... 이상한거 아닐까요?

그렇게 된다면.. C++ 과 JAVA 를 나눈다 또한

객체지향인데 둘중에 어떤걸?

이런것과 비슷한거 같네요 ㅋ

Can You See 1% of chance??
So that is MY WAY !!!

ed.netdiver의 이미지

yasoo wrote:
어떤놈을 쓰건간에...

장인의 정신? <- 여기 한표 드리고 싶네요 ㅋ

그 정신만 있다면....

C 와 C++ 을 나눈다는것 자체가... 이상한거 아닐까요?

그렇게 된다면.. C++ 과 JAVA 를 나눈다 또한

객체지향인데 둘중에 어떤걸?

이런것과 비슷한거 같네요 ㅋ

장인의 정신이라...

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

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

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

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

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

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

--------------------------------------------------------------------------------
\(´∇`)ノ \(´∇`)ノ \(´∇`)ノ \(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)

yasoo의 이미지

qed wrote:

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

모든사람들이 위장을 한다고 해도....
진짜 code를 사랑하는 사람 몇이 있을테니까요...

장인이란 그사람들을 지칭하는 말이겠죠???
저또한 무엇인가 잘하고 있는척...
그런짓을 해보지 않았다고는 말 못하는바이므로 ㅎ

장인이 되기위해서...
진정한 장인이되기 위하여.....(아직 무엇인지는 잘모르지만...)
노력을 해보렵니당 ^^

Can You See 1% of chance??
So that is MY WAY !!!

creativeidler의 이미지

Quote:

제가 보기에는 TDD 는 OOP와는 별개의 방법론으로 알고 있습니다.

그렇습니다. 별개의 방법론이죠. 하지만 TDD는 OOP에 이르는 아주 좋은 길을 제시하고 있습니다. 그런 차원에서 말한 것이죠.

Quote:
PP, SP, FP, OOP 프로그램 방법론이지 어떤 언어는 OOP이고 어떤언어는 OOP가 아니다 라고 말 할 수 없습니다.

개념의 구분을 위해 예로서 간략히 대비시킨 것을 이런 식으로 이해를 하시면 곤란합니다. C는 SP, Java는 OOP라는 말의 뜻은 C에서는 OOP를 할 수 없다는 뜻이 아니고 상대적으로 OOP를 하기 어렵다는 뜻입니다. 이 정도는 간단히 C는 SP다..라고 말해도 전체 맥락을 해치지 않는 범위 내에서 의사를 전달할 수 있다고 보는데요. 여기에 이런 식으로 따지고 드는 것은 C++로 C처럼 짜도 C++ 컴파일러로 컴파일 되는데 왜 C++ 아니라고 하느냐..와 같은 수준의 반론인 것 같습니다.

Quote:

또한 일반적으로 FP,SP,PP 는 서로 비슷한 특성을 지니고, OOP와는 완전히(??) 다른 특성을 지니 때문에, FP,SP,PP를 거의 하나로 보게 되는 경우도 많습니다.

FP에 대한 오해가 있지 않나 싶군요. 제가 말하는 FP는 소위 말하는 함수형 언어에서 지향하는 것입니다. FP의 function은 SP의 function과 의미가 다릅니다. Procedural Programming은 말 그대로 절차적인 프로그래밍이며 OOP 역시 그 메쏘드들은 PP로 작성되는 것이 당연하죠.

Quote:
혹시.. (요즘 재밌게 대두되고 있는) factor혹은 sin/cos 등과 같은 것 조차 OOP로 깔끔하게/잘(!!) 짤 수 있으신지요...
그렇다면, 그런분을 신(??)으로 모시겠습니다. ㅋㅋ

역시나 OOP가 PP와 상관 없다는 오해에서 출발한 발언인 듯 합니다. 신으로 모셔야할 사람이 아주 많을지도 모르겠군요. ^^
creativeidler의 이미지

Quote:
이 부분은 객체지향의 공이라고 생각하기는 힘듭니다. JAVA와 Python은 언어자체가 C/C++보다 경제적입니다. 객체를 배제한 Python 역시 경제적이며 하나의 클래스 속에 모든 것을 넣은 Java 프로그래밍 역시 C/C++에 비해서 경제적입니다.

하나의 클래스에 모든 것을 넣은 Java 프로그래밍이 C++에 비해서 더 경제적이라는 말은 동의할 수 없습니다. 제가 C++로 작성된 AES 암호화 모듈의 변종 하나를 Java로 포팅해본 적이 있고 또 반대로 Java로 만든 Regular Expression 엔진을 C++로 포팅해본 적이 있는데 원래 소스를 이해하고 새롭게 재작성하는 것이 아니라 직역하면서 차이를 반영하는 방식으로 포팅했습니다. 결과 소스의 크기는 당연히 원래 소스와 거의 같았습니다.

파이썬은 물론 Java보다도 문법상으로 훨씬 가벼운 점이 있습니다만 클래스 없이 짜면 C와 코드양의 차이는 3분의 1에서 4분의 1선이 될 겁니다. 하지만 파이썬 프로그래머들은 C에 비해 10분의 1의 코드로 같은 일을 할 수 있다고 주장하죠. OOP 없이 이 정도까지 차이를 만들어낼 수 있을까요?

Quote:
예를 들어 Vector와 List를 만든다면 객체지향적인 시야에서는 이 둘에 sort 메소드를 넣어야 할 것입니다.

이것이 OOP에 대한 오해 중 대표적인 것이 아닐까 싶습니다. Sort라는 객체를 만들고 Sort.sort(List), Sort.sort(Vector)도 OOP에서 벗어나는 구현이 아닙니다. OOP가 data+process라는 말을 써서 이런 오해가 발생한 듯도 한데 좀더 정확히 말하자면 state+process가 object입니다. 현재 자바에서는 Vector나 ArrayList에 sort가 있는 것이 아니고 Collections라는 클래스에 static 메쏘드로 sort가 들어 있습니다. 제가 STL과 비슷하다고 말한 것이 이런 부분이죠. 얼핏 보면 이것은 global function과 다를 바 없어보이지만 OOP가 있기 때문에 각 List 구현체별로 sort가 필요한 것이 아니라 List에 대한 하나의 sort 메쏘드만 있으면 되는 것이기에 여전히 OOP의 이득을 보고 있는 것이랍니다.
htna의 이미지

creativeidler wrote:
Quote:
이 부분은 객체지향의 공이라고 생각하기는 힘듭니다. JAVA와 Python은 언어자체가 C/C++보다 경제적입니다. 객체를 배제한 Python 역시 경제적이며 하나의 클래스 속에 모든 것을 넣은 Java 프로그래밍 역시 C/C++에 비해서 경제적입니다.

하나의 클래스에 모든 것을 넣은 Java 프로그래밍이 C++에 비해서 더 경제적이라는 말은 동의할 수 없습니다. 제가 C++로 작성된 AES 암호화 모듈의 변종 하나를 Java로 포팅해본 적이 있고 또 반대로 Java로 만든 Regular Expression 엔진을 C++로 포팅해본 적이 있는데 원래 소스를 이해하고 새롭게 재작성하는 것이 아니라 직역하면서 차이를 반영하는 방식으로 포팅했습니다. 결과 소스의 크기는 당연히 원래 소스와 거의 같았습니다.

파이썬은 물론 Java보다도 문법상으로 훨씬 가벼운 점이 있습니다만 클래스 없이 짜면 C와 코드양의 차이는 3분의 1에서 4분의 1선이 될 겁니다. 하지만 파이썬 프로그래머들은 C에 비해 10분의 1의 코드로 같은 일을 할 수 있다고 주장하죠. OOP 없이 이 정도까지 차이를 만들어낼 수 있을까요?


Python/Java/C++의 코드량을 줄이는 이득은 C 와 달리,
암시적인 this의 전달과 일종의 namespace효과에 의한 중복적인 이름을 피할 수 있어서인점 과,
각 언어의 편리함에 있다고 보여지는군요.

제가 Python을 알지는 못합니다만...
class/object를 물리적인 관점에서 볼때 data+function 추상적인 관점에서 볼때 state+operation 정도로 구분된다고 이해하고 있습니다. ( 머 용어의 차이는 이해해 주세요 ^^; )
또한 일반적인 object에서 객체에 대한 추상화 정도에 따라 base class의 operation을 재정의 하기 위해 virtual이란 키워드를 사용하며,
사용권한을 엄격히 체크하기 위해 private/protected/public 이란 키워드를 사용하고 있습니다.
순수가상함수 와 같은 이것들의 확장은 논외로 하겠습니다.
여기서 Python/Java/C++ 과 같은 언어와 과 C 와같은 언어사이의 차이로 볼때.
서로 호환되기에 가장 어려운 부분이 virtual입니다..
(물론 Java에서는 모든 함수가 virtual로 정의되어 있다고 하지만, 이는 논외로 보겠습니다. 즉 일반적인 경우에 base에 정의된 것을 그대로 사용하게 되고, 자신이 그 operation을 재정의하는 경우는 전체 procedure중에서 몇% 되지 않는다고 생각하고 있습니다. 머 %의 정도에 차이가 있겠지만, '아니다'라고 하신다면, 보다 실제적인 이유를 보여주셨음 합니다. 얼마나 많은 procedure가 재정의 되고 있으며, 실제 call되는 procedure중 얼마나 많은 비율이 operation이 재정의된 procedure인지 등에 대한 실제적인 것을...)
가장 일반적으로 operation을 재정의하지 않고 프로그램이 진행된다 했을때...
그 부분은 C 와 직접적으로 1:1 대응관계를 가집니다. 다만 코드의 량이 줄어든다는 장점을 가지게 되지요...
(머 this pointer를 넘기지 않아도 되는 점과, 함수의 이름이 중복되는것을 피하기 위해서 함수의 이름을 더욱 길게 하는 그러한 부조리가 줄어들죠..)
즉 여기까지가, Python/Java/C++ 등과 같은 언어를 사용할때 가장 기본적으로 볼 수 있는 잇점 입니다...
이제, 논외로 한 것들을 고려해 보겠습니다.
먼저 말씀드렸다시피, 이러한 순수가상함수나, operation의 재정의와 같은 부분이 C의 그것과 1:1 대응에 있지는 않습니다만.
구조의 추상화를 통해서 그러한 부분을 충분히 처리할 수 있습니다. 정 어렵다면 virtual function pointer table 라도 만들어 가며 추상화 하여 처리할 수 있습니다.
이렇게 추상화 하여 처리한다고 치더라도, 직접적으로 1의 양과 1/3 혹은 1/10의 양과 직접적인 영향을 미치는 factor라고 여겨지지는 않는다고 봅니다.
결론적으로, 물론 OOP가 훌륭한 방법입니다. 하지만 OOP이기 때문에만 그러한 효율성이 있는것만은 아닙니다.
이러한 여러 부가적인 효율성이 있기때문에, 단적으로 코드의 량이 줄어든다는 이득을 보게 되는 것입니다.

creativeidler wrote:
Quote:
예를 들어 Vector와 List를 만든다면 객체지향적인 시야에서는 이 둘에 sort 메소드를 넣어야 할 것입니다.

이것이 OOP에 대한 오해 중 대표적인 것이 아닐까 싶습니다. Sort라는 객체를 만들고 Sort.sort(List), Sort.sort(Vector)도 OOP에서 벗어나는 구현이 아닙니다. OOP가 data+process라는 말을 써서 이런 오해가 발생한 듯도 한데 좀더 정확히 말하자면 state+process가 object입니다. 현재 자바에서는 Vector나 ArrayList에 sort가 있는 것이 아니고 Collections라는 클래스에 static 메쏘드로 sort가 들어 있습니다. 제가 STL과 비슷하다고 말한 것이 이런 부분이죠. 얼핏 보면 이것은 global function과 다를 바 없어보이지만 OOP가 있기 때문에 각 List 구현체별로 sort가 필요한 것이 아니라 List에 대한 하나의 sort 메쏘드만 있으면 되는 것이기에 여전히 OOP의 이득을 보고 있는 것이랍니다.

sort라는 객체를 정의한다고 하셨는데. sort라는 객체가 가져야 하는 data가 무엇이 있나요 ?
class/object의 정의는 충분히 아시겠지만, state+process 입니다. (creativeidler님이 말씀하신대로..)
하지만 sort라는 객체는 state가 존재하지 않을법한 객체 입니다. 존재의 필요성에 의문이 드는군요..
차라리 namespace로 묶은 sort를 하기 위한 global function이 sort라는 객체보다는 나아보입니다.

또한, sort라는 객체에 어떠한 구조를 가지는 데이터라도 넘겨주면 자동으로 sort가 됩니까 ?
Java에 Collection에 있는 Sort라는 함수가, OOP의 이득을 보고 있다고 말씀하시고 계십니다만...
그것이 OOP의 어떠한 이득을 보는지 좀 설명이 부족한 듯 합니다. 제가 보기에는 global function을 만들 수 없기에 Collection이라는 category에 넣은것이 가장 큰 이유라고 보여집니다.
Collection에 sort라는 함수를 만들게 되면, map/set/hashtable 등과같이 sort라는 기능이 필요없는 데이터구조 조차도 sort라는 함수를 가지게되는 불상사를 막기위해서 라고 보여집니다만..
좀 예제가 맞지않는다고 생각이되네요..

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

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

creativeidler의 이미지

Quote:
Collection에 sort라는 함수를 만들게 되면, map/set/hashtable 등과같이 sort라는 기능이 필요없는 데이터구조 조차도 sort라는 함수를 가지게되는 불상사를 막기위해서 라고 보여집니다만..

그건 아니죠. Collections로 빼지 않더라도 상속 구조로 얼마든지 해결할 수 있습니다. 이미 자바 상속 구조상으로도 충분히 해결 가능한 상태입니다.

Quote:
sort라는 객체를 정의한다고 하셨는데. sort라는 객체가 가져야 하는 data가 무엇이 있나요 ?

어떤 알고리즘을 소트에서 사용할 것인가가 있죠. 이 알고리즘 자체는 process지만 Sort 객체가 특정 알고리즘을 사용한다는 사실은 Sort 객체의 state로 존재합니다. 물론 이 state는 명시적인 멤버 변수로 나타날 수도 있고 그저 하나의 메쏘드 안에 포함될 수도 있지만 "어떤 알고리즘을 사용한다."는 사실은 분명 그 Sort 객체의 attribute가 됩니다. 이런 추상적인 개념까지 object의 attribute가 된다는 사실이 제가 말하고 싶었던 것입니다.

그리고, 이 문제가 아니더라도 앞서 Collections의 메쏘드들은 이미 OOP의 혜택을 보고 있습니다. OOP가 아니라면 Collections의 sort 메쏘드는 각 List의 구현체별로 하나씩 있어야할 테니까요.

Quote:
속도문제는 해결한다고 치더라도, 그 메모리 비효율성에 대해서 이해하실 수 있으실런지...

글쎄요. 메모리 문제가 그렇게 중요하다면 char*의 7배 이상 메모리를 먹는 string을 사용할 명분은 어디서 찾으시겠습니까?

Quote:
Python/Java/C++의 코드량을 줄이는 이득은 C 와 달리,
암시적인 this의 전달과 일종의 namespace효과에 의한 중복적인 이름을 피할 수 있어서인점 과,
각 언어의 편리함에 있다고 보여지는군요.

이건 동의하기 힘들군요. 만약 C에서 namespace 효과를 피하기 위해 function 이름을 더 길게 짓기라도 한다면 좀 설득력이 있겠지만 일반적으로 자바 코드에서 보이는 이름들이 C에서 보이는 이름보다 훨씬 깁니다. 그래서 오히려 1000라인 내의 짧은 프로그램의 경우는 C가 Java보다 더 짧은 코드인 경우도 적지 않습니다. 암시적인 this의 전달? 파라미터 하나 줄어드는 정도로 그런 커다란 차이가 나온다고 생각하십니까?
happycat의 이미지

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

익명 사용자의 이미지

creativeidler wrote:
Quote:
이 부분은 객체지향의 공이라고 생각하기는 힘듭니다. JAVA와 Python은 언어자체가 C/C++보다 경제적입니다. 객체를 배제한 Python 역시 경제적이며 하나의 클래스 속에 모든 것을 넣은 Java 프로그래밍 역시 C/C++에 비해서 경제적입니다.

하나의 클래스에 모든 것을 넣은 Java 프로그래밍이 C++에 비해서 더 경제적이라는 말은 동의할 수 없습니다. 제가 C++로 작성된 AES 암호화 모듈의 변종 하나를 Java로 포팅해본 적이 있고 또 반대로 Java로 만든 Regular Expression 엔진을 C++로 포팅해본 적이 있는데 원래 소스를 이해하고 새롭게 재작성하는 것이 아니라 직역하면서 차이를 반영하는 방식으로 포팅했습니다. 결과 소스의 크기는 당연히 원래 소스와 거의 같았습니다.

이야기를 잘못했군요. 하나의 클래스에 모든 것을 넣은 Java 프로그래밍이 C프로그래밍 보다 경제적이고 객체지향적인 프로그래밍을 한 C++ 프로그래밍보다 Java 프로그래밍이 경제적일 것입니다. 우선은 대부분의 객체지향을 도입한 C++ 프로그램들이 해더부터 Java프로그램에 비한 오버헤드가 될 것입니다.

creativeidler wrote:
파이썬은 물론 Java보다도 문법상으로 훨씬 가벼운 점이 있습니다만 클래스 없이 짜면 C와 코드양의 차이는 3분의 1에서 4분의 1선이 될 겁니다. 하지만 파이썬 프로그래머들은 C에 비해 10분의 1의 코드로 같은 일을 할 수 있다고 주장하죠. OOP 없이 이 정도까지 차이를 만들어낼 수 있을까요?

OOP의 공이라면 C++으로 구성한 프로그램이 C언어보다 압도적으로 경제적일 때만 증명될 수 있을 것입니다. 하지만 현실은 그렇지 못합니다.

creativeidler wrote:
Quote:
예를 들어 Vector와 List를 만든다면 객체지향적인 시야에서는 이 둘에 sort 메소드를 넣어야 할 것입니다.

이것이 OOP에 대한 오해 중 대표적인 것이 아닐까 싶습니다. Sort라는 객체를 만들고 Sort.sort(List), Sort.sort(Vector)도 OOP에서 벗어나는 구현이 아닙니다. OOP가 data+process라는 말을 써서 이런 오해가 발생한 듯도 한데 좀더 정확히 말하자면 state+process가 object입니다. 현재 자바에서는 Vector나 ArrayList에 sort가 있는 것이 아니고 Collections라는 클래스에 static 메쏘드로 sort가 들어 있습니다. 제가 STL과 비슷하다고 말한 것이 이런 부분이죠. 얼핏 보면 이것은 global function과 다를 바 없어보이지만 OOP가 있기 때문에 각 List 구현체별로 sort가 필요한 것이 아니라 List에 대한 하나의 sort 메쏘드만 있으면 되는 것이기에 여전히 OOP의 이득을 보고 있는 것이랍니다.

물론 Sort라는 객체를 만드는 방법도 가능할 것입니다. 그렇다고 해서 문제가 달라질 것이 뭐가 있나요? Sort속의 sort는 오버로딩된 메소드이거나 상속을 통해서 다형성으로 문제를 해결 할 것입니다. 그 어떤 경우라도 같은 알고리즘을 여러 코드로 해결한다는 비난을 피하기는 힘들 것입니다. 여러가지 List구현에 대해서 List라는 하나의 추상된 형태를 도입할 수 있지만 이 모든 것이 필요이상의 두꺼운 레이어라고 봅니다. 객체지향이 아니라면 더 얇게 일반화시킬 수 있습니다.

상태를 이야기하시는 부분에 대해서는 쉽게 이해하기 힘들군요. 객체지향은 상태는 "객체"의 속성이 아닌 "객체" 자신이 표현해야 하는 것이 아닌가요? 예를 들면 성별이라는 상태는 자신이 "남성"혹은 "여성"임을 증명할 객체가 있어야 한다고 알고 있습니다. 그리고 그 것을 추상화할 하나의 성별이라는 객체가 필요하겠지요. 그리고 그것은 하나의 사람가 whole-part관계이기 때문에 사람이라는 객체와 물리겠지요. 상태 자체는 객체가 표현하고 객체는 데이터와 인터페이스를 제공해야 하는 것이 맞지 않은가요?

죠커의 이미지

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

htna의 이미지

creativeidler wrote:
글쎄요. 메모리 문제가 그렇게 중요하다면 char*의 7배 이상 메모리를 먹는 string을 사용할 명분은 어디서 찾으시겠습니까?

char* 에 비해서 7배나 크다고 하셨는데. 작업환경이 틀려서 그런가요 ? 4배 큽니다...
그보다 앞어서.
충분히 내용을 아시리라 생각합니다. 다만 반례를 잡을때 미처 생각하지 못하고 string을 예로 들으신게 아닌가 생각합니다만...
std::string 이 가지고 있는 변수로 _A, _Len, _Res, _Ptr 이렇게 4개의 값을 가지고 있습니다.
장점을 들면...
1.
allocator를 customize 할 수 있습니다. 머 allocator를 왜 customize해야하냐 라고 물으시면, 그냥.. ^^ 입니다. 공부해 보시기 바랍니다.
char* 로 allocator를 customize 할 수 있나요 ?
할수는 있군요.. char를 할당하는쪽과 파괴하는 쪽의 코드를 하나하나 고쳐주면요.^^
2.
내부적으로 _Len, _Res 로 메모리 할당&파괴와 스트링을 관리하기때문에, 스트링 길이의 자잘한 변경에 따른 메모리 할당&파괴에 덜 민감하게 속도향상을 볼 수 있습니다.
이의 이러한 방법은 std::vector<T> 에서도 사용되고 있습니다.
하지만 char*로 처리할 경우(물론 잘!! 처리하면 되겠지만..) 스트링의 길이가 바뀔 때 마다 재할당 과정을 거쳐야겠죠 ?
char*에서 재할당 과정이 싫다하면 _Len,_Res와 같은 변수를 추가로 처리해줘야 할 것입니다...
3.
메모리 문제에 대해서 실제로 std::string 이 16byte char* 이 4byte 차지합니다.
하지만 이는 실제적인 메모리할당량이 아닙니다. 실제로는 std::string이 O(16+n), char*(4+n) 의 메모리를 가져야 할 것입니다.
스트링이란것이 1~2 혹은 작은크기의 문자열만을 가정한 것이 아니기때문에 n이 충분히 커졌을때 (16+n)/(4+n)의 비율의 크기는 무의미해지게 됩니다.
4.
이게 가장 중요합니다만.
std::string str = "abcd";
std::string str2 = str;
이렇게 해 보시기 바랍니다.
실제 메모리가 할당되는것은 (16 + 16 + 5)byte 입니다. 즉 실제 스트링의 문자열을 두 str,str2 객체가 공유하게 됩니다.
하지만, char로 처리할 경우 ((4+5) + (4+5))byte가 되도록 처리해야 할 것입니다.
지금은 두 스트링의 작고, 공유하는 객체수가 적기에 별 차이가 없어보일지 모르겠지만, 스트링의 길이가 길어지고, 동일값을 가지는 스트링 객체가 많아질수록 메모리 효율은 올라가게 됩니다.

STL 그렇게 호락호락하게 만들어지지 않았습니다.

creativeidler wrote:
이건 동의하기 힘들군요. 만약 C에서 namespace 효과를 피하기 위해 function 이름을 더 길게 짓기라도 한다면 좀 설득력이 있겠지만 일반적으로 자바 코드에서 보이는 이름들이 C에서 보이는 이름보다 훨씬 깁니다. 그래서 오히려 1000라인 내의 짧은 프로그램의 경우는 C가 Java보다 더 짧은 코드인 경우도 적지 않습니다. 암시적인 this의 전달? 파라미터 하나 줄어드는 정도로 그런 커다란 차이가 나온다고 생각하십니까?

C와 비교하기 쉬운것은 Java보다는 C++에 가깝다는 생각이 드는군요..
적어도 Java에서는 delete 과정이 필요없지 않습니까. 그로인해 추가적인 메모리해제 과정과, 이의 확인과정 등이 줄어드니깐요...
물론, class로 함수에 파라메터 하나 추가하는것과, 추가하지 않는것이 차이가 거의 없다고 말씀하시 수 있습니다.
하시만 실제로 그렇지는 않습니다. 실제 프로그램을 짜게 되면서, 이러한 하나하나 사소한 차이가 프로그램 전반에 걸쳐 상당한 스트레스로 작용하게 됩니다.
실제 저희회사에서 사용하는 엔진(??)을 개발할 당시에도, 이러한 사소한 의견의 반영이 이루어질 수 밖에 없었습니다.
그때 실제로 global function에 this pointer를 매번 넘겨야 하는 것과 매우 유사하도록 처리하자는 다른 분의 의견에 대한 내용이었습니다만..
사용하는 입장에서 짜증나 사용 못하겠다는 의견이 지배적이기 때문에, 그러한 의견은 배제하게 되었습니다...
머. 그러한 모든 함수의 하나하나에 this와 유사한 파라메터를 넘기는게 별거 아닌데 말이죠...
다음의 코드는 너무 간단하게 작성되었기에 별 차이를 느끼지 못할 수도 있습니다만, 이러한 부분을 프로그랜 전반에 걸쳐서....
coding을 하는 거의 모든 위치에 적용된다고 할 경우 이에따른 추가되는 코드의 량과 이로인해 발생하는 스트레스와 또한 만만치 않습니다.
또한 1/x 의 비율을 예로 들으셨는데. C에서와 같이 제공되지 라이브러리를 일체 사용하지 않고도, 또한 이러한 추가되는 코드의 량을 배제하지 않고도 그만큼의 성능을 낼 수 있는지.. 는 좀 의심스럽군요...
저 또한 Java를 배울당시에 감탄을 금치 못했던것들이, 그러한 기본적으로 제공되는 라이브러리에 있었기 때문이죠..
class CBase {
    int _base;
    [b]void function1(int)[/b] {
	}
};
class CDerived : public CBase {
    int _derived;
    [b]void function2(int)[/b] {
	}
};
CDerived d;
[b]d.function2(1);[/b]
[b]d.function1(1);[/b]

struct CBase {
    int _base;
};
struct CDerived {
    struct CBase _super;
	int _derived;
};
[b]void CBase_function1(struct CBase* pThis, int) [/b]{
};
[b]void CDerived_function2(struct CDerived* pThis, int)[/b] {
};
struct CDerived d;
[b]CDerived_function2(&d,1);[/b]
[b]CBase_function1(&(d._super),1);[/b]

PS:
앗 회사서 나가야겠군요..
음. 나머지 이야기는 뒤이어 붙이겠습니다.

PS2:
음 그리고 추가하는것으로, 위와같이 C로 프로그램일 짜게 되는경우 일기가 매우 어려워집니다.
이로인해 개발시간 지연이라든가, 디버깅의 지연 등에 대해서도 문제가 될 듯 하네요..
C로 OOP를 짜야한다면 어쩔수 없겠지만...
그리고, 글을 올리구보니, 앞에 두가지부분은 CN님께서 대답을 해 주셨군요..
^^

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

creativeidler의 이미지

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

Quote:
물론 Sort라는 객체를 만드는 방법도 가능할 것입니다. 그렇다고 해서 문제가 달라질 것이 뭐가 있나요? Sort속의 sort는 오버로딩된 메소드이거나 상속을 통해서 다형성으로 문제를 해결 할 것입니다. 그 어떤 경우라도 같은 알고리즘을 여러 코드로 해결한다는 비난을 피하기는 힘들 것입니다. 여러가지 List구현에 대해서 List라는 하나의 추상된 형태를 도입할 수 있지만 이 모든 것이 필요이상의 두꺼운 레이어라고 봅니다. 객체지향이 아니라면 더 얇게 일반화시킬 수 있습니다.

generalization으로 인한 코드의 경량화와 다형성의 이점을 한 번에 부정하는 발언이군요. ListA, ListB, ListC에 대해 List라는 일반화를 하는 것이 "필요 이상의 두꺼운 레이어"라면 이 세 List에 대해 sort하는 기능을 만들고 싶을 때는 어떻게 하시렵니까? List로의 일반화가 있다면 단지 sort 하나만 만들면 되지만 그런 과정이 없다면 sortA, sortB, sortC를 만들어야 할 겁니다. 세 배의 코드가 나오는데 필요 없이 두꺼운 레이어라니 동의하기 힘들군요.

Quote:

상태를 이야기하시는 부분에 대해서는 쉽게 이해하기 힘들군요. 객체지향은 상태는 "객체"의 속성이 아닌 "객체" 자신이 표현해야 하는 것이 아닌가요? 예를 들면 성별이라는 상태는 자신이 "남성"혹은 "여성"임을 증명할 객체가 있어야 한다고 알고 있습니다. 그리고 그 것을 추상화할 하나의 성별이라는 객체가 필요하겠지요. 그리고 그것은 하나의 사람가 whole-part관계이기 때문에 사람이라는 객체와 물리겠지요. 상태 자체는 객체가 표현하고 객체는 데이터와 인터페이스를 제공해야 하는 것이 맞지 않은가요?

움. OOP 경험이 별로 없으신 것 같습니다. 객체의 속성도 물론 객체일 수 있지만 아닐 수도 있습니다. (물론 모든 것이 객체인 언어도 있죠.) 그리고 객체의 속성은 그 객체의 class가 나타낼 수도, 속성이 나타낼 수도 있습니다. 만약 A라는 사람을 묘사한다면 사람 class를 상속 받은 남자 class로 표현할 수 있겠죠. 그럼 이 A의 나이는 어떻게 표현하시겠습니까? 30세 사람 클래스, 40세 사람 클래스 따로 만드시겠습니까? 아마도 그냥 사람 객체의 속성으로 나타나겠죠. 남자 여자도 이 속성을 다형성으로 이용할 필요가 없다면 굳이 남자 class, 여자 class를 만들 필요가 없이 그냥 속성으로 넣어도 됩니다.

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

creativeidler의 이미지

Quote:

STL 그렇게 호락호락하게 만들어지지 않았습니다.

전 STL을 평가절하하려고 시도한 적이 단 한 번도 없는데 왜 거듭 STL이 좋다는 점을 강조하시는지 모르겠군요.

제가 string을 제시한 것이 string이 char*보다 장점이 있다는 걸 몰라서 그랬다고 생각하십니까? 조금 더 생각해봐 주시기 바랍니다.

this, delete에 관한 이야기는 원래 이부분의 논점이 "코드량"이었다는 점을 상기해주시면 굳이 제가 반박하지 않아도 될 것 같습니다.

litdream의 이미지

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

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

삽질의 대마왕...

죠커의 이미지

creativeidler wrote:
generalization으로 인한 코드의 경량화와 다형성의 이점을 한 번에 부정하는 발언이군요. ListA, ListB, ListC에 대해 List라는 일반화를 하는 것이 "필요 이상의 두꺼운 레이어"라면 이 세 List에 대해 sort하는 기능을 만들고 싶을 때는 어떻게 하시렵니까? List로의 일반화가 있다면 단지 sort 하나만 만들면 되지만 그런 과정이 없다면 sortA, sortB, sortC를 만들어야 할 겁니다. 세 배의 코드가 나오는데 필요 없이 두꺼운 레이어라니 동의하기 힘들군요.

한가지 예로 STL의 접근 방법이나 andrei의 정책 위주의 방법이 해답이 될 것입니다. 그 둘 방법은 sort의 인터페이스를 알려주기 위한 객체 없이 모델링 할 수 있습니다.

creativeidler wrote:
움. OOP 경험이 별로 없으신 것 같습니다. 객체의 속성도 물론 객체일 수 있지만 아닐 수도 있습니다. (물론 모든 것이 객체인 언어도 있죠.) 그리고 객체의 속성은 그 객체의 class가 나타낼 수도, 속성이 나타낼 수도 있습니다. 만약 A라는 사람을 묘사한다면 사람 class를 상속 받은 남자 class로 표현할 수 있겠죠. 그럼 이 A의 나이는 어떻게 표현하시겠습니까? 30세 사람 클래스, 40세 사람 클래스 따로 만드시겠습니까? 아마도 그냥 사람 객체의 속성으로 나타나겠죠. 남자 여자도 이 속성을 다형성으로 이용할 필요가 없다면 굳이 남자 class, 여자 class를 만들 필요가 없이 그냥 속성으로 넣어도 됩니다.

몇몇의 프로그래밍 과정에서 그런 부분을 멤버 변수로 만들어 처리했습니다만 더 나은 방법이 있을 줄 알았습니다. 개인 적인 입장은 필요할때 클래스 키워드를 쓴다는 생각이기 때문에 깊게 생각해본 적이 없군요. 순수 객체지향적인 방법으로의 처리는 불가능 한가요? 객체의 상태를 객체 자신만으로 취급하는 방법을 몰라서 객체의 상태로 인해서 두꺼운 레이어를 만들게 된다는 말을 철회하겠습니다.

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

더 얇은 코드가 더 높은 투명성을 가지기 때문입니다. 실용적인 관점에서 본다면 탑다운, 바텀업 개발 방식 모두 실패할 가능성이 높기 때문에 유닉스의 역사상 탑다운, 바텀업을 모두 도입하고 glue를 도입한 프로젝트가 많다고 알고 있습니다. 객체지향에서도 이 과정을 벗어날 수 있을거라고 생각하지 않습니다. 어차피 새로운 프로젝트에 도전한다면 실패할 확률이 높고 프로젝트 전반에 대해서 이해하여 전체적으로 뜯어 고쳐야 할 필요성이 생긴다고 생각합니다. 따라서 얇은 레이어를 통해서 프로젝트의 투명성이 보장되어야 프로젝트 전반을 프로그래머가 이해할 수 있다고 생각합니다.

creativeidler의 이미지

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

Quote:
따라서 얇은 레이어를 통해서 프로젝트의 투명성이 보장되어야 프로젝트 전반을 프로그래머가 이해할 수 있다고 생각합니다.

프로젝트 전반을 이해한다..라는 것이 프로젝트 전체의 코드를 이해한다의 의미로 하신 것 같은데 사실 큰 프로젝트를 하다보면 제일 중요한 것은 프로그래머가 몰라도 되는 부분은 모른 채 코딩할 수 있게 해주는 것입니다. strcpy의 내부 구현이 어떤지 잘 알아야 문자열 복사를 잘 할 수 있는 게 아니듯 OOP는 프로그래머가 몰라도 되는 부분을 효과적으로 덮어줍니다.

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

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

htna의 이미지

creativeidler 님의 큰 프로젝트에 공동작업을 하는 환경이 상당히 좋은듯 합니다.
저 역시 creativeidler님께서 말씀하시는 것과 같은 개념을 가지고 있었습니다.
하지만, 자신이 속한 환경에 적응한다는것이, 생각보다 자신의 개념의 많은 부분을 바꾸게하네요...
개념적인 객체의 구현을 하며 프로그램을 진행한다고 생각하더라도, 자신을 제외한 다른사람들의 프로그램을 보면서,
그들의 코드의 동작이 불확실해질 수 밖에 없다는 것을 차츰 적응해나가다보니..
모든 코드에 대해서 이렇게 완전히 신뢰하며 프로그램을 진행할 수 없게 만드는 듯 합니다.

주어진 코드를 개념적으로 가장 깔끔하게 유지하는 방법중 하나는, 처음 설계되었을때 그대로 이후로 계속 가져가는 것입니다.
하지만 프로그램의 유지보수라는 측면에서 볼 때에는, 그게 그렇게 되지는 않는다는걸... 지금 속한 회사로부터 충분히 경험하고 있습니다.
필요한 동작의 확장을 위해서, 가능한 적은 노력으로 결과를 보기 위해 (적은 노력은 시간과 직결되기 때문에...), 기존의 잘 만들어진 라이브러리를 수정을 할 수 밖에 없는 상황에 놓이게 됩니다.
이러한 과정이 한 두번 적용되다 보면, 그 코드의 신뢰도는 떨어질 수 밖에 없고, (자신이 알고있던 동작과는 다르게 동작 할 수 있으니깐요..), 결국에는 그 소스를 다시 볼 수밖에 없게 됩니다.
가장 좋은방법은, 다른사람의 소스를 내가 볼 필요가 없도록 모듈화 하는것이 제일 좋은 방법일듯 합니다만...
이 또한 프로젝트의 성격에 따라, 가능하지 않은 부분이 다분합니다.

creativeidler님 께서는 이렇게, 다른사람의 코드를 신뢰하고 사용할 수 있거나,
다른 coworker와의 모듈화가 충분하게 이루어진 환경에서 작업을 하고 계신듯 합니다만.
정말 부럽습니다.

PS:
음 독서실에서 PC 점유하고 글을 쓰니..
다른사람들의 눈치가 심하게 보이는군요.. ㅡ.ㅜ
이만 가봐야 할 듯 합니다.

PS2:
먼저번의 글을 읽다보니. creativeidler님께서 리플을하신, 하지만 제가 못보고 지나친글들이 좀 있군요...
이 쓰레드, 너무 글이 자주올라와, 따라가기 힘이드는 부분이 있군요...

creativeidler wrote:
Quote:
따라서 얇은 레이어를 통해서 프로젝트의 투명성이 보장되어야 프로젝트 전반을 프로그래머가 이해할 수 있다고 생각합니다.

프로젝트 전반을 이해한다..라는 것이 프로젝트 전체의 코드를 이해한다의 의미로 하신 것 같은데 사실 큰 프로젝트를 하다보면 제일 중요한 것은 프로그래머가 몰라도 되는 부분은 모른 채 코딩할 수 있게 해주는 것입니다. strcpy의 내부 구현이 어떤지 잘 알아야 문자열 복사를 잘 할 수 있는 게 아니듯 OOP는 프로그래머가 몰라도 되는 부분을 효과적으로 덮어줍니다.

...

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

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.