폰트 렌더러 클래스 다이어그램
DCGUI 라이브러리 :
2007/06/17 14:43
 UML은 처음 써보는데 기호를 맞게 쓴건지 모르겠네요 ㄱ- 여튼 위의 구조를 가질 예정입니다.. 어디까지 예정이므로 다 뒤집어질수도 있습니다 ㅋㅋ 위의 구조를 다시 한번 면밀히 검도해 보고 계속 작업을 진행해야겠습니다.  (0)  (0) |
'클래스 다이어그램'에 해당되는 글 1건
- 2007/06/17 폰트 렌더러 클래스 다이어그램 (5)
댓글을 달아 주세요
난 대학교 벡터방식그래픽프로그램프로젝트때 UML 써봤는데 유즈케이스랑 시퀀스다이어그램 그리고 클래스다이어그램만 알면
쓸만하게 되드라고 -_-a...
그렇근영
그려놓으신 UML을 보고 느낀점은 UML이 필요 이상으로 노트가 많다는 점입니다. 스케치 용도의 UML도 아니고 프로그래밍 언어로써의 UML도 아닌것 같아 가벼운 마음 으로 읽기가 어렵네요. ^^ (노트가 문서화나 주석같아 보입니다)
설계면으로 보면 첫째로 보이는 것이 FontManager 클래스가 Font와 FontTextureRenderer클래스를 동시에 강하게 포함한다는 점입니다. FontTextureRenderer클래스는 Font에만 연결되면 되면 않으려나요?
그리고 FontTextureCach를 Font클래스가 포함하는 것이 아니라 FontManager에 포함되면 좋지 않을까 싶습니다. 생각해 보면 캐쉬라는 것을 관리하는 것이 Font가 아니라 Font를 관리하는 매니저단과 관계가 더 연결성이 짙어 보여서요...
그 외에 관계 표현은 모두 제대로 하신것 같습니다. ^^
아.. 노트가 많은건 구동 방식을 일부러 상세하게 적어놓은것이라 그렇습니다.. 나중에 까먹으니 ㅎㅎ 그래도 UML의 본 목적이 가볍게 보는 의도가 가깝다면 간략하게 써야할것 같군요..
FontTextureRenderer는 약간의 오해가 있는 듯 합니다.
FontTextureRenderer는 싱글톤의 성격이 강합니다.. 그런데 제가 싱글톤은 개인적으로 안좋아라 해서 ㅎㅎ FontTextureRenderer를 FontManager에 객체를 포함시키고.. Font에서 FontTextureRenderer에 렌더링을 맡기는 구조입니다. 원래는 이 의도였는데 결론적으로 싱글톤이 안되어서 FontTextureRenderer가 Font와 FontManager에 강하게 연결되는 구조가 되어버렸군요.. 이는 한번 다시 고려를 해봐야겠습니다.
FontTextureCach가 Font에 포함되는 이유는 간단합니다.
FontManager에 포함이 된다면 모든 폰트의 텍스쳐를 다 관리를 해야 합니다. 그렇게 된다면 텍스쳐가 많아지면 검색하는데 시간이 오래 걸릴수 있으며 어차피 관련된 텍스쳐는 Font에 깊게 연관되어있으므로 차리리 Font에 포함을 시켜서 관리하는게 낫다는 생각이었습니다.
조언 주신점 감사드리며 검토하는데 참고하도록 하겠습니다.
짜증, 핏, ㅋㅋ