最近寫了不少類了，從垃圾代碼爬坑，雖然還是很垃圾，但是照葫蘆畫瓢，有幾分神韻。在這里總結一下，寫類的經驗教訓。
第一步 分析：
當拿到一個要求時，要先去考慮怎樣一個類到底該實現什么樣的功能，有什么樣的數據，簡而言之，就是分析。該用什么方式組織數據，達到解決一類問題的方式，在分析結束后腦子里會有一個大概的框架，在通過分析后將每個類的應該有的數據，與操作寫出來，這個時候不需要寫出具體實現方式，而是為后續寫類，搭建一個框架，分析時也要注意面向對象封裝的特點，一一定要注意數據與操作的分離，這樣讓每個類成為一種的獨立的類型，而不是數據操作混用，每個類都不能獨立的解決一些問題，這樣的代碼復用性差，所以還是按照老師講的數據類與操作類清晰的分離，到這里一個比較明確的思路就可以的出來。
第二步 補充操作使類完整
這一步，包括代碼的實現與調試，之前的時候寫代碼是一氣呵成，那時候還不太明白什么是寫一個功能調一個功能，指導有一次通訊錄管理系統最后跑不出來，也不報錯，但是就是不按自己想法出結果，于是，從頭開始往另一個CPP文件里粘代碼，一個函數一個函數的粘貼，這樣一個函數一個函數的調試，于是300行的代碼硬硬的調了快兩個小時，才明白什么是寫一個功能調試一個，不是寫完一整個程序調試一遍，也不是寫完一個類調一遍，這個功能就是對每一個要起到作用而函數，進行測試，可想而知要是1000行的代碼出現了問題，不是從頭開始寫一個，調一個的話，要是找錯誤的話，跟直接從新寫沒有太大區別。所以寫一個調試一個，看似增加了寫代碼的時間，實際上是減少了調試代碼的時間，更重要的是降低調試代碼的復雜度。
應該具備的素質
面向對象編程，要注意封裝繼承多態，寫出更具有通用性的代碼，提高代碼的復用率，就是減少重復代碼的出現次數，比如圖書館管理系統的管理端與用戶端有著同樣的查詢操作，如果不采用繼承的方式寫，就會少寫很多代碼，既可以減少代碼的長度，又能使類更加明了，但是一般說上來就知道那兩個類可以繼承，是不太現實的，一般是當第一部完成后，發現兩個類的功能有大量重疊，抽出重疊部分，形成一個基類，再由兩個類繼承。多態是為了提高類的封裝性，將一個接口通過動態的方式確定調用具體哪一項操作，應用程序不必為每一個派生類編寫功能調用，只需要對抽象基類進行處理即可。大大提高程序的可復用性。派生類的功能可以被基類的方法或引用變量所調用，這叫向后兼容，可以提高可擴充性和可維護性。 所以熟練的使用虛函數使提高類的封裝性的方法。
我認為就是根據不同的情況調用指向不同派生類的指針而使得可以調用不同的參數，可以通過鍵盤上敲的值動態的確定要調用那個函數。
最后一點
作為一名程序monkey，寫出的代碼不只是給自己的看的，應該讓別人也看懂，吃過的虧是寫代碼是每個成員變量是a,b,c不是上學期那么短的代碼，數據少，現在數據多，所以命名一定有意義，一來是讓別人看的懂，其次讓自己調代碼時也更加方便，然后是，寫代碼的時候，一定要類內聲明，類外定義，寫一攤，不能明確看出到底有哪些函數，有哪些功能，再根據函數、功能去找代碼，這樣更方便，與明了。
雖然，我們也沒學什么設計模式，軟件工程什么什么的，但是很多老師講了的知識就一定要會。上學期的時候Fls不讓寫注釋，上學期代碼短，一眼就看出來了，這學期開始時不寫注釋，寫出的代碼不盡人意，因為思路突然就中斷了，這是干嘛的，什么作用什么功能？所以我覺得適當的明了的注釋應該是可以有的，目前水平還很低，這是自己接觸的第一門語言，估計這應該是大學三年用的比較多的語言了，所以還要繼續努力。

總結

以上是生活随笔為你收集整理的C++--浅谈开发系统的经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。