面向抽象編程

A. 在C#中，類，抽象類和介面之間有什麼共同點和不同點

1.介面是包含一組虛方法的抽象類型，其中每一種方法都有其名稱、參數和返回值。介面方法不能包含任何實現，CLR允許介面可以包含事件、屬性、索引器、靜態方法、靜態欄位、靜態構造函數以及常數。
如果創建的功能將在大范圍的全異對象間使用，則使用介面。
2.抽象類提供多個派生類共享基類的公共定義，它既可以提供抽象方法，也可以提供非抽象方法。抽象類不能實例化，必須通過繼承由派生類實現其抽象方法。
相同點：都不能被直接實例化，都可以通過繼承實現其抽象方法。
都是面向抽象編程的技術基礎，實現了諸多的設計模式。
不同點
：介面支持多繼承;抽象類不能實現多繼承。
介面只能定義抽象規則;抽象類既可以定義規則，還可能提供已實現的成員。
介面是一組行為規范;抽象類是一個不完全的類，著重族的概念。
介面可以用於支持回調;抽象類不能實現回調，因為繼承不支持。
介面只包含方法、屬性、索引器、事件的簽名，但不能定義欄位和包含實現的方法;抽象類可以定義欄位、屬性、包含有實現的方法。
介面可以作用於值類型和引用類型;抽象類只能作用於引用類型。例如，Struct就可以繼承介面，而不能繼承類。

B. java 設計模式（工廠方法）

面向抽象（抽象類或介面）編程。
IWorkFactory studentWorkFactory = new StudentWorkFactory(); 注意：類型是介面類型，即抽象工廠，抽象工廠生產的是抽象產品，而new的則是具體工廠，是由子類實現的，具體工廠生產具體產品。面向抽象的好處：1.在設計抽象的時候不用管具體的實現，只要定義介面知道它用來干什麼就行，這樣，我只需要知道抽象介面就能繼續下面的開發設計工作了，而不用事先設計具體的實現內容；2. 可以擴展多個子類實現抽象介面，更利於系統後期的擴展，而對原系統不造成任何影響，即：開-閉原則。

TeacherWork tt = new TeacherWork(); 不用說就是面向具體實現類編程，缺點就是擴展性不好，對系統後期維護擴展影響較大。

舉個簡單的例子：
假如在系統的A.java中代碼中使用了TeacherWork 類型對象，是滿足了目前軟體的需求，但是，如果有一天需求變化了需要一個StudentWork 類型對象，該怎麼辦？只能修改A.java類來滿足這樣的修改需求。這樣就影響了原來系統結構穩定性，需要重新調試和測試，而這帶來的維護成本是非常大的，有時可能還會帶來系統錯誤，而影響系統運行。
如果在A.java類中應用Work介面類型就不會存在這種問題，A.java不需要任何修改，只需要修改注入到A中的Work介面的具體實現類即可。

面向抽象編程的好處就在於對系統維護和擴展上，即在不影響原系統穩定運行的基礎上增加新的擴展行為，即要符合「開-閉」原則。可能會因此而失去一定的效率問題，但是對於後期的維護成本來說，這個可以忽略不計。 推薦你一本好書：《軟體秘笈-設計模式那點事》其中講解的設計模式很到位，還有每個模式的靜態類圖和JDK中設計模式的具體分析講解，讀了收獲一定很大。祝你成功！

C. 面向對象的多態詳解 ！！

面向對象的軟體開發語言具有三個重要的特點分別為封裝性、繼承性、多態性。封裝性即意味著對象封裝其內部的數據，使其對外不可見，以保證數據的安全性。繼承性是代碼復用的一個很好的解決方案，但是繼承關系是編譯器在編譯階段就為所有的對象決定的，因而在軟體工程過程中，繼承性太過死板，存在很大的局限性。而多態性，它是將多種不同的特殊行為進行抽象的一種能力，通過結合繼承性，多態性很好地解決了OO遇到的很多麻煩，使得面向對象的編程方式最終得到淋漓盡致的推廣。

多態性和泛型編程

各種編程語言都內置了多種基本數據結構並且支持自定義數據類型，因而程序員在程序設計過程中可能會遇到多種數據類型，而針對這些數據類型的邏輯操作很有可能是雷同的。此時為每一種數據類型都設計出相應的邏輯函數似乎已經變得很不現實，因而泛型編程孕育而生了。泛型編程的出現，可以說在軟體工程領域里是一個極大的進步。利用泛型編程，我們可以不為特定的類型進行專門編碼，而採用對不同類型進行通用編碼的方式來解決應對大量數據類型的問題。C++
STL是泛型編程的成功案例。利用Template函數，STL成功實現了對多種數據類型進行泛化的效果。而OO通過介面或者抽象類進一步實現了對類的泛化，也就是在面向對象過程中出現的新名詞—多態！

多態性特點

簡單來說，多態是具有表現多種形態的能力的特徵，在OO中是指，語言具有根據對象的類型以不同方式處理，即指同樣的消息被不同類型的對象接收時導致完全不同的行為,是對類的特定成員函數的再抽象。多態性在不同的編程語言中擁有不同的解決方案，但多態性的最終目標卻始終不變，都是「以不變應萬變」。

兩種多態方式

一般來說，多態主要是存在兩種類型：編譯時的多態和運行時的多態。

1
編譯時的多態主要是通過函數重載來實現的。所謂函數重載是指保持函數名不變，主要通過更改函數形參的個數以及形參的類型來定義出多個同名函數來實現對多種類型數據的邏輯處理。這種類型的多態關系是編譯器在編譯階段就已經在函數調用的地方確定的，因而運行過程中速度較快，但功能比較局限。

2
運行時的多態在不同的語言中擁有不同的實現方案。C++通過虛函數的晚捆綁來實現，而Java通過面向介面編程和面向抽象編程來實現動態調用相應的函數實現。但歸根結點，這些語言都是通過將多種特殊實現的類抽象為一個泛化類來實現運行多態。

面向介面編程

軟體工程中程序涉及到的對象越多，對象之間相似的概率越大，因而這時候抽象變成了可能。通過定義介面，程序設計者可以成功實現對方法的定義和實現的分離，因而應用程序不必考慮子類成員函數中是如何實現內部邏輯細節，只需知道該類對象向外公開的介面便可成功操縱這類對象。而這種編程方式，為以後程序的改動以及程序的健壯性和擴展性都提供了一個比較理想的解決方案。因此面向抽象編程已經成為OO界強烈推崇的編程方式。

OO思想已經深入廣大編程人員的工作中，如何能夠充分合理利用OO的特點達到最優化軟體體系結構將會成為每一個OO程序員應該思考的問題，相信OO思想能夠為大家的軟體設計帶來前所未有的效果。

D. 什麼叫IOC（編程術語）

IoC就是Inversion of Control，控制反轉。在Java開發中，IoC意味著將你設計好的類交給系統去控制，而不是在你的類內部控制。這稱為控制反轉。

下面我們以幾個例子來說明什麼是IoC

假設我們要設計一個Girl和一個Boy類，其中Girl有kiss方法，即Girl想要Kiss一個Boy。那麼，我們的問題是，Girl如何能夠認識這個Boy？

在我們中國，常見的MM與GG的認識方式有以下幾種
1 青梅竹馬； 2 親友介紹； 3 父母包辦
那麼哪一種才是最好呢？

青梅竹馬：Girl從小就知道自己的Boy。

public class Girl {
void kiss(){
Boy boy = new Boy();
}
}

然而從開始就創建的Boy缺點就是無法在更換。並且要負責Boy的整個生命周期。如果我們的Girl想要換一個怎麼辦？（嚴重不支持Girl經常更換Boy,#_#）

親友介紹：由中間人負責提供Boy來見面

public class Girl {
void kiss(){
Boy boy = BoyFactory.createBoy();
}
}

親友介紹，固然是好。如果不滿意，盡管另外換一個好了。但是，親友BoyFactory經常是以Singleton的形式出現，不然就是，存在於Globals，無處不在，無處不能。實在是太繁瑣了一點，不夠靈活。我為什麼一定要這個親友摻和進來呢？為什麼一定要付給她介紹費呢？萬一最好的朋友愛上了我的男朋友呢？

父母包辦：一切交給父母，自己不用費吹灰之力，只需要等著Kiss就好了。

public class Girl {
void kiss(Boy boy){
// kiss boy
boy.kiss();
}
}

Well，這是對Girl最好的方法，只要想辦法賄賂了Girl的父母，並把Boy交給他。那麼我們就可以輕松的和Girl來Kiss了。看來幾千年傳統的父母之命還真是有用哦。至少Boy和Girl不用自己瞎忙乎了。

這就是IOC，將對象的創建和獲取提取到外部。由外部容器提供需要的組件。

我們知道好萊塢原則：「Do not call us, we will call you.」 意思就是，You, girlie, do not call the boy. We will feed you a boy。

我們還應該知道依賴倒轉原則即 Dependence Inversion Princinple，DIP

Eric Gamma說，要面向抽象編程。面向介面編程是面向對象的核心。

組件應該分為兩部分，即 Service, 所提供功能的聲明 Implementation, Service的實現

好處是：多實現可以任意切換，防止 「everything depends on everything」 問題．即具體依賴於具體。

所以，我們的Boy應該是實現Kissable介面。這樣一旦Girl不想kiss可惡的Boy的話，還可以kiss可愛的kitten和慈祥的grandmother。
二、IOC的type

IoC的Type指的是Girl得到Boy的幾種不同方式。我們逐一來說明。

IOC type 0：不用IOC
public class Girl implements Servicable {
private Kissable kissable;
public Girl() {
kissable = new Boy();
}
public void kissYourKissable() {
kissable.kiss();
}
}

Girl自己建立自己的Boy，很難更換，很難共享給別人，只能單獨使用，並負責完全的生命周期。

IOC type 1，先看代碼：代碼

public class Girl implements Servicable {

Kissable kissable;

public void service(ServiceManager mgr) {
kissable = (Kissable) mgr.lookup(「kissable」);
}

public void kissYourKissable() {
kissable.kiss();
}

}

這種情況出現於Avalon Framework。一個組件實現了Servicable介面，就必須實現service方法，並傳入一個ServiceManager。其中會含有需要的其它組件。只需要在service方法中初始化需要的Boy。

另外，J2EE中從Context取得對象也屬於type 1。它依賴於配置文件。

IOC type 2：

public class Girl {

private Kissable kissable;

public void setKissable(Kissable kissable) {
this.kissable = kissable;
}

public void kissYourKissable() {
kissable.kiss();
}

}

Type 2出現於Spring Framework，是通過JavaBean的set方法來將需要的Boy傳遞給Girl。它必須依賴於配置文件。

IOC type 3:

public class Girl {

private Kissable kissable;

public Girl(Kissable kissable) {
this.kissable = kissable;
}

public void kissYourKissable() {
kissable.kiss();
}

}

這就是PicoContainer的組件 。通過構造函數傳遞Boy給Girl

PicoContainer container = new DefaultPicoContainer();
container.(Boy.class);
container.(Girl.class);
Girl girl = (Girl) container.getComponentInstance(Girl.class);
girl.kissYourKissable();

參考資料

1 http://www.picocontainer.org/presentations/JavaPolis2003.ppt
http://www.picocontainer.org/presentations/JavaPolis2003.pdf

2 DIP， Robert C Martin, Bob大叔的優秀論文
http://www.objectmentor.com/resources/articles/dip.pdf

3 Dependency Injection 依賴注射，Matrin Fowler對DIP的擴展
http://www.martinfowler.com/articles/injection.html

4 IOC框架

PicoContainer 優秀的IOC框架
http://picocontainer.org/

Avalon
http://avalon.apache.org/

Spring Framework
http://www.springframework.org/

HiveMind
http://jakarta.apache.org/commons/hivemind

E. 面向對象設計的基本原則有哪些

SRP單一職責原則
就一個類而言，應該專注於做一件事和僅有一個引起它變化的原因。
OCP開放－－封閉原則
對於擴展開放，對於修改封閉。
LSP里氏替換原則
子（繼承）類能在程序中代替父類（C#：基類，Java：超類）。
DIP 依賴倒置原則
抽象不依賴於細節，細節應該依賴抽象。（面向抽象編程，C#為面向介面編程）。
ISP介面隔離原則
介面屬於用戶類。（介面面用用戶類，不用想著和自身層次、方法相關）
REP重用發布等價原則
重用的粒度就是發布的粒度。（？這個沒有具體的認識）
CCP共同封閉原則
對於需求的響應，一個包中的所以類，有一個共同的響應（改變），而對於包外是不造成影響。
CRP 共同重用原則
包中的所有類共同重用，就是要重用就全部重用。
ADP 無環依賴原則
依賴關系不要存在環。
ADP 穩定依賴原則
朝著穩定的方向進行依賴。
SAP穩定抽象原則
包的抽象程度應該和穩定程序一致。

F. java面向介面編程思想

A s=new B();
一個對象實例只能賦值給與它類型相同的引用、或者父類(包括介面)的引用。
B是A的實現類所以B的實例可以賦值給A的引用。

實例：確實的對象；引用：指向某一對象的名字。

這個耦合度是指：一個類(或者對象)對另一個類(或者對象)的依賴。
如果用類的繼承，要求所有的具有某一個方法的一類對象都必須是指定類的子類對象，總是存在依賴，應用靈活度非常差！

G. C# 抽象類 和結構 和類是的用處包括構造函數 介面!!

結構我沒怎麼用過，認為作用不大。
抽象類和介面可以放在一起看。希望不要看完了越來越混淆。
構造函數的作用：舉個簡單的例子，當你在實例化一個對象的時候需要初始化類中某些屬性值，可以用構造函數。還有就是當我們實例化類時通過調用不同的構造函數得到我們想要的實例對象。
什麼是介面？介面是包含一組虛方法的抽象類型，其中每一種方法都有其名稱、參數和返回值。介面方法不能包含任何實現，CLR允許介面可以包含事件、屬性、索引器、靜態方法、靜態欄位、靜態構造函數以及常數。但是注意：C#中不能包含任何靜態成員。一個類可以實現多個介面，當一個類繼承某個介面時，它不僅要實現該介面定義的所有方法，還要實現該介面從其他介面中繼承的所有方法。定義方法為：

public interface System.IComparable
{
int CompareTo(object o);
}

public class TestCls: IComparable
{
public TestCls()
{
}

private int _value;
public int Value
{
get { return _value; }
set { _value = value; }
}

public int CompareTo(object o)
{

//使用as模式進行轉型判斷
TestCls aCls = o as TestCls;
if (aCls != null)
{

//實現抽象方法
return _value.CompareTo(aCls._value);
}
}
} 什麼是抽象類？ 抽象類提供多個派生類共享基類的公共定義，它既可以提供抽象方法，也可以提供非抽象方法。抽象類不能實例化，必須通過繼承由派生類實現其抽象方法，因此對抽象類不能使用new關鍵字，也不能被密封。如果派生類沒有實現所有的抽象方法，則該派生類也必須聲明為抽象類。另外，實現抽象方法由overriding方法來實現。定義方法為：
/// <summary>
/// 定義抽象類
/// </summary>
abstract public class Animal
{
//定義靜態欄位
protected int _id;

//定義屬性
public abstract int Id
{
get;
set;
}

//定義方法
public abstract void Eat();

//定義索引器
public string this[int i]
{
get;
set;
}
}

/// <summary>
/// 實現抽象類
/// </summary>
public class Dog: Animal
{
public override int Id
{
get {return _id;}
set {_id = value;}
}

public override void Eat()
{
Console.Write("Dog Eats.")
}
}
相同點和不同點 相同點 都不能被直接實例化，都可以通過繼承實現其抽象方法。 都是面向抽象編程的技術基礎，實現了諸多的設計模式。 不同點
介面支持多繼承；抽象類不能實現多繼承。 介面只能定義抽象規則；抽象類既可以定義規則，還可能提供已實現的成員。 介面是一組行為規范；抽象類是一個不完全的類，著重族的概念。 介面可以用於支持回調；抽象類不能實現回調，因為繼承不支持。 介面只包含方法、屬性、索引器、事件的簽名，但不能定義欄位和包含實現的方法；抽象類可以定義欄位、屬性、包含有實現的方法。 介面可以作用於值類型和引用類型；抽象類只能作用於引用類型。例如，Struct就可以繼承介面，而不能繼承類。 通過相同與不同的比較，我們只能說介面和抽象類，各有所長，但無優略。在實際的編程實踐中，我們要視具體情況來酌情量才，但是以下的經驗和積累，或許能給大家一些啟示，除了我的一些積累之外，很多都來源於經典，我相信經得起考驗。所以在規則與場合中，我們學習這些經典，最重要的是學以致用，當然我將以一家之言博大家之笑，看官請繼續。規則與場合 請記住，面向對象思想的一個最重要的原則就是：面向介面編程。 藉助介面和抽象類，23個設計模式中的很多思想被巧妙的實現了，我認為其精髓簡單說來就是：面向抽象編程。 抽象類應主要用於關系密切的對象，而介面最適合為不相關的類提供通用功能。 介面著重於CAN-DO關系類型，而抽象類則偏重於IS-A式的關系； 介面多定義對象的行為；抽象類多定義對象的屬性； 介面定義可以使用public、protected、internal 和private修飾符，但是幾乎所有的介面都定義為public，原因就不必多說了。 「介面不變」，是應該考慮的重要因素。所以，在由介面增加擴展時，應該增加新的介面，而不能更改現有介面。 盡量將介面設計成功能單一的功能塊，以.NET Framework為例，IDisposable、IDisposable、IComparable、IEquatable、IEnumerable等都只包含一個公共方法。 介面名稱前面的大寫字母「I」是一個約定，正如欄位名以下劃線開頭一樣，請堅持這些原則。 在介面中，所有的方法都默認為public。 如果預計會出現版本問題，可以創建「抽象類」。例如，創建了狗（Dog）、雞（Chicken）和鴨（Duck），那麼應該考慮抽象出動物（Animal）來應對以後可能出現風馬牛的事情。而向介面中添加新成員則會強制要求修改所有派生類，並重新編譯，所以版本式的問題最好以抽象類來實現。 從抽象類派生的非抽象類必須包括繼承的所有抽象方法和抽象訪問器的實實現。 對抽象類不能使用new關鍵字，也不能被密封，原因是抽象類不能被實例化。 在抽象方法聲明中不能使用 static 或 virtual 修飾符。 以上的規則，我就厚顏無恥的暫定為T14條吧，寫的這么累，就當一時的獎賞吧。大家也可以互通有無，我將及時修訂。 經典示例 絕對經典 .NET Framework是學習的最好資源，有意識的研究FCL是每個.NET程序員的必修課，關於介面和抽象類在FCL中的使用，我有以下的建議： FCL對集合類使用了基於介面的設計，所以請關注System.Collections中關於介面的設計實現； FCL對數據流相關類使用了基於抽象類的設計，所以請關注System.IO.Stream類的抽象類設計機制。 別樣小菜 下面的實例，因為是我的理解，因此給經典打上「相對」的記號，至於什麼時候晉升為「絕對」，就看我在.NET追求的路上，是否能夠一如既往的如此執著，因此我將把相對重構到絕對為止（呵呵）。 本示例沒有闡述抽象類和介面在設計模式中的應用，因為那將是另一篇有討論價值的文本，本文著眼與概念和原則的把握，但是真正的應用來自於具體的需求規范。 設計結構如圖所示： 1. 定義抽象類 public abstract class Animal
{
protected string _name;

//聲明抽象屬性
public abstract string Name
{
get;
}

//聲明抽象方法
public abstract void Show();

//實現一般方法
public void MakeVoice()
{
Console.WriteLine("All animals can make voice!");
}
}
2. 定義介面 public interface IAction
{
//定義公共方法標簽
void Move();
}
3. 實現抽象類和介面
public class Duck : Animal, IAction
{
public Duck(string name)
{
_name = name;
}

//重載抽象方法
public override void Show()
{
Console.WriteLine(_name + " is showing for you.");
}

//重載抽象屬性
public override string Name
{
get { return _name;}
}

//實現介面方法
public void Move()
{
Console.WriteLine("Duck also can swim.");
}

}

public class Dog : Animal, IAction
{
public Dog(string name)
{
_name = name;
}

public override void Show()
{
Console.WriteLine(_name + " is showing for you.");
}

public override string Name
{
get { return _name; }
}

public void Move()
{
Console.WriteLine(_name + " also can run.");
}

}
4. 客戶端實現
public class TestAnmial
{
public static void Main(string [] args)
{
Animal ck = new Duck("Duck");
ck.MakeVoice();
ck.Show();

Animal dog = new Dog("Dog");
dog.MakeVoice();
dog.Show();

IAction dogAction = new Dog("A big dog");
dogAction.Move();
}
}
他山之石 正所謂真理是大家看出來的，所以將園子里有創新性的觀點潛列於此，一是感謝大家的共享，二是完善一家之言的不足，希望能夠將領域形成知識，受用於我，受用於眾。 nai認為：抽象類是提取具體類的公因式，而介面是為了將一些不相關的類「雜湊」成一個共同的群體。至於他們在各個語言中的句法，語言細節並不是我關心的重點。 樺山澗的收藏也很不錯。 Artech認為：所代碼共用和可擴展性考慮，盡量使用Abstract Class。當然介面在其他方面的優勢，我認為也不可忽視。 shenfx認為：當在差異較大的對象間尋求功能上的共性時，使用介面；當在共性較多的對象間尋求功能上的差異時，使用抽象基類。 最後，MSDN的建議是： 如果預計要創建組件的多個版本，則創建抽象類。抽象類提供簡單易行的方法來控制組件版本。通過更新基類，所有繼承類都隨更改自動更新。另一方面，介面一旦創建就不能更改。如果需要介面的新版本，必須創建一個全新的介面。 如果創建的功能將在大范圍的全異對象間使用，則使用介面。抽象類應主要用於關系密切的對象，而介面最適合為不相關的類提供通用功能。 如果要設計小而簡練的功能塊，則使用介面。如果要設計大的功能單元，則使用抽象類。 如果要在組件的所有實現間提供通用的已實現功能，則使用抽象類。抽象類允許部分實現類，而介面不包含任何成員的實現。 結論介面和抽象類，是論壇上、課堂間討論最多的話題之一，之所以將這個老話題拿出來再議，是因為從我的體會來說，深刻的理解這兩個面向對象的基本內容，對於盤活面向對象的抽象化編程思想至關重要。本文基本概況了介面和抽象類的概念、異同和使用規則，從學習的觀點來看，我認為這些總結已經足以表達其核心。但是，對於面向對象和軟體設計的深入理解，還是建立在不斷實踐的基礎上，Scott說自己每天堅持一個小時用來寫Demo，那麼我們是不是更應該勤於鍵盤呢。對於介面和抽象類，請多用而知其然，多想而知其奧吧。

H. 面向對象編程是什麼意思

面向對象編程是以建立模型體現出來的抽象思維過程和面向對象的方法。對象的含義是指具體的某一個事物，即在現實生活中能夠看得見摸得著的事物。

在面向對象程序設計中，對象所指的是計算機系統中的某一個成分。在面向對象程序設計中，對象包含兩個含義，其中一個是數據，另外一個是動作。對象則是數據和動作的結合體。對象不僅能夠進行操作，同時還能夠及時記錄下操作結果。

方法是指對象能夠進行的操作，方法同時還有另外一個名稱，叫做函數。方法是類中的定義函數，其具體的作用就是對對象進行描述操作。

特徵

（1）對象唯一性。

每個對象都有自身唯一的標識，通過這種標識，可找到相應的對象。在對象的整個生命期中，它的標識都不改變，不同的對象不能有相同的標識。

（2）抽象性。

抽象性是指將具有一致的數據結構（屬性）和行為（操作）的對象抽象成類。一個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。

（3）繼承性。

繼承性是子類自動共享父類數據結構和方法的機制，這是類之間的一種關系。在定義和實現一個類的時候，可以在一個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，並加入若干新的內容。