시작한김에 일단 제 밑천은 거덜냅니다. 더 글을 올리지는 않을 것입니다. (아는게 없는고로..) 누군가 최근에 반짝한(뒤로 어떻게되었는지는 저는 잘 모르는) X# 같은 데이터 지향적인 언어가 나와야한다는 논의가 비교적 최근에 있었고, 결국은 X#이 나왔는지 안나왔는지는 모르지만, MS는 충분히 광고를 했었는데.. 데이터 지향적 패러다임이 객체지향 진영에서 나온 얘기같던데.. (횡설수설이군요 -_-;) 그 얘기를 누군가 보충 설명으로 달아주시면 감사 ^^;

아래글은 pl/sql programming(orilly)의 일부입니다. pl/sql 에 객체지향적 특성이 추가되기 시작함에따라, 아마 저자는 그간 해오던 구조적 방식의 프로그래밍에서 객체지향을 볼 때 상당한 불만 또는 거부감이 있었나 봅니다. 어쨌든 이 사람은 구조적인 언어 하나로 큰 규모의 개발을 많이 한 전문가인 것은 사실..

————————-

옷벗은 황제 – 객체지향?

1. OOP는 광고와 달리 만능이 아니다.

2. 상속계층
– 실세상의 분할방식은 다수이다. 즉, OPTIMAL한 솔루션이 없다.
– 형의 진화는 쉬운일이 아니며, 더군다나 언제 어떻게 형이 진화할지 알지도 못하고 어떻게 설계를 하는가

3. 동작과 데이터를 모으면 항상 더 좋은가?
– 데이터는 잘 변하지 않으며 동작이 더 잘 변한다.
그런데도 모아두는 것이 좋은가? 잘 변하는 것과 잘 변하지 않는 것을 분리하는 것은 OOP의 목표중 하나가 아니었던가
– 데이터와 동작을 모아두는 객체를 강조하며서, 동시에 MVC구조를 통해 모델과 뷰와 컨트롤러를 분리하라는 이사람들이 옷을 입은 황제인가 아니면 벗고있는가? (이말은 논란의 소지가 있지만, 하여간 그대로 옮김)

4. 컴포넌트가 떠오른다
– 객체지향 패러다임이 지고 컴포넌트가 각광받고 있다. 컴포넌트란 인터페이스를 통해 통신하는 단위 유닛이다. 컴포넌트의 구성에 있어서 내부가 객체지향적 언어이든 구조적언어이든 상관이 없으나 객체지향 언어로 컴포넌트를 구성했다고 치자. 그렇다면 이건 완전한 모순이다. 왜냐하면 배포가능한 유닛은 컴포넌트이며, 객체는 배포가능한 유닛이 아니란 결론이 나온것이기 때문이다. 즉, 객체란 자신이 정의된 그 환경외에서 함부로 적용하고 배포할 수 있는 단위 유닛이 아니다.

5. 결과적으로 소프트웨어의 성공이란
– 전문적 개발자
– 좋은 절차와 좋은 개발 패러다임(XP든 RUP든 OOP든)으로 문제를 정의하고 해결
– 좋은 마케팅

6. ‘OOP로 짜야 좋은 S/W이다’ 는 항상 참은 아니다.