https://github.com/microsoft/calculator
gui, 공학용 기능넣는다고 해도 1,2학년 수준이 아닐까 생각했는데 진짜 엄청 복잡하고 파일도 상당히 많네;;;
혹시 대충이라도 설명해줄수 있음??
이 계산기소스에 내가 상상하지도 못했던 깊은세계가 어떤건지 알고싶음.
[%] 마이크로소프트 계산기 오픈소스인데 뭐가 들어가길래 이렇게 복잡한거임??
스카이라인(58.233)
2019-10-21 01:49
추천 0
댓글 23
다른 게시글
-
하스켈에서 제일 이해 안가는거 [4][%] 다믜(damhiya) | 19.10.21추천 0
-
근데 왜 있는이름으로 자꾸 짓는거야 [3][%] 익명(110.70) | 19.10.21추천 0
-
Effective C++ 현재 동작이랑 달라진거있음? [6][⚠애니짤] 익명(106.102) | 19.10.21추천 0
-
C++ 멤버변수 객체들 포인터선언하냐? [1][⚠애니짤] 익명(106.102) | 19.10.20추천 0
-
C++ exception 정상상황에서는 zero cost인데 [20][질문] dd(211.186) | 19.10.20추천 0
-
유한 오토마타를 정규식으로 바꾸는 게 이해 안 됨 [5][%] 기괴공학도(mecheng98) | 19.10.20추천 0
-
형덜 C++ 템플릿 질문점 [2][%] 익명(218.146) | 19.10.20추천 0
-
비동기 막 짜다보니 너무 조잡해졌네[%] ㅇㄹ(rerereq) | 19.10.20추천 0
-
Rust로 할만한거 머있음 [1][%] 익명(121.183) | 19.10.20추천 0
-
러스트하고 하스켈중에 하스켈 먼저해서 다행인듯 [7][%] 다믜(damhiya) | 19.10.20추천 0
아마 biginteger 구현하고 gui때문에 그럴것 같은데
CalcManager, Calulator만 봐도 오지게 복잡하던데... 이게 좃고수들의 추상화인가.
오 이렇게 복잡할줄은 몰랏네ㅋㅋㅋ나중에 봐야지
뭔가 했는데 uwp였네 UI부터 복잡할듯
코드릉 이해하려면 일단 MVVM 아키텍쳐부터 이해를 해야함.. 그게 뭐냐면, 우리가 계산기를 만든다고 하면 진짜 계산기(숫자끼리 연산시키고, Memory기능 넣는다면 Memory 넣었다 비웠다, 공학용 계산기도 있어야하니 특수함수도 연산가능한..) 로직이 있어야하는데 그걸 Model이라고 부름.
UI가 있으면 UI에 구체적인 버튼을 윈도우의 100, 100 위치에다가 마진 30씩 줘서 버튼을 만들어놔라. 하는 식의 디자인을 꾸릴수가 있는데 이런걸 View라고 부름.. UWP에선(그 이전 WPF에서도) xaml이라는 markup language를 써서 UI를 만들어놓으면 빌드툴이 그 코드를 읽고 알아서 UI 코드를 생성해주도록 함.
그럼 저 UI를 입력받아서 해당하는 model에다가 바로 쏴주면 좋겠는데, UI(Pressntation) Layer엔 또 그 나름의 로직이 있음. 예를들면 공학용으로 설정하면 화면 전체가 공학용으로 바뀌되 입력중인 데이터는 유지하라던가.. 이게 눌리면 이 버튼은 누르지 못하게 gray out 하라던가. 이런 Presentation logic을
그냥 UI에 바로 적어놓아도 코드는 작동하는데, 문젠 1. UI 컨트롤 지워버이면 연결된 이벤트 코드 다 깨진다 2. Presentation logic도 Unit test 하고 싶은데 UI를 생성못하는 상황이면 예를들면 테스트 서버가 linux에서 .net core로 테스트하면 Window 클래스에서 상속받은 애는 테스트도 못함
그래서 저런거 해결하기위해 MS가 UI랑 ViewModel이라 부르는 일반클래스 사이를 연결해주는 Databinding이란 계약방법을 만들고, 그 계약을 만족시키는 아무 클래스나 가져와서 View의 DataContext에 설정하면, 그 클래스의 property가 UI에 연동될수있게 함
그래서 좀 투박하게 비유하면 View는 web page고 ViewModel은 script고 Model은 server같은 느낌으로 아키텍쳐를 분해해놓음. View는 ViewModel하고만 통신하지만 그 통신방법은 string값 기반으로만 이루어지고 View와 ViewModel은 서로 독립적으로 존재할수 있게 됨. ViewModel은 특정 View를 염두해두고
그에 필요한 기능들을 제공하지만 뭐 직접 View를 건드리진 않아서 그냥 class일 뿐이라 unit test가 가능해짐..
그렇게 해서 Model-View-ViewModel이 서로 구분돼있고, (저기서 Model은 CalcManager) 마지막으로 View 만드는데 입력창이 텅텅 비면 Previewer에서 보기가 나쁘니 ViewModel을 흉내내는 데이터를 제공하기로 하는데 걔가 Design Data임... 나머진 사실 localization관련 리소스가 대부분이고
C++이라 코드가 참 거시기한데 C# 으로 MVVM 짜고 Xaml도 VS에서 디자이너로 만들고 하면 그정도로 끔찍하진 않은데.. boilerplate가 좀 많긴 하지..
아 마지막으로 저기 Converter들은 Xaml때문에 존제하는데, 예를들어 UI의 어떤 컨트롤에 Visibility라는 항목이 있다 치고, 그게 enum값 Visible, Hidden, Default 란 enum Visibility를 가지고 있고, ViewModel엔 bool Visible이란 값이 있으면
bool값을 enum값으로 변환해주는 Converter가 있어야하는데 BooleanToVisibilityConverter같은 클래스 만들어서 구현시키도록 하고있는데 그런식의 저 통신 관리하는 Converter들도 한쪽에 모여있음.. 그정도면 코드 구조는 대충 다 얘기한듯
아 마지막으로 MyView.xaml과 MyView.xaml.cpp는 같은 클래스 MyView를 부분구현해둔거. 이건 그냥 WinForm으로 치면 designer generated code와 event handler의 관계라고 보면 됨
엄청 복잡하네
자고 일어났는데 엄청 상세하네 ㄷㄷ 고마워용
방금 분석한거임? 아님 원래 알고있던거? 지식량오지네
닷넷충이라서(& 닷넷충이면) 폴더구조만 봐도 대충 암
model view controller인가 그거랑 비슷한 거임?
비슷하다면 비슷하고 인비슷하다면 안비슷한데.. 일단 둘다 Valid software architecture고 뭐가 좋고 나쁘고가 있진 않은데, MVC는 Controller가 View를 직접 인터페이스를 통해 소유하잖음? 좀더 tight하게 둘이 엮이게 된다면 MVVM은 string 기반 Dictionary로 loose하게 엮이게 되는데
둘다 결국 Model 의 logic을 분리해야한다. 는 점에선 비슷하고 Controller가 Model이랑 View가 직접 교류하게 하는걸 막는건 맞는데, Controller쓰면 이제 View를 흉내내는 애를 만들어 집어넣어주면 unit test가 돌아가겠지.