우리나라에서 객체지향은?

lenani의 이미지

요즘같은 시대는 객체지향이라는 개념이 상당히 널리 퍼진것 같습니다.
어떤 책을 봐도 유행처럼 객체지향이라는 말이 들어가 있습니다.

하지만 우리나라의 기업에서는 별로 객체지향이 유명하지 않은것 같습니다.
제가 아는 어떤분은 '우리나라에서 객체지향을 쓰는 곳은 없다'라고 극단적인
말까지 하던데요.

여러분 생각은 어떻습니까?
실제로 객체지향이 실제 (우리나라) 기업에서는 별로 쓸모없는 개념입니까?
아니면 어떤 객체지향의 단점이 존재해서 그것 때문에 쓰지 않는 것일까요?
혹시 객체지향으로의 진입비용(?)이 너무 비싸서 그런것은 아닐까요?

어쩌면 실제로는 우리나라에서 많이 사용하는데 그 사실이 외부에 많이 알려
지지 않았기 때문에 객체지향이 우리나라에서 별로 사용되지 않는것처럼 여겨지는 것은 아닐까요?

댓글

fender의 이미지

lenani wrote:
저도 XP를 선호하는 편 입니다.
다만 UP를 사용할때와 XP를 사용할때를 구분해서 적용합니다.

UP를 사용할때도 구현시에는 XP 방식을 사용합니다.
특히 저는 Mock을 자주 사용하는 편 입니다.
Mock을 통해서 코드를 테스트할때 제가 잘못된 로직을 사용하고
있음을 깨달은 적이 있는데요.
그 이후로 DB나 Network에 대한 코드를 작성하기 전에 항상
Mock을 통해서 올바르게 코딩을 하고 있는지 검사하게 되었습니다.

Mock은 단위테스트 시 MockObject를 말씀하시는 건가요?

이건 다른 주제가 되겠지만 솔직히 저는 웹 개발이나 GUI 중심 개발에서 단위테스트로 얻는 이득보다는 불필요한 오버헤드가 더 크다고 생각을 합니다. 그런 부분을 떠나서라도 페어프로그래밍이나 주 36시간 등 XP를 곧이 곧대로 적용하는 건 무리가 있더군요 :)

UP는... 솔직히 제대로 적용되서 돌아가는 걸 본적이 없습니다만 5명 내외의 개발팀에 쉽게 적용할 수 있는 방법인지 모르겠습니다. 지나치게 산출물 중심적이 아닌가 하는 걱정이 앞서더군요.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

fender wrote:
Mock은 단위테스트 시 MockObject를 말씀하시는 건가요?

네.

fender wrote:

이건 다른 주제가 되겠지만 솔직히 저는 웹 개발이나 GUI 중심 개발에서 단위테스트로 얻는 이득보다는 불필요한 오버헤드가 더 크다고 생각을 합니다. 그런 부분을 떠나서라도 페어프로그래밍이나 주 36시간 등 XP를 곧이 곧대로 적용하는 건 무리가 있더군요 :)

음...
동감입니다.
현실적으로는 불가능하다고 생각합니다.
하지만 저는 유닛테스트를 적용했을때 오히려 개발시간을 줄일수 있다고
믿고 있습니다.
겉으로 보기에는 유닛테스트가 쓸데없는 일을 하는 것처럼 보일수도 있습니다.
또한 유닛테스트만으로는 절대 코드에 완벽하다고 보장할수도 없습니다.
하지만 일단 유닛테스트를 마친 코드는 올바로 동작한다는 어느정도의
신뢰를 얻을수 있습니다.
또한 Refactoring을 하더라도 이전의 코드에 예상치 못했던 에러가 발생할
경우에도 이것을 알아낼수 있습니다.
당장은 코딩의 진척 상황이 느리게 보일수도 있지만 헤메는 시간을 줄여주기
때문에 결과적으로 더 빠르게 코딩을 할수 있습니다.
단, 재사용을 하지 않고 직접 코딩을 하는 경우를 말한 겁니다.

fender wrote:

UP는... 솔직히 제대로 적용되서 돌아가는 걸 본적이 없습니다만 5명 내외의 개발팀에 쉽게 적용할 수 있는 방법인지 모르겠습니다. 지나치게 산출물 중심적이 아닌가 하는 걱정이 앞서더군요.

UP는 소규모에서 절대로 적용하면 안됩니다.
얻는 이익보다는 잃는 손해가 더 많기 때문입니다.
산출물 중심이라고 말씀하셨는데 그것은 UP를 적용하는 규모에
대해서 생각해 보신다면 수긍하실거라 믿습니다.
UP를 적용하는 50명의 스텝들이 있다면 그들간의 의사소통을
무엇으로 해야 효율적일까요?
가장 효과적인 것은 문서밖에 없습니다.

lenani의 이미지

아...
그리고 UP는 반드시 제대로 된 architect가 필요합니다.
모든 프로젝트의 진행이 architect에 종속적이기 때문입니다.
만약 그동안 제대로 진행되는 UP 적용을 보신적이 없다면
architect가 실력이 없기 때문입니다.
(우리나라에서는 PM 인가요?)

fender의 이미지

lenani wrote:
음...
동감입니다.
현실적으로는 불가능하다고 생각합니다.
하지만 저는 유닛테스트를 적용했을때 오히려 개발시간을 줄일수 있다고
믿고 있습니다.
겉으로 보기에는 유닛테스트가 쓸데없는 일을 하는 것처럼 보일수도 있습니다.
또한 유닛테스트만으로는 절대 코드에 완벽하다고 보장할수도 없습니다.
하지만 일단 유닛테스트를 마친 코드는 올바로 동작한다는 어느정도의
신뢰를 얻을수 있습니다.

저도 유닛테스트를 씁니다 :) 하지만 정말 필요한 부분 - 특히 유틸 클래스들에 국한해서 쓰고 있습니다. 사실 경량 컨테이너 자체가 상당히 단위 테스트에 드는 노력을 줄여주는 건 사실입니다. 하지만 우리나라 같이 개발 일정이 빡빡한 상황에서 아무리 적은 오버헤드라도 과연 이게 반드시 필요한가 돌아보게 되는 것 같습니다.

예를들어 웹이나 GUI에서 단위테스트가 절실한 부분은 오히려 "이 버튼을 누르면 결과가 어떻게 나오는가? 레이아웃이 깨져 보이지는 않는지? 페이지 네비게이션은 제대로 되는가? 로드가 많이 걸렸을 때 어떻게 반응할 것인가?"하는 등 전통적인 개념의 단위테스트에선 다루기 어려운 부분들이 많습니다. 반면 사람이 테스트하면 클릭 몇번으로 단번에 알 수 있는 부분입니다.

일부에선 클라이언트 프로그램의 경우 심지어 마우스와 키보드를 갈무리해서 이를 재생하는 방식으로 만든 단위테스팅 프레임워크들을 사용하기도 하지만 개인적으로 GUI의 레이아웃에 의존성을 지닌 단위테스트 코드는 의미가 없다고 봅니다.

또 한가지 불만인 점은 많은 경우에 단위테스트가 private 필드나 메소드에 의존성을 갖는 경우 단위테스트를 위해 코드를 변경하지 않으면 동작하기 어렵다는 점입니다.

어쨌든 여러 이유로 단위 테스트는 최소화 하고 있습니다. 테스트 케이스를 짜고 코드가 발전함에 따라 유지보수 하는 것도 일이니까요 :) 아무래도 여기에 대해서 이야기가 길어지면 별도 쓰레드를 만드는게 좋지 않을까 싶습니다...

lenani wrote:
UP는 소규모에서 절대로 적용하면 안됩니다.
얻는 이익보다는 잃는 손해가 더 많기 때문입니다.
산출물 중심이라고 말씀하셨는데 그것은 UP를 적용하는 규모에
대해서 생각해 보신다면 수긍하실거라 믿습니다.
UP를 적용하는 50명의 스텝들이 있다면 그들간의 의사소통을
무엇으로 해야 효율적일까요?
가장 효과적인 것은 문서밖에 없습니다.

50명.... -_-;;;
글쿤요 -_-

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

fender wrote:

저도 유닛테스트를 씁니다 :) 하지만 정말 필요한 부분 - 특히 유틸 클래스들에 국한해서 쓰고 있습니다. 사실 경량 컨테이너 자체가 상당히 단위 테스트에 드는 노력을 줄여주는 건 사실입니다. 하지만 우리나라 같이 개발 일정이 빡빡한 상황에서 아무리 적은 오버헤드라도 과연 이게 반드시 필요한가 돌아보게 되는 것 같습니다.

만약 계약을 할때 XP 방식으로 하는 것을 어떨까요?

fender wrote:

예를들어 웹이나 GUI에서 단위테스트가 절실한 부분은 오히려 "이 버튼을 누르면 결과가 어떻게 나오는가? 레이아웃이 깨져 보이지는 않는지? 페이지 네비게이션은 제대로 되는가? 로드가 많이 걸렸을 때 어떻게 반응할 것인가?"하는 등 전통적인 개념의 단위테스트에선 다루기 어려운 부분들이 많습니다. 반면 사람이 테스트하면 클릭 몇번으로 단번에 알 수 있는 부분입니다.

일부에선 클라이언트 프로그램의 경우 심지어 마우스와 키보드를 갈무리해서 이를 재생하는 방식으로 만든 단위테스팅 프레임워크들을 사용하기도 하지만 개인적으로 GUI의 레이아웃에 의존성을 지닌 단위테스트 코드는 의미가 없다고 봅니다.

UI 에서 유닛테스트를 할수는 없습니다.
처음부터 불가능 했습니다.
하지만 에러가 가장 많이 발생하는 부분은 UI가 아니라 UI 안쪽의 코드(gut)
입니다.
유닛테스트는 그 안쪽의 코드의 에러를 잡아내기 위한 도구입니다.

fender wrote:

또 한가지 불만인 점은 많은 경우에 단위테스트가 private 필드나 메소드에 의존성을 갖는 경우 단위테스트를 위해 코드를 변경하지 않으면 동작하기 어렵다는 점입니다.

어쨌든 여러 이유로 단위 테스트는 최소화 하고 있습니다. 테스트 케이스를 짜고 코드가 발전함에 따라 유지보수 하는 것도 일이니까요 :) 아무래도 여기에 대해서 이야기가 길어지면 별도 쓰레드를 만드는게 좋지 않을까 싶습니다...

저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

likejazz의 이미지

와우 정말 열띤 토론이 오고가는군요

루비 vs 그놈, 두분 서명이 눈에 팍 들어옵니다 :)

얼핏보아서는 두분다 훌륭한 의견들을 제시하신듯한데 근무시간에 정독하기는 좀 그렇고 ^^; 프린트해서 퇴근시 정독해보도록 하겠습니다.

간만에 좋은 토론을 접하게되는것 같네요

--
Sang-Kil Park

fender의 이미지

주제와 점점 멀어지는 것 같아서 유닛 테스트 쪽은 별도 쓰레드를 열었습니다 :)

http://bbs.kldp.org/viewtopic.php?t=35711

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

Thread가 분리 되었기 때문에 원래의 주제로 돌아가겠습니다.

원래의 토론 주제는 우리나라에서 객체지향이 많이 안쓰이는 이유에
대한 것 이었습니다.
저는 객체지향이 최선이라고 생각하지 않습니다.
객체지향이 아니면 안된다는 생각을 가지고 있지도 않습니다.

아무리 사소한 의견이라도 좋습니다.
여러분들의 생각을 듣고 싶습니다.
많은 참여를 해주시기 바랍니다.

lenani의 이미지

다시 연 geek forum 에서 글을 따왔습니다.
http://geekforum.kldp.org/stories.php?story=04/04/07/8177529

이 Thread와 밀접한 관련이 있는 것 같습니다.
중복이 되기 때문에 글의 성격이 geek forum과 관련이
더 있다면 geek forum에 글을 쓰시기 바랍니다.

wildkuz의 이미지

:twisted:

우리나라에서 객체지향이 많이 안쓰이는 이유
-> 객체지향이 어려우니까....

현문우답 ..... --;

잠깐 상식....
객체지향과 모듈화의 차이점은? 상속성
객체지향의 힘은 어디서 나오나? 다형성

You may say I'm a dreamer.
But I'm not the only one.

RavenDarkmoon의 이미지

lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

RavenDarkmoon의 이미지

제 경우도 객체지향에 대해서는 아직 반신 반의 상태입니다. 무언가 부족하다는 생각도 들지만 딱히 무어라고 찝어내기는 어렵군요.

개발 효율이나 재사용성 면에서도 조금은 회의적입니다.
실지로 기존에 설계 해놓은 클래스를 수정없이 그대로 재사용 한 경우는 별로 없었던 것 같군요.

확실히, 유지보수 측면에서는 획기적인 개선이 이루어졌습니다만, 굳이 객체지향이 아니라도 충분히 잘 설계된 소프트웨어라면 마찬가지일테니 객체지향만의 장점이라고 볼수도 없군요. (아무래도 객체지향의 도움을 얻는 편이 잘 설계하기가 용이하긴 합니다.)

양날의 검처럼 느껴지기도 합니다. 초기 설계가 워낙 중요해서.. 덕분에 구현상의 리스크가 없는 경우에도 객체간의 관계며 확장성이며 고려하느라 머리 싸매는 경우가 많아서..

그리고 결정적으로, 객체지향 프로그래밍에 능숙한 개발자들을 주위에서 거의 보지 못했습니다. (물론 저도 포함됩니다..)

lenani의 이미지

wildkuz wrote:

우리나라에서 객체지향이 많이 안쓰이는 이유
-> 객체지향이 어려우니까....

제 생각에는 가장 현실적이고 중요한 이유라고 생각합니다.
사실 객체지향을 올바로 배우기는 아주 힘듭니다.
주변의 교육기관을 봐도 객체지향을 가리치는 곳이 드뭅니다.
또 가르치는 곳이 있어도 객체지향을 올바로 가르칠수 있는 곳은
제 생각에는 없는것 같습니다.

하지만 한편으로 생각해보면 객체지향을 배우기 이전에
구조적 분석/설계, 정보 공학과 같은 객체지향 이전에 등장한
방법론을 제대로 배울수 있는 기회조차 없었던것 같습니다.
어느 순간부터 우리나라에서는 무원칙이 원칙이 되어버린
상황이 된것 같습니다.

lenani의 이미지

RavenDarkmoon wrote:
lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

음...
제가 잘 이해를 못했습니다.
자세히 설명해주시면 감사하겠습니다.

madhatter의 이미지

lenani wrote:
wildkuz wrote:

우리나라에서 객체지향이 많이 안쓰이는 이유
-> 객체지향이 어려우니까....

제 생각에는 가장 현실적이고 중요한 이유라고 생각합니다.
사실 객체지향을 올바로 배우기는 아주 힘듭니다.
주변의 교육기관을 봐도 객체지향을 가리치는 곳이 드뭅니다.
또 가르치는 곳이 있어도 객체지향을 올바로 가르칠수 있는 곳은
제 생각에는 없는것 같습니다.

하지만 한편으로 생각해보면 객체지향을 배우기 이전에
구조적 분석/설계, 정보 공학과 같은 객체지향 이전에 등장한
방법론을 제대로 배울수 있는 기회조차 없었던것 같습니다.
어느 순간부터 우리나라에서는 무원칙이 원칙이 되어버린
상황이 된것 같습니다.

제가 느끼는 건 사람들은 구조적/절차적 방법론이 어떤 것인지 개념은 없고, 단지 객체 지향을 소개한 글에서 객체 지향에 반대되는 것이 구조적/절차적이고 거꾸로 그 반대가 객체 지향이라는 식으로 인지하고 있는 것이 대부분이라는 겁니다.
정립된 개념 사이의 차이를 인지하는 게 아니라 서로 반대되는 것이 이것과 이것이라는 식이지요. 그러니 객체 지향적 방법론을 쓰면 강박적으로 혹시 이게 구조적/절차적 방법론이 섞여 있는 것은 아닌지부터 검토를 합니다. 올바른 답을 내기 위한 수단으로써 본다면 객체 지향이던 절차적이던 적절한 것을 골라서 사용하면 된다고 생각합니다.
어찌 보면 C++이나 Java 등의 객체 지향적 언어를 다루는 도서가 주 공격 타겟으로 삼는 것이 Fortran이나 C등의 구조적 언어이다 보니 객체 지향은 구조적/절차적 방법론이 나빠서 나온 "좋은"것이다라는 인식이 강하다고 봐야겠지요.

kall의 이미지

lenani wrote:
RavenDarkmoon wrote:
lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

음...
제가 잘 이해를 못했습니다.
자세히 설명해주시면 감사하겠습니다.

클래스를 설계한 사람은 public으로 설정해놓고 쓰지 않는 것이 가능하겠지만,
그 클래스를 사용하는 다른 사람은 public으로 열려 있으면 그냥 마구 써도 되는 줄 알고 사용한다는 얘기가 아닐까요?
그 과정에서 데이터가 꼬일 가능성이 있다는 이야기 같은데요..

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

lenani의 이미지

RavenDarkmoon wrote:
개발 효율이나 재사용성 면에서도 조금은 회의적입니다.
실지로 기존에 설계 해놓은 클래스를 수정없이 그대로 재사용 한 경우는 별로 없었던 것 같군요.

재사용에 대해서는 동감합니다.
흔한 객체지향에 대한 오해중 하나가 바로 이것입니다.
'객체지향을 적용하면 80%~90%의 재사용이 가능하다'라는 말은 거짓입니다.
재사용이 완벽하게 이루어진다는 것은 객체의 속성과 로직이 이전에 만들어
놓은 것과 현재 개발하는 것이 정확하게 일치할때만 가능한 것입니다.
아주 작은 부분만 틀리더라도 코드 수정을 불가피한 것입니다.

하지만 개발 효용에 대해서는 동의하지 않습니다.
특히 10,000 라인이 넘어가는 경우는 확실히 개발 효율이 급격히 상승합니다.
제가 책에서 읽은 것이 아니라 실제로 경험한 것을 얘기 하는 것 입니다.

RavenDarkmoon wrote:

확실히, 유지보수 측면에서는 획기적인 개선이 이루어졌습니다만, 굳이 객체지향이 아니라도 충분히 잘 설계된 소프트웨어라면 마찬가지일테니 객체지향만의 장점이라고 볼수도 없군요. (아무래도 객체지향의 도움을 얻는 편이 잘 설계하기가 용이하긴 합니다.)

양날의 검처럼 느껴지기도 합니다. 초기 설계가 워낙 중요해서.. 덕분에 구현상의 리스크가 없는 경우에도 객체간의 관계며 확장성이며 고려하느라 머리 싸매는 경우가 많아서..

그리고 결정적으로, 객체지향 프로그래밍에 능숙한 개발자들을 주위에서 거의 보지 못했습니다. (물론 저도 포함됩니다..)

맞습니다.
객체지향을 꼭 도입하지 않아도 잘 설계만 한다면 정말 개발하기도 쉽고
유지보수도 쉽게 만들수 있습니다.
하지만 객체지향 이외의 방법으로 잘 설계하는 사람도 저는 본적이 없습니다.
사실 객체지향은 어느날 갑자기 나타난 것이 아니라 '잘 설계하는 법'을
반영시킨 결과로 나왔다고 저는 받아들이고 있습니다.

저는 초기 설계를 간단하게 합니다.
설계 시간이 30분을 넘지 않습니다.
대신 반복(Iteration)을 짧게 가져갑니다.
설계가 개발도중 변경되면 바로 반영합니다.
그래서 설계가 한번에 이루어지지 않습니다.
여러차례 반복되서 설계를 합니다.

그런데 왜 주변에 객체지향을 능숙하게 사용하는 개발자들이 없을까요?

fender의 이미지

kall wrote:
클래스를 설계한 사람은 public으로 설정해놓고 쓰지 않는 것이 가능하겠지만,
그 클래스를 사용하는 다른 사람은 public으로 열려 있으면 그냥 마구 써도 되는 줄 알고 사용한다는 얘기가 아닐까요?
그 과정에서 데이터가 꼬일 가능성이 있다는 이야기 같은데요..

음... 제가 최초에 문제제기했던 내용은 예를들어 개발자들이 흔히 모듈이 어떤 상태가 되면 private 필드인 특정 플래그를 주는 (예를들어 FTP 클라이언트의 경우 로그인했을 때 loggedin=true를 주고 다른 명령이 실행될 때 이를 먼저 체크하는 경우 등) 방식을 쓰는 데 이런 경우 외부에서 단위테스트를 위해 해당 플래그를 바꿀 방법이 없는 한 단위테스트를 위해 별도의 Mock framework/object를 만들어야 한다는 뜻이었습니다.

조금 와전된 것 같군요... :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

jj의 이미지

RavenDarkmoon wrote:
lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

저도 가능하면 private field를 사용합니다만, getter, setter가 모두 존재하는 private field는 어떤 의미가 있을런지 고민할때가 가끔 있습니다. getter, setter에 별도의 기능을 첨가하고 self-encapsulation해서 쓰는 경우라면 얘기가 다르지만... 이런 유형은 애초에 쓰기도 싫지만...

전혀 다른 얘기들 덧붙인다면 프로그램을 기계로 분석하는데 있어서, public member는 좀 골치아픈 녀석입니다. 더불어 getter, setter를 가지고 있는 private member또한 다를게 전혀 없지요.

--
Life is short. damn short...

madhatter의 이미지

lenani wrote:

저는 초기 설계를 간단하게 합니다.
설계 시간이 30분을 넘지 않습니다.
대신 반복(Iteration)을 짧게 가져갑니다.
설계가 개발도중 변경되면 바로 반영합니다.
그래서 설계가 한번에 이루어지지 않습니다.
여러차례 반복되서 설계를 합니다.

바로 CBD 방법론이군요. :)

lenani의 이미지

kall wrote:
lenani wrote:
RavenDarkmoon wrote:
lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

음...
제가 잘 이해를 못했습니다.
자세히 설명해주시면 감사하겠습니다.

클래스를 설계한 사람은 public으로 설정해놓고 쓰지 않는 것이 가능하겠지만,
그 클래스를 사용하는 다른 사람은 public으로 열려 있으면 그냥 마구 써도 되는 줄 알고 사용한다는 얘기가 아닐까요?
그 과정에서 데이터가 꼬일 가능성이 있다는 이야기 같은데요..

음...
글쓰신 분의 의도가 정확히 밝혀지지는 않았지만
그 의도가 kall님이 설명해주신 것과 같다고 가정하겠습니다.

public 속성을 그대로 사용한다는 것은 encapsulation을 깨게 됩니다.
당연히 나쁜것이기 때문에 되도록 사용하면 안됩니다.
그래서 저는 public 으로 연결되어 있는 것을 객체 밖에서 사용하지
않습니다.

이건 제가 알고 있는 사항이기 때문에 저는 모든 속성을 public으로
열어놔도 encapsulation을 깨지 않습니다.
다른 사람과 작업할때는 주석으로 절대 속성을 사용하지 말라고
표시합니다.
또는 속성의 이름에 특별한 표시를 합니다.
예를 들면 _name 처럼 말입니다.
만약 다른 사람이 public 속성을 그대로 아무 말없이 사용한다면
어쩌면 이것은 그 사람이 encapsulation에 대한 개념이 없다는
증거일수도 있습니다.

madhatter의 이미지

jj wrote:

저도 가능하면 private field를 사용합니다만, getter, setter가 모두 존재하는 private field는 어떤 의미가 있을런지 고민할때가 가끔 있습니다. getter, setter에 별도의 기능을 첨가하고 self-encapsulation해서 쓰는 경우라면 얘기가 다르지만... 이런 유형은 애초에 쓰기도 싫지만...

encapsulation 의 정의 자체가 interface 까지 포함하는 것 아닌가요? getter,setter 가 단순히 대입, return 작용을 하는 게 아니라 일정한 형태의 의도한 interface 만을 제공하기 때문에 encapsulation 이라고 불린다고 알고 있습니다만...

fender의 이미지

음... 좀 이해가 안가는 부분이지만 'public 속성'은 public int someValue = 10; 과 같은 걸 말씀하시는 건가요?

혹시 getter/setter를 쓰는 일반적인 방법을 쓰지 않는 대신 주석으로 '절대 쓰지 마라'라고 하시는 이유가 있나요? 궁금하네요...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

fender wrote:
kall wrote:
클래스를 설계한 사람은 public으로 설정해놓고 쓰지 않는 것이 가능하겠지만,
그 클래스를 사용하는 다른 사람은 public으로 열려 있으면 그냥 마구 써도 되는 줄 알고 사용한다는 얘기가 아닐까요?
그 과정에서 데이터가 꼬일 가능성이 있다는 이야기 같은데요..

음... 제가 최초에 문제제기했던 내용은 예를들어 개발자들이 흔히 모듈이 어떤 상태가 되면 private 필드인 특정 플래그를 주는 (예를들어 FTP 클라이언트의 경우 로그인했을 때 loggedin=true를 주고 다른 명령이 실행될 때 이를 먼저 체크하는 경우 등) 방식을 쓰는 데 이런 경우 외부에서 단위테스트를 위해 해당 플래그를 바꿀 방법이 없는 한 단위테스트를 위해 별도의 Mock framework/object를 만들어야 한다는 뜻이었습니다.

조금 와전된 것 같군요... :)

setup 에서 특정한 상태의 객체를 만들어 주거나 각각의 test_xxx 함수에서
assert_equal 을 하기전에 그런 객체를 만들어주면 되지 않을까 생각합니다.

그런데 여기에 이 글을 써야 될지 모르겠지만 fender님이 글이 여기에 있는
관계로 여기에 씁니다.

lenani의 이미지

madhatter wrote:
lenani wrote:

저는 초기 설계를 간단하게 합니다.
설계 시간이 30분을 넘지 않습니다.
대신 반복(Iteration)을 짧게 가져갑니다.
설계가 개발도중 변경되면 바로 반영합니다.
그래서 설계가 한번에 이루어지지 않습니다.
여러차례 반복되서 설계를 합니다.

바로 CBD 방법론이군요. :)

예. 비슷합니다.
하지만 꼭 CBD만을 지칭하는 것이 아니라 일반적인 객체지향방식의
개발 과정을 의미한 겁니다.

fender의 이미지

lenani wrote:
setup 에서 특정한 상태의 객체를 만들어 주거나 각각의 test_xxx 함수에서
assert_equal 을 하기전에 그런 객체를 만들어주면 되지 않을까 생각합니다.

그런데 여기에 이 글을 써야 될지 모르겠지만 fender님이 글이 여기에 있는
관계로 여기에 씁니다.


에구... 다시 단위 테스트 관련 내용을 여기에 쓰게 되네요 :)

그런 경우 단위테스트를 위해 내부 플래그를 세팅하는 public 메소드나 생성자를 만들어야 한다는 점에서 바람직하지 않습니다. 예를든 FTP 클라이언트의 경우도 단위테스트를 무시하면 상식적으로 connect(String host, int port) 정도의 메소드를 만들어 이를 호출해서 접속이 되면 내부적으로 loggedIn = true 정도로 세팅을 할 것입니다.

단위 테스트를 무시하면 setLoggedIn(boolean)이나 setTesting(boolean) 같은 군더더기가 필요 없으니까요...

일부에서는 이런 문제를 JVM의 보안을 우회하는 방식으로 직접 private 필드에 접근해서 해결하기도 합니다. (JUnit CVS의 private field accessor 참조) 하지만 개인적으로 이런 방식은 encapsulation의 원칙을 무시하는게 아닌가 하는 생각이 듭니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

jj wrote:
RavenDarkmoon wrote:
lenani wrote:
저는 모든 객체의 속성을 public으로 열어둡니다.
사실 좀 웃기는게 private으로 막아놨다는 것은 코드 작성자 스스로가
'나는 이 속성을 밖에서 쓰지 않겠다'라고 말하는 것과 같습니다.
저는 그냥 밖에서 그 속성을 쓰지 않습니다.

lenani님께서는 쓰지 않으실테니 문제가 없으나, 다른 사람은 쓸 가능성 이 있다는 것이 문제입니다.

저도 가능하면 private field를 사용합니다만, getter, setter가 모두 존재하는 private field는 어떤 의미가 있을런지 고민할때가 가끔 있습니다. getter, setter에 별도의 기능을 첨가하고 self-encapsulation해서 쓰는 경우라면 얘기가 다르지만... 이런 유형은 애초에 쓰기도 싫지만...

전혀 다른 얘기들 덧붙인다면 프로그램을 기계로 분석하는데 있어서, public member는 좀 골치아픈 녀석입니다. 더불어 getter, setter를 가지고 있는 private member또한 다를게 전혀 없지요.

정확히 지적하셨습니다.
저도 그 부분에 대한 고민을 많이 한적이 있습니다.
사실 속성이 private으로 막혀 있어도 public get/set 연산을 통해서
접근이 가능하다면 public 속성과 다를바가 없습니다.

하지만 이런 경우는 어떨까요?
get/set으로 들어가는 인자와 리턴되는 값이 객체 안에 존재하는 속성과
꼭 같아야 할까요?
만약 인자와 리턴 값으로 string 형을 사용하지만 실제로 객체 안의 속성은
double 형이라면 어떨까요?

사실 전통적인 객체지향에서는 get/set으로 외부와 값을 교환하지만
그 안에 저장되는 속성과는 전혀 상관 없는 것 입니다.
그렇게 함으로써 속성은 외부와 단절되고 보호되는 것 입니다.

lenani의 이미지

fender wrote:
음... 좀 이해가 안가는 부분이지만 'public 속성'은 public int someValue = 10; 과 같은 걸 말씀하시는 건가요?

네.

fender wrote:

혹시 getter/setter를 쓰는 일반적인 방법을 쓰지 않는 대신 주석으로 '절대 쓰지 마라'라고 하시는 이유가 있나요? 궁금하네요...

get/set 연산을 쓰지 않는것은 아닙니다.
단지 다른 점은 private 속성 대신에 public 속성을 사용하는 겁니다.
만약 어떤 값을 얻어오고 싶다면 getXXX 연산을 사용합니다.
그리고 절대 객체의 속성이 public 으로 열려 있지만 직접 값을 읽어오거나
쓰거나 하지 않습니다.

madhatter의 이미지

lenani wrote:
fender wrote:
음... 좀 이해가 안가는 부분이지만 'public 속성'은 public int someValue = 10; 과 같은 걸 말씀하시는 건가요?

네.

fender wrote:

혹시 getter/setter를 쓰는 일반적인 방법을 쓰지 않는 대신 주석으로 '절대 쓰지 마라'라고 하시는 이유가 있나요? 궁금하네요...

get/set 연산을 쓰지 않는것은 아닙니다.
단지 다른 점은 private 속성 대신에 public 속성을 사용하는 겁니다.
만약 어떤 값을 얻어오고 싶다면 getXXX 연산을 사용합니다.
그리고 절대 객체의 속성이 public 으로 열려 있지만 직접 값을 읽어오거나
쓰거나 하지 않습니다.

이건 저도 좀 궁금하네요. 원래 class 어트리뷰트의 오용을 막기 위한 장치가 private 인 것으로 알고 있는데 굳이 제공되는 장치를 쓰지 않으시는 이유라도 있으신가요?

lenani의 이미지

fender wrote:
lenani wrote:
setup 에서 특정한 상태의 객체를 만들어 주거나 각각의 test_xxx 함수에서
assert_equal 을 하기전에 그런 객체를 만들어주면 되지 않을까 생각합니다.

그런데 여기에 이 글을 써야 될지 모르겠지만 fender님이 글이 여기에 있는
관계로 여기에 씁니다.


에구... 다시 단위 테스트 관련 내용을 여기에 쓰게 되네요 :)

그런 경우 단위테스트를 위해 내부 플래그를 세팅하는 public 메소드나 생성자를 만들어야 한다는 점에서 바람직하지 않습니다. 예를든 FTP 클라이언트의 경우도 단위테스트를 무시하면 상식적으로 connect(String host, int port) 정도의 메소드를 만들어 이를 호출해서 접속이 되면 내부적으로 loggedIn = true 정도로 세팅을 할 것입니다.

단위 테스트를 무시하면 setLoggedIn(boolean)이나 setTesting(boolean) 같은 군더더기가 필요 없으니까요...

일부에서는 이런 문제를 JVM의 보안을 우회하는 방식으로 직접 private 필드에 접근해서 해결하기도 합니다. (JUnit CVS의 private field accessor 참조) 하지만 개인적으로 이런 방식은 encapsulation의 원칙을 무시하는게 아닌가 하는 생각이 듭니다.

저 같은 경우는 테스트의 용도로는 그냥 public 으로 열려진 속성값을 그대로
사용합니다.
테스트까지 encapsulation을 적용할 필요는 없기 때문입니다.
또 내부 속성을 정확히 확인해야지 올바로 동작했는지 알수 있기 때문이기도
합니다.

lenani의 이미지

madhatter wrote:
lenani wrote:
fender wrote:
음... 좀 이해가 안가는 부분이지만 'public 속성'은 public int someValue = 10; 과 같은 걸 말씀하시는 건가요?

네.

fender wrote:

혹시 getter/setter를 쓰는 일반적인 방법을 쓰지 않는 대신 주석으로 '절대 쓰지 마라'라고 하시는 이유가 있나요? 궁금하네요...

get/set 연산을 쓰지 않는것은 아닙니다.
단지 다른 점은 private 속성 대신에 public 속성을 사용하는 겁니다.
만약 어떤 값을 얻어오고 싶다면 getXXX 연산을 사용합니다.
그리고 절대 객체의 속성이 public 으로 열려 있지만 직접 값을 읽어오거나
쓰거나 하지 않습니다.

이건 저도 좀 궁금하네요. 원래 class 어트리뷰트의 오용을 막기 위한 장치가 private 인 것으로 알고 있는데 굳이 제공되는 장치를 쓰지 않으시는 이유라도 있으신가요?

아무리 속성을 private으로 막아 놨다고 하더라도 완벽히 속성을 막을순 없습니다.
만약 프로그래머가 마음만 먹는다면 소스를 고쳐서라도 객체의 속성에 직접
접근한수 있습니다.
그렇기 때문에 private은 단지 표시를 해주는 mark 이상의 효용은 없습니다.

상속의 경우도 마찬가지로 속성을 사용하지 않으면 됩니다.
꼭 그 속성을 private으로 표시할 필요는 없습니다.

최종호의 이미지

lenani wrote:

...
객체지향은 전통이 깊습니다.
제가 아는 한은 객체지향 이전의 구조적 설계/분석, 정보공학, SE 등등 각종
개념들이 서로 융합되어 나타난 것이 객체지향 입니다.
...

토론중에 죄송합니다. 궁금하고 몰라서 묻습니다. 정보공학이 어떤 것인가요?

전산관련 학과나 회사에서 '전산' 이라는 말 대신에 정보과학(Information Science)이나
정보공학(Information Engineering)라는 용어를 사용하는 것을 보았는데,,
'정보공학'이 구조적 기법이나 객체지향 기법과 같은 수준에서 얘기되는
이론적인 토대와 이를 실현하기 위한 구체적인 도구들을 가지고 있는 개발 패러다임인지요?
아니면 '소프트웨어공학'처럼 무언가 좀 갖춰서 잘해 보자는
여러가지 관련 방법론들이나 기술에 대한 총칭인지요?

Shannon의 Information Theory와는 상관 없는 것이겠죠?

말씀하신 '정보공학'과는 거리가 있는 듯 하지만, 구글에서 검색해 보니
Chinese University of Hongkong 에 Information Engineering 학과가 있는데
IE와 관련된 FAQ이 있어서 옮겨봅니다.

http://www.ie.cuhk.edu.hk/index.php?id=22

fender의 이미지

lenani wrote:
아무리 속성을 private으로 막아 놨다고 하더라도 완벽히 속성을 막을순 없습니다.
만약 프로그래머가 마음만 먹는다면 소스를 고쳐서라도 객체의 속성에 직접
접근한수 있습니다.
그렇기 때문에 private은 단지 표시를 해주는 mark 이상의 효용은 없습니다.

상속의 경우도 마찬가지로 속성을 사용하지 않으면 됩니다.
꼭 그 속성을 private으로 표시할 필요는 없습니다.

음... 제 생각에는 좋은 습관은 아닌 것 같습니다. 일단 접근자란 개념 자체는 객체지향의 주요 개념 중 하나입니다. 그리고 혼자서 개발한다면 그냥 public/private이 'marker' 정도 역할 밖에 하지 않을 지 몰라도 불특정 다수가 사용할 모듈을 개발한다면 문제는 달라지지 않을까요?

객체지향, 그리고 그 중에서도 서브클래싱과 서브타이핑을 구분하는 자바의 경우 인터페이스를 사이에 두고 프로그램을 하는 건 중요합니다. 자바의 '인터페이스' 개념도 같은 논리라면 일단 클래스의 특정 public 메소드에 주석으로 "이 메소드만 쓰세요"라고 써 놓는 걸로 대치할 수 있겠지요...

정상적인 방법으로 인터페이스 건너편의 내부구현을 알 수도 없고 알 필요도 없다는 건 중요한 개념이라고 생각합니다. 그리고 인터페이스에 공개된 메소드나 필드는 반드시 호출자에게 의미가 있는 - 즉, 개발자의 편의나 테스팅을 위한 것이 아닌 - 내용으로 구성되야 한다고 생각합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

최종호 wrote:
lenani wrote:

...
객체지향은 전통이 깊습니다.
제가 아는 한은 객체지향 이전의 구조적 설계/분석, 정보공학, SE 등등 각종
개념들이 서로 융합되어 나타난 것이 객체지향 입니다.
...

토론중에 죄송합니다. 궁금하고 몰라서 묻습니다. 정보공학이 어떤 것인가요?

전산관련 학과나 회사에서 '전산' 이라는 말 대신에 정보과학(Information Science)이나
정보공학(Information Engineering)라는 용어를 사용하는 것을 보았는데,,
'정보공학'이 구조적 기법이나 객체지향 기법과 같은 수준에서 얘기되는
이론적인 토대와 이를 실현하기 위한 구체적인 도구들을 가지고 있는 개발 패러다임인지요?
아니면 '소프트웨어공학'처럼 무언가 좀 갖춰서 잘해 보자는
여러가지 관련 방법론들이나 기술에 대한 총칭인지요?

Shannon의 Information Theory와는 상관 없는 것이겠죠?

말씀하신 '정보공학'과는 거리가 있는 듯 하지만, 구글에서 검색해 보니
Chinese University of Hongkong 에 Information Engineering 학과가 있는데
IE와 관련된 FAQ이 있어서 옮겨봅니다.

http://www.ie.cuhk.edu.hk/index.php?id=22

음...
제한된 공간에서 정보 공학에 대해 자세히 말할수 없어서 간단하게만
말하겠습니다.

정보 공학은 입/출력 정보에 따라서 프로그램을 구성하는 방법론입니다.
정보 공학이 동작하는 방식은 다음과 같습니다.
일단 전체 프로그램의 입/출력을 분석합니다.
그리고 그것을 더욱 세분화 합니다.
그 다음에 각각의 입력은 출력으로 변환시키는 것을 함수(그냥 함수라고
하겠습니다)로 정의 합니다.
이제 도출된 입/출력 정보들와 함수들을 구현하면 프로그램이 만들어집니다.

컴퓨터 영역에서 다른 뜻을 가지지만 동일한 이름을 가지는 단어가 많습니다.
정보 공학(Information Engineering)도 그중 하나 입니다.
프로그램을 구축하는 방법론중의 하나로 인식하시면 별 무리가 없을 겁니다.

lenani의 이미지

fender wrote:

음... 제 생각에는 좋은 습관은 아닌 것 같습니다. 일단 접근자란 개념 자체는 객체지향의 주요 개념 중 하나입니다. 그리고 혼자서 개발한다면 그냥 public/private이 'marker' 정도 역할 밖에 하지 않을 지 몰라도 불특정 다수가 사용할 모듈을 개발한다면 문제는 달라지지 않을까요?

그렇군요.
오픈소스 프로젝트의 경우 불특정 다수의 개발자가 참여합니다.
어떤 이는 소스를 확실히 알지 못하지만 어느 한부분의 개발에 참여할수도
있습니다.
또 다른 부분을 알지 못하는 상태에서 public 으로 열려 있는 것을 확인하고
그대로 써도 좋다는 의미로 받아들일수도 있습니다.
이럴 경우에는 속성을 private으로 막아놓는 것도 좋을 것 같습니다.

fender wrote:

객체지향, 그리고 그 중에서도 서브클래싱과 서브타이핑을 구분하는 자바의 경우 인터페이스를 사이에 두고 프로그램을 하는 건 중요합니다. 자바의 '인터페이스' 개념도 같은 논리라면 일단 클래스의 특정 public 메소드에 주석으로 "이 메소드만 쓰세요"라고 써 놓는 걸로 대치할 수 있겠지요...

글쎄요...
지금 fender님은 accessibility를 interface와 혼동하신것 같습니다.
어쩌면 제가 fender님의 글을 잘못 알아듣은 건지도 모르겠습니다.
이 문제는 조금만 자세히 풀어서 써 주시면 감사하겠습니다.
혹시 제가 fender님의 글을 잘못 이해하고 있는 건지도 모르니까요.

fender wrote:

정상적인 방법으로 인터페이스 건너편의 내부구현을 알 수도 없고 알 필요도 없다는 건 중요한 개념이라고 생각합니다. 그리고 인터페이스에 공개된 메소드나 필드는 반드시 호출자에게 의미가 있는 - 즉, 개발자의 편의나 테스팅을 위한 것이 아닌 - 내용으로 구성되야 한다고 생각합니다.

맞습니다.
반드시 그래야 합니다.
저도 테스트용도 이외에는 절대로 속성을 바로 접근하지 않습니다.
fender님은 테스트용도 에도 절대로 속성에 접근하지 않는것이 좋은것이라고
쓰신것 같습니다.

음...
어떤게 좋을까요?
테스트용도에도 철저히 속성을 감추는 것과 테스트용도에는 예외를 두는 것
사이에 말입니다.
각각에 장/단점이 있는것 같습니다.
제 생각에는 이 경우에 좀더 많은 의견과 토론이 필요한게 아닌가 생각됩니다.

RavenDarkmoon의 이미지

lenani wrote:
맞습니다.
반드시 그래야 합니다.
저도 테스트용도 이외에는 절대로 속성을 바로 접근하지 않습니다.
fender님은 테스트용도 에도 절대로 속성에 접근하지 않는것이 좋은것이라고
쓰신것 같습니다.

음...
어떤게 좋을까요?
테스트용도에도 철저히 속성을 감추는 것과 테스트용도에는 예외를 두는 것
사이에 말입니다.
각각에 장/단점이 있는것 같습니다.
제 생각에는 이 경우에 좀더 많은 의견과 토론이 필요한게 아닌가 생각됩니다.

이 부분에는 저도 lenani님과 비슷한 의견입니다. 제 경우 Windows 기반에서 주로 개발을 하기 때문에 User Input을 위한 Dialog를 상당히 많이 사용합니다.

MFC에서의 CDialog 상속 클래스들이죠. 사실 이 경우 매번 attribute를 private으로 묶고 Get/Set을 제공하는 것도 상당히 피곤한 일입니다. 이런 경우는 public으로 풀어줘도 별 문제가 없다고 봅니다.

제 경우는 외부로 노출되는 단위 모듈에서는 접근제한을 확실히 하고, 내부 구현을 위한 클래스는 좀 loose하게 하는 편입니다.

fender의 이미지

lenani wrote:
fender wrote:

객체지향, 그리고 그 중에서도 서브클래싱과 서브타이핑을 구분하는 자바의 경우 인터페이스를 사이에 두고 프로그램을 하는 건 중요합니다. 자바의 '인터페이스' 개념도 같은 논리라면 일단 클래스의 특정 public 메소드에 주석으로 "이 메소드만 쓰세요"라고 써 놓는 걸로 대치할 수 있겠지요...

글쎄요...
지금 fender님은 accessibility를 interface와 혼동하신것 같습니다.
어쩌면 제가 fender님의 글을 잘못 알아듣은 건지도 모르겠습니다.
이 문제는 조금만 자세히 풀어서 써 주시면 감사하겠습니다.
혹시 제가 fender님의 글을 잘못 이해하고 있는 건지도 모르니까요.


아... 제가 비유를 든다고 한게 좀 전달이 잘못됐네요 :) public으로 선언 후 임의로 주석등을 통해 '이 속성은 사용하지 마세요'라고 하는 방식이 좋지 못하다는 생각을 표현한 것이었습니다. 다시보니 비유가 좀 그렇군요... 예를들어 정상적인 방식으로 HashMap과 같은 key-value 형식의 자료구조를 만들려면 그냥 일반 클래스에 put이나 get 같은 메소드를 만들어 놓고 주석에 '이렇게 쓰는거다'하고 설명을 달아도 동작하는데는 무리가 없지만, 보다 좋은 방법은 java.util.Map을 구현해서 프로그래머의 의도를 명확히 하는게 좋지 않나 하는 뜻이었습니다.

lenani wrote:
음...
어떤게 좋을까요?
테스트용도에도 철저히 속성을 감추는 것과 테스트용도에는 예외를 두는 것
사이에 말입니다.
각각에 장/단점이 있는것 같습니다.
제 생각에는 이 경우에 좀더 많은 의견과 토론이 필요한게 아닌가 생각됩니다.

글쎄요... 쉬운 문제는 아닌 것 같습니다. 다만 개인적인 의견으로는 단위테스트를 위해 본래의 코드의 디자인이나 구현을 변경하는 일은 가능한 한 피해야 한다고 생각합니다. 왜냐하면 구현된 코드의 퀄리티를 높이려고 테스트를 하는 거지 테스트 케이스를 만들려고 프로젝트를 하는 건 아니니까요 :)

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

fender wrote:
lenani wrote:
음...
어떤게 좋을까요?
테스트용도에도 철저히 속성을 감추는 것과 테스트용도에는 예외를 두는 것
사이에 말입니다.
각각에 장/단점이 있는것 같습니다.
제 생각에는 이 경우에 좀더 많은 의견과 토론이 필요한게 아닌가 생각됩니다.

글쎄요... 쉬운 문제는 아닌 것 같습니다. 다만 개인적인 의견으로는 단위테스트를 위해 본래의 코드의 디자인이나 구현을 변경하는 일은 가능한 한 피해야 한다고 생각합니다. 왜냐하면 구현된 코드의 퀄리티를 높이려고 테스트를 하는 거지 테스트 케이스를 만들려고 프로젝트를 하는 건 아니니까요 :)

저는 테스트를 아주 애용(?)합니다.
테스트없이 코딩을 한다는 것은 상상조차 못합니다.
완전히 습관화가 되어버렸다고 할까요?

그런데 테스트를 수행할때 올바르게 동작한다는 것을 보장하기 위해서는
객체 내부의 속성을 바로 접근해야 할 경우가 많습니다.

fender님은 테스트를 할때 올바로 동작했다는 것을 확인할때 어떻게 하시는지
궁금합니다.
사실 eclipse를 사용할 경우 get/set을 만드는 것이 아주 편리하기 때문에
따로 get/set을 만드는 번거로움이 많이 줄었습니다.

lenani의 이미지

RavenDarkmoon wrote:
lenani wrote:
맞습니다.
반드시 그래야 합니다.
저도 테스트용도 이외에는 절대로 속성을 바로 접근하지 않습니다.
fender님은 테스트용도 에도 절대로 속성에 접근하지 않는것이 좋은것이라고
쓰신것 같습니다.

음...
어떤게 좋을까요?
테스트용도에도 철저히 속성을 감추는 것과 테스트용도에는 예외를 두는 것
사이에 말입니다.
각각에 장/단점이 있는것 같습니다.
제 생각에는 이 경우에 좀더 많은 의견과 토론이 필요한게 아닌가 생각됩니다.

이 부분에는 저도 lenani님과 비슷한 의견입니다. 제 경우 Windows 기반에서 주로 개발을 하기 때문에 User Input을 위한 Dialog를 상당히 많이 사용합니다.

MFC에서의 CDialog 상속 클래스들이죠. 사실 이 경우 매번 attribute를 private으로 묶고 Get/Set을 제공하는 것도 상당히 피곤한 일입니다. 이런 경우는 public으로 풀어줘도 별 문제가 없다고 봅니다.

제 경우는 외부로 노출되는 단위 모듈에서는 접근제한을 확실히 하고, 내부 구현을 위한 클래스는 좀 loose하게 하는 편입니다.

저도 주로 그렇게 하고 있습니다.
하지만 public 속성을 그대로 사용하지는 않습니다.
비록 public으로 열려 있지만 꼭 함수를 통해서 사용합니다.
왜냐하면 함수를 통해서 교환되는 값은 원래 속성과 관련이 없기
때문입니다.

fender의 이미지

lenani wrote:
저는 테스트를 아주 애용(?)합니다.
테스트없이 코딩을 한다는 것은 상상조차 못합니다.
완전히 습관화가 되어버렸다고 할까요?

그런데 테스트를 수행할때 올바르게 동작한다는 것을 보장하기 위해서는
객체 내부의 속성을 바로 접근해야 할 경우가 많습니다.

fender님은 테스트를 할때 올바로 동작했다는 것을 확인할때 어떻게 하시는지
궁금합니다.
사실 eclipse를 사용할 경우 get/set을 만드는 것이 아주 편리하기 때문에
따로 get/set을 만드는 번거로움이 많이 줄었습니다.


저는 말씀드린 대로 단위 테스트는 매우 제한적으로 수행합니다. 주로 대상이 되는 건 static 으로 선언된 유틸클래스들이나 어떤 변환, 스트링등의 치환, 하이버네이트 세션이나 원격호출 인터페이스 가져오기, 비교 작업 등 단순하고 그야말로 '단위(unit)'로 명확히 구분이 되는 부분에 대해서만 이클립스와 Maven을 이용해 테스트 케이스를 연동하고 있습니다. 따라서 In-Container나 MockTest는 가능하면 피하는 편입니다.

이런 경우를 제외하면 거의 전적으로 이클립스의 디버거와 로그에 의존하고 있습니다. 특히 로그의 경우 commons-logging/log4j를 쓰기 때문에 매우 상세한 부분까지 레벨별로 기록합니다. 테스트와는 달리 로그를 찍는 건 접근자에 제약받지 않으니까요. 또 assert 역시 어느정도 테스트를 대체할 수 있다고 생각합니다.

사실 단위테스트의 목적이 디버그 보다는 regression을 막는 것임을 생각해 본다면 상대적으로 개발인원이 제한적이고 한번 작성하면 여러 개발자에 의해 확장/수정이 자주 일어나지 않는 부분이 대부분인 성격의 프로그램이라면 많은 부분에서 단위테스트의 사용을 최소화할 수 있지 않나 생각합니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

lenani의 이미지

음...
그렇군요.
뭐 개발자마다 자기가 편한 연장(?)이 있으니까요.
뭐 어쨌든 중요한 것은 자기손에 맞는 연장(?)을 잘 사용하는것이라고 생각합니다.
결국 목표는 잘 만들어진 프로그램이고 어떤 길을 택하든지 그 목표만 잘
이루면 되니까요.

lenani의 이미지

사실 저는 확실한 결론을 좋아합니다.
하지만 이번의 경우는 확실한 결론의 문제가 아니라 취향의 문제이기
때문에 어떤 결론을 내리기는 힘들군요.

fender님과 제가 동의하는 것은 객체의 속성을 객체 밖에서 사용하면
안된다라는 것 입니다.
이것은 정말 동의하고 꼭 지켜져야 한다고 생각합니다.

다만 의견이 갈린 것은 테스트용도에서까지 그것을 지켜야 하느냐 입니다.
저는 테스트용도에서는 예외를 두어야 한다는 입장이고
fender님 테스트용도에서도 예외를 두면 안된다는 입장입니다.

사실 이것은 결론이 날수가 없습니다.
취향이 다르기 때문입니다.

lenani의 이미지

제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.
(2) 객체 지향에 익숙한 개발자가 드물다.
(3) 객체 지향은 배우기 어렵다.
(4) 수행 속도가 느리다.

뭐 이밖에 다른 원인이 있다면 말씀해주시기 바랍니다.

redbaron의 이미지

lenani wrote:
제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.


1번이 거의 모든 이유를 포함하고 있습니다.

(시간은 소중한 거니까요..)

likejazz의 이미지

lenani wrote:
제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.
(2) 객체 지향에 익숙한 개발자가 드물다.
(3) 객체 지향은 배우기 어렵다.


객체지향 방법론에 CBD 구현상의 문제까지 포함하여 다음항을 추가하고 싶습니다.

(4) 수행속도가 느리다.

소위 객체지향의 구현을 위한 양대 Framework 인 COM+ 나 EJB 의 수행속도가 아직은 만족스럽지 못합니다.

3-tier 로 인한 overhead 를 무시할수없으며 적어도 현재는 2-tier 에 모든 Biz-Logic 을 Stored Procedure 화 하여 DB-tier 에서 직접 수행하는게 속도면에서는 가장 유리합니다.

이 문제는 지속적으로 개선되어가고 시간이 해결해줄 문제라고 봅니다만 사실 더 오랜 시간을 들여 더 느린 시스템을 만들어낸다는데 좋아할 경영자가 몇이나 될까요 ? :oops:

* 물론 유지보수라던지 Scalability 등의 문제는 논외로하고 말하는것입니다 ;)

--
Sang-Kil Park

lenani의 이미지

redbaron wrote:
lenani wrote:
제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.


1번이 거의 모든 이유를 포함하고 있습니다.

(시간은 소중한 거니까요..)

맞습니다.
일단은 프로그램을 완성해야 하는게 1차 목표입니다.
한편으로는 왜 이렇게 프로그램 개발 시간을 작게 가져야 하는지 의문입니다.
계약 당시에 당장은 수주하는게 좋지만 그래도 지켜야 할 룰을 있어야 한다고
생각합니다.

lenani의 이미지

likejazz wrote:
lenani wrote:
제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.
(2) 객체 지향에 익숙한 개발자가 드물다.
(3) 객체 지향은 배우기 어렵다.


객체지향 방법론에 CBD 구현상의 문제까지 포함하여 다음항을 추가하고 싶습니다.

(4) 수행속도가 느리다.

소위 객체지향의 구현을 위한 양대 Framework 인 COM+ 나 EJB 의 수행속도가 아직은 만족스럽지 못합니다.

3-tier 로 인한 overhead 를 무시할수없으며 적어도 현재는 2-tier 에 모든 Biz-Logic 을 Stored Procedure 화 하여 DB-tier 에서 직접 수행하는게 속도면에서는 가장 유리합니다.

이 문제는 지속적으로 개선되어가고 시간이 해결해줄 문제라고 봅니다만 사실 더 오랜 시간을 들여 더 느린 시스템을 만들어낸다는데 좋아할 경영자가 몇이나 될까요 ? :oops:

* 물론 유지보수라던지 Scalability 등의 문제는 논외로하고 말하는것입니다 ;)

음...
제가 알기로는 3-tier는 기업용 프로그램에서만 사용하는 걸로 알고 있습니다.
말씀하신대로 기업용 프로그램에서는 잦은 업무 규칙의 변화가 발생하고 상대
적으로 속도가 느려도 별 상관이 없기 때문입니다.
일종의 유연성과 속도를 맞교환하는 개념이라고 할까요?
만약 업무 규칙이 잘 변하지 않고 그래서 유지보수의 압박이 심하지 않다면
3-tier 보다는 박상길님의 말씀대로 2-tier로 하는 것도 좋을듯 싶습니다.

ps. 리스트에 추가 했습니다.

tasy의 이미지

fender wrote:
예를들어 웹이나 GUI에서 단위테스트가 절실한 부분은 오히려 "이 버튼을 누르면 결과가 어떻게 나오는가? 레이아웃이 깨져 보이지는 않는지? 페이지 네비게이션은 제대로 되는가? 로드가 많이 걸렸을 때 어떻게 반응할 것인가?"하는 등 전통적인 개념의 단위테스트에선 다루기 어려운 부분들이 많습니다. 반면 사람이 테스트하면 클릭 몇번으로 단번에 알 수 있는 부분입니다.

http://xper.org/wiki/seminar/InternetExplorerAutomation
이와 같은 기능등을 이용하면 웹브라우저에서의 테스팅도 일정 부분에서는 가능하다고 생각합니다.
그 이외에도 GUI에서의 테스팅은 여러모로 연구되고 있으니 앞으로 좋은 방향으로 나갈 수 있을 것 같습니다.

제 생각이지만요.

---------
Byeongweon Moon
http://tasy.jaram.org/blog
사랑하면 알게 되고 알면 보이나니 그때에 보이는 것은 전과 같지 않으리라.

lenani의 이미지

tasy wrote:
fender wrote:
예를들어 웹이나 GUI에서 단위테스트가 절실한 부분은 오히려 "이 버튼을 누르면 결과가 어떻게 나오는가? 레이아웃이 깨져 보이지는 않는지? 페이지 네비게이션은 제대로 되는가? 로드가 많이 걸렸을 때 어떻게 반응할 것인가?"하는 등 전통적인 개념의 단위테스트에선 다루기 어려운 부분들이 많습니다. 반면 사람이 테스트하면 클릭 몇번으로 단번에 알 수 있는 부분입니다.

http://xper.org/wiki/seminar/InternetExplorerAutomation
이와 같은 기능등을 이용하면 웹브라우저에서의 테스팅도 일정 부분에서는 가능하다고 생각합니다.
그 이외에도 GUI에서의 테스팅은 여러모로 연구되고 있으니 앞으로 좋은 방향으로 나갈 수 있을 것 같습니다.

제 생각이지만요.

UI 테스트에 대한 논의가 이곳 저곳에서 많이 벌어집니다.
하지만 제 생각에는 UI 테스트는 기본적으로 불가능하다고 생각합니다.
그 이유로 UI 테스트를 자동화 할수 있는 방법이 없기 때문입니다.
일부 COM을 이용하거나 화면을 캡춰하거나 제어하는 방법을 사용해서
UI 테스트를 하는 기법도 존재하지만 그다지 효율적인 방법이 아닙니다.

ㅡ,.ㅡ;;의 이미지

likejazz wrote:
lenani wrote:
제가 이쯤에서 객체지향이 잘 사용되지 않는 이유에 대해서 정리를 하겠습니다.

객체지향이 외면 당하는 이유는...

(1) 프로그램의 개발기간이 작게 주어진다.
(2) 객체 지향에 익숙한 개발자가 드물다.
(3) 객체 지향은 배우기 어렵다.


객체지향 방법론에 CBD 구현상의 문제까지 포함하여 다음항을 추가하고 싶습니다.

(4) 수행속도가 느리다.

소위 객체지향의 구현을 위한 양대 Framework 인 COM+ 나 EJB 의 수행속도가 아직은 만족스럽지 못합니다.

3-tier 로 인한 overhead 를 무시할수없으며 적어도 현재는 2-tier 에 모든 Biz-Logic 을 Stored Procedure 화 하여 DB-tier 에서 직접 수행하는게 속도면에서는 가장 유리합니다.

이 문제는 지속적으로 개선되어가고 시간이 해결해줄 문제라고 봅니다만 사실 더 오랜 시간을 들여 더 느린 시스템을 만들어낸다는데 좋아할 경영자가 몇이나 될까요 ? :oops:

* 물론 유지보수라던지 Scalability 등의 문제는 논외로하고 말하는것입니다 ;)

결국 객체지향은 빛좋은 개살구군요.. :twisted:

편하고 빠르게 하기위해 사용하는것이 정작해보니.. 불편하고
오히려 더느리더라는게 일반적인경험이군요..

그러니 항상 신개념(?)이라는 포장이 번드르하게 만들어주니..


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

brianjungu의 이미지

객체지향이 출발한 가장 큰 이유가 현상과 분석사이의 간극때문이라고 봅니다. 현상은 객체인데, 분석은 구조적이나 절차적으로 되니, 그러한 분석에 기반한 설계와 구현이 현상을 완전하게
반영하기가 어려워 지는 것이죠.

두번째 이유는 갈 수록 커지는 시스템을 기존 방식으로 지탱하는것이 어려워져셔라고 봅니다. 가능하면 컴포넌트화하고, 가능하면 내부적인 메소드들은 가리는 이런 방식은 대규모 시스템을 안정적으로 지탱해주게 하는 주요한 요소들이며, 바로 객체지향이 지향하는 바입니다.

객체지향의 출발점은 여기에 있다고 보는데, 문제는 이러한 객체지향의 고민들에 대한 솔루션이 우리의 것이 아니라는데 있습니다.
그쪽은 우리보다 먼저 소프트웨어, 시스템을 시작했고 그 발전과정에서 자연스럽게 객체지향이라는 솔루션으로 이행한 반면,
우리는 전혀 자연스럽지 못하게 외부에서의 기술적 이입으로
객체지향을 시작했습니다. 더군다나 그 내재화에 대한 시간이나 노력도 별로 깊은 편이 아닙니다. ( 객체지향 말고도 쏟아져 들어오는 그 수많은 신기술들을 습득하는데도 시간이 부족하니까요 )

그러니 항상 "신기술을 가장한 장사꾼들의 고안품"이나
"도무지 이해가 안되는 두꺼운 서적들의 집합"뿐이 안된는 거지요.

추상적인 발언이긴 하나, 소프트웨어 엔지니어들이 기존의 구조적이거나 절차적인 개발방식에 한계를 느끼고, 다른 방안을 강구해야할 필요서을 느끼는 상황이 되야 ( 더 나아가서, 프로젝트를 발주하는 갑의 기획자들까지도 ) 객체지향의 개념이나 방식이 더 이상
난이한 신기술이 아닌 가능한 대안이 될거하고 봅니다.

구체적인 실천방안은 좀 더 생각을 해본후 적겠습니다.

지리즈의 이미지

모 프로 축구팀의 외국인 감독의 인터뷰중의 한내용입니다.

Quote:
Q : 우리나라 선수들이 외국 선수들에 비해 가장 부족한 점은 어떤 것이 있는가?

A : 선수들이 대체로 급하다. 성격도 급하고, 어떤 상황을 맞았을 때도 침착한 면이 떨어지고 행동 역시도 급하다. 이 부분이 대체적으로 갖는 대표적인 문제점이라고 생각한다.

설계와 분석이 중요한 개체지향이 우리나라에서 성공할 수 없는 이유를 잘 설명하고 있다고 생각합니다.

There is no spoon. Neo from the Matrix 1999.

malos의 이미지

- _ - ;;

객체지향 . .

태권v의 머리에
마징가제트의 가슴
메칸더의 다리
울트라맨의 팔

조립
-. -

+운전하는 사람이라면 누구나 너무 빨리 달리면
+자동차를 통제할 수 없다는 사실을
+잘 알고 있습니다.

+그러나 마음이 자동차와 거의 흡사하다는
+사실을 아는 사람은 거의 없습니다.

htna의 이미지

생산공장이 틀리군요..
태권V, 마징가제트, 메칸더, 울트라맨...
어떻게 연결은 시킬 수 있을지 몰라도..
각 연결이 데이터를 전송하는 타입이 틀려서..
테크노로봇이 되지 않을까 생각합니다..
이게 목적이었나요?? ㅋㅋ

malos wrote:
- _ - ;;

객체지향 . .

태권v의 머리에
마징가제트의 가슴
메칸더의 다리
울트라맨의 팔

조립
-. -

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

zoonoo의 이미지

Quote:

(2) 객체 지향에 익숙한 개발자가 드물다.

드물다가 아니라 거의 없다죠.
객체를 재사용가능하도록 유연하게 설계할 수 있는 개발자는 0.1%도 못되는것 같습니다.

그러니 맨날 EJB프로젝트에서 Utils클래스만 난무하죠.
첨부터 끝까지 static 메서드로 가득찼습니다. -ㅅ-;

lifthrasiir의 이미지

htna wrote:
생산공장이 틀리군요..
태권V, 마징가제트, 메칸더, 울트라맨...
어떻게 연결은 시킬 수 있을지 몰라도..
각 연결이 데이터를 전송하는 타입이 틀려서..
테크노로봇이 되지 않을까 생각합니다..
이게 목적이었나요?? ㅋㅋ
malos wrote:
- _ - ;;

객체지향 . .

태권v의 머리에
마징가제트의 가슴
메칸더의 다리
울트라맨의 팔

조립
-. -

프로토콜을 통일시킵시다아아.

- 토끼군

ageldama의 이미지

제가 생각하고 파악한 '객체지향'이란 그 이전의 다른 패러다임의 표현방법으로 표현이 불가능하거나 표현이 힘들거나, 혹은 가능하더라도 직교적이지 못하거나 바람직하지 않은 형태의 것들을 실세계의 모습을 반영한 모델을 반영하는 메타포어(객체, 메시징...)을 이용해서 단일한 방법을 통해 직교적이고 일관된 표현방법을 찾아낸데에 의미가 있다고 생각합니다.
정말로 개인적이고 주관적인 입장에서 제게 있어서 객체지향이란 그런 의미라고 파악하고 있습니다.
FunctionalProgramming와 같은 패러다임에 있어서도 표현의 수단이 객체가 아니라 함수라는 점에서 완전히 다른 목적을 갖는다고 생각하기는 생각의 범위가 좁은 저로서는 힘이 듭니다.

그리고 이런 제 생각에서 정말로 제 주위에서의 객체지향과 관련된 문제는 수단과 방법의 범주에 속하는 객체지향이 전도되어 오히려 객체지향이 목적이 되는 것이고, 또 하나는 이미 최근 몇년사이에 퍼져나간, 그리고 '객체지향은 이런 모습이다'라고 통용되는 형식에 집착하는 모습입니다. Java나 그와 유사한 기술들이 객체지향이고 좋은점이 많다는 것에는 저도 찬성하지만 그러한 것들이 마치 객체지향의 완결점인것처럼 말하는것에는 많은 무리가 있는것 같습니다. 개인적인 경험으로 객체지향이라는 넓고도 깊은 패러다임에 있어서 프로토타입기반 언어나 스몰토크 같은 관과해서는 안된다고 생각하는 부분에 대해서 이야기를 한적이 있습니다. 하지만 단순한 흥미본위의 이야기였음에도 상대방은 그저 또 다른 자바인지 아닌지에만 관심이 있는 것 같았습니다. 자바와 유사하다면 객체지향이고 합리적이며, 그렇지 않다면 그저 무의미한 공론인양 대하는 태도가 정말 보기 안스러웠습니다. 단순히 객체지향만이 아니라 다른 그 무엇에도 사람은 자연히 자신이 모르는 것에는 두려움을 갖겠지만 한편으로 저는 소름이 돋을 정도로 싫었습니다.

제가 생각하는 객체지향의 문제는 객체지향 본연의 임무(그게 뭔지는 희미하게나마 생각하시고 있을 "그것")과 관계없이 그저 관성에 의해서 굳어진 것들을 섬기는 것이 객체지향을 퇴색하게 만드는 것 같습니다. 얼마 지나지 않은 몇년전 객체지향이 무엇인지 조금씩 퍼져가던 그때에 가졌었던 혁신과 기존의 타성으로부터 자유롭고자 하던 나름의 용기들이 이제는 새로운 관성인 '그들만의 객체지향'을 '그렇지 않은 객체지향'으로부터 사수하기 위해서 수구적인 논쟁이 되어 버린 것 같습니다. (그 옛날에는 객체지향은 느리고 덩치가 너무 커서 몇몇 분야를 제외하고는 실용적으로 사용되지 않을거라는 말들도 많았던것 같습니다. 하지만 지금은 몇몇 분야를 제외하고는 어디든지 발견할 수 있는 것으로 알고 있습니다.)

이 글을 보시는 분의 '힘들고 실제적인 프로젝트'에 어떤 '혁신적인 기술과 대안'을 적용하시라고 권하는 글도 아니고 그저 객체지향은 지금도 발전하고 있고 현재의 모습이 절대적인 대안이 아닐 수도 있음을 생각해보셨으면 좀 더 객체지향을 사랑하는 사람들이 더 건설적인 일들을 할수 있지 않을까 싶습니다.

예전의 어떤 프로그래밍 관련 잡지에서 루비가 각광받기 한참전에 루비를(특히 루비의 입출력관련 클래스나 모듈에 대해서) 설명하며 유닉스 철학이 '객체', '메서드' 같은 말들만 없었지 얼마나 객체지향적인지에 대해서도 말한 글을 본 기억이 납니다. 그때까지 저는 객체지향이란 '클래스를 만들고 그 클래스를 인스턴스로 만들고, 메서드를 호출하고... 상속을 하고...'정도였었던 것 같습니다.

잡글이 길었습니다;;; 대한독립만세~

----
The future is here. It's just not widely distributed yet.
- William Gibson

magingax의 이미지

OO가 말은 그럴싸한데..초기에 설계가 완전한고 정확하지않으면 더 쓰기 어렵지 않은지.
나도 누구처럼 종이에 설계해서 코더한테 던져주고 싶지만..내공부족으로..
끝임없은 refactoring 만이 살길..ㅋㅋㅋ

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

hongminhee의 이미지

실무에 들어선지 얼마 되지는 않았지만, 왠지 사람들이 객체의 용도보다는 패턴에 집착하는 것처럼 보였습니다.

익명 사용자의 이미지

고도의 숙련된 고수..: (묵묵히 일만한다)..

이제 배운지한달된 꼬마: (고수보며)당신 그거 어떻게 하는지 난 다알아..
근데 난 그거에 한개 더할줄알아.. 당신은 아무것도 아냐.. 난 객체지향이야.(나불나불...)

고수: 꼬마야 좀있다 태어날 니동생이 태어나면 넌 개코도 아닌게 되겠구나...
그러면 너역시 객체지향은 아닌셈이지..

익명 사용자의 이미지

고도의 숙련된 고수..: (묵묵히 일만한다)..

이제 배운지한달된 꼬마: (고수보며)당신 그거 어떻게 하는지 난 다알아..
근데 난 그거에 한개 더할줄알아.. 당신은 아무것도 아냐.. 난 객체지향이야.(나불나불...)

고수: 꼬마야 좀있다 태어날 니동생이 태어나면 넌 개코도 아닌게 되겠구나...
그러면 너역시 객체지향은 아닌셈이지..

semmal의 이미지

OO를 안쓰거나 제대로 못쓰는 이유는 한가지 밖에 더 있을까요? 제대로 몰라서 겠지요.
패러다임으로 보면 Procedure, Function, Object, Logic은 그냥 생각을 표현하는 도구일 뿐입니다. 어떤 것을 써도 프로그램은 만들어집니다. 다만 어떤 일을 할 때는 어떤 도구를 쓰는 것이 편할 뿐이지요.
OO를 안다고 말할 수는 없지만 제가 뭘 모르는지는 이야기 할 수 있겠군요.
subtyping, subclassing, inheritance, delegation의 정확한 차이점은?
class-based, object-based 의 차이점은?
covariance, contravariance, invariance는?
저 또한 시간을 들여 찾아보지 않는다면 저 질문에서 제대로 대답할 수 있는 것은 하나도 없습니다.
OO는 두리뭉실한 무언가가 아닙니다. 일정 이상의 공부를 하지 않으면 알 수 없는 체계적인 학문입니다.
그저 몇몇 언어에서 설명하는 것만으로 OO를 짐작한다는 건 무리가 있다고 보여지네요.

------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

라이프니츠의 이미지

바로 위에서 얘기된 내용과 관련이 있는건데.. OO는 학문적인 정의와 실용적 기술간의 gap을 메우지 못한 측면 때문에 현재 많은 개발자들이 OO의 바다에서 허우적대고 있다고 생각합니다. 결국 이 글타래가 커버하는 문제는 많은 개발자들이 OO를 제대로 이해하지 못하고 있다는겁니다.

쉽게 얘기해서 OO는 학문적으로 그 개념이 엄밀하게 정의되지 못했습니다. 더 정확히는.. OO는 필드에서 그 구현물인 OO랭귀지가 먼저 선풍적 인기를 끌게 되었고..그것의 학문적 바탕은 오히려 필드의 랭귀지가 버전업되면서 거꾸로 그 학문이 서서히 정립되어 나갔다고 봐야합니다.(아직도 OO는 변화를 겪고 있는 중이고..)

이것은 펑셔널 패러다임의 경우와 매우 다릅니다. 펑셔널 패러다임과 그 구현물인 랭귀지에 대해선 일단 그것을 학습한 사람이라면 그것의 쓰임새와 개념에 대해 혼동을 하는 경우는 극히 적다는겁니다. 즉 펑셔널 패러다임은 그것에 대해 합의된 틀이 정확히 존재합니다. 지극히 세부적인 내용을 제외한다면 펑셔널 패러다임에 대해 이건 이렇다 저건 저렇다는것에 대해 논쟁의 여지는 거의 없다고 봐도 무방합니다. 반면에 OO는 전혀 사정이 다르죠. 이건 비단 한국내에서만의 문제는 아니라고 생각합니다.

그럼에도 불구하고 여태까지의 컴퓨터과학의 많은 분야들을 살펴볼 때 시간적으로 실용적 결과물이 이론에 선행하는 경우가 부지기수라 이런 케이스를 굳이 폄하시켜 볼 생각은 없습니다. 이런 점이 개인적으로 참 아쉬운 점이긴 합니다만...뭐 어쩔 수 없는 점인것 같긴 하군요. (잘 알려져 있듯이 C는 실제로 컴파일러 이론이 완성되기도 전에 나왔죠. TCP/IP도 이론적으로 OSI Layer 참조모델이 완성되기 전에 나온 결과물이고..)

즉 학문적으로 개념이 제대로 정의되지 못했기에 필드에서도 OO에 대해 여러가지 혼선을 빚을 수 밖에 없으며..그것이 제대로된 OO를 할 수 없는 가장 큰 이유라는게 제 생각입니다.

또 하나의 측면은...OO가 인간의 인지구조와 그닥 잘 맞아 떨어지지 않는다는겁니다. 오히려 인간 두뇌는 절차형 패러다임과 더 잘 맞는다는 사실이 여러 실험에서 입증된 바 있습니다. 굳이 연결을 시킨다면 OO는 인간의 "의미기억"메커니즘과 관련시켜볼 수 있겠습니다만 객체와 객체가 관계를 맺는 방식에 있어서 OO는 인간의 인지구조에 상당한 부담을 가중시키는 측면이 있고..그런 부분에서 OO는 인간의 의미기억 메커니즘과 어긋나게 되는것 같습니다.

특히 이 두번째 지적은 컴퓨터 랭귀지를 특정 작업을 수행하기 위한 도구가 아니라 사고를 표현하는 수단..즉 symbolic notation으로 보는 관점에서 심리학과 같은 학문에서 연구해볼만한 가치가 있습니다. 말하자면 마인드맵과 같은 사고 표현의 수단을 컴퓨터안에 짜 넣는다면 그것이 특정 유형의 컴퓨터 랭귀지로 구현될거란 말이죠.(이미 이런 의도로 개발된 랭귀지가 여럿 있는걸로 압니다만) 그렇다면 이런 관점에서 과연 OO패러다임으로 구현된 언어로서 예를들어 C++이 인간의 인지구조와 얼마나 잘 맞아떨어지겠느냐 하는것은 당연히 연구자들의 관심사로 설정될만한 주제일겁니다.

이런 내용은 이미 어딘가에서 연구가 되었을법한 내용이겠지만..개인적으로 그 결과를 안보고도 대충 예상해보자면 OO패러다임이 인간의 뇌상태와 잘 맞아떨어진다는 가설이 거짓일 확률이 클 것 같다는것입니다. 모르긴해도 개발자들이 OO를 어렵다고 느끼는데엔 분명히 이런 심리적인 이유가 있을것입니다.

요컨대, "제대로된" OO가 널리 퍼지지 못하는 이유는 그것이 실제로 알려진것보다 매우 두리뭉실하고..또 어렵기 때문이라고 봅니다.

meteors의 이미지

절차형에 익숙하다는 것도 학습된 결과로 보입니다.

공장식 교육인 유치원부터 대학교까지 시간표나 자신이 만든 계획표라는 것에 따라 처음에 뭘 하고 그 다음에 뭘 하고 하는 식의 절차를 따라 생각하는 것을 10년 이상 몸에 익혀왔기에 쉽게 느껴지는 것일뿐 교육을 받지 않은 어린아이 한테는 마찬가지 난이도일 겁니다.

그래도 관계에 대한 훈련을 하면 객체지향에 대해 충분히 익숙해 질 수 있겠지만 10년 넘게 체화된 것 보다는 힘들겠죠.

라이프니츠의 이미지

그건 그렇지 않습니다. 태어나서부터 사람이 생각하는 과정은 algorithmic합니다. 그렇다고 OO가 non-algorithmic 하다는건 아니고..절차지향형이 algorithmic 한 사고과정과 더 잘 맞는다는겁니다. 당연히 이건 한국인들만의 특성이 아닐뿐더러 또한 특정 시대의 사조에 지배받는 특성도 아닙니다.

인간두뇌는 자신의 여러 능력을 algorithmic하게 전개하도록 진화되어 왔습니다. (이것은 두뇌의 신경계산 과정이 parallel하다는것과는 별개의 것입니다.) 제가 말하려는건 인간이 생존에 필요한 과제를 적절하게 처리하기 위해선 커다란 과제를 여러개의 특정 하위과제로 분류하고 순서를 매겨 나열해서 순차적으로 처리하는 방식을 써야만 한다는것입니다. 그리고 이것 자체가 지극히 algorithmic한 과정이고 절차지향형 과제수행 방식과 아주 잘 들어맞는다는거죠.

절차지향형 패러다임은 기본적으로 이런 인간의 인지과정과 매우 잘 맞습니다. 기본적으로 시대와 지역을 막론하고 "시작, 끝, 순서"등등의 개념에 대해 사람들은 가장 직관적으로 분명한 인상을 갖고 있음이 증명되어 왔습니다. 반면에 시작과 끝이 존재하지 않고 순서가 불분명한 어떤것을 대할때면 그것에 대해 상당한 혼란을 일으킨다는 사실또한 지적되어 왔습니다.

헌데 불행하게도 OO는 인간에게 시작과 끝이 불분명한 개념들의 network을 상기시킵니다. 게다가 이런 개념network의 여러 node를 분류하는 방식은 집합론의 그것을 그대로 끌어오고 있습니다. 하지만 인간은 어떤 개념에 대해 사고할때 집합론적으로 사고하지 않습니다. 더구나 (대체적으로 말해서) OO에서의 동사는 명사류에 어색하게 통합되거나 어거지로 명사화시키는 과정을 거치게 되는데 이것은 분명히 인간의 평범한 사고과정과는 크게 어긋나는것입니다.

일상생활에서 본인이 어떻게 다양한 과제들을 해결하고 있는지를 반성해보시면 왜 OO가 인간의 인지구조와 잘 안맞는지를 잘 알 수 있을거라고 생각합니다.

meteors의 이미지

Quote:
인간이 생존에 필요한 과제를 적절하게 처리하기 위해선 커다란 과제를 여러개의 특정 하위과제로 분류하고 순서를 매겨 나열해서 순차적으로 처리하는 방식을 써야만 한다

위 인용에서 과제를 나누는 것에 대해서는 동의하지만 순차적 처리는 한가지 방법일 뿐입니다. 순서 없이 해도 되고 동시에 해도 되고 안해도 되는 여러가지 경우가 있습니다.

제가 로봇 시뮬레이션을 공부, 개발할 때 같이 연구했던 연구자의 이론에 따르면 목표와, 규칙이 있고 목표와 규칙은 계속 하위 목표과 규칙으로 나눠지며 우선 순위가 있고 사건들에 따라 목표 달성이 달라지며 달성 방법은 순차적인것과 비순차적인 것이 있고 또 동시에 할 수 있는 것도 있으며 달성 중에 특정 사건이 일어난 경우 더 우선순위가 필요한 목표나 규칙을 위해 포기할 수도 있으며 자원에도 제약이 있다고 합니다.

goal, rule-oriented에 event-driven 등의 혼합인데 단순한 절차적 행위보다 사람 생활에 잘 맞습니다.
예를 들어 밥을 먹더라도 밥이나 반찬 먹는 순서는 미리 정하고 먹지 않습니다. 반찬이 짠가, 매운가, 단가, 싱거운가라는 사건에 따라 밥이나 싱거운 반찬, 짠, 매운, 신 반찬을 먹는 먹는 행동이 달라집니다. 또 젓가락으로 집어 먹는 행위도 높은 단계에서 봤을 때에는 절차적이기는 하지만 더 아래 단계로 가서 보면 젓가락의 위치나 무게(반찬을 집었을 때에 달라짐)에 따라 몸이 계속 반응을 합니다. 또 너무 맛이 없다던지 벌레가 나온다던지 하면 밥맛이 떨어져 그냥 먹는다는 목표를 포기하고 식당을 나오기도 합니다.
반찬을 순서를 정하고 먹는 사람도 거의 없을 뿐더러 혹시 순서를 정한 다음 순서에 맞지 않게 먹는다고 해도 혼란을 겪을 것이라고는 생각되지 않습니다.

라이프니츠의 이미지

말씀하신 바 잘 알고 있습니다. 헌데 여기서 중요한것은 어프로치가 공학적이냐 과학적이냐 또 언급되는 수준이 신경세포단위냐 모듈단위냐등의 기준입니다.

가령 신경세포 단위를 언급하고자 한다면 인간 두뇌는 완전 병렬식 컴퓨터에 가깝습니다. 하지만 그것이 구현해내는 심리학적 과제 수행의 처리 과정은 폰노이만형 구조에 가깝습니다. 이것은 병렬식으로 정보 처리하는 뉴런이 폰노이만형 구조를 시뮬레이션한다는 뜻이며 정보가 처리되는 수준에 따라 계산의 구조를 달리 봐야 한다는 의미입니다. 동시에 이 문제는 AI에서는 고전적인 symbolic vs connectionism의 양분구도속에서 형성된 케케묵은 논쟁과 관련되어 있습니다.

물론 저는 위에서 symbolic한 접근을 강조하는 절차지향적 정보처리를 말씀드렸는데 이것은 제가 신경세포수준이 아니라 high-level한 symbolic한 정보처리에 관심이 있다는걸 반영한 결과이고 동시에 현재 대부분의 컴퓨터가 폰노이만형 구조라는 사실에 의거해 대부분의 계산모델과 프로그래밍 언어가 이에 맞춰 개발되어 왔음을 고려한 겁니다.

(현실적으로 병렬계산은 성취하기 지극히 어렵고, 또 다양한 프로그래밍 모델에서 병렬어쩌구라고 나온것도 대부분 진정한 병렬계산이 아닙니다. 현재까지 개발된 컴중에 진정한 병렬머신은 대니 힐리스가 개발한 커넥션 머신정도뿐인걸로 압니다. 또 하나는 우리 어깨위에 붙어있는거구요.)

그리고 goal, rule-oriented에 event-driven 등의 혼합이라는 언급으로 보아 이것은 인간의 cognitive system이라기 보다는 이를 구현하기 위한 구현기술을 나열한것이라고 생각합니다. 잘 알다싶이 어떤것의 구조와 그 구현은 별개의 것입니다. 인간의 뇌내 정보처리 메커니즘과 그 구조를 밝히는것이 과학의 역할이라면 그것을 동일하게 모사해 특정기술로 구현해내는것은 공학의 역할입니다. 그리고 이 지점에서 과학과 공학은 각자의 역할이 달라집니다. 당연히 어떤것을 지칭하는 term도 달라지고 동일한 term이라 해도 그 의미까지 달라집니다.

위에서 저는 과학적 접근을 염두에 두고 있었습니다. 따라서 여기에 공학적 기술을 지칭하는 용어나 개념을 그대로 대입하는건 제가 원래 하려던 주장과는 어긋나게 되는겁니다.

그러나 말씀하신 내용은 잘 알겠습니다.

keizie의 이미지

말씀하신 것처럼 별도의 학습행동이 아니라 사회화의 산물로 습득한 것이라면, 그건 그냥 주어진 조건으로 봐야지 '학습'이라고 할 수 없지 않겠습니까?

라이프니츠의 이미지

덧붙여 말씀드리고 싶은건 객체지향 설계와 객체지향 방법론은 실무에서 같이가는게 맞지만 이론적으로는 서로 다른 개념이기 때문에( 하나의 객체지향 설계를 산출해내는 다수의 객체지향 방법론을 생각해보는건 비교적 쉬운 일입니다.) OO를 심도있게 논하려 한다면 이 둘은 분리시켜 얘기가 되어야 할거라고 봅니다. 현재 진행되고 있는 논의는 이 둘이 이곳저곳에서 섞여있는것 같습니다.

semmal의 이미지

오히려 imperative paradigm으로 작성하는 것이 사람들의 사고를 방해하는 경우도 있습니다. John Backus 아저씨가 "Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs"(http://www.stanford.edu/class/cs242/readings/backus.pdf)이라는 글에서 말했듯이, functional이 더 좋은 경우도 있지요.
실제로 절차지향형이라는 것이 fortran시대부터 시작된 procedure로 추상(abstraction)하는 패러다임이니까요. procedure로 추상한다는 말은 즉 사람의 사고방식이 아닌 컴퓨터의 동작방식에 따라 프로그램이 진행된다는 말이고, 기계를 이해하지 못하면 오히려 절차지향형이 더 사람이 프로그램을 짜는데 방해가 되는 경우가 생깁니다. 그리고 이런 경우는 상당히 많습니다.
C/C++/Java가 괜히 보통 사람들이 배우기 어려워하는 것이 아닙니다. 폰 노이만 구조를 이해못하는 데서 생기는 현실과의 괴리감이 적지 않기때문이지요. 오히려 언어를 배우는 난이도로 보면 Haskell과 같은 fucntional 언어가 C/C++/Java보다 초보자에게 더 쉬운 것이 바로, imperative paradigm이 말하는 "절차"(컴퓨터 동작방식에 대한)와 우리가 생각하는 "절차"(인지과정)가 확연히 다르다는 것을 알려주는 것이라 생각합니다.
절차는 사람들이 사고하는 방식일 뿐, 프로그래밍 언어수준으로 떨어지면 imperative가 무조건 사람과 맞다라고 하는 데는 무리가 있을 것 같습니다. backus아저씨의 글에서 처럼 어떤 문제는 분명 functional이나 oo로 더 풀기 쉬울 때도 있으니까요.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

라이프니츠의 이미지

해당 논문은 시간나면 읽어봐야겠지만, 펑셔널 패러다임이 경우에 따라 더 좋은 경우가 있을 수 있다는것과 사람이 편히 느끼는 스타일로 펑셔널 패러다임이 존재한다는건 전혀 다른 뜻이죠. 제 생각엔 펑셔널 패러다임은 개념적으로 잘 정의되어 있긴 하지만 OO의 경우보다 사람이 이해하기가 더 어려운 스타일이 아닌가 합니다만...

아무리 봐도 그 베이스가 되는 람다계산을 필드 엔지니어들이 친숙하게 느낄것 같지는 않네요. 이건 교육의 문제를 떠나서 실제 함수를 또 다른 함수의 입력으로 조작한다는 개념자체가 상당히 이해하기 어렵다는것이 밝혀져 있기 때문이고요. 이에 대한 실험자료는 이미 수학교육, 수학적 창의성과 관련된 여러 연구자료들에서 제시되고 있습니다.

그리고 "기계를 이해하지 못하면 오히려 절차지향형이 더 사람이 프로그램을 짜는데 방해가 되는 경우"라는건 뭔가 잘못 생각하신것 같네요. 기계를 이해해야 프로그램을 짤 수 있다는건 levels of abstraction의 문제이지 절차지향에 내재한 문제가 아니라고 봅니다. 심지어 어셈으로도 객체지향 패러다임에 맞는 프로그램을 짤 수 있지만, 그 경우라 하더라도 기계를 이해하지 않고서 코드를 작성할 수 있는 방법은 없습니다. 곧 SW 개발 패러다임을 "사람과 기계와의 거리"를 재는 기준으로 바로 설정할 수 없다는 뜻입니다.

추가로 말씀드리면 폰노이만 구조(여기선 절차지향을 가능케 하는 기본 구조쯤으로 규정할 수 있겠군요)는 1900년대 중반 맥클럭 & 피츠의 뇌내 뉴런들간의 연합에 따른 논리계산의 가능성을 상세히 밝힌 당시로선 혁신적인 연구논문에 크게 영향을 받은것으로 알려져 있습니다. stored program..즉 저장장치에 프로그램을 넣어두고 순차적으로 읽어 계산을 처리하는 방식은 여러가지 면에서 인간의 작업기억이 작동하는 방식과도 아주 비슷하죠.

개인적으로 이 분야에 대한 다양한 연구논문을 뒤져서 여기서 보다 전문적으로 논해보고 싶은 생각이 굴뚝같지만 사정이 여의치 않아 그러지 못하는것이 아쉽습니다.

semmal의 이미지

대화가 너무 재밌네요. :)
논문은 꼭 읽어보시길 권합니다. backus아저씨가 자신이 만든 fortran을 깔아뭉개면서까지 말하고 싶었던 답답한 심정이 그대로 들어가있습니다.
어쨌든 imperative paradigm에서 side-effect를 빼놓고 말할 수는 없을 것 같습니다. 또한 side-effect가 있다는 것 자체가 추상 레벨이 낮다는 의미라고 봅니다. side-effect는 언어의 추상 수준을 인간의 사고수준에서 기계(실제든 가상이든)의 메모리 수준까지 낮춰버립니다. 결국, imperative 패러다임으로 프로그램을 작성하면 루프내에서 변수가 어떻게 변해가고 함수가 호출될때 어떤식으로 스택에 쌓이는지 그런 프로세스를 알아야 합니다.
그렇다해도, 말씀하신 것처럼 imperative 패러다임 자체는 추상 레벨과 분리해야하는 개념인 것은 맞습니다. 그렇게 하려면 imperative가 side-effect와 완전히 분리되어야 합니다. 하지만 제가 경험이 적어서 그런지 몰라도 side-effect가 없이 imperative 패러다임으로 작성할 수 있는 언어는 Haskell이 유일했습니다. 재밌게도 Haskell은 functional 언어입니다. 그리고 Haskell조차도 내부적으로 side-effect 없이 작성해서 프로그램이 보다 안전하게 돌아가도록 했을 뿐이지, 프로그래머 입장에서는 메모리를 건드리는 side-effect와 다를바 없고, 폰노이만 구조를 머리속에 그려야하는 것도 사실입니다.
결과적으로 폰노이만 구조를 벗어나서는 imperative 패러다임을 말할 수는 없을 것 같습니다. 그 근본적인 사상이 인간의 사고방식을 따랐다는 바에 대해서는 별로 더하고 뺄말이 없다고 봅니다만, 프로그래밍 언어 수준으로 떨어져버리면 사람이 생각하는 방식보다는 기계가 어떻게 처리할까를 고민하는 것이 현실이라 봅니다. 스스로의 경험을 봤을 때는, 기계가 어떻게 동작해야하는지 고민하지 않았던 때는 imperative 패러다임이 아니라 오히려 functional이나 oo 패러다임을 쓸 때였습니다.
당연하게도 이런 패러다임을 쓴다고 하더라도 프로그램에는 반드시 "절차(process)"는 있어야합니다. 다만 그 절차가 imperative에서 procedure로 표현되는 것과 달리, functional에서는 function(또는 lambda)로 표현되고, oo에서는 object와 message로 표현되는 것이 다를 뿐이지요. 표현방식이 다르다고 해서 "절차"를 따르지 않는 것이 아니고, imperative 언어를 쓰거나 패러다임을 따른다고 "절차"를 따르기가 편해지는 것이 아니라는 걸 말씀드리고 싶은 겁니다. 다시 말하자면, functional이나 oo 패러다임을 따른다고 생각대로 프로그램을 짜기가 imperative보다 더 어려운게 아니라는 말이지요.
사실 제 지식의 한계는 윗글까지였습니다. 더이상 논문이나 연구결과를 들이대시면 전 묵비권을 행사할 수 밖에 없습니다. :D
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

라이프니츠의 이미지

기계를 알아야 한다는게 그런뜻이었군요. 이제 잘 알것 같습니다. imperative랭귀지를 쓸때 현실적으로 부딪히는 문제인만큼 랭귀지가 얼마나 기계와 독립적이냐라는걸 고려해야 할때 추상수준과 함께 생각해봐야 할 요소라는데 동의합니다.

그리고 위에서 잠시 비쳐두었지만 OO or 펑셔널 랭귀지가 절차를 따르지 않는다고 생각하는건 당연히 아닙니다. 설마 그럴리가 있겠습니까.. 다만 OO, 펑셔널 랭귀지의 경우 계산 절차가 드러나는 방식이 익숙하지 않거나 간접적이어서 절차지향형 랭귀지에서보다 덜 직관적으로 보일거라는 거죠.

뭐 현재로선 저도 이에 대해선 딱히 들이댈 자료는 없으니 제가 무슨 근거를 대는것에 큰 우려(?)를 하지 않으셔도 될듯~ 단지 제가 알고 있는건 여러가지 심리학적 사실들일뿐입니다.

위에서 주장했던건 제 입장에서 추론해보건대 "그럴것 같다..."라는 정도구요. 이건 수학의 문제풀이나 사람이 책을 읽거나 과제를 수행하는 과정에서 발생하는 여러 심리학적 사실들로부터 외삽된겁니다. 하지만 프로그래밍 과정에서 어떤 심리적 메커니즘이 작동하는지는 저도 알지못하는 관계로 이 분야는 별도의 스터디를 필요로 합니다.

그런데 이 바닥이 그럴만한 여유를 줘야 말이죠...(한숨)

kalstein의 이미지

일단 접근하는 방법이 절차적 프로그래밍에 비해 많이 다릅니다.
그리고 제대로 된 클래스를 뽑아내는데는, 해당 데이터에 대한 경험이 있어서 직관적으로 뽑아 낼 수 있어야합니다.

가장 중요한 점이라면...대다수의 사람들은 이론적인 공부는 학교과정에서 끝납니다. 업무 시작하면 일에 치이면서 이론적인 공부는 없고, 실무적인 경험이 쌓여갑니다. (속칭 짬밥이라고들 하죠 ㅎㅎ) OOP에 대한 접근은 이론적인 측면이 좀 가미되어있습니다. 그 생각하는 패러다임을 쉽게 바꿀순 없다는거죠...

위에서도...답글 다신분 있지만... 생성자와 소멸자 때문에 OOP를 써야되는게 웃기다. C로도 다 된다. 라고 하셨는데...음.

사실 (전 자바는 잘 모르니..C++만 예로 들겠습니다) 제 생각으로는 C++의 OOP적인 측면은 생성자,소멸자,가상함수. 이 3가지가 전부라고 봅니다. (generic 쪽은 별 세계라서 ㅎㅎㅎ)
C++을 쓰는 이유를 들자면

1. 생성자,소멸자를 통해서 안정성을 높인다.
2. 가상함수를 통하여 재사용성, 쉬운유지보수를 기대한다.
3. STL
4. Boost
5. ACE

입니다. (3,4,5는 라이브러리군요 ㅎㅎㅎ)

더불어...학교에서 가르쳐주는 C++들은 대부분...C++로 짠 C가 많은것 같더군요...^^;; (사실 그럴수밖에 없을꺼같기두하지만...)


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

hongminhee의 이미지

제가 생각하기에는 생성자, 소멸자는 OOP 자체의 특성은 아닌 것 같습니다. OOP의 핵심은 다형성이라고 생각합니다. 상속을 OOP의 특성으로 보는 견해도 있긴 하지만, 제가 볼 때는 다형성을 어떤 방식으로 구현(표현?)하냐의 문제인 것 같고……(프로토타입 복제로도 가능하니까요).

semmal의 이미지

oop의 다른 특성이야 방법적인 차이에 따라 때었다 붙였다, 이리끼우고 저리끼우고 할 수 있지만 다형성이야 말로 가장 중요한 특성이죠. functional과 oop간, 또 oop진영내에서 벌어지는 class-based programming과 object-based programming과의 오랜 싸움은 결국 어떤 방법으로 다형성을 쓰는 것이 더 좋으냐는 종교전쟁일 뿐입니다.
dahlia님 잘지내시죠? 직장은 잘 옮기셨나요?

------------------------------
How many legs does a dog have?

hongminhee의 이미지

넵, 얼마 전에 산업기능요원으로 일할 업체를 찾아서 출근을 하고 있습니다.

semmal의 이미지

그리고, 어느 언어가 좋다 안좋다라고 하는 건, 그 문법이 자신의 생각을 표현하는데 얼마나 편하느냐로 판단할 수 밖에 없습니다. 문법이 편하다 안편하다는 주제는 oo가 좋은지 안좋은지 이야기하는 주제와는 동떨어집니다.
또한, 현존하는 어떤 복잡한 언어의 기능이라도, 결국에는 그 기능을 다른 언어로 1:1 매핑이 되도록 구현할 수 있습니다. 언어에 그런 기능이 있다 없다 역시 oo가 좋은지 안좋은지에 대한 논의주제와는 벗어납니다.
결국, 몇몇 언어의 기능이나 그 언어의 문법만으로 oo의 가치여부를 따지는 건 (아마도...) 큰 의미가 없을겁니다. 라이브러리도 마찬가지지요. 단지 언어의 가치여부를 따지는 것일 뿐일겝니다.
중요한 것은 oo의 사고방식을(즉, 그 무언가를 object로 abstraction하는 방법) 쓸 것이냐 말 것이냐가 되어야지, oo언어를 쓸거냐 말거냐라는 말은 논점을 벗어나는게 됩니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

kalstein의 이미지

글쎄요...패러다임이 다른 언어를 단순히 OOP에 맞춰서 프로그래밍 한다고 해서...OOP가 되는지는 의문입니다. 이런 내용은...상당히 오래전에도 토론이 되었습니다만... C로 OOP가능은 합니다만...쉽게 되진않지요 ^^; C 자체가 OOP에 맞는 언어가 아니니까요.

사실 패러다임만 따져서...OOP에 맞춰서 짜면 OOP이다. 라고 해버리면...솔직히 OOP에서의 언어적 제약은 사라집니다. 하다못해 어셈으로도 잘 짤수는 있으니까요 ^^;
그냥 일반론으로 생각하는게 좋지않을까 싶네요. 보통 OOP라고 하면 C++,JAVA,C#등을 떠올리지 C를 떠올리지는 않지않습니까~ 더불어 해당언어를 잘 쓰는 방법은 해당언어의 패러다임에 맞게 쓸때가 제일 유용하지않나 싶네요...

저도 예전에는...컴퓨터 언어는 그다지 중요하지않고, 프로그래머가 자신의 생각을 표현하는 한가지 방법이다. 라고 생각했었습니다만...요즘에는 좀 다른 생각이네요. 언어에서 표현할수있는 폭이 넓을수록 프로그래머의 생각의 폭도 같이 넓어질수있다고 생각합니다 ^^


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

hongminhee의 이미지

한때 Smalltalk의 Class-based OOP만이 “순수한” OOP라고 인식되던 시절, Java 등은 “진정한” 객체 지향 언어로 취급되었고, 한편에선 이름은 비슷하지만 Prototype-based OOPL인 JavaScript는 “상속이 없으므로 객체 지향 언어가 아니다”라는 찌질이들의 과소 평가를 받았습니다. (“왜 Array 클래스가 아니라 Array 객체라고 부르느냐?”) 지금에서야 사람들이 객체 지향의 구현 방식이 클래스 기반 말고도 다양한 것들이 있다는 것을 알고, 또 람다니 클로져니 하는 함수형 언어의 개념들도 소개되면서 JavaScript가 무척 뛰어난 언어로 평가 받고 있지만요. 그렇다고 또 JavaScript를 함수형 언어라고도 볼 수 있을까요? 다른 사람들은 어떻게 볼지 몰라도, 저는 Array.prototype.map, Function.prototype.apply 같은 것들을 보면 함수형 프로그래밍이 어느 수준 이상 가능한 언어라고 생각합니다.

JavaScript를 예로 든 것은, 이 언어만큼 시간이 지나면서 평가가 반전된 경우를 쉽게 찾기 힘들어서입니다.

객체 지향 언어냐, 함수형 언어냐 하는 것은 중요하지 않다고 생각해요. 윗분 말씀처럼 패러다임을 실제로 적용했느냐의 문제겠죠. 사실 더 나아가면 패러다임이라는 방법 자체보다, 그 방법이 추구하는 실제 가치가 의미있는 거겠죠. 객체 지향이 다형성을 최고의 가치라고 생각한다면(만약 그렇다면요), 함수형 언어에서 자료형에 따라 특수화를 하는 것(혹은 C++에서 템플릿 특수화 등을 통해 일반화 프로그래밍을 하는 것)은 다형성의 일종으로 볼 수 없을까요? 제가 생각하기엔 둘 다 같은 것을 추구한 다른 방식 같습니다.

덧. 아, 극단적인 예시가 될 수도 있겠는데, 예전에 마이크로소프트웨어에 안철수 씨가 객체지향적으로 어셈블리 프로그래밍을 하는 방식에 대해서 기고한 글을 본 기억이 납니다. 제가 잘못 기억하고 있는 건지… 혹시 다른 분들은 그 글 보신 적 있나요?

Darkcircle의 이미지

정확히 말하자면 "제대로 된 객체지향"을 "제대로" 쓰는 업체는 몇 안됩니다...

동감하면 +1, 아니라고 생각하면 -1
(포인트는 눈치 볼 것 없이 주는 겁니다. -ㅂ-b)

============================================
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

mobonie의 이미지

전 C프로그램으로 월급 받은지 10년이 되었지만 C++류의 객체지향은 너무 어렵습니다.
앞으로도 전 객체지향적이지 않은 C로만 먹고 살 예정입니다.

jehovahnissi의 이미지

왜 oop는 어려운가? 라는 주제에 관련된 글입니다.

학부생 4학년입니다. 저는 실무경험은 부족하기 때문에 책에 있는 내용을 소개해드리겠습니다.

'생각의 지도' 라는 책을 보며는
동양인과 서양인의 생각의 구조/방식이 다르다 라고 나옵니다.
모든 '인간'은 같은 방식으로 사고 하는 것이 아니라 문화적 차이에 의해 다르다는 것이지요.

서양인은 개인/부분/추상(이론)/속성/ 논리 적으로 생각하며
동양인은 집단/전체/실용 /관계/동작/경험 적으로 생각을 합니다.

그래서 중세시대까지 서양에서 기하학등의 수학/철학 등이 발전을 했고
동양은 실용품들과 단체행동강령인 각종 '학' (유학등..) 이 발전을 했습니다.

서양인은 전체에서 어떤 '속성'을 추출하여 생각할수 있는 반면에 (수학에서 정말 중요한 능력인..)
동양인은 전체에서의 관계를 중점적으로 생각하여 시야를 넓게 가질수 있는 장점이 있습니다.

객체지향은 하나하나의 객체를 인지하고 알맞은 속성과 행동을 부여하여 코딩을 하기 때문에
프로시져의 절차를 밟아가며 각각 관계를 형성하는 절차지향이 훨씬 쉽게 느껴집니다.

// 수업중에 글쓰는거라 엉망이니 이해 해주세요..ㅠ.ㅠ
// 저는 위의 책을 읽음으로 해서 프로그래밍에 대한 생각을 넓히게 되었습니다.
// 한번 읽어보시면 도움이 될꺼에요(아마도)

magingax의 이미지

이론은 좋을지 모르지만..C++, JAVA 처럼 리팩토링 힘든 언어로 OOP 하기는 쫌..
결국 시간당 생산성문제인데..역시 최고는 CLOS..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

r0oo0t의 이미지

이잰 객체지향이 아니고 CBD로 넘어가는 듯한 추세인거 같던대...

/*********************************
*모든것을 방관하고 지켜보며
*모든것을 창조하고 파괴할수
* 있는 '권한'을 가진 자
*
* 루트 == 신 같은 뜻 아닌가?
*********************************/

/*********************************
*모든것을 방관하고 지켜보며
*모든것을 창조하고 파괴할수
* 있는 '권한'을 가진 자
*
* 루트 == 신 같은 뜻 아닌가?
*********************************/

winner의 이미지

발굴해주신 덕분에 좋은 글 잘 읽었습니다.
지금에 와서야 이 글들이 조금이나 이해가 간다는게 안도가 되기도 하지만 또한 제 자신의 능력부족이 많이 안타깝습니다.

CBD를 이야기하시는데 CBD는 OO의 규모의 문제가 아닌가 싶은데요. Paradigm은 같다고 봅니다. 혹시 차이점을 명확히 알려주실 수 있는 분 없을까요?

페이지

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.