四個主要類（2）類cmainframe
類cmainframe是由mfc中的cframewnd派生來的，所以它也是乙個框架視窗。前面已經指出，cmainframe是類cmyview的父類，也就是說cmyview類的物件顯示在主框架視窗的客戶區中。在類cmainframe中，系統已經從類cframewnd那裡繼承了處理視窗的一般事件的windows訊息，比如改變視窗的大小，視窗最小化等的成員函式，因此程式設計的時候程式設計師不需要再關心此類訊息的處理，從而減輕了程式設計師的負擔。當然，如果確實需要重新編寫處理此類訊息的成員函式，則需要對原有的成員函式進行過載。
（3）類cmyview與cmydoc
之所以把cmyview類和cmydoc類放一起來介紹，是因為這兩個類是密切相關的，文件是由文件模板物件生成的，並由應用程式物件管理，而使用者則是通過與文件相聯絡的視窗物件來儲存、管理應用程式的資料，使用者與文件之間的互動則是通過與文件相關聯的視窗物件來進行的。
生成乙個新的文件的時候，mfc程式同時生成乙個框架視窗，並且在框架視窗的客戶區中生成乙個視窗物件作為框架視窗的子視窗，這個子視窗以視覺化的方式表現文件中的內容。視窗的重要功能就是負責處理使用者的滑鼠、鍵盤等操作，通過對視窗物件的處理達到處理文件物件的目的。
要指出的一點是，windows應用程式分單文件介面sdi和多文件介面mdi兩種，在單文件介面中，文件視窗與主框架視窗是同一概念。而這時的視窗物件則是顯示在文件視窗的客戶區當中。前面生成的test程式使用的就是單文件介面方式，此時文件視窗是主框架視窗，即類cmainframe的物件。
文件/檢視結構將資料操作和資料顯示、使用者介面分離開。這是一種「分而治之」的思想，這種思想使得模組劃分更加合理、模組獨立性更強，同時也簡化了資料操作和資料顯示、使用者介面工作。文件只負責資料管理，不涉及使用者介面；檢視只負責資料輸出與使用者介面的互動，可以不考慮應用程式的資料是如何組織的，甚至當文件中的資料結構發生變化時也不必改動檢視的**。
mfc庫訊息對映
mfc庫應用框架並沒有採用虛函式來處理windows訊息，相反，它通過一些巨集來將特定的訊息對映到派生類中相應的成員函式。庫類應用框架沒有採用虛函式，這主要是因為以下原因：庫類中包含了5個視窗類，分別和windows的5種視窗型別相對應，如果採用虛函式的辦法來處理訊息，那麼每個視窗基類就要對140條訊息分別定義乙個虛函式。c++對每個虛函式都要求有乙個4位元組的傳遞結構，稱做「vtable」，無論該虛函式是否在派生類中被重新定義，「vtable」都必不可少。這樣，對於每個特定型別的視窗或控制項，應用都需要乙個2.8kb大小的表來支援虛訊息控制函式。
那麼對於選單命令訊息及按鈕命令訊息來說，設計訊息控制函式不能將它們定義成視窗基類中的虛函式，因為不同的應用會有不同的選單項和按鈕。mfc庫的這種訊息對映系統就避免了使用大的vtable表，並且能夠處理各種各樣應用的命令訊息。這種體制也允許某些非視窗類（如文件類和應用類）來控制命令訊息。這種訊息對映體制同borland作為owl的乙個組成部分所提供的「動態傳遞表」系統也有所不同，它不需要c++作任何擴充套件。
mfc庫訊息控制函式要求我們提供函式原型、函式體，以及在訊息對映中的入口，而classwizard會幫助我們將訊息控制函式引入我們所設計的類中，只要我們從列表框中選擇乙個windows訊息id，classwizard就會自動產生具有正確引數及返回值的**。
Golang學習 記錄一下下
標誌符 只能以英文本元與 開頭 go語言當中的變數必須宣告了再使用，宣告之後必須使用 函式內部可以使用短變數宣告 函式外部一般使用 var 變數名 型別 值 匿名變數 v 常量使用 const pi 3.14 iota 常量計數器，每次遇到const都會重置為0 const n1 iota 0 n2...
專案做完了，總結一下（下）
昨天下午總結了一下專案值得注意的地方，記錄在 專案做完了，總結一下 上 時間倉促，也沒有總結完全。等有時間，還要細細總結。今天，我主要總結一下專案成功的可能因素，比較膚淺。雖然專案受很多不利的因素的困擾，但最終還是交付給使用者使用，不管怎麼樣，這中間還是有很多值得思考的方面。1 專案經理 這個專案經...
忙裡偷閒，學習了一下下
這兩天，專案趕得不是很近，也沒什麼bug需要修復的，就自己看了點知識 強迫症又犯了，糾結點還是些，有啥區別麼，就是腦子不好 比較雜，負載均衡啊，髒讀啊，索引啊，檢視啊，訪問修飾符啊，好像又沒啥了，看來也沒看多少東西啊，還是效率太低了，這是病得治 想想有什麼印象比較深的哈 想優化就得從小的抓起，建索引...