物件導向
基礎知識概要
最近學設計模式想重頭回歸物件導向根本上，所以寫一些筆記，作為記錄...比較常認知的是，物件與類別到底差異在哪，底下可以用兩個例子來舉例它的差異
物件
【萬物皆可為物件】，其實可以把身邊的萬物都可看成一個物件，EX:一個人、一杯水、一杯車。
類別
在萬物皆可為物件，某些物件有相同的屬性，例如人有身高、體重、性別屬性車有品牌、型號、排氣量，這時候可以把物件進行歸類、例如火車與汽車都是車類，這樣的物件導向的類別就誕生了。
不同的物件之間互動與聯繫、構成完整世界，所以要圍繞現實世界中的物件來構造系統。
static void Main(string[] args)
{
String str = "abc";
str = str.Insert(3,"de");
Console.WriteLine(str);
}String是類別名稱，str是物件名稱，那方法則是Insert，則對
它的操作無法得知，不知道儲存在哪。
類別的不可知性，操作過程不可知性，稱為類別的封裝特性。
類別的用法
new：新建類別，表明類別中隱藏基底類別。
public：公用類別，表示外界可以不受限制存取該類別。
protected：受保護類別，只能從所在類別和所在類別延伸的子類別存取。
internal：內部類別，只能從所在類別存取。
private：只有該類別才能存取。
abstract：抽象類別，不予許實體化。
sealed：密封類別，不予許被繼承。
一、概念
1.物件導向程式設計，不是類別越多越好，類別的劃分是為了封裝，分類的基礎是抽象，具有相同屬性和功能之物件的抽象集合才是類別。
2.以抽象來隔離，可能會發生同類變化。
3.在初始化資訊不會發生變化下，複製Clone是最好的辦法。
4.委託是一種參考方法類型。
一旦委託分派了方法，委派與該方法具有完全相同的行為。
一個委託可以搭載多個方法。
委託可以使得委託物件所搭載的方法並不需要屬於同一個類別。
5.委託物件所搭載所有方法，必須有相同參數列表返回值類型。
6.不要為程式碼加上基於猜測的、實際不需要的功能。
二、物件導向的語言特性
封裝：將變化封裝至method中，外部code在使用時只需要知道call method，不需要了
解內部實作的細節。
繼承：可以從類別當中衍生出子類別，子類別可以implementation屬於自己的method。
多型：從老爸類別衍生出來的兒子類別，可以替代兒子類別，而不會出錯
1.單一職責原則：就一個「類別」而言，應只會有一個引起它變化的原因。
註記：對一個類別來說，應該只有一個引起他變化的原因。如果類別承擔的職責太多，在產生變化時，會遭受意想不到的破壞。如果你想到超過一個原因去修改類別，那該類別就承擔了過多的職責。
2.開放-封閉原則：對於「擴展」是開放的，對於「更改」是封閉的。
註記：設計類別時對類別的擴充保持開放，對修改保持封閉。當面對需求變化時，一定會有無法封閉的變化，這時候就必須構造抽象點來隔離那些變化。
3.依賴倒轉原則：
- 高階模組不應依賴低階模組。兩個都應依賴「抽象」。
- 細節依賴抽象，而非抽象依賴細節（亦即針對介面設計，而非針對要實現的程式）。
4.Liskov 替換原則：子類型必須能夠替換掉它們的父類型。
註記：子類別必須可以替換他們的父類別，子類別的可替換性使得父類別的模組在無需修改的情況下可以擴展。
5.迪米特原則（最少知識原則）：若兩個類別不必彼此直接通信，則這兩個類別就不應當發生直接的相互作用。
若其中一個類別需要調用另一個類別的某一個方法，則應透過第三者轉發這個調用。
註記：此原則的前提是在類別的結構設計上，每一個類別都應當降低成員的使用許可權。
6.合成/聚合複用原則：盡量使用合成/聚合，少用類別繼承。
• 聚合表示的是 A 物件可以包含 B 物件，但 B 物件不是 A 物件的一部份。
• 合成表示的是 A 物件可以包含 B 物件，且 B 物件是 A 物件的一部份。
7.介面隔離： 針對介面程式設計，而非對實現(Implement)程式設計。
註記：抽取相同功能形成介面，讓各類別去實作，對呼叫的程式端來說， 只須在意開放出來介面提供的功能，且將來需要抽換時只需要實作相同介面的類別即可。
8.依賴反轉：
類別中，不應該直接使用另一個具有實作類別，而是使用抽象的介面，去承接繼承該介面的實作類別。
它的目標就是解除物件與物件間，兩者的直接相依關係。
其他設計原則：
1.Don't Repeat Yourself：不做重複的事。
系統包含許多共用功能代碼，DRY主張，抽離這些共用程式碼，整合單一功能，統一
提供系統其他部分使用，避免撰寫重複程式碼，以利系統維護開發。
2.Keep it Simple Stupid：保持簡單直接。
系統功能代碼盡量保持單純，原則必須建立維持功能完整性前提上，避免開發過度複雜單一
功能，也不應有過度簡化設計情形。
3.You Ain’t Gonna Need It：你不需要它。
不要在系統加入不需要的功能代碼，有時開發會有過多考慮，加入不必要代碼，遵循此原則
按照需求的適度撰寫代碼，排除那些可能需要，事實多餘的代碼。
元哥的筆記