객체지향 웹 개발 방법론?
글쓴이: 이정욱 / 작성시간: 수, 2002/02/27 - 10:36오전
안녕하세요, 날씨가 점점 봄 같아지는 것 같습니다.
OO 개발론을 웹 환경에 어떻게 적용시켜야 하는지 여러분들의 의견을 듣고자 글 올립니다. 일반적인 클라이언트 혹은 C/S 환경에서는 OO 개발 방식이 큰 무리가 없이 적용되는 것 같습니다. 그런데 웹 프로그래밍에서는 OO 개발론이 잘 어울리지 않는 것 같습니다. 일단 웹 환경이 request/response가 주가 되는 환경이고, OO 개발론을 사용하게 되면 일단 구성요소들의 모델링과 각각의 request에 관한 처리 부분, repository에 관한 - DB, LDAP, ... - 부분 등, 개발 자체가 너무 과다한게 아닌가 싶은 생각도 듭니다. 그런다고 무조건 request 단위로 개발 할 수도 없는 노릇이구요. 기존의 struts 나 jdf 등의 프레임웍도 사용하다보면 이것도 아니고저것도 아닌 스타일의 프로그램이 되는 것 같아, 굉장히 혼란스럽습니다.
물론 이런 일련의 사태-_-가 내공 부족이라는 거 잘 알고 있지만, 미리 경험하신 분들의 의견을 듣고 싶습니다~ 그럼, 좋은 하루 되세요.
댓글
일단 왜 OO 로 하려고 하는지 자기 자신에게 되묻는 것이 중요하다고 생
일단 왜 OO 로 하려고 하는지 자기 자신에게 되묻는 것이 중요하다고 생각합니다.
OO 가 모든 문제를 해결해주는 만병통치약인지 물어보고 싶습니다.
OO 역시 많은 방법 중 하나라는 사실을 알아주시길.
나는.잘난척에 바쁜 몇몇 인간들의 허무맹랑한 OO적 신기술을 포함
나는.
잘난척에 바쁜 몇몇 인간들의 허무맹랑한 OO적 신기술을 포함한 제안서와 프로젝트 진행에 의하여.
아직 준비가 안 된 실제 개발자들의 과다노동을 유발하고
그 과다노동이 "능력부족"으로 격하되는 분노스런 일들을 보아왔다.
정말 멋진 표현이네요.가슴 뭉클합니다.. ㅠ_ㅠ코딩 시다바리가
정말 멋진 표현이네요.
가슴 뭉클합니다.. ㅠ_ㅠ
코딩 시다바리가.
일단 HTTP구조..즉 request/response구조가 OO를 구현하
일단 HTTP구조..즉 request/response구조가 OO를 구현하는데 문제가 있는 말은 설득력이 없습니다. OO의 관점이 그렇게 단순한것 많은 아니죠. 만약에 각 Compoent들을 SOAP로 실어 보내면 그건 OO가 아닌건 아니죠.
그리고 배치관점에서 OO로 본다면 이미 OO의 개념은 여러분의 수만은 web 프로그래밍에 이미 들어가 있습니다.
Web OO계발론으로는 UML의 창시자들이 모여있는 rational사의 rational 방법론을 참조하시기 바랍니다. rational process는 기본 web방법론입니다.
그리고 MVC에 관한 문제인데요..이건 단지 OO의 수만을 방법론중 하나일 뿐입니다. 그리고 MVC구조는 따른다고 해서 꼭 좋은 프로그램이 나오는 것은 또한 아닙니다.
MVC가 유명한 이유는 상대적으로 이해하기 쉬으며 상대적으로 괜찮은 구조의 결과물을 생성할 수 있기 때문입니다.
RUP는 웹을 전제로 만들어진 방법론이 아닙니다.실제 웹사이트 제작을
RUP는 웹을 전제로 만들어진 방법론이 아닙니다.
실제 웹사이트 제작을 RUP를 위해 설계하기 위해서는 레셔날에서도
익스텐션 사용을 권고하고 있습니다. ( 레셔날 자체의 자료에 근거 )
오브젝트를 웹페이지 단위로 변형시켜놨더군요.
그리고 대개의 웹사이트 프로젝트가 단기간(6개월 안쪽)에 끝나는
현실을 감안할때 웹사이트 프로젝트에 전면적인 RUP적용은 상당한 오버헤드를
가져옵니다.
제가 생각할때도 RUP은 상당한... 말 그대로 상당한 오버헤드 입니다.
제가 생각할때도 RUP은 상당한... 말 그대로 상당한 오버헤드 입니다.
한 두번쯤 회사내에서 실험해 봤습니다만... xp 가 그런대로 어울리지 않나
싶네요. 특히나 우리나라 같은 상황에서는 초기 설계가 얼마나
쓸모가 있을지..
초기설계는 얼마나 쓸모가 있냐는 말씀에 몇글자 긁적여봅니다.분명 설계
초기설계는 얼마나 쓸모가 있냐는 말씀에 몇글자 긁적여봅니다.
분명 설계란 기간 자체는 주어지지만 그렇게나 충분히 주어지지 않고,
기간 중간중간 내에 무리한 산출물을 바라는 상황에 문제가 있긴하지만,
상황이 어떻건 초기설계의 유용성과 필요성 자체를 의심하시면 않되죠~ :)
이러한 부분이 빠진채 간다는 건, 마치 가느다란 막대 위에 산을 올린다는 느낌입니다.
음.. 그리고 xp와 rup에 대해서 개인적 잡담을 좀 해보면,
4명 프로젝트에서 management작업과 방향을 제시할 PM이
RUP를 따라간다 했을 때, 작업의 효과적 진행에
1. 너무 많은 부하와(too much to do)
2. 어떠한 원인에 있어서 설계와 구현도중, 다시 거슬러 올라가거나 변경의 사태가 발생한다면, 그 많은 작업들은 초~~기 단계까지 수포로 돌아갑니다.
(목적변경, 범위확장 기타 등
rup는 느릿하고, 부하가 큰만큼 철저하게 다져가긴 하지만, 그건 대규모의 프로젝트에 해당하는 경우에 해당되는 얘기라서 실제 실무를 하면서 그대로 적용한다고 하면 이러한 작업마저 해야하는가..라는 느낌을 받게 되더군요..
xp와 비교한다면 rup를 생각하다가 xp를 생각하면 몸이 가벼워진다는 느낌이 들 정도입니다. 휴..
어쨌든 회사내에 그러한 부분이 따로 잡혀져 있지 않은 특성상,
개인적으로 현재 xp를 최대한 적용을 해서 프로젝트를 진행중이고,
나름대로 많은 효과를 보고 있답니다.
특히나 잦은 변경과, 빠른 결과를 확인하길 원하는 분위기상 -_-;;
Test First Programming은 말할 것 없이 감동을 줍니다.
(훌륭한 제품이 될 수 있는 것을, 중치로 만들어서 대충판다는 것에서 비애를 느낍니다.T-T
아..참.. white indexed card를 얘기하고 싶네요
참가자로 하여금 공유라는 문제 자체가 발생할 수 없게 만듭니다.
웃으면서 카드를 주고 받으면서 어플리케이션을 돌리는 거 재미있더랍니다.
나중에 uml로 표기야 하겠지만,
uml그려놓고 세세히 표현하기 힘든
감정적 문제라던가 느낌을 같은 팀원들이 문서를 보고
알아서 그러한 느낌마저도 이해하기를 바란다거나,
혹은 직접 설계한 사람이 말로써 일일이 표현하고
머리나 가슴속까지 뛰어들어서 알려주기는 매우 힘이 들었는데,
이렇게 한번 모두가 참가해 보면 완벽히는 아니지만, 어느정도는 공유되더군요..
특히나 자신이 설계중간에 산출물 모듈을 자신이라고 주체를 이입시키는 효과란 정말 말할 수가 없더군요..
얘기가 삼천포로 빠지기 시작하네요..
마지막으로 하나, 이른바 '말로 돌리는 어플리케이션'을 경험해 보시면 어떨까 싶네요..
제 생각에도 조그만 프로젝트에 RUP를 적용하는 것은 무리가 있는 것 같
제 생각에도 조그만 프로젝트에 RUP를 적용하는 것은 무리가 있는 것 같습니다. RUP에 보면 어떠한 규모에도 적용 가능하도록 커스터마이즈 할 수 있다고 누누히 강조되있지만 아무래도 XP에 비해선 overkill이라는 느낌이 들 때가 많습니다.
무엇보다 프로젝트 매니저 뿐 아니라 팀원들 모두가 RUP에서 요구하는 그 많은 산출물에 대한 필요를 공감하지 못하는 이상 문서를 위한 문서가 되버리는 경우가 많습니다.
단지 XP에서 웹개발에 적용하기 가장 난감한 부분이 테스팅인 것 같습니다. 우선 유닛테스트 환경을 갖추기도 쉽지 않지만 잦은 UI변경이나 사람이 직접 결과를 확인해야 하는 상황이 자주 발생하다 보니 클라이언트 환경에비해 효용성이 떨어지는 것 같습니다.
얼마전 JUnit + Cactus + StrutsTest를 연동해서 간단한 J2EE어플리케이션에 대한 유닛테스트를 시도했는데 액션에서발생할 수 있는 모든 상황에 대해 일일히 테스트케이스를 만드는 것은 거의 불가능해보였고, 어플리케이션 자체보다 테스트케이스 디버깅에 더 많은 시간이 들었습니다. 제가 아직 관련 라이브러리에 대한 경험이 부족해서 그랬을지 모르지만 어쨌든 클라이언트 프로그램의 경우보다 훨씬 많은 오버헤드가 나더군요.
더구나 유닛테스팅이 의미가 있으려면 개별 개발자들이 최대한 자주 테스트를 수행해야 하는데 테스트 한 번마다 패키징-재배포, 심지어는 서버 재시작이 필요하다는 건 생산성 측면에서 결코 바람직한 상황은 아니었습니다.
OOP에 대한 내용은 아니지만 이왕 웹개발과 XP 이야기가 나온김에 웹환경에서의 테스트에 대해 경험있는분들의 의견을 구하고 싶습니다.
그럼~
OO와 레이어 분리가 반드시 상관이 있는 개념인가요?OO자체에 레이어
OO와 레이어 분리가 반드시 상관이 있는 개념인가요?
OO자체에 레이어분리가 포함되어있는건 아니라고
알고 있는데요.
OO방법론(예를 들어 RUP같은)에 레이어분리같은
것들이 포함되어 있는건 사실이지만, 그건 "방법론"
차원에서 들어간것이지 거기서 핵심이 "OO"에 있는건
아닙니다.
그리고 레이어분리는 OO가 아니라도 충분히 가능합니다.
> ...>>그러니 웹프로그래밍에서는 먼저 OO를 생각하기 보다는
> ...
>
>그러니 웹프로그래밍에서는 먼저 OO를 생각하기 보다는 어떻>게 작업을 능률적으로 분리할 수 있을 것인가?
>를 생각하게 되는 것이고.. 능률적으로 분리할 수
>있는 방법에 대하여 알아내었다면 그다음부터
>프로그래머는 자신의 모듈을 작성하는데 OO의 개념을
>가지고 작성하게 되는 것입니다.
디자이너와 협업, 개발 분야를 능률적으로 분리하는 것을
먼저 생각하고, 그 다음 프로그래머의 모듈을 만든다...
비지니스 로직보다 개발 능률이 먼저...
음 뭔가 아닌 듯 한데요.
jsp, 서블릿으로 쉭 만들어버리는
프로젝트가 아니라면 뭔가 문제가 있지 않을까요?
아래에 쓴 조기태님의 의견과 저의 의견이 같네요 ^^저가 말하고자
아래에 쓴 조기태님의 의견과 저의 의견이 같네요 ^^
저가 말하고자 하는 것은 OO가 왜 사용되느냐라는 것입니다.
프로젝트가 OO를 위하여 존재하는 것이 아니라,
OO가 프로젝트를 위하여 존재한다라는 것이 저의 생각입니다.
그렇기 때문에 많은 사람들이 함께 작업하는 웹 프로젝트에서는
프로그래머 입장만을 따질 수는 없겠지요.
어떻게 작업을 분리할 것인가를 생각을 한다음에야 비로서
비지니스 로직에 대하여 생각을 할 수 있다고 생각을 합니다.
비지니스 로직을 제대로 작성되기 위하여 선행 조건이라는 것이지요.
프로그래밍 쪽만 보지 말고, 전체 프로젝트를 본다면 저의 말에 대하여
이해하리라 생각됩니다.^^
기획자, 프로그래머, 디자이너, 업체사장등도 모두 만족시키는 것이
좋은 방향 같다는 생각이 듭니다.
OO개발의 웹환경에 대하여 어떻게 적용할 것인가? 라는 첫글에대하여
OO개발의 웹환경에 대하여 어떻게 적용할 것인가? 라는 첫글에
대하여 도움이 될까하고 쓴 글인데 ( 처음 OO를 이용하여
웹을 이용하는 분 ) 저의 글을 보고 너무 심각하게는 생각하지
말아주세요 ^^
음... 아랫분의 말씀은 비즈니스 로직보다 능률이 우선한다는게 아니라 M
음... 아랫분의 말씀은 비즈니스 로직보다 능률이 우선한다는게 아니라 MVC 계층간의 분리가 효율적으로 OOP를 구현하기 위한 전제 조건이 된다는 뜻이 아닌지요?
아무리 프로그래머의 능력이 뛰어나도 웹 디자인을 적용하기 위해 디자이너가 만든 HTML에 수도없이 out.println이나 <%=...%> 등을 써넣다보면 OOP 적인 개발과는 동떨어진 결과를 가져오겠지요.
또한 비즈니스 로직만이 들어가야 할 부분에 리퀘 스트 변수 명이나 포워드할 페이지 URL 같은 프리젠테이션 관련 로직이 섞이는 상황이 되면 아무리 다른 부분에서 OOP 적인 개념에 충실했다고 해도 정작 OOP를 도입함으로써 얻을 수 있는 확장과 유지보수의 용이성 등을 포기하게 되지 않을까 생각합니다.
웹어플리케이션에서 디자인적 고려사항의 핵심은, 프레임워크를 사용하던 직접 관련 클래스를 만들던 간에 어떻게 하면 계층간의 분리를 실현할 수 있을까 하는 점입니다.
이 글 쓰신 분께 질문 하나 드리겠습니다~비즈니스 로직과 프리젠테
이 글 쓰신 분께 질문 하나 드리겠습니다~
비즈니스 로직과 프리젠테이션 로직, 콘트롤 부분 등만을
효과적으로 분리하는 것이 음... 예를 들면 쇼핑몰에서
상품, 카트, 구매자, 공급자 등의 객체를 미리 모델링하는 것보다 중요하다고
생각하시는지 궁금합니다.?
이거 질문이 좀 엉성한데요, 질문의 포인트는 웹환경에서는 객체의 모델링이
레이어의 분리보다 중요하지 않은지 입니다.-_-;;;
흘... 그런 뜻이 아니었는데... ^^;문제는 계층의 분리와 적
흘... 그런 뜻이 아니었는데... ^^;
문제는 계층의 분리와 적절한 모델링 중에 양자택일하는 상황이 아닙니다. 당연히 둘 다 중요합니다. 아니 다 떠나서 어쨌든 빠른 시간안에 이해하기 쉽고 유지보수 가능한, 그리고 경우에 따라 이식이나 확장이 가능한 코드를 만드는게 목적입니다.
OOP에서 보통 객체는 비즈니스적으로 의미있는 개념들을 나타내며 이 때 관련이 없는 객체 사이의 연관성(커플링)을 최소화 하는 것이 중요할 것입니다.
예를들어 쇼핑몰의 '상품'을 구현하는 객체에 상품을 읽어오려면 어떤 데이터베이스에 어떤 계정으로 접근해서 어떤 테이블을 읽어와야 하는지에 대한 정보가 들어가는 것이 필수적일까요?
혹은 '주문' 프로세스를 구현하는 객체가 주문 완료 후에 어떤 url로 어떤 리퀘스트 파라메터를 가지고 포워드 되어야 하는지를 결정하는 것이 OOP 적인 방법일까요?
이런 경우 보통 프리젠테이션 계층에 와서는 아예 전적으로 OOP와는 관계 없는, 스크립팅에 가까운 방식으로 처리 결과를 HTML으로 변환하곤 합니다.
핵심은 OOP적 모델링이 계층의 분리보다 안중요하다는게 아니라 그러한 모델링 방식을 웹어플리케이션에 적용하기 위해서는 계층을 깔끔하게 분리해주는 별도의 방식 - 예를들어 MVC 프레임워크 - 이 필수적이라는 겁니다.
그리고 주의할 한 가지는 꼭 '상품', '카트', '구매자', '공급자'와 같은 데이터 모델링 만이 중요한 것은 아니라는 점입니다. 오히려 웹어플리케이션에서 OOP 적인 설계를 희생해야되는 경우는 대부분 사용자의 리퀘스트를 받아 처리하는 프로세스 부분이 아닌가 합니다.
그럼~
헉.. 글이 잘못 붙어버렸네요...
헉.. 글이 잘못 붙어버렸네요...
음.. 역시 중요한건 프레임웍인감 -_-;;;
음.. 역시 중요한건 프레임웍인감 -_-;;;
웹프로그래밍에서의 객체지향 이라고 말하기 전에일단. 무슨 웹프로그래밍
웹프로그래밍에서의 객체지향 이라고 말하기 전에
일단. 무슨 웹프로그래밍을 작성하느냐에 따라서
효율이 달라지기도 합니다.
보통, 디자이너와 프로그래머가 함께 작업을 한다면,
서로에게 도움이 될수 있도록 개발이 진행이
되어야 합니다.
디자이너는 디자인에 힘을쓰고, 프로그래머는
프로그래밍에 힘을써야 한다는 것이지요.
그렇게 하기 위하여는 몇가지 설계방식이 나오는데
그중에서 대표적인 것이 MVC 라는 것입니다.
일단 보여주는 쪽은 jsp로 만들고,
컨틀롤과 모델쪽은 servlet이나, 빈으로 만들게
되는 것이죠.
이때 보여주는 쪽은 순수하게 tag 로 되는 것이
좋습니다. 그래서 jsp 는 action tag 와 tag lib등을
지원해 주는 것입니다.
프로그래머는 프로그래밍 코드가 아닌 미리 태그에
대한 모양을 결정하여 놓고 ( 설계가 잘 되어야겠지요. )
디자이너에게는 태그에 대한 설명을 해주고 원하는 곳에 적어넣어라 라고 가르쳐 주면 됩니다.
태그라는 것이 프로그램의 코드가 아니기 때문에,
서로가 대화할때 거리감이 줄어들게 되지요.
그리고 프로그래머는 해당 태그가 출력하여 주는
결과를 만들어 주기위하여 객체를 만들어 주게 되는
것입니다.
그러니 웹프로그래밍에서는 먼저 OO를 생각하기 보다는 어떻게 작업을 능률적으로 분리할 수 있을 것인가?
를 생각하게 되는 것이고.. 능률적으로 분리할 수
있는 방법에 대하여 알아내었다면 그다음부터
프로그래머는 자신의 모듈을 작성하는데 OO의 개념을
가지고 작성하게 되는 것입니다.
--
게시판 프로그램을 만들었는데.. 어떤 경우는 게시판 관리 프로그램을 웹환경이 아닌, 어플리케이션으로 만들길 기대할 경우가 있습니다. 이럴때는 어떻게 해야 할까요?
그런것을 생각하는 것이 OO라고 생각을 합니다.
물론.. 게시판과 비슷한 기능의 웹프로그래밍을
만들때도 재이용할 수있도록 작성되는 것이 좋겠지요.
자바 관련 웹어플리케이션을 제작하면서 Ant, Log4J, XDoclet
자바 관련 웹어플리케이션을 제작하면서 Ant, Log4J, XDoclet 등 몇몇 프레임워크의 사용이나 패턴, 혹은 컨벤션 등이 표준으로 만들어지더군요.
주제와 관련있는 부분만 뽑는다면 CMP빈을 사용하는 EJB와 본문에서도 잠깐 언급된 Struts의 조합을 들 수 있습니다.
PetStore예제와 같이 웹 상에서도 이벤트 모델을 도입하는 수준까지는 아니지만 최소한 MVC(혹은 Model2)아키텍처를 최소한의 노력으로 구축할수 있게 도와줍니다.
이런 식으로 작업하면 JSP에 단 한 줄의 자바 코드 없이, 백엔드에도 한줄의 데이터베이스 관련 로직 없이 순수하게 객체 레벨에서의 개발이 가능해집니다.
물론 이런 것들이 OOP의 전부는 아니겠지만 최소한 HTML태그에 지저분한 스크립트가 섞이거나 비즈니스 로직과 퍼시스턴스, 혹은 보안 관련 로직을 구분하기 어려운 경우보다는 분명 한 단계 진보된 프레임워크라고 생각합니다.
그럼~
^^;제가 이런데 글을 달 실력이 아닌것은 같습니다만.제가 php같은
^^;제가 이런데 글을 달 실력이 아닌것은 같습니다만.
제가 php같은 경우 클래스를 주로 이용한 코딩을 했기
때문에, 저도 저의 생각에 대한 여러분들의 의견들을 묻고 싶어서 이렇게 한번글을 써봅니다.
저는, 오라클db를 사용하여(일반 연관db) xml데이타를
넣고 꺼내고 하는 작업을 했던 경험이 있었습니다.
그때 클래스 구현 한 것들이.
session관리
tag maker
request 처리하는 클래스.
sax
검색조건 처리하는 클래스.
db(저의 경우oracle을 조작하는 클래스, 인터페이스만 공통이 된다면 다른 MYSQL같은 것으로도 되는거죠)
위의 db를 이용해서 xml데이타가 db에 넣고 들어가는 작업을 수행하는 함수들(거창하지만 api처럼 , 이들을 이용해서 db를 조작하라고 하는 거죠..^^;)
뭐. 꼭 필요한 부분들만 적어보았습니다.
확실히 ,저의 처음목표는 (확실히 tag그리면서 또는
계속 sql문 쓰면서 코딩하는게 무척 싫었기 때문에^^;다들 그러시리라는)- 소스의 지저분함과 노가다를 막으려고 ,또 페이지 많이 만드는 것도 싫어해서..
하나의 페이지에서 모든내용을(가능한한) 처리 할수 있게 할려고 했었습니다.
확실히 소스코드에 tag나, sql이 많이 줄어 들고
실제 엔드 부분에서는 그런것들이 보이지 않기는 합니다만..
느낀 것은요..
실제 이런식으로 해보니까, 여간 잘 구상해 놓지 않으면 ,이런저런 부분만들고 하는 것들히 오히려 리퀘스트만 처리해서 끝내는 것보다 오래 걸릴수도있겠더라는 것입니다..(많은 경우가 그렇지요..^^;)
차라리 객체 쪽으로 한다면, 개발 쪽에서 라이브러리처럼 나중에도 혹시(?^^;) 쓸 수 있는 타입들로 개발을 먼저 하는게 훨씬 좋은 것 같습니다.
ASP,JSP같은 경우 보다 PHP 같은 경우 OO식으로개발되어있는 것이 아니기 때문에 더 골치 아팠던 것도 같기도 하구요..
xsql servlet을 공연히 구현하셨군요..php는 언어 특성상
xsql servlet을 공연히 구현하셨군요..
php는 언어 특성상 굳이 class를 쓰는 것 그리 맞지 않습니다.
깔끔하다고 하는 pear를 쓴 phpwiki소스를 봐도 한숨이 나오죠..
php는 내장함수와 collection을 이용해서 함수형으로 개발한게,
높은 효율과 개발생산성, 수정의 용이함을 가져오더군요..
억지로 ooad에 끼워맞추다 보면 php의 장점은 다 날아갑니다.
PHP는 함수형(?) 언어라서 OO식으로 개발하는 것이어울리지 않게됩
PHP는 함수형(?) 언어라서 OO식으로 개발하는 것이
어울리지 않게됩니다.
뭐 적용은 가능하지만 실제 업무에 들어가면
늘상 쫒기는 마감일과 클라이언트의 요구가 다양하기 때문에
OO식으로 하다가 결국 황금같은 시간만 더 들어가고
노력에 비해서 작업 결과는 미비하니까요.
경험상 작업 시간을 보면 PHP내장함수와 사용자 정의 함수 몇 개로 만든
사이트가 제일 제작하기도 수정하기도 편했습니다.
또한 맨 처음 실행되는 <??>안에 그 페이지 안에서 실행해야할
모든 작업을 마치려고 노력했기에 실제 디자인 부분에서
지져분하게 되지 않았던 점도 있었겠지요.
각설하고 PHP의 경우 OO적으로 하는 것은 실무에서는
별로 추천하고 싶지 않네요.
단순히 함수 라이브러리나 코드를 줄이기 위해 클래스를 사용할 수 도 있지
단순히 함수 라이브러리나 코드를 줄이기 위해 클래스를 사용할 수 도 있지만
OO 적이라고 하면 객체를 추상화 시켜서 구현해야 하는게 큰 문제거든요...
뭔자 OO적으로 -_-;;;; 어렵다...
확실히 OO 개발론의 웹에는 적용이 어려운 것 같습니다.'단지 c
확실히 OO 개발론의 웹에는 적용이 어려운 것 같습니다.
'단지 class 를 만들어 쓴다'리고 하는 것이 OO 개발론이
아니기 때문에 정말로 고민해야 할 부분이 많은 것 같습니다.
어떻게 추상화 할 것인지, 객체를 추상화 한 후에, 객체간의
메세지는 어떻게 처리할 것인지 - 객체안에 같이 설계할 것인지, 아니면 작업 단위로 만들 것인지 -
객체 모델링에 따른 오버헤드를 어떻게 처리할 것인지
아마 고민해야할 부분은 긑도 없는 것 같습니다.
아 .. 이거 ToT 저도 요즘 한참 고민하고 있습니다.많은 고수
아 .. 이거 ToT 저도 요즘 한참 고민하고 있습니다.
많은 고수님들의 경험 부탁 드립니다.~
댓글 달기