[EP님의 VO 사용 시 subclass로 불변, 가변을 지원하는 팁]를 보고..

밸류 오브젝트(Value Object)는 상태값을 가지는 객체이다.

가장 손쉬운 예가 numbers, dates, monies등이라고 할 수 있겠다.

DAO 패턴을 사용하면서 가장 많이 고민꺼리는
밸류 오브젝트는 어느정도의 로직을 가질 수 있는 것인가?
이었다.

이피님의 말로써는
Value Object는 무슨 짓을 하든 내부 상태만 바꾸지 않으면 Value Object입니다.

이라고 했다.

궁금증이 더해져서

오리지널 위키에 가보니
Domain Object라는 항목에 그 정의를 볼 수 있었다.
maintain business logic

결국 Value Object + Business logic = Domain Object
라고 생각하면 되겠다.
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 헉군

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2008/07/31 10:11
    댓글 주소 수정/삭제 댓글
    VO는 신뢰성면에서 중요한 객체입니다. context를 넘나들면서 값이 바뀌기 시작하면 디버깅도 어렵고 코드가 복잡해져서 몰락할수 있죠.
    • 2008/07/31 14:50
      댓글 주소 수정/삭제
      네 VO는 immutable한 것이 원칙적으로 맞다고 생각해요..
      validate 처럼 내부 값을 이용해서 새로운 정보를 찾는 경우 비즈니스 로직을 가지게 된다고 생각했어요.
  2. 2008/08/05 00:54
    댓글 주소 수정/삭제 댓글
    개인적으로는 정말 필요할 때가 아니면 불변 ValueObject 사용을 자제하는 것이 좋다고 생각하는데 왜냐하면 ValueObject가 불편 성격을 갖게되면 객체의 유연성이 떨어지고 JavaBean규칙을 따르는 iBatis와 같은 프레임웍에서 사용하기가 까다로와 지는 것 같아서야. 그렇다면 불변이 보편적인 경우에 항상 유용하냐라고 질문한다면 그것은 아니라고 생각하거든.

    이 부분은 사실 블로그에 쓰고 있는 주제이기도 한데 지금까지의 글쓰는 상태로 보아 언제 완성할지는 모르겠네 ㅋㅋ(아마 일년이 걸릴지도)
    • 2008/08/05 10:49
      댓글 주소 수정/삭제
      불변VO과 iBatis 지원 방식에 대해서는 EP님의 포스팅이 적절했던 것 같아.
      VO를 건들이기 시작하면 누가 건들였는지 알기 참 난감해져서..
  3. 2008/08/07 00:35
    댓글 주소 수정/삭제 댓글
    OOP에서 Value Object는 특이한 경우죠. 그래서 Object가 아니고 Value Object입니다. Value라는 수식어가 더 붙는 것이죠. OOP에서는 당연히 VO가 유용한 경우가 더 적습니다. 더 많았으면 VOOP가 되었겠죠. :-)

    하지만 일상적으로 많이 막 쓰는 객체는 Value Object여야 더 쓰기 편합니다. Integer, String이 Mutable이면 어떤 일이 일어날까요? Value Object가 아니여서 불편한 대표적인 예가 자바의 Date와 Calendar죠.

◀ PREV : [1] : ... [24] : [25] : [26] : [27] : [28] : [29] : [30] : [31] : [32] : ... [120] : NEXT ▶

BLOG main image
안녕하세요. 안정된 코딩, 여유로운 프로젝트, 떠오르는 코더 by 헉군

카테고리

분류 전체보기 (120)
direct (68)
indirect (29)
transmissive (13)
agenda (6)
idea (3)

달력

«   2010/02   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            

최근에 달린 레몬펜 쪽지

Statistics Graph