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

lenani의 이미지

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

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

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

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

댓글

버려진의 이미지

게임 프로그래밍 하시는 분들은 상당히 진보적이지 않나요? 요즘엔 generic programming이니 aspect oriented programming이니 하던데 ;;

matrix의 이미지

질문이 참 난해합니다.
시스템 설계시 객체지향 방법론의 적용을 말씀하시는거죠?

많이 아니 굉장히 많이 씁니다.
설계가 잘된 곳도 굉장히 많습니다.

금융권은 거의 다 객체지향 방법론 적용했고...
삼성은 거의 다 EJB로 다 바꾼 듯 하고..
현재 진행되는 프로젝트도 모두 CASE 툴을 이용한 객체지향 방법론을 적용하고 있고..
대형 프로젝은 모두 도입하고 있습니다. 특히 정부 기관은 default입니다.

도대체 우리나라에서 안쓴다는 말이 무슨 말인지?

How do you define Real?

mastercho의 이미지

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

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

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

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

어떤 일을 하시는분의 말씀인가여?
C만 죽어라 코딩하던 분의 말씀이라면.... 그런말이 나올 법도 하지요

실지로.... 객체지향 같은거에 아직도 많은 거부감을 가지고 있는 사람이 많으니까요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

fender의 이미지

matrix wrote:
질문이 참 난해합니다.
시스템 설계시 객체지향 방법론의 적용을 말씀하시는거죠?

많이 아니 굉장히 많이 씁니다.
설계가 잘된 곳도 굉장히 많습니다.

금융권은 거의 다 객체지향 방법론 적용했고...
삼성은 거의 다 EJB로 다 바꾼 듯 하고..
현재 진행되는 프로젝트도 모두 CASE 툴을 이용한 객체지향 방법론을 적용하고 있고..
대형 프로젝은 모두 도입하고 있습니다. 특히 정부 기관은 default입니다.

도대체 우리나라에서 안쓴다는 말이 무슨 말인지?

실제로 큰 프로젝트에서 EJB를 쓰는데를 봐도 설계자가 EJB 스펙의 50%라도 이해하고 제대로 쓰는데는 아직까지 단 한 번도 못봤습니다. 그냥 EJB가 좋다니까, 미션 크리티컬한 솔루션에 적합하다니까 쓰는거지 구체적으로 어떤 이점이 있는지 이해하고 적용하는 경우는 거의 없습니다.

그러다보니 EJB 설계랍시고 한 걸 보면 사실상 세션빈은 펑션 모음이고 엔티티빈은 데이터베이스 테이블 매핑입니다. 이건 결코 객체지향도 아니고 원래 EJB 같은 컴포넌트 중심의 프레임워크는 제대로 써도 객체지향적인 설계가 나오기 쉽지 않습니다.

외국의 경우는 EJB가 실패하고 경량 컨테이너와 경량 퍼시스턴스 솔루션으로 이행하는 추세입니다. 이런 경우 그나마 객체지향의 이점을 살려 설계가 가능할 지 몰라도 '웹개발=디비설계 + html 삽질'이란 공식이 일반적인 우리나라 SI 쪽에서는 별로 영향을 안받을 것 같군요...

어쨌든 최소한 웹 쪽 SI만 놓고 볼 때 실무에서 개발되는 코드의 95%는 전혀 객체지향적이지 않습니다. 거의 데이터베이스 스크립트와 html/자바스크립트의 조합이라고 보셔도 크게 틀리지 않습니다.

암담한 현실이지요 :cry:

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

세벌의 이미지

객체지향...
object oriented 를 우리말로 번역한 것이라지요.
그런데 object oriented 를 객체지향이라고 번역한 것 자체가 잘못이라는 이야기도 있더군요. 개체기반이라고 해야 된다는 이야기도 있고... 어떻게 번역해야 정확한 번역이 될지는 저도 잘 모르겠습니다.
object oriented 라는 개념을 정확히 이해하는 사람이 적어서가 아닐까요?

daybreak의 이미지

Object-Oriented가 객체지향이 된 것은
Object-Based가 객체기반이기 때문입니다. 이쪽에 속하는 대표적인 언어로 ADA가 있죠.

객체지향이라는 번역에 대해서 말은 많았으나 객체기반이 옳다는 말은 틀린 말입니다.

neo0925의 이미지

어떤 측면에서 객체지향이란 번역이 잘못이라는 것인지는 모르겠으나

적어도 사전적인 의미로는 틀린 번역이 아닙니다.

'oriented'란 단어는 무언가를 지향하고 그것에로 방향지어지는

상태를 나타내는 단어입니다.

---------------------------------------------------------------
- The best is yet to come, and there's always hope. -
---------------------------------------------------------------

---------------------------------------------------------------
- The best is yet to come, and there's always hope. -
---------------------------------------------------------------

madhatter의 이미지

객체지향의 구체적으로 어떤 부분을 사용해야 한다는 것인지 잘 이해가 가질 않습니다. 가령 웹기반 서비스를 개발하는 프로젝트에 EJB를 도입한다고 하면, 윗 분 말씀대로 세션빈은 펑션의 집합입니다. 엔티티 빈은 잘 쓰지도 않습니다. 웹 환경이라는 게 초기 설계가 6개월이내에 대부분 DB 설계부터 수정이 가해지기 때문에 엔티티 빈은 운영상에 장애요인으로 작용합니다.
객체지향의 추상화, 상속, 다형성 중에 추상화와 다형성은 어느 정도 사용되지만 상속은 특히 웹기반 서비스에는 거의 쓰이지 않습니다. EJB 컨테이너 솔루션 엔지니어들도 상속은 쓰지 않을 것을 권고합니다. 그 이유는 튜닝이 어렵고 리소스의 낭비가 심해질 수 있으며 디버깅이 어려워지는 경우도 있기 때문입니다.
그 외에 다른 분야는 잘 모르겠네요. :)

fender의 이미지

madhatter wrote:
상속은 특히 웹기반 서비스에는 거의 쓰이지 않습니다. EJB 컨테이너 솔루션 엔지니어들도 상속은 쓰지 않을 것을 권고합니다. 그 이유는 튜닝이 어렵고 리소스의 낭비가 심해질 수 있으며 디버깅이 어려워지는 경우도 있기 때문입니다.

딴지 거는 건 아니지만 정확히는 상속이 웹기반 서비스에서 거의 쓰이지 않는 것이 아니라 컴포넌트 지향적인 특성상 EJB 솔루션에서는 쓰기가 어렵습니다. 튜닝이 어려워 진다는 부분은 잘 이해가 가지 않지만 어쨌든 구조적으로 거의 쓰기가 불가능합니다.

EJB에 대한 비판은 여러 가지가 있지만 대표적으로 앞서말한 비객체지향적 특성 이외에도 불필요한 오버헤드, 생산성 저하, 비슷한 종류의 중복되는 코딩 - 예를들어 엔티티빈과 데이터모델(value object), 유닛 테스트의 어려움, 벤더 종속성 등등이 있습니다.

이런 한계를 극복하려는 시도가 다방면에서 있어왔고 최근의 경량 프레임워크 들을 활용하면 웹기반 서비스에서도 상속과 같은 객체지향의 장점들을 100% 활용할 수 있습니다. 따라서 객체지향적 설계가 어렵다는 건 웹기반 솔루션의 한계라기 보다는 EJB 모델의 한계라고 하는게 더 적합할 것 같습니다.

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

fender의 이미지

madhatter wrote:
웹 환경이라는 게 초기 설계가 6개월이내에 대부분 DB 설계부터 수정이 가해지기 때문에 엔티티 빈은 운영상에 장애요인으로 작용합니다.

부연 하자면 바로 그런 관행이 국내 웹SI 설계의 수준을 반증한다고 생각합니다. 대부분, 최소한 제가 수년간 실무에서 본 개발자 모두는 SQL에 대한 지식은 수준급이지만 객체지향적 개발이나 XP 등의 방법론에 대해서는 거의 경험이 없습니다. 그러다보니 모든 개발이 데이터베이스를 중심으로 돌아가게 되고 설계는 곧 ERD를 그리는 것이라는 잘못된 고정관념이 생긴 것입니다. 말씀하신 대로 대부분 초기에 기획서를 보고 데이터베이스를 좀 아는 개발자가 ERD를 뽑아 놓으면 나머지 초급 개발자들이 달라붙어 부분 부분 나눠서 디자이너가 작성한 html과 연결하는 식의 작업이 대표적인 국내의 웹기반 SI의 개발 방법론(?)입니다.

사실 EJB의 엔티티빈이 나오게된 배경을 보아도, 이는 엔티티빈 이전부터 널리 쓰이던 O/R 매핑이나 퍼시스턴스 프레임워크 들을 표준화 하려는 시도입니다. 즉, 정석대로 도메인 객체를 설계하고 이를 퍼시스턴스하는 과정에서 DAO를 만들건 TopLink 같은 O/R 매핑 툴을 쓰건 하는 탑다운 방식이 권장되었음을 알 수 있습니다. 그런데 이런 엔티티빈이 아예 '탑다운'이라는 개념 자체가 생소한 국내에 들어오면 반대로 기존의 ERD에 엔티티빈을 '올리는' bottom-up으로 둔갑하다보니 "왜 굳이 ERD를 만들었는데 또 엔티티빈이 있어야 하나?"하는 의문이 드는 것입니다.

물론 외국에서 EJB, 특히 그 중에서도 엔티티빈이 비판받는 건 다른 이유지만 엄밀히 말하면 국내에서 정상적으로 엔티티빈을 제대로 이용해서 설계를 한 경우는 제가 아는 한 많지 않습니다.

즉, 이런 문제점들은 웹 개발이라는 환경에서 비롯된 것이 아니라 대부분 데이터베이스 중심적 사고를 하는 국내 개발자들의 수준에서 오는 것이라고 생각합니다.

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

zienie의 이미지

SessionBean, EJB3 Entity Bean을 사용한 프로젝이 튜닝 단계에
이르니 전통적인 JAVA 개발자들은
"튜닝이 불가능하다. 이걸로는 뭘 못하겠다. DB Query 튜닝이 불가능하다"는 좀 말이 안되는 의견을 제시하면서...
걷어내자" 는 말이 나오더군요. "당혹" 스러웠습니다.
신기술에 대해 익숙치 않음을 그런식으로 표출하는 개발자들에게 적잖이 실망하게되었습니다.
뭐, 현실에 안주하는걸 탓할 마음은 없지만, 좀 그렇더군요.
특히 SI 경험이 많고, 그쪽 작업 경험이 많은 개발자일수록
기존에 해온 방식대로 ERD를 만들고 Entity를 올리려고 하는 경향이 강하더군요.

여담이지만, EJB3 기반의 Entity Bean이 성능과 상속에 대한 유연성은 놀랍더군요.
다만, 익숙치 않은 (저를 비롯한) 몇 몇 목수들이 기술 연마가 아닌 때문에 연장탓을 하는 바람에....
에휴.......
##########################################################
넘어지는건 아직 괜찮다.
하지만 넘어질때마다 무언가를 주워서 일어나자.

##########################################################
넘어지는건 아직 괜찮다.
하지만 넘어질때마다 무언가를 주워서 일어나자.

soungno의 이미지

DAO 또는 DataAccessLayer 를 두는건 엔트프라이즈 환경에서 보편적을 널리 사용되는 구조 이지요
그런데 그 계층이 존재 한다고 해서 DataBase 설계 방향의 영향을 끼친다고 생각하지는 않습니다.
지금 주장하시는 것은 DAO 또는 DataAccessLayer의 객체들의 형태에 맞는 DataBase 구조가 완성되어야 한다고 생각 할수 있는데요
근본적으로 둘은 틀린형태의 구조를 가질 수 밖에 없는 형태 입니다.
그래서 DataAccessLayer 에서는 객체구조환경 부분과 관계 데이터베이스 환경 부분을 추상화 시켜 분리시키는 역활을 하는것 아니겠습니까?
즉 객체환경의 설계 내용이 관계 데이터 베이스 설계 내용에 많은 영향을 끼치면 안되며, 또한 관계 데이터베이스 환경이 객체환경의 설계 부분에 많은 영향을 끼치면 안됩니다.
또한 하나만 더붙혀 말씀드리면 아키텍쳐 레벨에서 개발자들의 성향과 능력도 아키텍쳐 구성 및 설계에 많은 영향을 주고 있습니다.
결국 국내 개발자들 스스로 객체지향 방법 또는 기타 다른 기술과 능력을 배양하지 않는 한 님께서 말씀하신 SQL 프로시저기반(과거 4GL)과 같은 구조의 애플리케이션들이 나올수 밖에 없지 않을까 생각 합니다.

잘 가야지.

crimsoncream의 이미지

c만 죽어라 '코딩'하는 사람으로써 매우 기분 나쁘군요.
기껏해야 생성자와 소멸자가 주는 편리함 정도 때문에 c++을 쓰는 사람에게 c를 쓴다는 이유만으로 "c를 쓰면 안됩니다. oo로 개발해야합니다."라는 소리를 들었던 때처럼 황당하기도 하구요.

c로도 oo 할 사람들은 다 한답니다.
뭐 c가 oo를 '진정'으로 구사할 수 있냐는 논쟁을 원하시는 거라면 해야할 코딩이 쌓여 있어서 피하고 싶군요. 다만 그 문제는 학문으로서 컴퓨터언어론을 파고 있지 않다면 여기 bbs에 그에 대한 많은 글이 있으니까 검색해서 읽어보시고 각자가 나름대로 선택하면 될 문제라고 생각합니다.

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

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

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

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

어떤 일을 하시는분의 말씀인가여?
C만 죽어라 코딩하던 분의 말씀이라면.... 그런말이 나올 법도 하지요

실지로.... 객체지향 같은거에 아직도 많은 거부감을 가지고 있는 사람이 많으니까요

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

madhatter의 이미지

fender wrote:

부연 하자면 바로 그런 관행이 국내 웹SI 설계의 수준을 반증한다고 생각합니다. 대부분, 최소한 제가 수년간 실무에서 본 개발자 모두는 SQL에 대한 지식은 수준급이지만 객체지향적 개발이나 XP 등의 방법론에 대해서는 거의 경험이 없습니다. 그러다보니 모든 개발이 데이터베이스를 중심으로 돌아가게 되고 설계는 곧 ERD를 그리는 것이라는 잘못된 고정관념이 생긴 것입니다. 말씀하신 대로 대부분 초기에 기획서를 보고 데이터베이스를 좀 아는 개발자가 ERD를 뽑아 놓으면 나머지 초급 개발자들이 달라붙어 부분 부분 나눠서 디자이너가 작성한 html과 연결하는 식의 작업이 대표적인 국내의 웹기반 SI의 개발 방법론(?)입니다.

사실 EJB의 엔티티빈이 나오게된 배경을 보아도, 이는 엔티티빈 이전부터 널리 쓰이던 O/R 매핑이나 퍼시스턴스 프레임워크 들을 표준화 하려는 시도입니다. 즉, 정석대로 도메인 객체를 설계하고 이를 퍼시스턴스하는 과정에서 DAO를 만들건 TopLink 같은 O/R 매핑 툴을 쓰건 하는 탑다운 방식이 권장되었음을 알 수 있습니다. 그런데 이런 엔티티빈이 아예 '탑다운'이라는 개념 자체가 생소한 국내에 들어오면 반대로 기존의 ERD에 엔티티빈을 '올리는' bottom-up으로 둔갑하다보니 "왜 굳이 ERD를 만들었는데 또 엔티티빈이 있어야 하나?"하는 의문이 드는 것입니다.

물론 외국에서 EJB, 특히 그 중에서도 엔티티빈이 비판받는 건 다른 이유지만 엄밀히 말하면 국내에서 정상적으로 엔티티빈을 제대로 이용해서 설계를 한 경우는 제가 아는 한 많지 않습니다.

즉, 이런 문제점들은 웹 개발이라는 환경에서 비롯된 것이 아니라 대부분 데이터베이스 중심적 사고를 하는 국내 개발자들의 수준에서 오는 것이라고 생각합니다.

글쎄요, EJB가 Top-Down 식의 설계 방법을 도입해야한다는 건 좀 의외입니다. 실제로 지금까지 제가 수행해온 Web 기반의 SI 프로젝트는 모두 Top-Down 방식이었습니다. 거기에 EJB등의 객체지향 솔루션을 도입하면서 CBD 방법론이나 UML 툴을 써서 설계를 하는 게 유행(?) 비슷한 경향이 되었습니다. 물론, UML을 쓴다, EJB를 쓴다고 해서 그게 객체 지향적이고 컴퍼넌트 기반의 시스템이 된다고는 생각하지 않습니다.
그리고 설계란 곧 ERD가 아니라 업무를 IT적으로 분석한 것이 곧 ERD라고 생각합니다. 기타 class 설계는 업무에 기반했다기 보다는 순수 구현을 위한 설계라는 것이 개인적인 견해입니다. 액션 중심의 시스템이라면 객체와 액션간의 상관관계에서 엔티티를 끌어낼 수 있지만 데이타 중심의 시스템이라면 엔티티의 효율적인 사용을 위해 객체와 액션을 정의할 수 있는 것 아닌가요? 웹 기반이라면 물론 액션에 치우치는 경향이 많지만 대용량 DB나 데이타간의 연관관계가 복잡해질 경우엔 ERD의 설계가 전체의 절반이상을 차지한다고 봅니다. 거꾸로 제가 겪어본 웹 관련 개발자들은 엔티티나 DB의 중요성은 경시하고 액션에만 치우쳐서 어떻게 EJB를 멋있게 쓸 것인가에만 골몰하는 경우가 더 많았습니다.

물론 개인적인 경험이므로 개인적인 견해입니다. :)

kuma의 이미지

객체지향이라고 한참 떠벌리고 그게 아니면 죽음을 달라던 시절은 이미 96년도에 지나 갔습니다. 지금은 어떤 방식이 수행 작업에 가장 적절한지 판단해서 사용하는 시대입니다. 모든걸 객체지향이어야 한다는 생각은 이제 그만되었으면 하네요.

digitie의 이미지

madhatter wrote:
거꾸로 제가 겪어본 웹 관련 개발자들은 엔티티나 DB의 중요성은 경시하고 액션에만 치우쳐서 어떻게 EJB를 멋있게 쓸 것인가에만 골몰하는 경우가 더 많았습니다.

저도 이부분에 대해서는 매우 동감합니다. EJB를 왜 써야되고 어떤면에서 장점이 있는가를 파악하기보다는 EJB이기 때문에, 뭔가 있어보이기 때문에 쓰는 경우도 적지 않았습니다.

그때문인지 서블릿 수준에서 끝날 웹 어플도 EJB로 개발 하는 경우를 종종 보았구요.

showmethemoney

fender의 이미지

CBD 방법론이나 UML 툴을 써서 설계를 하는 게 유행 비슷한 경향이 된 건 사실입니다. 하지만 CBD는 오히려 객체지향과 충돌하는 부분이 많고, 말씀하신 것처럼 UML이나 케이스툴을 쓰는 것이 곧 객체지향 설계를 하는 것은 아닙니다.

물론 엔터프라이즈 솔루션에서 엔티티의 설계는 매우 중요합니다. 하지만 여기서 말하는 '엔티티'는 절대로 데이터베이스의 테이블을 나타내는 것은 아니며 또한 ERD도 반드시 데이터베이스 스키마를 뜻하지 않습니다.

즉, 탑다운 방식으로 엔티티를 먼저 설계한다는 건 업무 분석 후에 디비 전문가가 ERWin 같은 걸로 디비 스키마를 뽑는 다는 뜻이 아니라 케이스 툴을 쓰건 안쓰건 구현하고자하는 업무의 도메인 모델을 테이블이 아닌 클래스의 관계로 나타내는 작업입니다. 그 이후에 여기에 대한 프로세스를 설계하고 마지막으로 구체적인 퍼시스턴스를 구현하는게 정석입니다.

유일한 예외라면 이미 DB가 기구축되어 있어서 다른 어플리케이션과 공유하는 경우지만 제가 아는 한 대부분의 경우 EJB를 쓰건 안쓰건 국내 웹개발 환경에서 엔티티 설계는 곧 테이블 스키마를 그리는 걸 의미합니다.

국내에서 EJB를 사용할 때 얼마나 스펙과 동떨어져 사용하고 있는지는 단적인 예로 EJB의 대표적인 장점이라고 이야기하는 선언적인 보안, 트랜잭션 처리를 들 수 있습니다. 트랜잭션은 몰라도 제가 아는 한 JAAS를 연동해서 EJB 단까지 보안을 통합해서 정석대로 구축하는 경우는 그렇게 많지 않습니다. 대부분 세션에다가 플래그 박아두고 필터도 아닌 jsp 인클루드에서 조건문으로 거르는게 일반적입니다.

물론 제가 국내의 모든 웹개발자를 만나본건 아니지만 수년간 크고 작은 업체의 많은 개발자들과 접하면서 단 한명도 객체지향적인 설계를 하는 것을 보지 못했다는 건 분명 국내 웹 SI의 어떤 심각한 문제점을 나타내는 것이라 생각합니다.

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

fender의 이미지

kuma wrote:
객체지향이라고 한참 떠벌리고 그게 아니면 죽음을 달라던 시절은 이미 96년도에 지나 갔습니다. 지금은 어떤 방식이 수행 작업에 가장 적절한지 판단해서 사용하는 시대입니다. 모든걸 객체지향이어야 한다는 생각은 이제 그만되었으면 하네요.

동감합니다만 이는 실무에서 개발하는 분들이 실제 객체지향, 컴포넌트 지향 등등의 장단점을 이해하고 케이스별로 가장 적합한 사례를 찾아 적용할 때만 의미가 있지 않을까요? 단순하게 '아는게 데이터베이스밖에 없어서' 객체지향을 못쓰는 것이라면 문제가 있다고 봅니다.

어쨌거나 웹개발에서 많이 쓰이는 자바 언어는 객체지향적 특성을 많이 갖추고 있고 사용하는 라이브러리, 프레임워크, 방법론 등등 모두 객체지향적 원리를 적용했을 때 최상의 생산성을 내도록 구현되어 있는 경우가 많습니다.

물론 유명한 IT 격언에 '내가 가진 도구가 망치 뿐이라면 모든 문제가 다 못으로 보인다'라는 말도 있지만 망치를 쓸 줄 몰라서 톱으로 못을 박으려 하는 것도 올바른 접근은 아닐 것입니다.

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

madhatter의 이미지

fender wrote:

물론 엔터프라이즈 솔루션에서 엔티티의 설계는 매우 중요합니다. 하지만 여기서 말하는 '엔티티'는 절대로 데이터베이스의 테이블을 나타내는 것은 아니며 또한 ERD도 반드시 데이터베이스 스키마를 뜻하지 않습니다.

엔티티가 데이터베이스의 테이블을 나타내는 것이 아니라면 구체적으로 어떤 것을 나타내는 것인지 궁금합니다.

fender wrote:

즉, 탑다운 방식으로 엔티티를 먼저 설계한다는 건 업무 분석 후에 디비 전문가가 ERWin 같은 걸로 디비 스키마를 뽑는 다는 뜻이 아니라 케이스 툴을 쓰건 안쓰건 구현하고자하는 업무의 도메인 모델을 테이블이 아닌 클래스의 관계로 나타내는 작업입니다. 그 이후에 여기에 대한 프로세스를 설계하고 마지막으로 구체적인 퍼시스턴스를 구현하는게 정석입니다.

이건 일반적인 Top-Down 방법론 같습니다. 그리고 제가 아는한 거의 대부분의 Biz proc. 을 구현하는 경우에 있어서는 위와 같은 방법을 씁니다. 클래스의 관계로 나타내는 것은 UML 에서의 용어인 듯 하구요. 업무 플로우 차트와 DFD 등의 프로세스 설계를 거쳐 ERD를 생성해 냅니다.

fender wrote:

유일한 예외라면 이미 DB가 기구축되어 있어서 다른 어플리케이션과 공유하는 경우지만 제가 아는 한 대부분의 경우 EJB를 쓰건 안쓰건 국내 웹개발 환경에서 엔티티 설계는 곧 테이블 스키마를 그리는 걸 의미합니다.

맞습니다. 그런데 UML에서도 엔티티와 어트리뷰트 설계는 곧 테이블 스키마로 연결되지 않던가요? ERD가 곧 테이블 스키마는 아니지만 거의 유사하게 구현되므로 별로 무리가 없는 전개라고 생각합니다.

fender wrote:

국내에서 EJB를 사용할 때 얼마나 스펙과 동떨어져 사용하고 있는지는 단적인 예로 EJB의 대표적인 장점이라고 이야기하는 선언적인 보안, 트랜잭션 처리를 들 수 있습니다. 트랜잭션은 몰라도 제가 아는 한 JAAS를 연동해서 EJB 단까지 보안을 통합해서 정석대로 구축하는 경우는 그렇게 많지 않습니다. 대부분 세션에다가 플래그 박아두고 필터도 아닌 jsp 인클루드에서 조건문으로 거르는게 일반적입니다.

이건 설계에 대한 것이라기 보다는 스펙에서 제공하는 기능을 사용하지 않는다고 보여지네요. 약간 논외의 이야기 같습니다.

lenani의 이미지

그런데 갑자기 생긴 의문인데요.
왜 우리나라에선 객체지향이 이렇게 푸대접을 받는지 모르겠습니다.

제가 아는 사람이 지금 영국에서 공부하고 있는데요.
공부하는 커리큘럼을 보내줬습니다.
그런데 제가 대학때 배우던거랑 많이 다르더군요.

이건 뭐 1학년 때부터 4학년 때까지 전부 객체 지향으로 되어 있던걸요.
중간 중간에 자료 구조, OS, 컴파일러(이건 OS 배울때 같이 배운다고
합니다) 등등을 배우고요.

제가 그래서 '너네 학교는 객체지향만 하냐?'라고 물어봤더니
학교측에서 객체지향을 아주 중요하게 생각한다고 하더라구요.

그런데 왜 우리는 그렇게 객체지향을 중요하게 생각하지 않을까요?
외국이 좋다라는 의미도 아니고 객체지향이 무조건 좋다라는 것도 아닙니다.
그냥 왜 우리나라와 외국의 생각의 차이가 생겼는지 궁금합니다.

lenani의 이미지

madhatter wrote:
fender wrote:

물론 엔터프라이즈 솔루션에서 엔티티의 설계는 매우 중요합니다. 하지만 여기서 말하는 '엔티티'는 절대로 데이터베이스의 테이블을 나타내는 것은 아니며 또한 ERD도 반드시 데이터베이스 스키마를 뜻하지 않습니다.

엔티티가 데이터베이스의 테이블을 나타내는 것이 아니라면 구체적으로 어떤 것을 나타내는 것인지 궁금합니다.

제가 아는 한 DB table과 객체(Entity)는 다른 것입니다.
DB table은 객체의 persistence를 구현하기 위한 하나의
수단일 뿐입니다.
정확하게 1:1로 매치되는 경우도 있지만 그렇지 않은 경우도
많습니다.
1개의 객체가 여러개의 table에 저장될수도 있고 그 반대로
하나의 table이 여러개의 객체와 연관될수도 있습니다.

madhatter wrote:
fender wrote:

즉, 탑다운 방식으로 엔티티를 먼저 설계한다는 건 업무 분석 후에 디비 전문가가 ERWin 같은 걸로 디비 스키마를 뽑는 다는 뜻이 아니라 케이스 툴을 쓰건 안쓰건 구현하고자하는 업무의 도메인 모델을 테이블이 아닌 클래스의 관계로 나타내는 작업입니다. 그 이후에 여기에 대한 프로세스를 설계하고 마지막으로 구체적인 퍼시스턴스를 구현하는게 정석입니다.

이건 일반적인 Top-Down 방법론 같습니다. 그리고 제가 아는한 거의 대부분의 Biz proc. 을 구현하는 경우에 있어서는 위와 같은 방법을 씁니다. 클래스의 관계로 나타내는 것은 UML 에서의 용어인 듯 하구요. 업무 플로우 차트와 DFD 등의 프로세스 설계를 거쳐 ERD를 생성해 냅니다.

또 Top-Down 방식과 객체지향적 구현 절차에 대해서 제 의견을 말하자면,
이 둘이 상당히 비슷해 보이는 것이 사실입니다.
실제로 정보 공학과 객체 지향은 서로 밀접한 관련이 있습니다.
하지만 가장 큰 차이점은 프로그램의 구성 요소로서 객체를 생각하느냐
구체적인 DB table을 생각하느냐 입니다.

madhatter wrote:
fender wrote:

유일한 예외라면 이미 DB가 기구축되어 있어서 다른 어플리케이션과 공유하는 경우지만 제가 아는 한 대부분의 경우 EJB를 쓰건 안쓰건 국내 웹개발 환경에서 엔티티 설계는 곧 테이블 스키마를 그리는 걸 의미합니다.

맞습니다. 그런데 UML에서도 엔티티와 어트리뷰트 설계는 곧 테이블 스키마로 연결되지 않던가요? ERD가 곧 테이블 스키마는 아니지만 거의 유사하게 구현되므로 별로 무리가 없는 전개라고 생각합니다.

제 생각에는 UP에서 바로 객체가 스키마로 전환되는 경우는 없습니다.
뭐 객체를 저장할 구조로 그렇게 구현하기로 했다면 그대로 전환해도
별 무리는 없습니다.

fender의 이미지

madhatter wrote:
엔티티가 데이터베이스의 테이블을 나타내는 것이 아니라면 구체적으로 어떤 것을 나타내는 것인지 궁금합니다.
......
맞습니다. 그런데 UML에서도 엔티티와 어트리뷰트 설계는 곧 테이블 스키마로 연결되지 않던가요? ERD가 곧 테이블 스키마는 아니지만 거의 유사하게 구현되므로 별로 무리가 없는 전개라고 생각합니다.

대부분의 EJB 컨테이너가 배포시에 엔티티빈에 맞춰서 테이블을 생성해 주고 Hibernate와 같은 많은 수의 퍼시스턴스 프레임워크도 유사한 기능을 갖추고 있습니다. 즉, 탑다운 방식에서 데이터베이스란 단순히 데이터를 지속적으로 저장하는 장치 이상도 이하도 아님을 뜻합니다.

객체지샹 설계에서 ('UML에서'보다는 정확한 표현인 것 같습니다. 객체지향이 반드시 UML로 표기될 필요는 없으니까요 :)) 클래스의 관계로 나타난 도메인 모델이 어떤 형식으로든 퍼시스턴트 레이어에 매핑되어야 한다는 건 맞지만 여기에는 여러가지 문제점이 있습니다.

OODBMS가 아닌 이상 특히 엔티티의 상속관계(테이블이 테이블을 상속할 수 없습니다)나 1:n의 관계(FK-PK 관계는 n:1, n:m만 허용합니다), 네비게이션을 다양하게 표현할 수 없는 것 (테이블에서는 무조건 FK가 있는 쪽에서의 네비게이션만 가능합니다) 등등의 문제가 있고 이는 전통적으로 'impedence mismatch'라는 문제로 알려져 있습니다.

외국에서는 탑다운 접근 방식을 유지하면서 이런 문제를 해결하기 위해 DAO 패턴이나 O/R 매핑 솔루션, JDO/EJB 등을 고안해 냈습니다. 하지만 기본적으로 데이터베이스 스키마에서 bottom-up으로 올라오는 경우 사실상 데이터베이스 연결 관련 유틸 클래스를 제외하면 이런 '부가적'인 계층에 대한 필요를 느끼지 않는 다는 차이가 있습니다.

최근에 UML이나 MDA(모델 드리븐 아키텍쳐/어프로치) 등등이 유행하지만 이런 모든 방식은 탑다운으로 도메인 모델을 완성한 후 여기에 대한 퍼시스턴스 레이어를 얼마나 쉽고 투명하게 만들어줄 수 있나 하는데 초점이 맞추어져 있지 어떻게하면 데이터베이스 위에 상부구조를 얹을 수 있는지에 있지 않습니다.

후자의 경우라면 투게더 등의 유명 케이스툴의 UI는 클래스다이어그램에서 출발하는게 아니라 데이터베이스 테이블의 컬럼들을 선택해서 이를 클래스로 표현하는 식이 되어야 맞겠지요 (실제 이런 툴들이 있기는 합니다만...)

이런 추세에서는 데이터베이스 전문가는 어디까지나 솔루션 전체의 설계를 담당하는 사람이 아니라 객체지향에 능숙한 설계자가 O/R 매퍼를 통해 자동으로 생성한 디비 스키마를 다듬고 튜닝하는 전문가로 역할이 제한됩니다. 이런 부분이 상향식과 하향식 개발 방법론, 그리고 디비 중심적, 혹은 객체지향적 접근 방법의 근본적인 차이점이라고 봅니다.

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

madhatter의 이미지

lenani wrote:
제가 아는 한 DB table과 객체(Entity)는 다른 것입니다.
DB table은 객체의 persistence를 구현하기 위한 하나의
수단일 뿐입니다.
정확하게 1:1로 매치되는 경우도 있지만 그렇지 않은 경우도
많습니다.
1개의 객체가 여러개의 table에 저장될수도 있고 그 반대로
하나의 table이 여러개의 객체와 연관될수도 있습니다.

또 Top-Down 방식과 객체지향적 구현 절차에 대해서 제 의견을 말하자면,
이 둘이 상당히 비슷해 보이는 것이 사실입니다.
실제로 정보 공학과 객체 지향은 서로 밀접한 관련이 있습니다.
하지만 가장 큰 차이점은 프로그램의 구성 요소로서 객체를 생각하느냐
구체적인 DB table을 생각하느냐 입니다.

그리고 또 한가지 제 의견을 말하겠습니다.
UP에서 바로 객체가 스키마로 바로 전환되는 경우는 없습니다.
뭐 객체를 저장할 구조로 그렇게 구현하기로 했다면 그대로 전환해도
별 무리는 없습니다.

물론 "엔티티가 곧 테이블이다. " 는 저도 틀린 말이라고 생각합니다. 하지만 ERD를 그려대는 것이 곧 테이블 설계부터 하는 것이라는 논리에서 의문이 생겨서 설명을 부탁드린 것입니다. 그렇기는 해도 실제 구현에 있어서는 거의 엔티티가 그대로 테이블로 생성되는 경우가 많습니다.그리고 제가 하고 싶은 말도 UML등의 툴을 쓰는 것은 CBD등의 컴포넌트 기반, 즉 객체지향 방법론에 적합하지 Top-Down 은 오히려 구조적인 프로그래밍을 많이 쓰는 고전적인 방법론이라는 것입니다.

여담입니다만, 엔티티는 객체 지향에서 말하는 객체가 아니라 고전적 의미의 어트리뷰트를 갖는 개체이겠지요? 객체 혹은 개체(Object)와 개체(entity)의 의미가 섞여서 표현된 것 같아 덧붙입니다.

madhatter의 이미지

fender wrote:
madhatter wrote:
엔티티가 데이터베이스의 테이블을 나타내는 것이 아니라면 구체적으로 어떤 것을 나타내는 것인지 궁금합니다.
......
맞습니다. 그런데 UML에서도 엔티티와 어트리뷰트 설계는 곧 테이블 스키마로 연결되지 않던가요? ERD가 곧 테이블 스키마는 아니지만 거의 유사하게 구현되므로 별로 무리가 없는 전개라고 생각합니다.

대부분의 EJB 컨테이너가 배포시에 엔티티빈에 맞춰서 테이블을 생성해 주고 Hibernate와 같은 많은 수의 퍼시스턴스 프레임워크도 유사한 기능을 갖추고 있습니다. 즉, 탑다운 방식에서 데이터베이스란 단순히 데이터를 지속적으로 저장하는 장치 이상도 이하도 아님을 뜻합니다.

객체지샹 설계에서 ('UML에서'보다는 정확한 표현인 것 같습니다. 객체지향이 반드시 UML로 표기될 필요는 없으니까요 :)) 클래스의 관계로 나타난 도메인 모델이 어떤 형식으로든 퍼시스턴트 레이어에 매핑되어야 한다는 건 맞지만 여기에는 여러가지 문제점이 있습니다.

OODBMS가 아닌 이상 특히 엔티티의 상속관계(테이블이 테이블을 상속할 수 없습니다)나 1:n의 관계(FK-PK 관계는 n:1, n:m만 허용합니다), 네비게이션을 다양하게 표현할 수 없는 것 (테이블에서는 무조건 FK가 있는 쪽에서의 네비게이션만 가능합니다) 등등의 문제가 있고 이는 전통적으로 'impedence mismatch'라는 문제로 알려져 있습니다.

외국에서는 탑다운 접근 방식을 유지하면서 이런 문제를 해결하기 위해 DAO 패턴이나 O/R 매핑 솔루션, JDO/EJB 등을 고안해 냈습니다. 하지만 기본적으로 데이터베이스 스키마에서 bottom-up으로 올라오는 경우 사실상 데이터베이스 연결 관련 유틸 클래스를 제외하면 이런 '부가적'인 계층에 대한 필요를 느끼지 않는 다는 차이가 있습니다.

최근에 UML이나 MDA(모델 드리븐 아키텍쳐/어프로치) 등등이 유행하지만 이런 모든 방식은 탑다운으로 도메인 모델을 완성한 후 여기에 대한 퍼시스턴스 레이어를 얼마나 쉽고 투명하게 만들어줄 수 있나 하는데 초점이 맞추어져 있지 어떻게하면 데이터베이스 위에 상부구조를 얹을 수 있는지에 있지 않습니다.

후자의 경우라면 투게더 등의 유명 케이스툴의 UI는 클래스다이어그램에서 출발하는게 아니라 데이터베이스 테이블의 컬럼들을 선택해서 이를 클래스로 표현하는 식이 되어야 맞겠지요 (실제 이런 툴들이 있기는 합니다만...)

이런 추세에서는 데이터베이스 전문가는 어디까지나 솔루션 전체의 설계를 담당하는 사람이 아니라 객체지향에 능숙한 설계자가 O/R 매퍼를 통해 자동으로 생성한 디비 스키마를 다듬고 튜닝하는 전문가로 역할이 제한됩니다. 이런 부분이 상향식과 하향식 개발 방법론, 그리고 디비 중심적, 혹은 객체지향적 접근 방법의 근본적인 차이점이라고 봅니다.

아무래도 논의에 있어서 여러가지 개념이 불분명하게 섞여서 논지가 흐려지는 듯 합니다. 처음 시작된 것은 객체 지향이 적용되고 있느냐였는데, 워낙 그 범위가 불명확하다 보니 객체 지향적인 개발 방법론(CBD나 Use-Case tool등과 Top-Down, ERD 등의 차이), 객체 지향적 플랫폼 사용(EJB가 제대로 사용되는가), 객체 지향 DB(DAO패턴,OODB와 RDB의 차이)까지 나오고 있는 것 같습니다. :)

기본적으로 impedence mismatch 에 대한 문제는 RDB에서의 경우로 알고 있습니다. 이건 개발 방법론과는 거리가 있는 이야기입니다. 솔루션에 디펜던트한 경우이고 DB 설계에 국한되는 이야기입니다.

C로도 OOP를 할 수 있듯이 RDB로도 객체 지향 방법론에 따른 개발이 가능합니다. 거꾸로 Top-Down 방식으로도 class 설계를 거친 객체 지향형 시스템 개발이 가능합니다. 예를 들어 기업에서의 Web 서비스 개발은 보통 J2EE 가 대세를 이루고 있기 때문에 EJB를 사용해서 객체 지향적인 시스템을 개발하려고 하나 방법론은 고전적인 것을 사용할 수 있습니다. 아무래도 문제 제기 하신 분이 어떤 개념으로 객체 지향이 우리 나라에서 이루어지고 있는가 명확하게 구분하지 않으신 게 이렇게 동어반복적인 논의를 만들고 있다고 생각 되네요. :)

덧. ERD는 테이블 설계가 아니라 entity 설계인데 왜 처음에 데이타 베이스 전문가가 ERD부터 그리며 테이블 설계를 한다고 하셨는지 궁금네요. 그리고 DB 전문가와 DBA는 반드시 같은 영역이 아니라고 생각합니다. DB 스키마와 튜닝에 대한 전문가도 있고 데이타 베이스 모델링을 하는 전문가는 엔티티 설계의 전문가라고 생각합니다. 그리고 객체 지향이던 구조적이던 전문가를 구분할 필요는 없다고 생각합니다. 넓은 의미에서 "설계" 이고 어떤 "방법론"을 적용하는가를 고민하는 것이 설계자가 아닐런지요.

lenani의 이미지

동감입니다.
UML은 객체지향 방법론이 난립하던 시절 표기법의 난립을 하나로 통합한
일종의 규격안 입니다.
뭐 UML을 구조적 분석/설계에 쓸수 없는 것은 아니지만 아무래도 객체지향
방법론에 맞춰진 도구입니다.

madhatter wrote:

여담입니다만, 엔티티는 객체 지향에서 말하는 객체가 아니라 고전적 의미의 어트리뷰트를 갖는 개체이겠지요? 객체 혹은 개체(Object)와 개체(entity)의 의미가 섞여서 표현된 것 같아 덧붙입니다.

음...
정보 공학측과 객체지향측의 사용하는 언어가 좀 틀립니다.
저는 UML에서 사용되는 Boundary/Control/Entity, 이렇게 3개의
기본적인 stereo type중 하나인 Entity를 말한 것입니다.
저는 객체(Object)를 말했는데 혹시나 개체로 받아들이신건 아닌지요?

fender의 이미지

음... 구체적인 예를 드는게 서로 간의 이해를 도울 수 있을 것 같네요 :)

최근 추세는 무엇보다 도메인 모델이나 비즈니스 로직을 설계할 때 가능하면 외부 컨테이너나 어떤 특정 인터페이스를 구현해야 한다는 등의 의존성을 제거하고 순수하게 객체지향에 근거한 일반 클래스(자바에서는 POJO - Plain Old Java Object라고 합니다)를 사용해서 설계하는 것입니다.

왜 이런 경향이 생겼는지 살펴보면, 예를들어 EJB 엔티티빈을 사용하려면 원격 호출을 위해 반드시 빈 클래스 이외에도 홈인터페이스, 원격 혹은 로컬 인터페이스를 만들어야 하며 이들은 J2EE의 특정 인터페이스를 상속해야 합니다. 또한 이러한 엔티티빈 객체를 웹에서 직접 불러들이는 것은 여러가지 이유로 적합하지 않기 때문에 Session Facade나 Bulk Load 등등의 방식으로 실제 엔티티에 대응하는 도메인 클래스를 다시 만들어 변환합니다.

이런 방식에서는 다음과 같은 문제가 있습니다 :
(1) 개발이 불필요하게 복잡해 집니다
(2) 배치 디스크립터 등 벤더 종속적 의존성이 생깁니다
(3) 실제 도메인 클래스들 간에는 상속 관계가 있을 수 있어도 이에 대응하는 엔티티빈은 CBD의 특성상 상속 관계가 나오기 어렵습니다
(4) XP에서 권장하는 유닛테스트의 경우 엔티티빈은 반드시 컨테이너에서 동작하기 때문에 단순한 방법으로 유닛테스트를 적용하기 어렵습니다.

다시 본론으로 돌아가서, 이런 문제를 극복하기 위해 나온 경량 컨테이너/퍼시스턴스 프레임워크의 대표적인 스프링/하이버네이트의 조합을 예로 들겠습니다.

(1) 어떠한 종속성도 없이 순수하게 요구사항에 대한 도메인 모델을 일반 클래스로 구현합니다. UML 기반 CASE 툴이나 MDA를 지원하는 툴을 사용하면 자동으로 생성할 수도 있습니다.

(2) (1)의 결과물인 도메인 모델을 바탕으로 데이터베이스 스키마와 실제 테이블을 자동 생성합니다. 이의 결과물은 데이터베이스 전문가에게 넘겨 튜닝작업을 병행합니다.

(3) (1)의 도메인 모델을 사용하는 비즈니스 계층을 역시 의존성없는 일반 클래스로 구현합니다. 트랜잭션이나 퍼시스턴스에 필요한 세션 등등의 모든 리소스는 외부에서 IOC(Inversion of Control)의 방식으로 제공하기 때문에 코드 자체에 의존성은 불필요합니다.

(4) (1) + (3)으로 구성된 백엔드 어플리케이션에 웹단의 프론트 엔드를 제작합니다, 주로 Struts 등의 MVC 구성을 이용합니다.

이런 방식이 최근에 유행하는 웹개발의 best practice이고 보시다시피 철저하게 탑다운 접근 방식이 중시되고 있습니다.

반면에 우리나라의 전통적(?) 접근 방식을 보겠습니다 :

(1) 데이터베이스 전문가가 ERD를 그립니다.
(2) 사용할 데이터베이스에 맞는 커넥션 관련 유틸 클래스를 제작합니다.
(3) 각각의 비즈니스 로직을 위해 적절한 SQL 쿼리를 날리고 생성 결과를 반환하는 클래스를 작성합니다.
(4) (3)을 이용해 jsp 페이지를 만듭니다.

일부의 경우 (3)과 (4) 사이에 그나마 객체지향적 접근을 위해 쿼리를 담을 수 있는 모델을 설계하기도 하지만 많은 경우에 문자열 배열이나 벡터 혹은 맵에 다 때려 담아 넘기는 등의 구현도 많습니다. 이 경우 아예 '도메인 모델'이란 개념 자체가 없는 설계지만 설사 이런 중간단계의 모델을 설계 했다고 해도 탑다운에 비해 명확한 제약이 있습니다.

즉, 모델이 나타내는 건 직접적인 비즈니스 요구사항(requirement)가 아닌 특정 쿼리에 대한 결과 집합입니다. 즉, 비즈니스 로직과 엔티티는 테이블 스키마와 이에 대한 SQL 쿼리가 표현하는 반면, 실제 사용되는 클래스는 단순히 이 결과 값을 전달하기 위한 도구에 지나지 않습니다. 따라서 SQL이나 디비 스키마가 상속이나 클래스의 다양한 관계를 표현할 수 없는 이상 여기에 대한 모델 역시 동일한 문제를 지닙니다.

또한 비즈니스 로직이 SQL로 표현되는 관계로 쿼리가 복잡해지고 데이터베이스 벤더에 종속적이 될 수 있습니다.

EJB를 쓴다고 해도 이런 모델에 적용하면, 데이터베이스와 코드 사이에 단지 복잡한 계층을 덧붙여 생산성을 떨어뜨리는 결과 이상을 기대하기 어렵습니다.

대부분의 CASE 툴이 UML, 그 중에서도 클래스다이어그램을 중심으로 구성되어 있다는 점만 봐도 이런 객체지향적인 탑다운 접근 방식의 이점을 잘 알 수 있지 않나 생각합니다...

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

fender의 이미지

madhatter wrote:
기본적으로 impedence mismatch 에 대한 문제는 RDB에서의 경우로 알고 있습니다. 이건 개발 방법론과는 거리가 있는 이야기입니다. 솔루션에 디펜던트한 경우이고 DB 설계에 국한되는 이야기입니다.

impedance mismatch는 솔루션에 국한된 이야기라기 보다는 RDBMS를 객체지향언어로 다루는 이상 피할 수 없는 문제입니다. 다만 탑다운이 아니라 데이터베이스 중심적인 설계를 할 때 그 문제점이 더 극명히 드러날 뿐입니다.

madhatter wrote:
덧. ERD는 테이블 설계가 아니라 entity 설계인데 왜 처음에 데이타 베이스 전문가가 ERD부터 그리며 테이블 설계를 한다고 하셨는지 궁금네요. 그리고 DB 전문가와 DBA는 반드시 같은 영역이 아니라고 생각합니다. DB 스키마와 튜닝에 대한 전문가도 있고 데이타 베이스 모델링을 하는 전문가는 엔티티 설계의 전문가라고 생각합니다.

실제로 국내에선 ERD 설계는 거의 90% 데이터베이스 스키마 설계를 의미하기 때문입니다. 아직 ERD 달라고 했을 때 디비스키마 이외에 다른 산출물을 제시하는 경우는 못봤습니다 :)

DB 전문가와 DBA는 물론 다릅니다. 하지만 튜닝등의 분야가 아니라 데이터베이스 모델링 자체만 놓고 본다면 점차 비중이 떨어지는 추세에 있는 것만은 분명합니다. 이런 시대의 변화가 바로 탑다운으로 도메인 모델에서 자동으로 퍼시스턴트를 관리하는 설계가 늘어나기 때문이 아닌가 싶네요...

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

lenani의 이미지

글이 밀려서 어뚱한 곳에 글을 올리게 되었습니다.
급히 읽으시는 분이 계시면 마치 조선일보식 처럼
엉뚱하게 받아들일수도 있겠는데요? :lol:

객체의 중요한 특성(?)중 하나가 persistence 입니다.
어떻게 객체의 속성(attribute)를 프로그램이 끝난후 또는
다른 위치에서도 유지할수 있는가가 객체지향의 주요
논의점중 하나였습니다.
그래서 ODMG(Object Data Management Group)가 생겨나게
되었습니다.

이제는 그 결과 Hibernate, JDO, Turbin 등등 수많은 도구들이
생겨났습니다.
아참 EJB는 종합선물세트지만 어쨌든 EJB도 여기에 속한다고 할수
있습니다.

지금 이야기의 흐름이 주제와 벗어나긴 했지만 중요한 주제를
다루고 있다고 생각합니다.

저도 사실은 이야기의 주제를 바꿔보고자 중간에 글을 하나 썼는데요.
그냥 위로 쭉 올라가 버리고 말았습니다.

어떻게 하는게 좋을까요?
원래의 주제로 돌아가는게 좋을까요?
아니면 지금의 것으로 하는게 좋을까요?

madhatter의 이미지

자꾸 드는 의문입니다만, CBD 는 EJB의 특성이고 Top-Down 개발 방식이 객체 지향 개발 방법론에 쓰인다고 하셨는데요, CBD 방법론 자체가 바로 클래스 다이어그램을 중심으로 개발하는 방법론으로 알고 있었는데 어떻게 된 일인지요.

두번째 예시에서 ERD부터 그린다고 하셨습니다만...객체 지향 방법론을 쓰지 않는 경우에도 ERD부터 그리지는 않습니다. User request 에 대한 Biz Logic 분석을 위해 플로우 차트부터 생성을 하고 거기에서 DFD를 그린 후에 프로세스별 엔티티를 정의하고 통합하여 릴레이션을 생성해 나갑니다. 이 부분이 ERD 작성입니다. SQL 쿼리에 Biz Logic을 담을 수도 있지만, 순수히 Table로 정의되는 logic 외의 것은 function을 정의하여 묶을 수도 있고 나름대로 class를 정의하여 사용하기도 합니다. 이것이 사용하는 접근 방식이 다를뿐 유스케이스 다이어그램부터 시작하는 것과 비교할 때 Top-Down이라고 하지 못할 이유는 없다고 봅니다. 제가 알기로 다양한 User Requirement에보다 유동적으로 대응할 수 있고 관계를 쉽게 파악할 수 있는 모델이 Use-Case Diagram 일 뿐이지 고전적 방법론이 ERD부터 그려나가는 거라고는 알고 있지 않습니다.

fender의 이미지

lenani wrote:
객체의 중요한 특성(?)중 하나가 persistence 입니다.
어떻게 객체의 속성(attribute)를 프로그램이 끝난후 또는
다른 위치에서도 유지할수 있는가가 객체지향의 주요
논의점중 하나였습니다.

'Persistence'라는 말 자체가 객체지향적인 사고와 데이터베이스 중심적 사고의 간극을 잘 나타내고 있는게 아닐지요... 실제 실무에서 교육을 할 때 개발자에게 'persistence'라는 개념을 이해시키는 것보다 어려운 점은 없습니다.

디비 중심에 익숙해지면 웹단에서 디비에 있는 걸 끌어와서 보여주고 반대로 입력한 걸 넣어주면 되는거 아니냐? 도대체 왜 복잡하게 별도의 계층이 필요하냐?라고 반문 하는 경우가 많습니다.

그런 경우 저는 데이터베이스 없이 클래스로만 게시판 프로그램을 짜보라고 권합니다. Board 클래스를 만들고 Thread, Message 등등의 클래스와 이를 연동하는 BoardManager를 만들게 한 후 "이렇게 구현했을 때 JVM이 종료하면 Board나 Thread 등등의 인스턴스가 사라진다. 바로 이 문제를 해결하는 것이 persistence이다"라고 설명하면 이해가 빠른 것 같습니다 :)

음.. 그리고 쓰레드에 대한 문제는 주제가 크게 벗어나지 않으면 어차피 많은 사람들이 토론을 하는 주제도 아니니 굳이 별도의 쓰레드를 달 필요는 없을 것 같다는 생각입니다.

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

madhatter의 이미지

fender wrote:

실제로 국내에선 ERD 설계는 거의 90% 데이터베이스 스키마 설계를 의미하기 때문입니다. 아직 ERD 달라고 했을 때 디비스키마 이외에 다른 산출물을 제시하는 경우는 못봤습니다 :)

앗..저도 하고픈 말 한마디만 하겠습니다. 물론 개인적인 경험에서 우러나온 것입니다. UML tool 써서 Use-Case Diagram 설계 후에 entity까지 유도해서 class 까지 스크립트로 생성시켜 바로 사용할 수 있는 경우는 못봤습니다. 거의 90% class는 재 설계를 해야되더군요. :)

ERD는 테이블 스키마가 아닌데 ERD 달라면 테이블 스키마 준다. 그러므로 설계부터 ERD 그리는 건 테이블 설계부터 하려는 데이타 베이스 중심의 사고방식이다. - 제가 맞게 이해한 것인가요?

fender의 이미지

madhatter wrote:
자꾸 드는 의문입니다만, CBD 는 EJB의 특성이고 Top-Down 개발 방식이 객체 지향 개발 방법론에 쓰인다고 하셨는데요, CBD 방법론 자체가 바로 클래스 다이어그램을 중심으로 개발하는 방법론으로 알고 있었는데 어떻게 된 일인지요.

CBD는 클래스 다이어그램을 중심으로 개발하는 것이 아니라 OOP에 비해 상속이라던지 하는 언어 자체의 특성보다는 생산성을 위해 별도로 정의한 규격을 따르는 컴포넌트를 중심에 놓고 생각하는 접근 방법입니다. COM이나 EJB 등등이 대표적인 CBD에 해당하는데, 이들 모델이 OOP와 구분되는 점은 컴포넌트 사이의 결합니 상대적으로 '느슨하다'는 점입니다. 즉 자동차를 만든다면 추상화된 엔진을 구현해서 구체적인 엔진을 만들고 4륜구동을 구현해서 지프를 만드는 식이 아니라 부품 업체에서 완제품인 문짝과 엔진 등등을 구입해서 조립하는 방식입니다.

따라서 클래스다이어그램이나 CASE 툴은 오히려 후자보다 전자의 방식에 더 적합합니다.

madhatter wrote:
두번째 예시에서 ERD부터 그린다고 하셨습니다만...객체 지향 방법론을 쓰지 않는 경우에도 ERD부터 그리지는 않습니다. User request 에 대한 Biz Logic 분석을 위해 플로우 차트부터 생성을 하고 거기에서 DFD를 그린 후에 프로세스별 엔티티를 정의하고 통합하여 릴레이션을 생성해 나갑니다. 이 부분이 ERD 작성입니다. SQL 쿼리에 Biz Logic을 담을 수도 있지만, 순수히 Table로 정의되는 logic 외의 것은 function을 정의하여 묶을 수도 있고 나름대로 class를 정의하여 사용하기도 합니다. 이것이 사용하는 접근 방식이 다를뿐 유스케이스 다이어그램부터 시작하는 것과 비교할 때 Top-Down이라고 하지 못할 이유는 없다고 봅니다. 제가 알기로 다양한 User Requirement에보다 유동적으로 대응할 수 있고 관계를 쉽게 파악할 수 있는 모델이 Use-Case Diagram 일 뿐이지 고전적 방법론이 ERD부터 그려나가는 거라고는 알고 있지 않습니다.

약간 제 생각을 전달하는 과정에 문제가 있었던 것 같습니다. 요구사항 수집을 제외하면 오히려 탑다운이던 아니던 ERD 부터 접근하는게 일반적입니다. 문제는 그 ERD가 클래스 사이의 관계로 표현되는지 테이블 스키마로 표현되는지가 아닐까요?

그리고 어떤 독립적인 기능(펑션)의 묶음이 클래스가 되는 것은 객체지향적인 특성은 아닙니다. 물론 유틸클래스도 존재하지만 객체지향적인 특성은 속성과 동작이 합쳐져 그 자체로 비즈니스 로직을 나타낼 때 의미가 있는게 아닌지요...

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

fender의 이미지

madhatter wrote:
ERD는 테이블 스키마가 아닌데 ERD 달라면 테이블 스키마 준다. 그러므로 설계부터 ERD 그리는 건 테이블 설계부터 하려는 데이타 베이스 중심의 사고방식이다. - 제가 맞게 이해한 것인가요?

넵. 문제는 제 경험상 실제로 실무에서 대부분의 경우 초기 접근을 RDBMS의 테이블 스키마를 그린다는데 있다는 뜻이었습니다.

즉, 요구사항 수집도 안하고 엔티티부터 그린다는게 아니라 엔티티 설계는 곧 RDBMS 설계라고 동일시하는 관행을 이야기 한 것입니다.

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

lenani의 이미지

madhatter wrote:
자꾸 드는 의문입니다만, CBD 는 EJB의 특성이고 Top-Down 개발 방식이 객체 지향 개발 방법론에 쓰인다고 하셨는데요, CBD 방법론 자체가 바로 클래스 다이어그램을 중심으로 개발하는 방법론으로 알고 있었는데 어떻게 된 일인지요.

두번째 예시에서 ERD부터 그린다고 하셨습니다만...객체 지향 방법론을 쓰지 않는 경우에도 ERD부터 그리지는 않습니다. User request 에 대한 Biz Logic 분석을 위해 플로우 차트부터 생성을 하고 거기에서 DFD를 그린 후에 프로세스별 엔티티를 정의하고 통합하여 릴레이션을 생성해 나갑니다. 이 부분이 ERD 작성입니다. SQL 쿼리에 Biz Logic을 담을 수도 있지만, 순수히 Table로 정의되는 logic 외의 것은 function을 정의하여 묶을 수도 있고 나름대로 class를 정의하여 사용하기도 합니다. 이것이 사용하는 접근 방식이 다를뿐 유스케이스 다이어그램부터 시작하는 것과 비교할 때 Top-Down이라고 하지 못할 이유는 없다고 봅니다. 제가 알기로 다양한 User Requirement에보다 유동적으로 대응할 수 있고 관계를 쉽게 파악할 수 있는 모델이 Use-Case Diagram 일 뿐이지 고전적 방법론이 ERD부터 그려나가는 거라고는 알고 있지 않습니다.

비록 형태는 비슷하지만 프로그램의 구성 요소로 보는 것이 다릅니다.
그래서 비 객체지향에서 객체지향으로 전환시에 어떤 관점의 변화
(paradime shift)가 필요하다고 객체지향의 전문가가 어떤 책에서 쓴걸
본적이 있습니다.
저도 그의 생각에 동의하구요.

사실 ERD부터 그리는 것은 나쁜 것 입니다.
마치 기본적인 분석/설계도 하지 않고 바로 코딩에 들어가는 것 처럼 말입니다.
구조적 분석/설계, 정보 공학쪽에서도 그렇게는 하지 않습니다.

저는 정보 공학도 좋아하고 구조적 분석/설계도 좋아합니다.
그리고 객체지향적 방법론도 좋아합니다.
모두들 다 장점과 단점을 가지고 있기 때문에 어떤 특정한 상황에
써야지 최대의 효과를 얻을수 있습니다.

구조적 분석/설계에서는 절대 ERD 부터 그리는 것을 추천한적도 없고
그렇게 하지 말라고 반대하는 입장에 있습니다.
fender님도 아마 이 말에는 적극 찬성할 것입니다.

하지만 실무에서는 그렇지 않은 경우를 몇번 본적이 있습니다.
당장 납기일에 맞춰야 한다는 명분으로 그런 프로그램 개발 단계를
간단히 skip해 버리더군요.

fender님은 아마도 이런 현실에 대해서 말했을 거라고 생각합니다.
그리고 절대로 구조적 분석/설계에서 ERD 부터 먼저 그리지 않습니다.
적극 동감합니다.

madhatter의 이미지

fender wrote:

약간 제 생각을 전달하는 과정에 문제가 있었던 것 같습니다. 요구사항 수집을 제외하면 오히려 탑다운이던 아니던 ERD 부터 접근하는게 일반적입니다. 문제는 그 ERD가 클래스 사이의 관계로 표현되는지 테이블 스키마로 표현되는지가 아닐까요?

그리고 어떤 독립적인 기능(펑션)의 묶음이 클래스가 되는 것은 객체지향적인 특성은 아닙니다. 물론 유틸클래스도 존재하지만 객체지향적인 특성은 속성과 동작이 합쳐져 그 자체로 비즈니스 로직을 나타낼 때 의미가 있는게 아닌지요...

요구 사항 수집 과정 후 설계과정에서 바로 ERD로 들어가지 않는다는 의미입니다. 만약 그렇게 하는 설계자가 있다면 그건 방법론을 '잘못' 적용한 것이지 방법론 자체가 잘못됐다고 보긴 어렵습니다.

그리고 펑션 묶음이 클래스가 된다는 의미가 아니라 펑션 묶음을 사용할 수도 있고(이건 util 적 성격의 모듈이 되겠지요. 혹은 Stored Procedure가 될 수도 있겠구요.) class 를 설계하여 사용할 수도 있다는 의미였습니다. 물론 어트리뷰트와 method를 포함하고 있어야 class의 기본 요건을 만족한다라는 기초 개념은알고 있습니다. :)

lenani의 이미지

한참 타자쳐서 글을 올리면 위로 쭉 올라가 있더군요. :P

그런데 왜 우리나라에서는 객체지향을 쓰지 않게 된거죠?

fender의 이미지

madhatter wrote:
요구 사항 수집 과정 후 설계과정에서 바로 ERD로 들어가지 않는다는 의미입니다. 만약 그렇게 하는 설계자가 있다면 그건 방법론을 '잘못' 적용한 것이지 방법론 자체가 잘못됐다고 보긴 어렵습니다.

동의합니다. 하지만 이해하셨겠지만 제가 지적하고 싶은 부분은 위에서 말한 'persistence'를 이해하는지 그렇지 않은지에 대한 부분입니다.

즉, madhatter님께서는 게시판을 구현하기 위해서 '게시판', '게시물', '쓰레드', '사용자' 등등의 클래스를 먼저 구현하고 여기에 대해 퍼시스턴스 계층을 추가하는 개발자를 몇 명이나 보셨나요? 반대로 MESSAGE, BOARD, USER 테이블을 먼저 생성하고 이에 대한 쿼리 날리는 클래스를 얹는 경우가 훨신 일반적이지 않았나요? 별 차이가 아니라고 생각하실 수 있지만 이는 근본적인 패러다임의 차이입니다. 이 부분은 이야기가 나오면 더 설명 드리겠습니다 :)

madhatter wrote:
그리고 펑션 묶음이 클래스가 된다는 의미가 아니라 펑션 묶음을 사용할 수도 있고(이건 util 적 성격의 모듈이 되겠지요. 혹은 Stored Procedure가 될 수도 있겠구요.) class 를 설계하여 사용할 수도 있다는 의미였습니다. 물론 어트리뷰트와 method를 포함하고 있어야 class의 기본 요건을 만족한다라는 기초 개념은알고 있습니다. :)

넵 :)

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

madhatter의 이미지

lenani wrote:
한참 타자쳐서 글을 올리면 위로 쭉 올라가 있더군요. :P

그런데 왜 우리나라에서는 객체지향을 쓰지 않게 된거죠?

"부분적으로 쓰고 있다." 라고 말씀드리겠습니다. 실제 SI에서 가장 큰 문제는 솔루션도 아니고 개발 방법론도 아닌 "납기" 입니다. 그리고 Client 의 요구사항은 하루가 다르게 변화합니다. 거기에 겹쳐서 개발자들의 "객체 지향"에 대한 인식이 천차 만별인 것도 있습니다. 그 이유로 보자면 IT라는 영역이 진입장벽이 낮은 것에서부터 시작할 수도 있겠습니다만..그건 길어지니 논외로 하고, 현실적으로 다양한 requirement를 충족시킬만한 객체 지향 설계를 능숙하게 할 인력이 부족하다고 봅니다.

구조적 접근도 이상적으로 되지 않는데 객체 지향적 접근이 이상적으로 될 수는 없는 것 아닐까요?

madhatter의 이미지

fender wrote:

즉, madhatter님께서는 게시판을 구현하기 위해서 '게시판', '게시물', '쓰레드', '사용자' 등등의 클래스를 먼저 구현하고 여기에 대해 퍼시스턴스 계층을 추가하는 개발자를 몇 명이나 보셨나요? 반대로 MESSAGE, BOARD, USER 테이블을 먼저 생성하고 이에 대한 쿼리 날리는 클래스를 얹는 경우가 훨신 일반적이지 않았나요? 별 차이가 아니라고 생각하실 수 있지만 이는 근본적인 패러다임의 차이입니다. 이 부분은 이야기가 나오면 더 설명 드리겠습니다 :)

음, 확실히 이건 패러다임의 차이이겠네요. 하지만 제가 본 대부분의 개발자는 테이블에 대한 개념이 없습니다. UI의 액션에 대한 개념만 있습니다. 클래스를 먼저 생각한다기 보다는 UI 설계를 먼저 하고 그 구현을 위한 class 를 생성한 다음 필요한 데이타를 넣기 위한 도구로 DB를 생각합니다. 어떤 개발자는 그러더군요.

"필요한 칼럼이 A,B,C 입니다. 해보고 나중에 필요하면 더 넣고.."
"일단 데이타 넣어보고 운영하다가 느려지면 Index 추가하고..."

제 생각은 퍼시스턴스 개념이 없어서 클래스와 분리시켜 DB를 중요시 한다기 보다는 엔티티에 대한 물리적 계층이 DB가 가장 근접하기 때문에 설계에서 DB를 중요시 하는 것이 아닌가 합니다. 개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

lenani의 이미지

언제부터 그렇게 됐는지 모르겠지만 업계에서는 분석/설계가를 불필요하게
생각하는것 같습니다.
오직 코딩만 하는 사람만을 필요로 하구요.

사실 저는 좀 운이 좋은 경우로 제 주위에 분석/설계만 집중적으로 하는
사람들이 몇명 있습니다.
그 사람들에게도 많이 배웠구요 제 스스로 그쪽으로 공부도 많이 했습니다.
하지만 그 선배들의 경우를 보았을때 참 우리나라 IT쪽의 앞날이
막막하더라구요.

선배들은 지금 거의 외국으로 나갔습니다.
아직 우리나라에 있는 분들은 외국에 나갈려고 준비하는 사람과
영어를 배우는 사람으로 나뉘어 있습니다.
빨리 외국으로 진출하려구요.

납기에 대해서 말씀하셨는데, 맞습니다.
납기가 가장 중요하지요.
한편으로 프로그램의 품질도 아주 중요하다고 생각합니다.

그냥 저의 의견으로는 우리나라에서 만들어진 프로그램의 경우
그 품질이 아주 낮다고 생각해본적도 있습니다.
왜냐하면 한번 프로그램을 만들고 나서 그것을 확장시키는 경우를
보지 못해서요.
그냥 처음부터 다시 만들곤 하는 경우를 많이 봤습니다.

lenani의 이미지

madhatter wrote:
fender wrote:

즉, madhatter님께서는 게시판을 구현하기 위해서 '게시판', '게시물', '쓰레드', '사용자' 등등의 클래스를 먼저 구현하고 여기에 대해 퍼시스턴스 계층을 추가하는 개발자를 몇 명이나 보셨나요? 반대로 MESSAGE, BOARD, USER 테이블을 먼저 생성하고 이에 대한 쿼리 날리는 클래스를 얹는 경우가 훨신 일반적이지 않았나요? 별 차이가 아니라고 생각하실 수 있지만 이는 근본적인 패러다임의 차이입니다. 이 부분은 이야기가 나오면 더 설명 드리겠습니다 :)

음, 확실히 이건 패러다임의 차이이겠네요. 하지만 제가 본 대부분의 개발자는 테이블에 대한 개념이 없습니다. UI의 액션에 대한 개념만 있습니다. 클래스를 먼저 생각한다기 보다는 UI 설계를 먼저 하고 그 구현을 위한 class 를 생성한 다음 필요한 데이타를 넣기 위한 도구로 DB를 생각합니다. 어떤 개발자는 그러더군요.

"필요한 칼럼이 A,B,C 입니다. 해보고 나중에 필요하면 더 넣고.."
"일단 데이타 넣어보고 운영하다가 느려지면 Index 추가하고..."

제 생각은 퍼시스턴스 개념이 없어서 클래스와 분리시켜 DB를 중요시 한다기 보다는 엔티티에 대한 물리적 계층이 DB가 가장 근접하기 때문에 설계에서 DB를 중요시 하는 것이 아닌가 합니다. 개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

객체지향을 함으로써 얻어지는 효과중에 하나가 DB 스키마를 변경시켜도
프로그램을 수정하는 범위와 노력이 현저하게 줄어드는 현상이 있습니다.

물론 객체지향을 어설프게 적용시켜서 뭐 오히려 수정하는데 드는 노력이
늘어나는 경우도 있고요.

fender의 이미지

madhatter wrote:
음, 확실히 이건 패러다임의 차이이겠네요. 하지만 제가 본 대부분의 개발자는 테이블에 대한 개념이 없습니다. UI의 액션에 대한 개념만 있습니다. 클래스를 먼저 생각한다기 보다는 UI 설계를 먼저 하고 그 구현을 위한 class 를 생성한 다음 필요한 데이타를 넣기 위한 도구로 DB를 생각합니다. 어떤 개발자는 그러더군요.

흑... 신기하네요 -_-;; 제가 수년간 접한 웹 기반 SI 개발자의 전형은 자바나 PHP/ASP 등의 기초 문법 지식 + SQL 중급 수준의 지식 + 통밥 + @ 였거든요 :) 혹시 HTML은 만들 수 있는데 아예 디비 쪽은 개념도 없는 경우를 말씀하시는 건가요?

madhatter wrote:
개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

스키마 변경에 비용이 드는 건 어쩔 수 없지만 최소한 디비 중심적인 방식보다 자동화된 퍼시스턴스를 사용하는 것이 이를 최소화 할 수는 있습니다.

예를들어 EJB나 Hibernate 등을 쓰는 경우만 봐도 컬럼이나 테이블 이름이 바뀌어도 코드 자체에는 전혀 수정이 필요 없으니까요... 심지어 후자의 경우 한 테이블을 여러개로 쪼개거나 디비를 둘로 나누고 0/1로 된 플래그를 'YES', 'NO'로 바꾸는 등의 작업을 해도 거의 영향을 받지 않습니다.

이 경우는 꼭 디비 중심적인 설계가 그런 건 아니지만 '개념 없는' 디비 중심적 설계에서 테이블 이름 하나만 바꿔도 EditPlus에서 파일 다 찾아서 바꾸고 난리가 아니지요 :)

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

madhatter의 이미지

lenani wrote:
언제부터 그렇게 됐는지 모르겠지만 업계에서는 분석/설계가를 불필요하게
생각하는것 같습니다.
오직 코딩만 하는 사람만을 필요로 하구요.

아닙니다. 코딩만 하는 사람은 널렸습니다. 오히려 업계에서 필요로 하는 것은 분석/설계에 대한 전문가입니다. 이른바 컨설턴트란 직함을 들고 다니는 사람들입니다. 대신에 컨설턴트는 명함에 제대로 된 업체 이름이 있어야 인정해 줍니다.

lenani wrote:

그냥 저의 의견으로는 우리나라에서 만들어진 프로그램의 경우
그 품질이 아주 낮다고 생각해본적도 있습니다.
왜냐하면 한번 프로그램을 만들고 나서 그것을 확장시키는 경우를
보지 못해서요.
그냥 처음부터 다시 만들곤 하는 경우를 많이 봤습니다.

재사용성에 대해서는 여러가지 다른 이유도 있습니다. 재개발해야 수주비용이 올라가기 때문에 재사용성이 낮은 시스템을 개발하는 경우도 있답니다. :(

하지만 기본 모듈에 대한 재사용성은 꽤 높은 편입니다. 거의 패키지 수준으로 커스터마이징만 하는 경우도 있습니다. 이것도 퀄리티와 납기간의 적정한 타협점을 찾아야 가능한 일입니다. 하지만, IT를 노가다로 보는 경향이 짙은 지라 그도 어렵습니다.

madhatter의 이미지

개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

역시 이 부분에서 문제가 되는군요. 제 의미는 그렇게 DB를 퍼시스턴스로만 봤을 때 접근방법이 class 우선이라면 DB의 스키마의 완성도에 대한 우선순위가 낮아지지 않겠느냐는 것이었습니다. 구조적 설계도 개념 있게 하면 Table 변경에 대한 비용을 최소화할 수 있습니다. :)

lenani의 이미지

fender wrote:

스키마 변경에 비용이 드는 건 어쩔 수 없지만 최소한 디비 중심적인 방식보다 자동화된 퍼시스턴스를 사용하는 것이 이를 최소화 할 수는 있습니다.

예를들어 EJB나 Hibernate 등을 쓰는 경우만 봐도 컬럼이나 테이블 이름이 바뀌어도 코드 자체에는 전혀 수정이 필요 없으니까요... 심지어 후자의 경우 한 테이블을 여러개로 쪼개거나 디비를 둘로 나누고 0/1로 된 플래그를 'YES', 'NO'로 바꾸는 등의 작업을 해도 거의 영향을 받지 않습니다.

이 경우는 꼭 디비 중심적인 설계가 그런 건 아니지만 '개념 없는' 디비 중심적 설계에서 테이블 이름 하나만 바꿔도 EditPlus에서 파일 다 찾아서 바꾸고 난리가 아니지요 :)

동감입니다.
하지만 꼭 ORM을 쓰지 않아도 로직에 손을 대지 않고도 스키마를 바꿀수
있다고 생각합니다.
단 확실한 객체지향적 생각을 가지고 프로그램을 구성했을때 말입니다.

lenani의 이미지

madhatter wrote:
개발만 중요시 한다면 객체 지향적 방법론이 이상이겠으나 운영상의 문제를 생각한다면 반드시 이상적이라고 할 수 없습니다. 실제로 DB 스키마를 변경하는 것이 비용이 훨씬 많이 발생하기 때문입니다.

역시 이 부분에서 문제가 되는군요. 제 의미는 그렇게 DB를 퍼시스턴스로만 봤을 때 접근방법이 class 우선이라면 DB의 스키마의 완성도에 대한 우선순위가 낮아지지 않겠느냐는 것이었습니다. 구조적 설계도 개념 있게 하면 Table 변경에 대한 비용을 최소화할 수 있습니다. :)

DB 스키마를 객체 설계와 분리해서 할수도 있습니다.
단, 객체의 어떤 속성이 저장되어야 하는지는 스키마에 반영되어야 하지만요.
만약에 튜닝의 목적으로 통짜 DB table을 구성하더라고 객체는 이것과 분리
되어 구성될수 있습니다.

물론 구조적 방법론에서도 이렇게 할수 있지만 객체지향 방식보다는 상당히
불편합니다.
그 폭이 생각보다 큽니다.

fender의 이미지

public abstract class Pet {
  String getName();
  Color getColor();
  Date getBirthDay();
}

public class Cat extends Pet {
  Cat mate;
  Collection kittens;
...getter...setter... 중얼...
}

public class Dog extends Pet {
  Dog mate;
  Collection puppies;
...getter...setter... 어쩌구...
}

도메인 모델을 이렇게 구성했을 때 이를 RDBMS로 매핑하는 것을 생각해보시면 얼마나 객체지향과 RDBMS의 간극이 큰 지 알 수 있습니다. 일단 Date, Color 등의 클래스를 직렬화해서 넣지 않는 이상 일일이 VARCHAR나 DATE로 임의로 변환해야 하고 kittens나 puppies의 매핑은 foreign key로 처리를 한다 해도 클래스에서는 부모 고양이에서 새끼고양이로 가는 네비게이션이 반대로 구현이 됩니다.

무엇보다 일일이 SQL을 때려서 이 값을 다시 Cat이나 Dog 객체로 변환하는 작업을 한다 해도, 예를들어 재귀적으로 들어가면 - 즉, ((Cat) cat.getMate().getKittens().iterate().next()).getMate() 등을 제대로 구현한다는 건 사실상 불가능합니다.

탑다운 방식의 자동화된 퍼시스턴스를 사용하는 경우 위와 같은 문제들은 모두 프레임워크가 알아서 처리해 줍니다. SQL을 쓸 필요가 없는 것은 물론 심지어 자동으로 테이블까지 생성합니다.

이런 부분은 탑다운의 장점이라기 보다 퍼시스턴스 프레임워크의 장점이지만, 반대로 생각해볼 때 먼저 CAT, DOG의 테이블 스키마를 만들고 이를 FK관계로 엮었을 때 과연 제일 처음 제시한 것 과 같은 클래스 모델을 끌어 낼 수 있을 지, 또 과연 그 매핑을 어떻게 처리할 것인지는 쉽지 않은 문제입니다.

스키마 자체의 유연성을 보더라도 최근의 ORM 솔루션들은 위와 같은 상속관계의 경우 CAT, DOG 클래스를 각각 만들거나 PET이란 클래스의 KIND라는 플래그를 통해 개/고양이를 구분하는 경우등 코드 변경 없이 다양한 스키마 설계를 지원합니다. 따라서 오히려 탑다운으로 접근하는게 테이블 스키마 설계에서도 최대한 유연성을 확보할 수 있는 방법이기도 합니다.

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

lenani의 이미지

음...
foreign key로 구현되는 table 간의 관계를 언어의 pointer나 reference로
구현하는 것은 쉽지가 않죠.
말씀하신데로 navigation이 반대 방향으로 이루어질수밖에 없기 때문입니다.
또한 상속의 문제도 보통의 SQL로는 해결할수 없는 문제입니다.

fender님은 Hibernate나 JDO에 익숙하실거라고 생각해봅니다.

저는 사실 Hibernate같은 ORM을 사용하지 않습니다.
그냥 보통의 SQL로 처리하는데요.
(ORM이 좋지만) 뭐 저 같은 경우는 보통의 SQL로도 충분하니까요.
만약 단순한 객체 속성의 저장, 읽기이외에 조건에 맞게 객체를 모아오는
것은 ORM에서는 어떻게 구현하는지 알고 싶습니다.

제가 알기로는 SQL 이외에 따로 객체 질의 언어를 사용하는 것으로
알고 있는데요.

fender의 이미지

lenani wrote:
만약 단순한 객체 속성의 저장, 읽기이외에 조건에 맞게 객체를 모아오는 것은 ORM에서는 어떻게 구현하는지 알고 싶습니다.

제가 알기로는 SQL 이외에 따로 객체 질의 언어를 사용하는 것으로
알고 있는데요.

물론 ejb-ql이나 hql 같은 객체 질의 언어들이 있지만 위의 예제에서와 같이 단순이 특정 엔티티의 getter/setter를 통해 객체 트리를 네비게이션 하는 작업에는 필요하지 않습니다.

구현에 따라 다르지만 대표적인 경우는 Proxy나 AOP를 사용하는 것입니다. 즉,
((Cat) cat.getMate().getKittens().iterate().next()).getMate() 과 같은 호출이 있을 때 최초 cat.getMate()를 하는 시점에 이를 가로채서 mate에 해당하는 Cat 인스턴스가 없으면 적절한 sql을 호출해서 다시 이를 프록시로 감싸서 반환하고 사용자가 이에 대해 getKittens()를 호출하면 이를 가로 채서 캐쉬에 없으면 sql을 보내 kittens에 해당하는 Cat의 인스턴스 프록시들을 만들고... 하는 식으로 처리 합니다.

물론 객체 질의가 필요한 경우가 있습니다. 예를들어 특정 색깔의 강아지나 고양이, 혹은 모두를 가져올 경우 pet.color = Color.RED와 같이 조건을 주면 해당하는 인스턴스를 모두 반환합니다. 이게 SQL select 쿼리와 다른 점은 SQL이 반환하는 건 scalar 속성들의 집합에 불과하지만 이 경우는 직접 완전한 Cat이나 Dog의 인스턴스가 돌아오는 점이 다릅니다.

즉, 어떠한 처리 없이 프론트 단에 반환하기만 하면 알아서 처리할 수 있다는 뜻이고 예를들어 받은 쪽에서 "두번째로 반환된 고양이의 3번째 새끼 고양이의 색은 무엇인가?"와 같은 문제를 간단히 알 수 있다는 점에서 다릅니다.

심지어 일부에선 한걸음 더 나아가 이렇게 로딩한 인스턴스를 XML 매핑 툴을 이용해 자동으로 xml로 변환해서 미리 정의한 XSL로 직접 HTML로 변환하는 방식을 시도하기도 합니다. 유연성에 문제가 있긴 하지만 SQL이나 JSP 코딩 한 줄 없이 클래스 모델이 곧 프로그램이라는 획기적인 방식이긴 합니다.

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

madhatter의 이미지

fender wrote:
public abstract class Pet {
  String getName();
  Color getColor();
  Date getBirthDay();
}

public class Cat extends Pet {
  Cat mate;
  Collection kittens;
...getter...setter... 중얼...
}

public class Dog extends Pet {
  Dog mate;
  Collection puppies;
...getter...setter... 어쩌구...
}

도메인 모델을 이렇게 구성했을 때 이를 RDBMS로 매핑하는 것을 생각해보시면 얼마나 객체지향과 RDBMS의 간극이 큰 지 알 수 있습니다. 일단 Date, Color 등의 클래스를 직렬화해서 넣지 않는 이상 일일이 VARCHAR나 DATE로 임의로 변환해야 하고 kittens나 puppies의 매핑은 foreign key로 처리를 한다 해도 클래스에서는 부모 고양이에서 새끼고양이로 가는 네비게이션이 반대로 구현이 됩니다.

무엇보다 일일이 SQL을 때려서 이 값을 다시 Cat이나 Dog 객체로 변환하는 작업을 한다 해도, 예를들어 재귀적으로 들어가면 - 즉, ((Cat) cat.getMate().getKittens().iterate().next()).getMate() 등을 제대로 구현한다는 건 사실상 불가능합니다.

탑다운 방식의 자동화된 퍼시스턴스를 사용하는 경우 위와 같은 문제들은 모두 프레임워크가 알아서 처리해 줍니다. SQL을 쓸 필요가 없는 것은 물론 심지어 자동으로 테이블까지 생성합니다.

이런 부분은 탑다운의 장점이라기 보다 퍼시스턴스 프레임워크의 장점이지만, 반대로 생각해볼 때 먼저 CAT, DOG의 테이블 스키마를 만들고 이를 FK관계로 엮었을 때 과연 제일 처음 제시한 것 과 같은 클래스 모델을 끌어 낼 수 있을 지, 또 과연 그 매핑을 어떻게 처리할 것인지는 쉽지 않은 문제입니다.

스키마 자체의 유연성을 보더라도 최근의 ORM 솔루션들은 위와 같은 상속관계의 경우 CAT, DOG 클래스를 각각 만들거나 PET이란 클래스의 KIND라는 플래그를 통해 개/고양이를 구분하는 경우등 코드 변경 없이 다양한 스키마 설계를 지원합니다. 따라서 오히려 탑다운으로 접근하는게 테이블 스키마 설계에서도 최대한 유연성을 확보할 수 있는 방법이기도 합니다.

자동화된 툴을 사용하는 게 일일이 손으로 작업하는 것보다 편하다 - 이렇게 해석하는 게 맞는 것인가요? 결국 수작업으로 매핑하는 것과 자동화 되었다는 것 이외에는 접근 방법상 차이가 보이지 않는군요. 논외의 이야기일지 모르지만 사실 자동화된 툴에 의해 제너레이팅된 결과물을 그대로 사용할 수 있다는 것에 대해서는 불신하고 있습니다. 어찌 되었건 자동화 툴에 의해 제너레이팅 되면 리던던시가 생기게 마련이라고 봅니다.

kittens 와 puppies 의 FK적 접근과 class에서 reference를 사용한 것과의 구현 차이점을 자세히 설명해 주셨으면 합니다. 잘 와닿지가 않네요.

lenani의 이미지

감사합니다.
그런데 궁금한 점이 있는데요.
fender님이 다니는 회사에서는 객체지향을 실제로 사용하는지 알고 싶습니다.
제가 그동안 봐왔던 회사는 객체지향과는 거리가 멀거나
객체지향이라는 것이 있다는 걸 아는 정도였거든요.
궁금한데요?

fender의 이미지

madhatter wrote:
자동화된 툴을 사용하는 게 일일이 손으로 작업하는 것보다 편하다 - 이렇게 해석하는 게 맞는 것인가요? 결국 수작업으로 매핑하는 것과 자동화 되었다는 것 이외에는 접근 방법상 차이가 보이지 않는군요. 논외의 이야기일지 모르지만 사실 자동화된 툴에 의해 제너레이팅된 결과물을 그대로 사용할 수 있다는 것에 대해서는 불신하고 있습니다. 어찌 되었건 자동화 툴에 의해 제너레이팅 되면 리던던시가 생기게 마련이라고 봅니다.

kittens 와 puppies 의 FK적 접근과 calss에서 reference를 사용한 것과의 구현 차이점을 자세히 설명해 주셨으면 합니다. 잘 와닿지가 않네요.

음... 이는 단순히 자동으로 클래스나 테이블을 생성하는 차원의 차이는 아닙니다. 예를들어 상향식/하향식 접근에 상관없이 생각해 보면, 비즈니스 로직을 처리하는 단에서 Cat PetManager.getCat(String name);이라는 메소드가 있다고 생각해 보겠습니다.

이를 호출하는 프론트 쪽에서는 이렇게 반환된 Car의 인스턴스로 여러 가지 작업을 할 수 있습니다. 예를들어, 고양이의 색깔을 표시하는 뷰를 만든다면

Cat cat = PetManager.getCat("Lucy");
out.println(cat.getColor());

이렇게 할 수 있습니다. 이를 구현하기 위해서 SQL 백엔드를 직접 짜는 방식에선 PetManager의 getCat() 메소드를 어떻게 구현 해야 할까요?

커넥션 얻어오기... 어쩌구 저쩌구...
String sql = "select * from CAT where NAME = ?";
...SQL 실행... 중얼...
Cat cat = new Cat();
cat.setName(rs.getString("NAME"));
...
return cat;

여기까지는 별 차이가 없습니다. 그럼 한 단계 더 내려가서 만약 프론트에서 다음과 같은 코드를 짠다면 어떨까요?

Cat cat = PetManager.getCat("Lucy");
Collection kitten = cat.getMate().getKitten();
Cat firstChild = (Cat) kitten.iterator().next();
Cat mate = firstChild.getMate();
out.println(mate.getName());

즉, Lucy란 이름의 고양이의 첫번째 새끼고양이가 결혼-_-;한 상대 고양이의 이름을 구하는 것입니다. 분명 최초 설계한 도메인 모델을 볼 때 Cat 인스턴스가 있다면 getKittens()을 통해 새끼 고양이 컬렉션을 가져올 수 있어야 하고 이 컬렉션의 엘레먼트가 Cat 클래스 인 한 다시 getMate()를 해서 배우자 고양이(?)를 가져와야 합니다.

그리고 PetManager의 인터페이스에서 Cat getCat(String name)이란 메소드가 있는 한 이러한 작업은 당연하게 구현이 되어야 합니다. 하지만 과연 SQL로 이런 코드를 짜는게 가능할까요?

커넥션 얻어오기... 어쩌구 저쩌구...
String sql = "select * from CAT where NAME = ?";
...SQL 실행... 중얼...
Cat cat = new Cat();
cat.setName(rs.getString("NAME"));

sql = "select * from CAT where PARENT_NAME= ?";
... 자식 고양이 구하는 SQL 실행...
루프 돌림...
sql = "select * from CAT where NAME = ?"
NAME에 위에서 구한 특정 자식 고양이의 배우자 이름 입력...
.....
...루프 끝...
...
return cat;

실제 각 고양이의 색상, 나이 등을 넣는 부분이 없어서 그렇지 이 정도만 해도 거의 유지보수가 불가능한 수준의 복잡한 코드가 됩니다. 문제는 논리적으로는 cat에서 몇 단계든 재귀호출이 가능하지만 이런 임의의 단계의 호출을 모두 고려해서 SQL을 짜는 건 사실상 불가능합니다.

반면에 예를들어 스프링과 하이버네이트 조합이라면 이는 단 한줄로 표현됩니다.

return (Cat) session.load(Cat.class, name);

물론 SQL로도 같은 방식으로 AOP든 프록시든 써서 실제 호출이 올 때 해당 값을 읽어오게 구현할 수도 있습니다. 하지만 이건 사실상 EJB나 Hibernate와 같은 ORM을 직접 구현하겠다는 것으로 배보다 배꼽이 큰 결과가 날 확률이 큽니다.

이는 프론트에선 Cat, Dog, Pet과 같은 클래스, 즉 객체 지향의 개념을 사용해서 프로그램을 구현하지만 이를 백엔드에서 이와는 완전히 이질적인 RDBMS라는 매체에 매핑을 하려 해서 생기는 문제이며 여기엔 간단하게 코딩으로 풀 수 있는 해결책이 없습니다.

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

fender의 이미지

lenani wrote:
감사합니다.
그런데 궁금한 점이 있는데요.
fender님이 다니는 회사에서는 객체지향을 실제로 사용하는지 알고 싶습니다.
제가 그동안 봐왔던 회사는 객체지향과는 거리가 멀거나
객체지향이라는 것이 있다는 걸 아는 정도였거든요.
궁금한데요?

프리랜스 개발을 하고 있는데... 가는데 마다.... 무조건 CVS나 maven/ant, hibernate, spring, struts 등등의 사용을 강요 -_-;;; 합니다.

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

lenani의 이미지

Quote:
논외의 이야기일지 모르지만 사실 자동화된 툴에 의해 제너레이팅된 결과물을 그대로 사용할 수 있다는 것에 대해서는 불신하고 있습니다. 어찌 되었건 자동화 툴에 의해 제너레이팅 되면 리던던시가 생기게 마련이라고 봅니다.

당연히 그낭 사용할수는 없습니다.
스키마라는 것이 있듯이 객체를 정의하는 스키마가 존재합니다.
그것을 통해서 어떻게 DB에 저장될지 기술하게 됩니다.
하지만 일단 그것만 만들어 놓으면 그 결과를 그대로 사용할수 있습니다.

중복문제를 말씀하셨는데 구체적으로 어떤 말씀을 하는지 모르겠습니다.
하지만 사용하는데 문제는 없습니다.

Quote:

kittens 와 puppies 의 FK적 접근과 class에서 reference를 사용한 것과의 구현 차이점을 자세히 설명해 주셨으면 합니다. 잘 와닿지가 않네요.

만약 위의 코드를 그대로 SQL로 전환한다면 어떻게 하시겠습니까?
만약 부모가 자식을 여러개 거느리고 있을때 어떤 부모만이 주어진다면
그 자식에게 어떻게 접근할수 있을까요?
만약 DB에서라면 tbl_자식이 foreign key로 tbl_부모를 가리키고 있을텐데
tbl_부모로 tbl_자식을 구한다면 필연적으로 tbl_부모의 primary key가
필요합니다.

SELECT tbl_자식.oid WHERE tbl_자식.fk_parent = tbl_부모.oid;
이런 SQL문은 자식 객체와 연관되어 있는 부모 객체의 id를 얻어오게 됩니다.

이때 foreign key가 가리키는 방향을 보면 객체의 방향과 반대인것을 알수
있습니다.
분명히 부모 -> 자식 이었는데 DB에서는 tbl_부모 <- tbl_자식
이렇게 되어 있습니다.
그리고 맨처음 제가 원한 구조는 부모 -> 자식이었습니다.

lenani의 이미지

fender wrote:
lenani wrote:
감사합니다.
그런데 궁금한 점이 있는데요.
fender님이 다니는 회사에서는 객체지향을 실제로 사용하는지 알고 싶습니다.
제가 그동안 봐왔던 회사는 객체지향과는 거리가 멀거나
객체지향이라는 것이 있다는 걸 아는 정도였거든요.
궁금한데요?

프리랜스 개발을 하고 있는데... 가는데 마다.... 무조건 CVS나 maven/ant, hibernate, spring, struts 등등의 사용을 강요 -_-;;; 합니다.

그럼 그 가시는 곳에서는 객체지향을 효과적으로(?) 사용하고 있던가요?

fender의 이미지

lenani wrote:
그럼 그 가시는 곳에서는 객체지향을 효과적으로(?) 사용하고 있던가요?

그게 아니라 가는데 마다 제 맘대로 -_-;;; 알아서 한다는 -_-; 물론 기 구축된 시스템이 있거나 규모가 커져서 전체 설계에 대한 권한이 없다면 다르지만 그런 경우가 아니면 대충 자기 주장을 하는 편입니다.

제가 객체지향을 제대로 이해하는 지는 모르겠습니다 :) 잘하는 프로그래머는 많으니까요.... 유독 국내 웹 SI 쪽에만 별로 없어서 그렇지요 -_-;

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

madhatter의 이미지

fender 님 설명 잘 봤습니다만, 그 설명만으론 인스턴트 생성시 객체의 어트리뷰트를 담아 두거나 relation 을 맺어두는 것으로 풀지 못할 경우는 없어보입니다. 그리고 RDB를 사용하여 객체 지향 설계를 하면 아무도 그런 식으로 SQL을 나열하지 않습니다. class 단위로 method를 정의하고 해당 method의 액션에 필요한 SQL을 back end 에 둡니다. 결국 Biz Logic 에 대한 layer는 가시적으로 class 레벨에 머물게 되며 실제 SQL 문이 들어있는 것은 Data Access Object에 국한됩니다. front-end에서는 제공되는 class 를 사용하여 코딩하면 됩니다. 이게 무슨 차이가 있는 것인가요? 거꾸로 front-end에서 새로운 class 가 필요하다고 하면 설계 및 생성을 하여 그 액션에 필요한 Data Access Object를 back-end에서 만들어 내면 됩니다.

fender의 이미지

madhatter wrote:
fender 님 설명 잘 봤습니다만, 그 설명만으론 인스턴트 생성시 객체의 어트리뷰트를 담아 두거나 relation 을 맺어두는 것으로 풀지 못할 경우는 없어보입니다. 그리고 RDB를 사용하여 객체 지향 설계를 하면 아무도 그런 식으로 SQL을 나열하지 않습니다.

DAO를 써서 SQL 을 쓰는 계층을 분리하는 것과 위의 문제는 다른 이야기입니다. 제가 제기한 문제 - 즉, Cat PetManager.getCat(String name)의 인터페이스를 SQL로 구현하는 부분은 어떻게 해결해야 하는 지 좀 더 자세한 설명을 부탁 드립니다.

내부 구현을 어떻게 하던 반환된 Cat의 인스턴스에서 getMate().getKittens().getKittens()... 하는 식의 호출이 가능한 방법이 있나요?

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

lenani의 이미지

초기에 가졌던 의문이 아직 풀리지 않았습니다.
왜 우리나라에서는 객체지향을 많이 사용하지 않을까요?

madhatter님은 납기일이라든가 하는 현실적 제한이 있다고 말씀하셨습니다.
그리고 분석/설계쪽 전문가가 필요하다고 하셨습니다.

fender님도 우리나라 웹 SI에 실력자(?)가 없다고 하셨습니다.

제가 가지는 의문은 바로 이것입니다.
왜 분석/설계 전문가가 없을까요?

뭔가 구조적 문제점이 있는게 아닐까요?

madhatter의 이미지

제 말은 자식 고양이의 배우자를 구하는데 getMate().getKittens().getKittens()... 하는 재귀적 방법을 굳이 사용해야 하느냐는 의미도 됩니다. 그리고 재귀적 호출이라해도 동일한 method 반복이라면 구현되지 못할 이유가 없다고 보는데요?

M.W.Park의 이미지

lenani wrote:
초기에 가졌던 의문이 아직 풀리지 않았습니다.
왜 우리나라에서는 객체지향을 많이 사용하지 않을까요?

madhatter님은 납기일이라든가 하는 현실적 제한이 있다고 말씀하셨습니다.
그리고 분석/설계쪽 전문가가 필요하다고 하셨습니다.

fender님도 우리나라 웹 SI에 실력자(?)가 없다고 하셨습니다.

제가 가지는 의문은 바로 이것입니다.
왜 분석/설계 전문가가 없을까요?

뭔가 구조적 문제점이 있는게 아닐까요?

납기내에 돌아가기만 하는 제품을 납품하면 끝이기 때문입니다.
사실 내부가 어떻게 되었든 돌아가기만 하면, 로직이나 설계가 잘못된 것은 장비로 떼우는....
이런 분위기가 팽배(?) 해 있다고 보시는 편이 이해하기 쉬울듯하네요.
일단 서비스 오픈하고 나중에 땜방하기가 이바닥 돌아가는 분위기라 그렇겠지만, 엔지니어로서는 뭔가 찜찜한게 사실이죠.

대부분의 전임/후임 업무 인수인계 때 나오는 대화는 다음과 비슷합니다.

Q: 이거 설계/구현 이상한거 아니냐?
A: 시간에 쫓겨서 어쩔수 없었다. (고칠테면 고쳐라...)

이런 대화 후엔 땜방이 시작되겠죠. 그리고 실제로 한군데 고치려고 하면...
스파게티인 경우가 많아 다른데에서 문제가 생기고...
맨땅에 헤딩 한번 해본 후임자는 그냥 문제생기면 땜방하는 정책으로 현실과 타협하죠.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

fender의 이미지

lenani wrote:
초기에 가졌던 의문이 아직 풀리지 않았습니다.
왜 우리나라에서는 객체지향을 많이 사용하지 않을까요?

madhatter님은 납기일이라든가 하는 현실적 제한이 있다고 말씀하셨습니다.
그리고 분석/설계쪽 전문가가 필요하다고 하셨습니다.

fender님도 우리나라 웹 SI에 실력자(?)가 없다고 하셨습니다.

제가 가지는 의문은 바로 이것입니다.
왜 분석/설계 전문가가 없을까요?

뭔가 구조적 문제점이 있는게 아닐까요?

그 부분은 madhatter님의 말씀이 정답이 아닐까 싶습니다. 하청에 재하청을 거듭하는 SI의 특성상 실제 개발하는 개발자들에게 돌아가는 급여가 넉넉할리 없고 프로젝트 기간이 길리가 없습니다. 이런 상황에서, 수년 걸려 무슨 킬러 어플리케이션을 개발하는 것도 아니고 만약에 한두달 삽질하고 인건비 뽑을 수 있는 SI 성 프로젝트라면 일단 싸게 먹히고 빨리 끝내는게 장 땡입니다.

그리고 지금 IT 업계에는 2/3년차 개발자는 넘쳐나서 주체를 못합니다. IT는 어려워도 막 졸업하는 학생들은 마치 학원에서 6개월 쯤 수료하면 주 5일에 고액 연봉 받으면서 영화에 나오는 해커처럼 살 수 있다는 환상도 가지고 있고 반면에 외주개발 업체에선 경력이 10년이 넘는 고급 개발자들을 장기간 고액 연봉을 주면서 부릴 수 있는 처지도 아닙니다.

그러니 수주받은 금액에서 마진 떼고 최소한의 비용으로 값싼 2-3년 차 개발자들로 프로젝을 채우고 이들은 실력부족, 촉박한 기간, 회사 차원의 잘 정립된 방법론의 부재, 낮은 임금 수준으로 인한 의욕상실 등등의 이유로 퀄리티가 나올래야 나올 수가 없습니다.

이런 상황에서 한 두명이 제대로 소프트웨어 공학을 배웠다고 총대메고 나서서 프로젝마다 얼굴이 바뀌는 초급 개발자들 앉혀놓고 방법론이나 객체지향에 대해 일장 강의를 해가며 프로젝 진행을 할 수는 없습니다.

어차피 유지보수 할지 안할지도 모르고 해봐야 재개발이라도 해야 단가가 더 나오는 상황이라면 어떻게든 최저비용으로 검수 받는게 장땡입니다. 고객들은 아무리 3계층 구조가 어떻고 객체지향이 어떻고 해도 기간이 길어지면 싫어합니다 -_-;

그저 빨리 빨리 한쪽에서 ERD그리고 디자이너 html 만들면 스크립 갖다 붙이고 넘기는게 남는 거니까요... 암담하죠 -_-

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

madhatter의 이미지

tbl_relation

id 부모 id 배우자 id
A B E
B C D
C
D A B
E B A

getKitten(id)
{
connection 어쩌고 저쩌고
...

query = "select id from tbl_relation where 부모 id = id"

결과 하나일 때 어쩌고..
둘 이상일 때 어쩌고...
.....

}

뭐가 다른가요?

lenani의 이미지

madhatter wrote:
제 말은 자식 고양이의 배우자를 구하는데 getMate().getKittens().getKittens()... 하는 재귀적 방법을 굳이 사용해야 하느냐는 의미도 됩니다. 그리고 재귀적 호출이라해도 동일한 method 반복이라면 구현되지 못할 이유가 없다고 보는데요?

제가 개인적으로 ORM 비슷한것을 만들어 본적이 있는데요.
상당히 까다로운 일입니다.
일단 목표는 SQL의 작성 없이 객체사이의 어떤 연산만으로 DB table에
대한 SQL문을 내부적으로 만들어서 그 결과로 객체의 배열을 얻어내는
것이었습니다.

결론적으로 말하자면 구현을 하기는 했는데 단점이 정말 많았었습니다.
table에 접근하기 위해서는 oid라는 primary key를 꼭 사용해야 했습니다.
또 table 정보를 어디에 담아 두어야 했습니다.

제가 만들 당시는 제가 generic programming과 RTTI를 모르는 상태였기
때문에 더욱 힘들었습니다.

또 한가지 생각할 점은 지금 사용하는 객체와 그것의 저장 수단인 table
과의 불일치 문제가 있습니다.
또한 성능상의 문제로 Object Cache를 만들어야 했습니다.

어쨌든 그 ORM 비슷한 것을 만들고 난 이후에 든 생각은 그냥 OODBMS
를 쓰거나 이미 만들어져 있는 ORM을 사용하는게 좋겠다는 것이었습니다.

뭐 어쨌든 지금 생각난 것보다 더 많은 문제가 있었던 걸로 기억합니다.

fender의 이미지

madhatter wrote:
제 말은 자식 고양이의 배우자를 구하는데 getMate().getKittens().getKittens()... 하는 재귀적 방법을 굳이 사용해야 하느냐는 의미도 됩니다. 그리고 재귀적 호출이라해도 동일한 method 반복이라면 구현되지 못할 이유가 없다고 보는데요?

그러한 극단적 재귀적 호출은 드물지만 아무리 단순한 경우라도 객체 트리를 온전히 RDBMS에서 뽑아오는 것 만큼 손이 많이가고 어려운 작업도 드뭅니다.

더구나 분명 Cat PetManager.getCat(String name)이라는 인터페이스가 객체지향적 사고 방식으로는 가장 단순하고 합리적인데, 예를들어 SQL을 쓸 경우 "Cat에 getKittens()란 메소드가 있지만 실제로는 SQL로 구현이 어렵기 때문에 동작하지 않는다. 대신 PetManager.getKittens(String parentName)을 써라"라고 말하는게 과연 객체지향적 사고방식인지 생각해 봐야 합니다.

부모고양이의 새끼고양이를 구하는 방식이 cat.getKittens()이 객체 지향적인가요 아니면 PetManager.getKittens(String parentName)이 객체지향적인가요?

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

lenani의 이미지

이런 부정적 상황을 해결 방법은 없을까요?

요즘에 정부에서 의탁하는 프로젝트에 line수로
수가를 정하는게 아니라 기능 점수(function point)로
수가를 책정하도록 정책을 바꾼다는 소식을 들었습니다.

또한 IT 노조 얘기도 있고요.

프로그래머 개인으로서도 뭔가 할수 있는 방법이 있을거라 생각합니다.

fender의 이미지

madhatter wrote:
tbl_relation

id 부모 id 배우자 id
A B E
B C D
C
D A B
E B A

getKitten(id)
{
connection 어쩌고 저쩌고
...

query = "select id from tbl_relation where 부모 id = id"

결과 하나일 때 어쩌고..
둘 이상일 때 어쩌고...
.....

}

뭐가 다른가요?

죄송하지만 madhatter님께서는 최초의 예제를 처음부터 꼼꼼하게 확인을 해주셨으면 부탁드립니다. 일단 과연 getKittens()가 왜 Cat 클래스가 아닌 PetManager에 있는지는 차치 하더라도 그렇게 구한 결과 값의 형(type)은 무엇이 될까요? Cat 인스턴스의 배열인가요 아니면 단순히 새끼고양이의 이름을 담은 배열인가요?

전자의 경우라면 각각의 Cat 인스턴스를 로딩하기 위한 SQL이 반복되어야 하는게 아닌지요? 후자의 경우라면 Cat에는 getMate()나 getKittens()의 메소드를 넣을 수 없습니다 왜냐하면 이는 Cat이 아닌 PetManager에 정의되어 있으니까요.

특정 고양이 인스턴스의 새끼고양이들을 가져오는데 제3의 유틸 클래스에게 물어봐야 한다는 건 분명 객체지향적인 방식이 아니지 않나요?

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

madhatter의 이미지

lenani wrote:
madhatter wrote:
제 말은 자식 고양이의 배우자를 구하는데 getMate().getKittens().getKittens()... 하는 재귀적 방법을 굳이 사용해야 하느냐는 의미도 됩니다. 그리고 재귀적 호출이라해도 동일한 method 반복이라면 구현되지 못할 이유가 없다고 보는데요?

제가 개인적으로 ORM 비슷한것을 만들어 본적이 있는데요.
상당히 까다로운 일입니다.
일단 목표는 SQL의 작성 없이 객체사이의 어떤 연산만으로 DB table에
대한 SQL문을 내부적으로 만들어서 그 결과로 객체의 배열을 얻어내는
것이었습니다.

결론적으로 말하자면 구현을 하기는 했는데 단점이 정말 많았었습니다.
table에 접근하기 위해서는 oid라는 primary key를 꼭 사용해야 했습니다.
또 table 정보를 어디에 담아 두어야 했습니다.

제가 만들 당시는 제가 generic programming과 RTTI를 모르는 상태였기
때문에 더욱 힘들었습니다.

또 한가지 생각할 점은 지금 사용하는 객체와 그것의 저장 수단인 table
과의 불일치 문제가 있습니다.
또한 성능상의 문제로 Object Cache를 만들어야 했습니다.

어쨌든 그 ORM 비슷한 것을 만들고 난 이후에 든 생각은 그냥 OODBMS
를 쓰거나 이미 만들어져 있는 ORM을 사용하는게 좋겠다는 것이었습니다.

뭐 어쨌든 지금 생각난 것보다 더 많은 문제가 있었던 걸로 기억합니다.

그건 객체 지향적 구현에 너무 연연한 결과가 아닌가 하는데요.
처음에 제가 제기한 문제는 객체 지향적 방법론과 객체 지향적 구현과 객체 지향적으로 구성된 솔루션과의 차이가 존재하는데 그 개념이 마구 뒤섞이고 있어서 경계하자는 것이었습니다. 객체 지향적 구현에 RDB를 매핑하는 것은 어렵다. 이건 객체 지향적 방법론에 대한 문제가 아닙니다. 구현 개념이 다른 솔루션간의 충돌로 봐야합니다. 그리고 그 가운데 어느 정도 타협점을 찾을 수 있는 구현 방법은 많이 나와 있습니다. 당연히 OODB가 객체 지향적 구현이 더 적합하다는 것은 동의하겠습니다. 하지만 개발 방법론(이건 소프트웨어 개발 방법론을 말하는 것입니다. 구조적,객체 지향적 등으로 구분되는 방법론입니다.)에서 재귀적 메쏘드 호출이 RDB로는 구현 불가능 하다는 것이 문제가 된다는 건 납득이 안갑니다. 동일한 결과를 얻기 위한 RDB적 접근이 있다고 생각합니다. 그리고 그 자체를 유연하게 구현할 수 없다고 해서 객체 지향적이 아니다라고 단정할 수는 없다고 봅니다.
fender의 이미지

madhatter wrote:
동일한 결과를 얻기 위한 RDB적 접근이 있다고 생각합니다. 그리고 그 자체를 유연하게 구현할 수 없다고 해서 객체 지향적이 아니다라고 단정할 수는 없다고 봅니다.

동일한 결과를 RDBMS를 써서 얻을 수 있습니다. 단, 그건 객체지향적은 아닙니다. 그렇다고 생각하시면 위의 예제에서 Cat 클래스에 getKittens()과 getMate()를 구현할 수 있는 간단한 pseudo 코드라도 보여주시기를 부탁 드리겠습니다.

Cat에 이런 메소드를 넣을 수 있는지 없는지가 뭐 대수냐고 생각하실 수 있지만 RDBMS에서 테이블 릴레이션이 없다면 그건 RDBMS가 아닙니다. 객체지향은 말 그대로 문제 영역을 객체의 상속, 참조 관계로 나타내는 건데 상속은 고사하고 getKittens() (1:n), getMate() (1:1)과 같은 기본적인 상관관계조차 표현할 수 없다면 그건 이미 객체지향은 아니라고 봅니다.

객체지향이 반드시 RDBMS 중심적인 개발보다 우월하다고 주장하진 않겠지만 최소한 그런 방식은 '객체지향'은 아니라는 점을 강조하고 싶습니다.

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

lenani의 이미지

madhatter wrote:
lenani wrote:
madhatter wrote:
제 말은 자식 고양이의 배우자를 구하는데 getMate().getKittens().getKittens()... 하는 재귀적 방법을 굳이 사용해야 하느냐는 의미도 됩니다. 그리고 재귀적 호출이라해도 동일한 method 반복이라면 구현되지 못할 이유가 없다고 보는데요?

제가 개인적으로 ORM 비슷한것을 만들어 본적이 있는데요.
상당히 까다로운 일입니다.
일단 목표는 SQL의 작성 없이 객체사이의 어떤 연산만으로 DB table에
대한 SQL문을 내부적으로 만들어서 그 결과로 객체의 배열을 얻어내는
것이었습니다.

결론적으로 말하자면 구현을 하기는 했는데 단점이 정말 많았었습니다.
table에 접근하기 위해서는 oid라는 primary key를 꼭 사용해야 했습니다.
또 table 정보를 어디에 담아 두어야 했습니다.

제가 만들 당시는 제가 generic programming과 RTTI를 모르는 상태였기
때문에 더욱 힘들었습니다.

또 한가지 생각할 점은 지금 사용하는 객체와 그것의 저장 수단인 table
과의 불일치 문제가 있습니다.
또한 성능상의 문제로 Object Cache를 만들어야 했습니다.

어쨌든 그 ORM 비슷한 것을 만들고 난 이후에 든 생각은 그냥 OODBMS
를 쓰거나 이미 만들어져 있는 ORM을 사용하는게 좋겠다는 것이었습니다.

뭐 어쨌든 지금 생각난 것보다 더 많은 문제가 있었던 걸로 기억합니다.

그건 객체 지향적 구현에 너무 연연한 결과가 아닌가 하는데요.
처음에 제가 제기한 문제는 객체 지향적 방법론과 객체 지향적 구현과 객체 지향적으로 구성된 솔루션과의 차이가 존재하는데 그 개념이 마구 뒤섞이고 있어서 경계하자는 것이었습니다. 객체 지향적 구현에 RDB를 매핑하는 것은 어렵다. 이건 객체 지향적 방법론에 대한 문제가 아닙니다. 구현 개념이 다른 솔루션간의 충돌로 봐야합니다. 그리고 그 가운데 어느 정도 타협점을 찾을 수 있는 구현 방법은 많이 나와 있습니다. 당연히 OODB가 객체 지향적 구현이 더 적합하다는 것은 동의하겠습니다. 하지만 개발 방법론(이건 소프트웨어 개발 방법론을 말하는 것입니다. 구조적,객체 지향적 등으로 구분되는 방법론입니다.)에서 재귀적 메쏘드 호출이 RDB로는 구현 불가능 하다는 것이 문제가 된다는 건 납득이 안갑니다. 동일한 결과를 얻기 위한 RDB적 접근이 있다고 생각합니다. 그리고 그 자체를 유연하게 구현할 수 없다고 해서 객체 지향적이 아니다라고 단정할 수는 없다고 봅니다.

동의합니다.
사실 ORM은 내부적으로 SQL을 생성해서 동작합니다.
그렇기 때문에 RDB 적인 방법으로 객체지향을 구현할수 없다는 것은 말이
되지 않습니다.
다만 ORM은 더 편리하는 장점이 있고 그것을 이용할 뿐입니다.

사실 객체지향을 사용하지 않는다면 ORM이 필요가 없겠지요.
하지만 왜 객체지향이 생겨나게 되었는지 생각해 보신다면
어느정도 수긍을 하시지 않을까 생각합니다.

madhatter의 이미지

자꾸 반복되는 질문입니다만, 왜 RDB와 객체 지향이 대립이 되어야 하는 개념인가요? 그러면 현재의 RDB를 사용한 모든 시스템이 객체 지향적이 아니다란 말씀이신가요?
그리고 말씀하신대로 Cat 클래스가 getKitten(), getMate()를 가질 수도 있는 것이고 PetManager 에서 담당할 수도 있는 문제 아닌가 합니다. 또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

설마 취약한 점을 예로 드는 문제를 해결하기 위한 class 설계를 여기에 해달라는 말씀은 아니시겠지요? :wink:

fender의 이미지

madhatter wrote:
자꾸 반복되는 질문입니다만, 왜 RDB와 객체 지향이 대립이 되어야 하는 개념인가요? 그러면 현재의 RDB를 사용한 모든 시스템이 객체 지향적이 아니다란 말씀이신가요?

객체지향의 패러다임이 테이블의 상관관계로 표현할 수 없기 때문입니다. RDBMS로 객체지향적 구현을 할 수 없는 것이 아니라 그러기 위해선 ORM과 같은 별도의 복잡한 계층이 존재하지 않는 한 가능하지 않다는 뜻입니다.

madhatter wrote:
그리고 말씀하신대로 Cat 클래스가 getKitten(), getMate()를 가질 수도 있는 것이고 PetManager 에서 담당할 수도 있는 문제 아닌가 합니다.

'객체지향'은 단지 구조체 대신 클래스를 쓰고 펑션을 메소드 라고 부르는게 아니라는 건 아시리라 믿습니다. 말씀하신 방법은 특정 어미 고양이의 이름으로 새끼고양이를 찾는 '기능'을 구현한 별도 프로그램 단위를 만든다는 뜻입니다. 고양이의 이름을 특정 '함수'에 넘기면 새끼 고양이 이름 배열을 반환한다. 이건 철저하게 절차지향적인 사고 방식이 아닌지요?

객체지향적 사고방식에서는 특정 고양이의 새끼 고양이를 알고 싶으면 해당 고양이 인스턴스의 getter를 호출해서 새끼 고양이 '이름 배열'이 아닌 실제 새끼 고양이 인스턴스들의 묶음을 가져와야 합니다. 이는 RDBMS에서 FK로 레코드를 참조하는 것처럼 객체지향 패러다임의 가장 단순하고 기본이 되는 부분입니다.

UML을 이용한 케이스 툴을 말씀하셨는데 클래스간의 상속과 association이 불가능 하다면 과연 무엇 때문에 클래스 다이어그램이 필요한지 생각해 보시기 바랍니다.

madhatter wrote:
또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

psuedo코드라도 부탁드립니다 :)

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

lenani의 이미지

madhatter wrote:
자꾸 반복되는 질문입니다만, 왜 RDB와 객체 지향이 대립이 되어야 하는 개념인가요? 그러면 현재의 RDB를 사용한 모든 시스템이 객체 지향적이 아니다란 말씀이신가요?
그리고 말씀하신대로 Cat 클래스가 getKitten(), getMate()를 가질 수도 있는 것이고 PetManager 에서 담당할 수도 있는 문제 아닌가 합니다. 또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

설마 취약한 점을 예로 드는 문제를 해결하기 위한 class 설계를 여기에 해달라는 말씀은 아니시겠지요? :wink:

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

다만 객체지향과 다른 방법들과의 차이점은 대상을 바라보는 시각의 차이
입니다.
RDB가 객체지향에서 문제점이 된것은 그 시각을 방해한다는 것입니다.

ORM, OODBMS 등등은 그런 문제를 해결하기 위해서 고안된 것입니다.
물론 Facade 패턴으로 RDB를 감출수도 있습니다.

madhatter의 이미지

fender wrote:

객체지향의 패러다임이 테이블의 상관관계로 표현할 수 없기 때문입니다. RDBMS로 객체지향적 구현을 할 수 없는 것이 아니라 그러기 위해선 ORM과 같은 별도의 복잡한 계층이 존재하지 않는 한 가능하지 않다는 뜻입니다.

별도의 복잡한 계층을 구현하는 게 객체 지향이 아니란 말씀이신지 아니면 객체 지향적인 솔루션을 사용하면 별도의 복잡한 계층이 필요 없으므로 진정한 객체 지향이란 말씀이신지 정확히 파악이 안됩니다. Biz Logic 을 객체 지향적으로 가져갈 수 있으면 back-end 에서 어떤 꽁수를 쓰건 사실 이건 객체 지향적 개발 방법이 아닌가요?

fender wrote:

'객체지향'은 단지 구조체 대신 클래스를 쓰고 펑션을 메소드 라고 부르는게 아니라는 건 아시리라 믿습니다. 말씀하신 것은 어미 특정 고양이의 이름으로 새끼고양이를 찾는 '기능'을 구현한 별도 프로그램 단위를 만든다는 뜻입니다. 고양이의 이름을 특정 '함수'에 넘기면 새끼 고양이 이름 배열을 반환한다. 이건 철저하게 절차지향적인 사고 방식이 아닌지요?

고양이 클래스가 새끼 고양이를 찾는 메쏘드를 가지는가 안가지는가는 그런 기능이 필요한가 안필요한가의 문제이지 별도 기능의 프로그램 단위를 만든다고 해서 객체 지향이 아니란 것은 납득이 가지 않습니다. 새끼 고양이를 찾아주거나 배우자 고양이를 찾아주는 PetManager 혹은 가족사랑 class가 존재한다는 것이 무슨 문제가 되는가요? 객체 지향에 is-a 개념만 존재하는 것은 아닐텐데요.

fender wrote:

객체지향적 사고방식에서는 특정 고양이의 새끼 고양이를 알고 싶으면 해당 고양이 인스턴스의 getter를 호출해서 새끼 고양이 '이름 배열'이 아닌 실제 새끼 고양이 인스턴스들의 묶음을 가져와야 합니다. 이는 RDBMS에서 FK로 레코드를 참조하는 것처럼 객체지향 패러다임의 가장 단순하고 기본이 되는 부분입니다.

class의 어트리뷰트가 아닌 인스턴스 묶음을 가져와야 객체 지향이라고 말씀하시는 건가요? 그럼 말씀하신대로 getter 호출시에 Instance의 어트리뷰트를 가져오는 SQL 을 back-end에 매핑하면 되겠군요. 이걸 자동으로 해주는가 back-end 에 매핑이 필요한가가 객체 지향이냐 아니냐를 구분짓는 거라고는 생각지 않습니다만..

pseudo 코드는 실력이 일천한 관계로 말로 푸는 논리도 부족하여 딱히 전체적인 그림이 떠오르질 않네요. :)

lenani의 이미지

madhatter wrote:
또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

중간에 끼어들어서 죄송합니다.
저도 이점이 궁금하군요.
어떻게 PetDAO로 상속을 받아서 SQL문을 조합하실 겁니까?

madhatter의 이미지

lenani wrote:
madhatter wrote:
또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

중간에 끼어들어서 죄송합니다.
저도 이점이 궁금하군요.
어떻게 PetDAO로 상속을 받아서 SQL문을 조합하실 겁니까?

어떻게 조합하길 원하시나요..?
잘 이해가 안가는 게 is-a 개념의 집합이 객체 지향적 설계인가요? 상속과 참조외에 타 class를 has-a 하면 안되는 것인지..그럼 rapping 이나 mapping 은 도대체 어떻게 구현을 해야 하는지요.

제 생각엔 객체 지향적 구현으로 entity bean 을 구현한다 하더라도 내부적으로 벌어지는 일들은 SQL mapping 에 다르지 않을 거라고 봅니다마는.. 전체적인 설계에서 하나라도 절차적인 개념이라고 볼 수 있는 부분이 있으면 객체 지향이 아닌 건가요? :oops:

lenani의 이미지

저는 공격적인 의도가 없습니다.
다만 어떻게 구현하실지가 궁금할 따름입니다.
혹시 공격적으로 받아들이셨다면 죄송합니다. :oops:

madhatter의 이미지

잠시 다른 얘기입니다만, 객체 지향에 대한 설명에서 항상 불만인 것은 그 개념 설명시 과거 개념(절차적, 구조적 개발 방법)에 대한 비판으로부터 객체 지향 개념을 끌어낸다는 것입니다.
설마 객체 지향적 방법과 절차적 방법에 교집합이 없다는 것은 납득이 가지 않습니다. 거꾸로 말해서 절차적 방법론으로 구현을 했다고 해도 거기에서 객체 지향적 요소를 발견할 수도 있는 것 아닐까요.

lenani의 이미지

madhatter wrote:
잠시 다른 얘기입니다만, 객체 지향에 대한 설명에서 항상 불만인 것은 그 개념 설명시 과거 개념(절차적, 구조적 개발 방법)에 대한 비판으로부터 객체 지향 개념을 끌어낸다는 것입니다.
설마 객체 지향적 방법과 절차적 방법에 교집합이 없다는 것은 납득이 가지 않습니다. 거꾸로 말해서 절차적 방법론으로 구현을 했다고 해도 거기에서 객체 지향적 요소를 발견할 수도 있는 것 아닐까요.

사실 과거 방식에 대한 단점이 존재합니다.
객체지향은 그 과거 방식이 단점이 존재하기 때문에 발생된 겁니다.
그건 어쩔수 없는 사실이지요.
만약 구조적 방법으로 지금의 거대규모 프로그램을 무리없이 만들수 있다면
아마 객체지향은 존재하지 못했을 겁니다.

하지만 객체지향이 어느날 하늘에서 떨어진 것은 아닙니다.
madhatter님의 말씀대로 분명히 교집합이 존재하고 생각보다는
상당히 큽니다.
다른점보다는 같은점이 더 많죠.

하지만 문제점은 구조적 방법 조차도 제대로 사용하기도 힘든다는 것입니다.
몇몇 선구자들은 구조적 방법에 한계를 느끼고 객체지향을 만들어
냈지만 사실 대부분의 사람들은 그 구조적 방법조차 제대로 사용하기
힘듭니다.
그렇기 때문에 객체지향은 배우기 힘듭니다.

저도 아마 책으로 객체지향을 배우려 했다면 지금도 괴로워하고 있었을
겁니다. :P

fender의 이미지

madhatter wrote:
별도의 복잡한 계층을 구현하는 게 객체 지향이 아니란 말씀이신지 아니면 객체 지향적인 솔루션을 사용하면 별도의 복잡한 계층이 필요 없으므로 진정한 객체 지향이란 말씀이신지 정확히 파악이 안됩니다. Biz Logic 을 객체 지향적으로 가져갈 수 있으면 back-end 에서 어떤 꽁수를 쓰건 사실 이건 객체 지향적 개발 방법이 아닌가요?

네 백단에서 어떤 꽁수를 쓰건 보이는 부분이 객체지향적이라면 객체 지향적이라고 할 수 있습니다. 하지만 그 '꽁수'는 사실상 EJB나 Hibernate와 같은 ORM 프레임워크를 만드는 수준이 될 것입니다. 그러니 대부분의 경우 기 구축된 ORM 솔루션 등을 쓰는 것이고 이런 방식을 이용하기 위해선 탑다운 설계가 가장 적합합니다.

즉, 제가 주장하는 핵심은 (1) 객체지향적 접근법과 RDBMS 중심적 접근법에는 큰 차이가 있다 (제가 처음 생각해낸 것도 아니고 'impedance mismatch'라는 개념이 있습니다 (2) (1)을 해소하기 위해서 직접 SQL을 써서 구현하려면 엄청난 노력이 든다 (3) 따라서 다양한 ORM 솔루션을 활용하는 것이 훨씬 합리적이다라는 것입니다.

madhatter님께서는 (2)번에 대한 반론으로 다양한 예시를 들고 계시지만, 이는 객체지향/RDBMS의 간극을 해소하는 해결책이 아니라 RDBMS 중심적 접근 방법으로 예시로 제시된 고양이 문제를 풀 수 있다는 내용으로 논지와 관계가 없습니다.

madhatter wrote:
고양이 클래스가 새끼 고양이를 찾는 메쏘드를 가지는가 안가지는가는 그런 기능이 필요한가 안필요한가의 문제이지 별도 기능의 프로그램 단위를 만든다고 해서 객체 지향이 아니란 것은 납득이 가지 않습니다. 새끼 고양이를 찾아주거나 배우자 고양이를 찾아주는 PetManager 혹은 가족사랑 class가 존재한다는 것이 무슨 문제가 되는가요? 객체 지향에 is-a 개념만 존재하는 것은 아닐텐데요.

madhatter wrote:
잘 이해가 안가는 게 is-a 개념의 집합이 객체 지향적 설계인가요? 상속과 참조외에 타 class를 has-a 하면 안되는 것인지..그럼 rapping 이나 mapping 은 도대체 어떻게 구현을 해야 하는지요.

"상속과 참조 외에 has-a 관계가 있는 것"이 아니라 is-a가 상속이고 has-a가 바로 참조입니다. 약간 혼동하신 것 같군요. Cat이 getKittens()으로 다른 Cat 인스턴스를 참조하는게 바로 'has-a' 관계 입니다. 그리고 객체 지향에서 has-a는 다른 객체를 대표하는 PK가 아니라 바로 그 객체 자체를 참조해야 합니다.

즉, ORM 계층을 따로 만들기 전에 단순한 SQL 쿼리로는 has-a든 is-a든 구현이 어렵습니다. 상속과 참조는 객체지향의 핵심입니다. PK개념이 없고 join이 안되는 데이터베이스를 'RDBMS'라고 부르지 않는 것과 같습니다.

madhatter wrote:
pseudo 코드는 실력이 일천한 관계로 말로 푸는 논리도 부족하여 딱히 전체적인 그림이 떠오르질 않네요. :)

저는 단순 SQL로 제시해드린 예시를 구현하기 어렵다고 말씀드렸는데 이게 가능하다고 말씀하신다면, 제가 왜 안되는지 설명하는 것보다 madhatter님이 간단하게라도 어떻게 가능한지 보여주시는게 빠를 것 같아서 말씀드린 겁니다 :)

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

gurugio의 이미지

저는 객체지향이 뭔지 전혀 몰랐는데요

얼마전부터 씨로 클래스 비슷한 거를 만들어서 객체지향을 흉내내면서

코딩하고 있는데 많이 편합니다.

설계에 편하고 모듈화나 레이어 구분이 편해서

좋은 점들이 매우 많다는 것을 느꼈습니다.

역시 먹어봐야 맛을 아는 것 같습니다.

하지만 속도는 좀 불만입니다..

꼭 STL등 고급 프로그래밍 기술을 배워서 쓰고 싶습니다.

여하튼 당장은 프로젝트에서 설계를 할때 객체 개념을 도입하니까

설계가 명쾌해져서 좋습니다.

lenani의 이미지

madhatter wrote:
lenani wrote:
madhatter wrote:
또 제 예시는 단지 RDB에서 method의 재귀적 호출이 왜 문제가 되는가에 대한 것입니다. 제 3의 유틸 클래스에 묻는 게 문제가 된다면 Cat 을 위해서 DAO class 를 상속받아 PetDAO 를 만들면 될 일입니다.

중간에 끼어들어서 죄송합니다.
저도 이점이 궁금하군요.
어떻게 PetDAO로 상속을 받아서 SQL문을 조합하실 겁니까?

어떻게 조합하길 원하시나요..?
잘 이해가 안가는 게 is-a 개념의 집합이 객체 지향적 설계인가요? 상속과 참조외에 타 class를 has-a 하면 안되는 것인지..그럼 rapping 이나 mapping 은 도대체 어떻게 구현을 해야 하는지요.

제 생각엔 객체 지향적 구현으로 entity bean 을 구현한다 하더라도 내부적으로 벌어지는 일들은 SQL mapping 에 다르지 않을 거라고 봅니다마는.. 전체적인 설계에서 하나라도 절차적인 개념이라고 볼 수 있는 부분이 있으면 객체 지향이 아닌 건가요? :oops:

is-a 나 has-a 아무거나 사용해도 상관 없습니다.
지금 madhatter님은 객체지향을 기존방식의 대립되는 것으로 생각하시는것
같은데요.
저는 그렇게 생각하지 않습니다.
객체지향은 그냥 사용해서 얻는 이익이 잃는 손해보다 더 많을때 사용하시면
됩니다.

하지만 분명한 것은 망치만 가지고 있는 목수와 망치와 톱까지 가지고 있는
목수는 분명히 차이가 있다는 것 입니다.
망치가 필요할때도 있고 톱이 필요할때가 있습니다.
객체지향은 그냥 용도에 맞게 사용하시면 됩니다.

lenani의 이미지

fender님 궁금한게 있는데요.
방법론은 어떤것을 사용하십니까?

fender의 이미지

lenani wrote:
fender님 궁금한게 있는데요.
방법론은 어떤것을 사용하십니까?

음... 방법론이 산출물 관리나 요구조건 수집방법 등등을 포괄하는 개념이라면, 대부분의 경우 제가 개발만 담당하는 프리랜스 입장에서 방법론까지 정할 수 있는 경우는 거의 없습니다.

개발 쪽만 국한해서 말씀드리면 느슨하게 XP 쪽을 따르고 있습니다. 어차피 XP 자체도 산출물 중심적인게 아니라 사실상 'best practice'를 모아놓은 원칙에 가깝기 때문에 적합한 내용을 적용하는데 크게 무리는 없습니다.

일단 소스관리시스템의 사용, 자동화된 빌드, 빠른 이터레이션, 필요한 경우 단위 테스트 작성, 코딩 컨벤션을 자동으로 적용해서 코드 공유개념을 도입 등은 필수적으로 적용합니다.

그 밖에 방법론이라고 하긴 뭐하지만 계속 이야기가 나온 자동화된 퍼시스턴스 프레임워크, 로깅 프레임워크, 경량 컨테이너, MVC 프레임워크, 메타데이터를 이용한 산출물 생성 등은 프로젝트에 맞춰 필요한 경우 적용하고 있습니다.

여기 계시는 분들은 이런 부분들이 상식적으로 받아들여지실지 모르지만 솔직히 실무, 특히 웹 SI에서 CVS라도 쓰고 있는데는 별로 없는 것 같더군요 -_-;

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

morning의 이미지

오랫만에 눈이 좀 많이 넓어지는 쓰레드이군요.
그냥 저는 낮은 수준에서 제가 객체지향을 사용하지 못하는 이유를 말씀드리고 싶습니다
결론은 조금 황당합니다 ^^

저는 줄코딩으로 작업합니다.
그래서 가끔 스스로의 스킬도 넓혀보고
편하고 장점 많은 객체스타일로 작업하고자 시도 해보았지만
급한 시간때문에 손에 익숙한 줄 코딩의 바닥을 벗어나지 못하고 있습니다.

그래서 적당한 수준에 재사용이 편하게 할려고 모듈화 작업했었습니다.
작업하면서 생성되는 모듈들을 유심히 살펴보니 90% 이상 비슷한 것들이 많더군요.
객체라는 개념이 왜 나오고, 사람들이 객체를 노래부르는 이유를 알겠더군요.
그래서 저도 낮은 수준이나마 객체화된 작업을 할려고 했지만 잘 안되더군요.
옹색한 변명을 하자면 쉘과 에디트의 강력함 때문입니다.
vim, grep, sed... 이런 것들로 줄코딩 노가다 조금(?) 자동화가 되니
스스로 작업방식을 업그레이드 못하고 있습니다.

비록 줄코딩이지만 혼자 576000줄 짜리 프로젝트를 완성했습니다.
버그가 매우적고 유지보수 잘하고 있습니다. 위에서 말한 에디트와 유틸의 덕택입니다.
저의 작업에서 힘들었던 것은 프로젝트의 명확한 설정과 그에 따른 기획이더군요.
혼자 기획,설계,코딩하다 보니 작업 시간의 80% 이상이 업그레이드이더군요.

이상! 조금 옆으로 빠진 이야기 였습니다.

조르바와 함께 춤을....

lenani의 이미지

morning wrote:
저는 줄코딩으로 작업합니다.
그래서 가끔 스스로의 스킬도 넓혀보고
편하고 장점 많은 객체스타일로 작업하고자 시도 해보았지만
급한 시간때문에 손에 익숙한 줄 코딩의 바닥을 벗어나지 못하고 있습니다.

그래서 적당한 수준에 재사용이 편하게 할려고 모듈화 작업했었습니다.
작업하면서 생성되는 모듈들을 유심히 살펴보니 90% 이상 비슷한 것들이 많더군요.
객체라는 개념이 왜 나오고, 사람들이 객체를 노래부르는 이유를 알겠더군요.
그래서 저도 낮은 수준이나마 객체화된 작업을 할려고 했지만 잘 안되더군요.
옹색한 변명을 하자면 쉘과 에디트의 강력함 때문입니다.
vim, grep, sed... 이런 것들로 줄코딩 노가다 조금(?) 자동화가 되니
스스로 작업방식을 업그레이드 못하고 있습니다.

비록 줄코딩이지만 혼자 576000줄 짜리 프로젝트를 완성했습니다.
버그가 매우적고 유지보수 잘하고 있습니다. 위에서 말한 에디트와 유틸의 덕택입니다.
저의 작업에서 힘들었던 것은 프로젝트의 명확한 설정과 그에 따른 기획이더군요.
혼자 기획,설계,코딩하다 보니 작업 시간의 80% 이상이 업그레이드이더군요.

옜날에 KLDP 에서 주최하는 세미나에 참석한 적이 있습니다.
한참을 서서 들어야 했기 때문에 조금더 일찍왔으면 좋았을걸 하는 생각도
했었는데요.
그때 주제가 VIM의 사용법과 Thread 프로그래밍으로 기억하고 있습니다.

그때 발표자 분께서 VIM을 사용하는 것을 보고 깊은 인상을 받았었습니다.
그래서 저도 VIM을 배워보자라고 생각했었는데 지금은 VIM 대신 다른 것을
사용하고 있습니다.
개인적으로 손을 많이 움직이는게 싫어서요.
지금 사용하고 있는 것은 emacs, eclipse, scite 입니다.

VIM, GREP은 알겠는데 SED는 사용해본적이 없어서 한번 찾아봤습니다.

GNU wrote:
Sed (streams editor) isn't really a true text editor or text processor. Instead, it is used to filter text, i.e., it takes text input and performs some operation (or set of operations) on it and outputs the modified text. Sed is typically used for extracting part of a file using pattern matching or substituting multiple occurances of a string within a file.

저는 VIM의 RE와 비슷한 것으로 받아들였습니다.

어느정도 반자동(?)화 된 도구들이 코딩을 상당히 편하게 해주는것은
사실입니다.
저도 즐겨 사용하고 있습니다.

ps. 그런데 조르바처럼 살고 계십니까?

lenani의 이미지

fender wrote:
lenani wrote:
fender님 궁금한게 있는데요.
방법론은 어떤것을 사용하십니까?

음... 방법론이 산출물 관리나 요구조건 수집방법 등등을 포괄하는 개념이라면, 대부분의 경우 제가 개발만 담당하는 프리랜스 입장에서 방법론까지 정할 수 있는 경우는 거의 없습니다.

개발 쪽만 국한해서 말씀드리면 느슨하게 XP 쪽을 따르고 있습니다. 어차피 XP 자체도 산출물 중심적인게 아니라 사실상 'best practice'를 모아놓은 원칙에 가깝기 때문에 적합한 내용을 적용하는데 크게 무리는 없습니다.

일단 소스관리시스템의 사용, 자동화된 빌드, 빠른 이터레이션, 필요한 경우 단위 테스트 작성, 코딩 컨벤션을 자동으로 적용해서 코드 공유개념을 도입 등은 필수적으로 적용합니다.

그 밖에 방법론이라고 하긴 뭐하지만 계속 이야기가 나온 자동화된 퍼시스턴스 프레임워크, 로깅 프레임워크, 경량 컨테이너, MVC 프레임워크, 메타데이터를 이용한 산출물 생성 등은 프로젝트에 맞춰 필요한 경우 적용하고 있습니다.

여기 계시는 분들은 이런 부분들이 상식적으로 받아들여지실지 모르지만 솔직히 실무, 특히 웹 SI에서 CVS라도 쓰고 있는데는 별로 없는 것 같더군요 -_-;


음...
XP를 사용하고 계시군요.
pynoos의 이미지

lenani wrote:
fender wrote:
lenani wrote:
fender님 궁금한게 있는데요.
방법론은 어떤것을 사용하십니까?

음... 방법론이 산출물 관리나 요구조건 수집방법 등등을 포괄하는 개념이라면, 대부분의 경우 제가 개발만 담당하는 프리랜스 입장에서 방법론까지 정할 수 있는 경우는 거의 없습니다.

개발 쪽만 국한해서 말씀드리면 느슨하게 XP 쪽을 따르고 있습니다. 어차피 XP 자체도 산출물 중심적인게 아니라 사실상 'best practice'를 모아놓은 원칙에 가깝기 때문에 적합한 내용을 적용하는데 크게 무리는 없습니다.

일단 소스관리시스템의 사용, 자동화된 빌드, 빠른 이터레이션, 필요한 경우 단위 테스트 작성, 코딩 컨벤션을 자동으로 적용해서 코드 공유개념을 도입 등은 필수적으로 적용합니다.

그 밖에 방법론이라고 하긴 뭐하지만 계속 이야기가 나온 자동화된 퍼시스턴스 프레임워크, 로깅 프레임워크, 경량 컨테이너, MVC 프레임워크, 메타데이터를 이용한 산출물 생성 등은 프로젝트에 맞춰 필요한 경우 적용하고 있습니다.

여기 계시는 분들은 이런 부분들이 상식적으로 받아들여지실지 모르지만 솔직히 실무, 특히 웹 SI에서 CVS라도 쓰고 있는데는 별로 없는 것 같더군요 -_-;


음...
XP를 사용하고 계시군요.

설마 Windows XP 를 사용하고 계시군요라고 말씀하신것은 아니죠? :)

lenani의 이미지

pynoos wrote:

설마 Windows XP 를 사용하고 계시군요라고 말씀하신것은 아니죠? :)

:P 하하하~~~
저는 농담 잘하시는 분이 좋습니다.

lenani의 이미지

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

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

페이지

댓글 달기

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