• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            聚星亭

            吾笨笨且懶散兮 急須改之而奮進
            posts - 74, comments - 166, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            現在,伴隨著網絡不斷的普及,計算機的技術人員一直在低齡化,再也不敢像以前小瞧任何一個小朋友了,但是讓我很自卑的是:空長了這么大把的年紀,技術卻比不過小自己很多的中學生。哎~~~,感慨啊~~~~~

             

            起這個系列的文章,不為炫耀,更不敢聲稱教大家什么,只當是我淡茶飯后打發時間、娛樂消遣的一種方式吧……

             

            06年的時候,我有幸被山東工商學院的一老師看中,招到學校來學編程,不知道這個算不算是我編程生涯的開端,但是比較幸運的是,那個老師在出去招生的時候,四處宣傳我編程水平如何之高,如何了得,奈何大學正式開學之后,卻惹來好多同學的注意,本不喜歡張揚的我,也不得已成了班里一個小小的焦點,也正是因為這個,讓我發現:教別人學習什么東西的方式反而會讓自己學的更好

             

            可現實中不可能都像當出剛上大學時那樣單純,如果你口出狂言,說要教某人某某東西,那你基本上就算是杜絕了自己跟別人交流的機會!本人不想也更加的不敢閉門造車,于是就索性依仗于網絡,寫著不知正確與否的破爛文章,就當是教導自己吧,希望這樣的效果不會減退,也希望我寫的這些文字能幫助到那些有心的人!

             

            我就是一個普普通通的學生,所寫的這些所有的東西,都是我個人的理解,并不能保證我所寫所講都是正確的,所以,如果您發現文章中存在錯誤,請您多多費心, 幫忙斧正。希望我起這個專題能拋磚引玉,讓大家一起多多分享。

             

                   下面我對我的這個專題作個大概的介紹,希望對大家閱讀我的破爛文章能有所幫助。

            一、適宜閱讀本系列的人群。

            本系列文章是編程的入門系列,所以,各位高手可以飄過,為了不浪費各位朋友的時間,所以,我在這里對本系列文章如下定位:

            1)        從來沒有接觸過編程而又想學習編程的朋友。

            2)        想學C語言,卻苦于門檻太高的朋友。

            3)        由于自己無編程基礎而對破解造成瓶頸的朋友(破解愛好者)。

            4)        想學編程,卻怎么也深入不下去的朋友。

             

            二、閱讀本系列的前置知識。

            由于本人時間和能力有限,無法真正的從零基礎開始講解本系列文章,因此需要各位朋友提前掌握如下知識:

            1)        Olldbg調試器的基礎使用方法(只需要掌握最基礎的用法即可)。

            2)        盡量的看下 吾愛破解 (或其它同類站點提供的)破解入門系列文章。

            3)        盡量的自己提前看一些C語言程序設計的文章(大致了解一下)。

             

            三、本系列文章講解的內容。

            本系列文章要講解的內容主要是編程方面,用來描述的語言用的CC++,個人認為它比較適合一個要學破解而不懂得編程的朋友的進階讀物。

             

            本文從最基礎的調試分析入手,逐步分析,盡量涵蓋編程的方方面面(由于時間問題,本系列文章不定期更新)。

             

            四、本系列文章的組織形式。

            本系列文章是以專題形式來講解我所理解的編程內容的。因此,本文沒有固定的組織形式,選擇這種方式也只希望隨時都有一個明確的目標,每次專題都能感覺到自己的進步,爭取做到一步一個腳印。也希望大家在讀取本文時,能確定好自己的目標,認真的學好每一個專題,堅持下來你我都會發現自己的進步和收獲。

             

            另外,本人希望大家能在看完我寫的破爛兒以后,能自己根據自己的理解,寫一個自己的專題,分享出來,大家相互學習,共同進步。

             

            五、每個專題文章的書寫格式。

            在每個專題的文章中,我都會先寫好本專題要寫什么內容和概要的目錄,然后會根據目錄將專題逐以的分析要講解的內容是什么,怎么用,為什么。大家可以根據開頭的介紹有選擇性的閱讀。

             

            本系列文章幾乎是本人學習編程經歷的記錄,它記錄了本人對編程學習的每一個腳步,在此分享出來希望能達到如下效果:

            l         能結交更多與我有相同愛好的朋友。

            l         能幫助新人菜鳥朋友更快速的進步。

            l         能鼓勵想我一樣老資格的笨鳥繼續追逐自己的夢想。

            l         能夠記錄我成長的腳步,成為我將來努力學習的動力。

             

            最后,送大家一首詩,愿大家能珍惜現在,把握將來!

             

            金縷衣 (唐)

            ——杜秋娘

            勸君莫惜金縷衣,

            勸君惜取少年時。

            花開堪折直須折,

            莫待無花空折枝。

             

             

             

                                                                                                                                                 ------ besterChen

                                                                                                                                          200973星期五

            Feedback

            # re: 笨鳥先飛學編程系列之前言[未登錄]  回復  更多評論   

            2015-07-13 16:20 by 菜鳥
            你不必嚴格遵守這些原則,違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴,若違背了其中的一條,那么警鈴就會響起。 Arthur J.Riel
              (1)所有數據都應該隱藏在所在的類的內部。
              (2)類的使用者必須依賴類的共有接口,但類不能依賴它的使用者。
              (3)盡量減少類的協議中的消息。
              (4)實現所有類都理解的最基本公有接口[例如,拷貝操作(深拷貝和淺拷貝)、相等性判斷、正確輸出內容、從ASCII描述解析等等]。
              (5)不要把實現細節(例如放置共用代碼的私有函數)放到類的公有接口中。如果類的兩個方法有一段公共代碼,那么就可以創建一個防止這些公共代碼的私有函數。
              (6)不要以用戶無法使用或不感興趣的東西擾亂類的公有接口。
              (7)類之間應該零耦合,或者只有導出耦合關系。也即,一個類要么同另一個類毫無關系,要么只使用另一個類的公有接口中的操作。
              (8)類應該只表示一個關鍵抽象。包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包影響,則將對包中的所有類產生影響,而對其他的包不造成任何影響 .
              (9)把相關的數據和行為集中放置。 設計者應當留意那些通過get之類操作從別的對象中獲取數據的對象。這種類型的行為暗示著這條經驗原則被違反了。
              (10)把不相關的信息放在另一個類中(也即:互不溝通的行為)。朝著穩定的方向進行依賴.
              (11)確保你為之建模的抽象概念是類,而不只是對象扮演的角色。
              (12)在水平方向上盡可能統一地分布系統功能,也即:按照設計,頂層類應當統一地共享工作。
              (13)在你的系統中不要創建全能類/對象。對名字包含Driver、Manager、System、Susystem的類要特別多加小心。規劃一個接口而不是實現一個接口。
              (14)對公共接口中定義了大量訪問方法的類多加小心。大量訪問方法意味著相關數據和行為沒有集中存放。
              (15)對包含太多互不溝通的行為的類多加小心。這個問題的另一表現是在你的應用程序中的類的公有接口中創建了很多的get和set函數。
              (16)在由同用戶界面交互的面向對象模型構成的應用程序中,模型不應該依賴于界面,界面則應當依賴于模型。
              (17)盡可能地按照現實世界建模(我們常常為了遵守系統功能分布原則、避免全能類原則以及集中放置相關數據和行為的原則而違背這條原則) 。
              (18)從你的設計中去除不需要的類。一般來說,我們會把這個類降級成一個屬性。
              (19)去除系統外的類。系統外的類的特點是,抽象地看它們只往系統領域發送消息但并不接受系統領域內其他類發出的消息。
              (20)不要把操作變成類。質疑任何名字是動詞或者派生自動詞的類,特別是只有一個有意義行為的類。考慮一下那個有意義的行為是否應當遷移到已經存在或者尚未發現的某個類中。
              (21)我們在創建應用程序的分析模型時常常引入代理類。在設計階段,我們常會發現很多代理沒有用的,應當去除。
              (22)盡量減少類的協作者的數量。一個類用到的其他類的數目應當盡量少。
              (23)盡量減少類和協作者之間傳遞的消息的數量。
              (24)盡量減少類和協作者之間的協作量,也即:減少類和協作者之間傳遞的不同消息的數量。
              (25)盡量減少類的扇出,也即:減少類定義的消息數和發送的消息數的乘積。
              (26)如果類包含另一個類的對象,那么包含類應當給被包含的對象發送消息。也即:包含關系總是意味著使用關系。
              (27)類中定義的大多數方法都應當在大多數時間里使用大多數數據成員。
              (28)類包含的對象數目不應當超過開發者短期記憶的容量。這個數目常常是6。 當類包含多于6個數據成員時,可以把邏輯相關的數據成員劃分為一組,然后用一個新的包含類去包含這一組成員。
              (29)讓系統功能在窄而深的繼承體系中垂直分布。
              (30)在實現語義約束時,最好根據類定義來實現。這常常會導致類泛濫成災,在這種情況下,約束應當在類的行為中實現,通常是在構造函數中實現,但不是必須如此。
              (31)在類的構造函數中實現語義約束時,把約束測試放在構造函數領域所允許的盡量深的包含層次中。
              (32)約束所依賴的語義信息如果經常改變,那么最好放在一個集中式的第3方對象中。
              (33)約束所依賴的語義信息如果很少改變,那么最好分布在約束所涉及的各個類中。
              (34)類必須知道它包含什么,但是不能知道誰包含它。
              (35)共享字面范圍(也就是被同一個類所包含)的對象相互之間不應當有使用關系。
              (36)繼承只應被用來為特化層次結構建模。
              (37)派生類必須知道基類,基類不應該知道關于它們的派生類的任何信息。
              (38)基類中的所有數據都應當是私有的,不要使用保護數據。類的設計者永遠都不應該把類的使用者不需要的東西放在公有接口中。
              (39)在理論上,繼承層次體系應當深一點,越深越好。
              (40)在實踐中,繼承層次體系的深度不應當超出一個普通人的短期記憶能力。一個廣為接受的深度值是6。
              (41)所有的抽象類都應當是基類。
              (42)所有的基類都應當是抽象類。
              (43)把數據、行為和/或接口的共性盡可能地放到繼承層次體系的高端。
              (44)如果兩個或更多個類共享公共數據(但沒有公共行為),那么應當把公共數據放在一個類中,每個共享這個數據的類都包含這個類。
              (45)如果兩個或更多個類有共同的數據和行為(就是方法),那么這些類的每一個都應當從一個表示了這些數據和方法的公共基類繼承。
              (46)如果兩個或更多個類共享公共接口(指的是消息,而不是方法),那么只有他們需要被多態地使用時,他們才應當從一個公共基類繼承。
              (47)對對象類型的顯示的分情況分析一般是錯誤的。在大多數這樣的情況下,設計者應當使用多態。
              (48)對屬性值的顯示的分情況分析常常是錯誤的。類應當解耦合成一個繼承層次結構,每個屬性值都被變換成一個派生類。
              (49)不要通過繼承關系來為類的動態語義建模。試圖用靜態語義關系來為動態語義建模會導致在運行時切換類型。
              (50)不要把類的對象變成派生類。對任何只有一個實例的派生類都要多加小心。
              (51)如果你覺得需要在運行時刻創建新的類,那么退后一步以認清你要創建的是對象。現在,把這些對象概括成一個類。
              (52)在派生類中用空方法(也就是什么也不做的方法)來覆寫基類中的方法應當是非法的。
              (53)不要把可選包含同對繼承的需要相混淆。把可選包含建模成繼承會帶來泛濫成災的類。
              (54)在創建繼承層次時,試著創建可復用的框架,而不是可復用的組件。p112
              (55)如果你在設計中使用了多重繼承,先假設你犯了錯誤。如果沒犯錯誤,你需要設法證明。
              (56)只要在面向對象設計中用到了繼承,問自己兩個問題:(1)派生類是否是它繼承的那個東西的一個特殊類型?(2)基類是不是派生類的一部分?
              (57)如果你在一個面向對象設計中發現了多重繼承關系,確保沒有哪個基類實際上是另一個基類的派生類。
              (58)在面向對象設計中如果你需要在包含關系和關聯關系間作出選擇,請選擇包含關系。
              (59)不要把全局數據或全局函數用于類的對象的薄記工作。應當使用類變量或類方法。
              (60)面向對象設計者不應當讓物理設計準則來破壞他們的邏輯設計。但是,在對邏輯設計作出決策的過程中我們經常用到物理設計準則。
              (61)不要繞開公共接口去修改對象的狀態。
            国产精品对白刺激久久久| 亚洲AV无码一区东京热久久| 国产成人精品白浆久久69| 国内精品久久久久影院免费| 日本精品久久久中文字幕| 精品视频久久久久| 中文字幕无码精品亚洲资源网久久| 欧美大香线蕉线伊人久久| 26uuu久久五月天| 久久久久国产精品嫩草影院| 久久精品成人免费看| 久久SE精品一区二区| 51久久夜色精品国产| 久久久久人妻一区二区三区vr| 国产高清美女一级a毛片久久w| 久久精品一区二区三区AV| 国产精自产拍久久久久久蜜| 99久久精品免费看国产一区二区三区| 99久久国产综合精品网成人影院| 国产A三级久久精品| 亚洲精品无码久久久久AV麻豆| 丁香狠狠色婷婷久久综合| 狠狠综合久久AV一区二区三区| 日本久久久精品中文字幕| 国产精品美女久久久m| 精品久久亚洲中文无码| 国产精品中文久久久久久久| 久久国产精品免费一区二区三区| 久久99亚洲网美利坚合众国| 久久精品日日躁夜夜躁欧美| 久久涩综合| 欧美伊人久久大香线蕉综合69 | 亚洲av日韩精品久久久久久a| 国产精品伦理久久久久久| 国产成人久久精品激情| 九九久久99综合一区二区| 久久精品国产亚洲AV电影| av无码久久久久久不卡网站| 久久永久免费人妻精品下载| 色欲久久久天天天综合网精品| 久久国产色AV免费看|