다음 프로젝트를 MFC를 조금 할 줄 알아야 해서 짬이 있는 틈을 타서 시작 해 버렸
습니다. 원래는 기존에 자바로 구현한 Flower를 그대로 리펙토링 할 예정이었는데, 
C++코딩을 너무 안해서 공부를 다시 해야 하고 MFC프레임웍에 익숙해져야 하기 때문에 Flower를 아주 MFC로 구현 해보려고 합니다.

코드가 나름 커졌기 때문에 한번에 똑같이 구현 할 수는 없으니까 작은 단위로 잘라서 구현해 나갈 생각입니다. 이미 구현을 한 것을 다른 언어와 GUI를 이용하는 거라서 크게 어렵지는 않을 것으로 예상합니다.

아자아자~~ 화이팅!!

일단 MFC의 컨트롤들을 잘 못쓰기 때문에 GUI쪽 말고 로직과 자료구조를 구현하는 것에 일단 초점을 맞추고 있습니다.

오늘은 MFC패턴을 적용하여 큰 틀을 잡는 것만 구현 했습니다.

스윙에서는 controller클래스인 DPainter가 있었지만 MFC자체가 controller가 OS가 담당한다고 해서 위와 같은 모양이 되었습니다.DCanvas가 view에 해당되고(실제 MFC의 뷰클래스입니다.) DSymbolManager가 Model이 됩니다. DSymbol은 도형의 최상위 객체이구요.(DFigure와 DProcedure의 틀만 만들었습니다.) DCanvas와 DSymbolManager가 옵저버패턴이 적용되어야 하는데 그건 내일 해야 겠습니다.

마지막으로 오늘 한 코드의 시퀀스 다이어그램을 올립니다.

신고
by danguria 2010.01.21 18:55
드디어 올것이 왔군요..

지금까지 프로시저를 생각하지 않고 구현하고 있었습니다. 큰 문제가 없을 것이라고 생각 했지만

문제가 있긴하군요..

현재는 심볼 매니저와 캔버스가 하나의 쌍으로 있어서 그것이 뷰와 모델의 관계를 했었는데

이제 함수가 들어오면서 부터 여러개의 심볼 매니저와 캔버스가 있어야 합니다.

먼저 painter(controller)는 심볼매니져와 캔버스의 쌍을 관리 하고 있어야 합니다.

즉, 사용자가 활성화 한 캔버스에 대한 심볼 매니저가 적정하게 동작 해야 합니다.

그리고, 프로시저 심볼을 디자인 해야 합니다.

프로시저라는 심볼은 내부적으로 나의 심볼 매니저를 알고 있어야 합니다. 왜냐하면 심볼 매니저로 부터 해당 

프로시저의 시작 심볼을 가져 와야 하니까요(컴파일러가 추적할 수 있어야 함니다.)

일단 설계를 해보았습니다.

기본적으로 MVC패턴입니다.

symMng가 모델, canva가 뷰, painter가 컨트롤러 입니다.

각각의 참조가 MVC과 약간 달르고 아직 변경의 여지가 있기 때문에 association로 표현 했습니다.

페인터와 캔버스가 symMng의 데이터, 즉 심볼들의 변화에 따라서 상태와 겉모습이 바뀌어야 합니다.

캔버스는 심볼의 그림을 그려 주어야 하므로 draw옵저버가 되고,
페인터는 심볼이 선택됨에 따라 해당 심볼의 속성을 각 컨트롤에 반영해야 합니다 (이부분이 뷰에 대당하는 것 같은데 컨트롤이 painter에서 구현 되어 있습니다...)그래서 속성 옵저버가 되고, 프로시저가 생성되고 소멸됨에 따라 현재 캔버스와 심볼매니저의 쌍을 교체 해야 하므로 프로시저 옵저버가 필요합니다.
여기서는 표현 되어 있지않지만 사용자에 의해 현재 캔버스와 심볼매니저의 쌍을 교체 해주어야 하는데 이것은 페인터가 내부적으로 해결 할 수 있을 것 같습니다.

심볼 매니저는 만들어진 모든 옵저버를 받아드리고 notify하는 subject를 구현 하도록 하였습니다.


신고
by danguria 2009.11.18 00:14
MVC
Undo Redo기능을 구현하고 painter 클래스의 복잡성이 너무 커지고, 전체적인 구조가 흔들려서 

과감히 리팩토링을 하고 있습니다. 일단 MVC모델을 기반으로 하려고 하고 있고(전에도 그랬었지만 view와 controller가 섞여 있었습니다.) 그 첫단계로 UI(view)를 설계하고 있습니다.

함수 기능과, 디버깅 기능을 추가 고려 하여 완벽한 버전의 UI를 만들고 있습니다.

아마 다음주 중간쯤에는 완성될 것 같네요.. 

이번주말은 컴파일러 숙제가 있어서 많이 코딩을 하지는 못할 것 같습니다.
신고
by danguria 2009.11.08 00:29
head first에 MVC를 설명? 찬양? 하는 노래를 만들었네요.ㅋㅋ

역시 특이합니다. 

아래 링크로 노래를 들을 수 있습니다.ㅋㅋ

저는 지금 기타로 악보를 만들어 보려고 합니다.ㅋ


노래 가사: 

Lyrics by James Dempsey

Model View, Model View, Model View Controller
MVC’s the paradigm for factoring your code,
into functional segments so your brain does not explode.
To achieve reusability you gotta keep those boundaries clean, 
Model on the one side, View on the other, the Controller’s in between.

Model View - It’s got three layers like Oreos do.
Model View creamy Controller

Model objects represent your applications raison d’tre.
Custom classes that contain data logic and et cetra.
You create custom classes in your app’s problem domain,
then you can choose to reuse them with all the views,
but the model objects stay the same.

You can model a throttle in a manifold,
Model level two year old.
Model a bottle of fine Chardonnay.
Model all the twaddle stuff people say.
Model the coddle in a boiling eggs.
Model the waddle in Hexley’s legs.

One, two, three, four.
Model View - You can model all the models that pose for GQ.
Model View Controller

View objects tend to be controls that view and edit,
Cocoa’s got a lot of those, well written to its credit.
Take an NSTextView, hand it any old Unicode string,
the user interacts with it, it can hold most anything.
But the view don’t knows about the Model:
That string could be a phone number or the words of Aristotle.
Keep the coupling loose and so achieve a massive level of reuse.

Model View - All rendered very nicely in Aqua blue
Model View Controller

You’re probably wondering now.
You’re probably wondering how,
the data flows between Model and View.
The Controller has to mediate,
between each layer’s changing state,
to synchronize the data of the two.
It pulls and pushes every changed value.
Yeah.

Model View - mad props to the smalltalk crew!
for Model View Controller

Model View - it’s pronouced Oh Oh not Uh Uh
Model View Controller

There’s a bit more on this story, 
a few more miles upon this road,
well nobody seems to get much glory 
writing controller code.
Well the model is mission critical 
and gorgeous is the view,
But I’m not being lazy, but sometimes it’s just crazy 
how much code i write is just glue.
And it wouldn’t be so tragic,
but the code ain’t doing magic:
it’s just moving values through.
And I wish I had a dime
for every single time 
I set a TextField’s stringValue.

Model View - how we’re gonna deep-six all that glue
Model View Controller

Controller’s know the Model and View very
uahh - intimately 
They often are hardcoding 
which is very verboten for reusability.
But now you can connect any value you select
to any view property.
And I think you’ll start binding,
then you’ll be finding less code in your source tree.
Yeah I know I was astounded,
that’s not even a rhyme.

But I think it bares repeating
all the code you won’t be needing,
when you hook it up in IB.

Model View - it even handles multiple selections too
Model View Controller

Model View - hope I get my G5 before you
Model View Controller

Yeah, yeah, yeah. Yeah.
신고
by danguria 2009.10.30 20:26
| 1 |

티스토리 툴바