牛客 C++刷題day14&15&16&17&18&19&20 假期以後的複習

前幾天去大伯家休養了一個星期，打打球，釣釣魚至關愜意，刷題強度降低了不少。如今恢復正常做息

1：fscanf和fprintf

fscanf() 和 fprintf() 函數與前面使用的 scanf() 和 printf() 功能類似，都是格式化讀寫函數，二者的區別在於 fscanf() 和 fprintf() 的讀寫對象不是鍵盤和顯示器，而是磁盤文件。

這兩個函數的原型爲：

int fscanf ( FILE *fp, char * format, ... );
int fprintf ( FILE *fp, char * format, ... );

fp 爲文件指針，format 爲格式控制字符串，... 表示參數列表。與 scanf() 和 printf() 相比，它們僅僅多了一個 fp 參數。例如：

1. FILE *fp;
2. int i, j;
3. char *str, ch;
4. fscanf(fp, "%d %s", &i, str);
5. fprintf(fp,"%d %c", j, ch);

fprintf() 返回成功寫入的字符的個數，失敗則返回負數。fscanf() 返回參數列表中被成功賦值的參數個數。

2:面向對象的五大基本原則

單一職責原則（SRP）

 

1.1，SRP(Single Responsibilities Principle)的定義：就一個類而言，應該僅有一個引發它變化的緣由。簡而言之，就是功能要單一。
　　1.2，若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其它職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。(敏捷軟件開發)
　　1.3，軟件設計真正要作的許多內容，就是發現職責並把那些職責相互分離。(敏捷軟件開發)

 

小結：

 

單一職責原則能夠看作是低耦合、高內聚在面向對象原則上的引伸，將職責定義爲引發變化的緣由，以提升內聚性來減小引發變化的緣由。職責過多，可能引發它變化的緣由就越多，這樣致使職責依賴，相互之間就會產生緣由，大大損傷其內聚性和耦合度。

 

開放封閉原則（OCP）

 

　2.1，OCP(Open-Close Principle)的定義：就是說軟件實體(類，方法等等)應該能夠擴展，可是不能修改。它是軟件設計中也是最重要的一種設計原則。
　　2.2，OCP的兩個特徵：
　　　　2.2.1> 對於擴展是開放的。
　　　　2.2.2> 對於修改是封閉的。

 

 

 

　　2.3，何時應用OCP原則呢？
　　　　在咱們最初編寫代碼時，假設變化不會發生，當變化發生時，咱們就建立抽象(好比抽象類，接口等等)來隔離之後發生的同類變化。
　　2.4，開放-封閉原則是面向對象設計的核心所在。遵循這個原則能夠帶來面向對象技術所聲稱的巨大好處，也就是可維護，可擴展，可複用，靈活性好。開發人員應該僅對程序中呈現出頻繁變化的那些部分作出抽象，然而，對於應用程序中的每一個部分都刻意地進行抽象一樣不是一個好主意。拒毫不成熟的抽象和抽象自己同樣重要。
　　2.5，OCP的UML圖：

 

 

小結：

 

開放封閉原則是面向對象設計的核心所在。遵循這個原則能夠帶來面向對象技術所聲稱的巨大好處：可維護、可擴展、可複用、靈活性好。開發人員應該僅對程序中呈現頻繁變化的那些部分作出抽象，然而，對於應用程序中的每一個部分都刻意地進行抽象一樣也不是一個好主意。拒毫不成熟的抽象和抽象自己同樣重要。「需求老是變化」沒有不變的軟件，因此須要用開放封閉原則來封閉變化知足需求，同時還能保持軟件內部的封裝體系穩定，不被需求的變化影響。

依賴倒置原則（DIP）

 

3.1，DIP(Dependence Inversion Principle)的定義：抽象不該該依賴細節，細節應該依賴於抽象。簡單說就是，咱們要針對接口編程，而不要針對實現編程。

 

           3.1. 1 高層模塊不該該依賴低層模塊。兩個都應該依賴抽象。

 

           3.1.2 抽象不該該依賴具體（細節）。具體（細節）應該依賴抽象。

 

　　3.二、反面例子UML圖：

 

      
　　缺點：高層模塊太依賴低層模塊，耦合太緊密。低層模塊發生變化會影響到高層模塊。
　　解決方法：利用依賴倒置原則使高層模塊和低層模塊都依賴於抽象(接口或抽象類)。
　　3.三、修改後的UML圖以下：
　　
　　優勢：這樣的話修改低層模塊不會影響到高層模塊，減少了它們之間的耦合度，加強系統的穩定性。
　　

 

小結：

 

依賴倒置原則其實能夠說是面向對象設計的標誌，用哪一種語言來編寫程序不重要，若是編寫時考慮的都是如何針對抽象編程而不是針對細節編程，即程序中全部的依賴關係都是終止於抽象類或者接口，那就是面向對象的設計，反之那就是過程化的設計了。

 

接口隔離原則（ISP）

 

使用多個專門的接口比使用單一的總接口要好。

 

一個類對另一個類的依賴性應當是創建在最小的接口上的。

 

一個接口表明一個角色，不該當將不一樣的角色都交給一個接口。沒有關係的接口合併在一塊兒，造成一個臃腫的大接口，這是對角色和接口的污染。

 

「不該該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。」這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，若是強迫用戶使用它們不使用的方法，那麼這些客戶就會面臨因爲這些不使用的方法的改變所帶來的改變。

 

 小結：

 

接口隔離的方法有兩種（分享客戶就是分離接口）：
一、使用委託（此委託非.net委託[delegate]）分離接口
使用委託即，建立一個委託類，用此類去實現分離後的其它接口中的方法。
二、使用多重繼承分離接口、
此方法，即將現有「胖」接口分紅供不一樣客戶程序調用的兩個或多個接口，而須要實現多個接口的客戶程序，則使用多重繼承來實現。

 

里氏替換原則（LSP）

5.1，LSP(Liskov Substitution Principle)的定義：子類型必須可以替換掉它們的父類型。簡單地說，這是由於子類型繼承了父類，因此子類能夠以父類的身份出現。

　　實例UML圖：

     

 

小結：

任何基類能夠出現的地方，子類必定能夠出現。 LSP是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

 

補充：

迪米特法則(LoD)：

     自從咱們接觸編程開始，就知道了軟件編程的總的原則：低耦合，高內聚。不管是面向過程編程仍是面向對象編程，只有使各個模塊之間的耦合儘可能的低，才能提升代碼的複用率。低耦合的優勢不言而喻，可是怎麼樣編程才能作到低耦合呢？那正是迪米特法則要去完成的。

迪米特法則又叫最少知道原則，最先是在1987年由美國Northeastern University的Ian Holland提出。通俗的來說，就是一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。

   1，LoD(Law of Demeter)的定義：若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。

   2，在類的結構設計上，每個類都應當儘可能下降成員的訪問權限，也就是說，一個類包裝好本身的private狀態，不須要讓別的類知道的字段或行爲(方法)就儘可能不要公開。

 

定義：一個對象應該對其餘對象保持最少的瞭解。

問題由來：類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。

解決方案：儘可能下降類與類之間的耦合。

小結：

迪米特法則的初衷是下降類之間的耦合，因爲每一個類都減小了沒必要要的依賴，所以的確能夠下降耦合關係。可是凡事都有度，雖然能夠避免與非直接的類通訊，可是要通訊，必然會經過一個「中介」來發生聯繫，例如本例中，總公司就是經過分公司這個「中介」來與分公司的員工發生聯繫的。過度的使用迪米特原則，會產生大量這樣的中介和傳遞類，致使系統複雜度變大。因此在採用迪米特法則時要反覆權衡，既作到結構清晰，又要高內聚低耦合。

3：關於整數強轉爲指針變量

int是能夠強制轉換的，而float，double均不可。且咱們知道整數的位長不能超過尋址範圍。

4：一個類中的構造函數能夠是私有的好比單例模式。

5：二維數組做爲形參時，一維能夠省略可是二維不可省略，聲明二維數組一維不可省略，二維能夠。

6:常成員只能在初始列表初始化，常靜態變量只能經過類外定以。要注意定以時加上const type 不須要static

7：靜態聯編是經過對象名調用虛函數，這個是在編譯階段就肯定了的。

可是動態聯編在編譯階段沒法經過語句自己肯定調用哪個類的虛函數，只有在運行時指向一個對象後才能肯定調用哪一個類的虛函數。

8：

小端存儲：低位存低位，高位存高位

大端存儲：低位存高位，高位存低位

還有結構體中先聲明的是低地址，後聲明的是高地址

9：靜態變量，全局變量其實不在棧區而是在另一個單獨的區，這裏不要搞混淆了

 10:逗號運算符獲得的結果都是括號最後一個表達式的值....16位機器下不考慮字節對齊，劃重點，要考的(shit！！！)