面向編程

⑴ 面向介面編程和面向實現編程的區別

這個涉及到設計上的原則，也就是依賴倒轉原則。舉個簡單的例子，我們經常用的操作資料庫的方法，在jdk中定義的都是介面，由不同的資料庫廠商實現，比如mysql的驅動，oracle的驅動，都是實現了jdk中定義介面標准。jdk中的設計就是面向介面的，而不同的資料庫廠商就是面向實現的。
面向介面的好處就是，定義好介面標准，不管是誰只要按定義好的標准來實現，都可以無縫的切換，所以您應該發現，不管是用mysql也好，還是用oracle也都，您都是在使用jdk的api。

⑵ 面向過程的編程

到了編程就是:
public class 汽車運營
{
void 汽車啟動
{
}
void 汽車到站
{
}
}
「面向對象」需要建立一個汽車的實體，由實體引發事件。我們關心的是由汽車抽象成的對象,這個對象有自己的屬性,像輪胎,顏色等;有自己的方法,像啟動,行駛等.方法也就是汽車的行為.而不是汽車的每個事件。
public class 汽車
{
void 到站()
{
}
void 啟動()
{
}
}
使用的時候需要建立一個汽車對象，然後進行應用。

⑶ 面向方面編程的特點

每個框架應用切點、通知或方面的方法都是獨特的，但是其目的和概念是相同的。在本文示例中，Encaser 包裝一個對象時真正進行的操作是，通過 System.Reflection.Emit 命名空間中的類產生 MSIL 代碼，從而隨時創建新的 Contact 類型。新 Contact 類型派生於 Contact 類，它仍然共享類型，但是新包裝的對象還持有對 ContactSave 對象的引用，後者是我們混入的。ISavable.Save 方法在新的 Contact對象上實現，因此在調用 Save 時，它實際上將調用委託給混入的 ContactSave 對象。這樣做的優點是能夠將新的 Contact對象轉換為在任何混入對象上實現的任何介面。

圖 2. 包裝對象的 UML 圖表。
您或許在想，通過 .NET Framework 2.0 的部分類語言功能，可以在另一個 partial 類中添加 Save 行為。這是可能實現的，但是本文沒有採用這種方法，這是為了使代碼與 .NET Framework 1.x 的其他版本向後兼容。既然有部分語言功能，那麼在正常情況下，前面的示例也就不需要使用混入 了。但是混入 仍然很有價值，因為通過它，開發人員可以混入可重用的對象行為，這些對象可以源自其他不相關的對象層次結構，它實現的功能比 partial 類更多。在使用 partial 關鍵字時，是在同一個類或類型中添加代碼，只不過物理位置不同。下一個混入示例說明的添加行為不只特定於 Contact 類，而是一個名為 FieldUndoer 的可重用類。FieldUndoer 實現了 IUndoable 介面，允許已修改的對象恢復為原來的狀態。
Public Interface IUndoable
ReadOnly Property HasChanges() As Boolean
Sub Undo()
Sub AcceptChanges()
End Interface
HasChanges 屬性表示，如果發生了更改，Undo 將對象恢復為原來的狀態，AcceptChanges 接收對象的當前更改，因此任何時候再調用 Undo 時都會恢復為上一次接收更改的狀態。如果該介面是在一個部分類中實現的，那麼在每個希望包含該行為的類中，都必須不厭其煩地重復實現這三個方法。作為一個實用主義編程人員，我嘗試堅持「一次且僅一次代碼」原則，所以我永遠不想重復任何代碼，復制和粘貼越少越好。通過使用混入，我能夠重用實現 IUndoable 的 FieldUndoer對象。在 ServiceManager 中我又混入了這個新功能。所有客戶端代碼仍然不知道新的混入，而且也不需要更改，除非需要使用 IUndoable 介面。更改 MainForm 中的 Contact對象，然後單擊「撤消」，測試這個行為。
Public Shared Function GetAllContacts() As ContactService.Contact()
Dim service As ContactService.Service = New ContactService.Service
Dim contacts() As ContactService.Contact = service.GetAllContacts
'//Wrap each contact object
For i As Integer = 0 To contacts.Length-1
'//Create a new instance of the encaser
'//responsible for wrapping our object
Dim encaser As encaser = New encaser
'//Add mixin instance of ContactSave
Dim saver As ContactSave = New ContactSave
encaser.AddMixin(saver)
'//Add mixin instance of FieldUndoer
Dim undoer As FieldUndoer = New FieldUndoer
encaser.AddMixin(undoer)
'//Creates a new object with Contact
'//and ContactSave implementations
Dim wrappedObject As Object = encaser.Wrap(contacts(i))
'//Assign our new wrapped contact object
'//to the previous contact object
contacts(i) = DirectCast(wrappedObject, _
ContactService.Contact)
'//Notice the wrapped object is still the same type
'//Assign the new wrapped Contact object to target fields
saver.Target = contacts(i)
undoer.Target = contacts(i)
Next
Return contacts
End Function
組合行為
混入還只是冰山一角。真正讓 AOP 聲名鵲起的功能是組合混入行為。以使用新 Contact對象為例，在調用 ISavable.Save 方法時，客戶端代碼還需要調用 IUndoable.AcceptChanges 方法，以便在下一次調用 IUndoable.Undo 時恢復到所保存的上一次更改。在這個小的 MainForm 中瀏覽和添加該對象很容易，但是在任何比用戶界面大得多的系統中對該規則編碼將是一項繁重的任務。您需要查找所有調用 Save 方法的情況，然後添加另一個對 AcceptChanges 的調用。而且在創建新代碼的過程中，開發人員也需要牢記，在每次調用 Save 時都添加這個新功能。這很快就會產生級聯效應，很容易會破壞系統穩定姓，引入一些難於跟蹤的 bug。而使用面向方面的編程則能夠組合這些方法。指定一個切點和通知，在調用 Save 方法時，Contact對象將自動調用後台的 AcceptChanges。
為了在應用程序中實現組合，需要在 ServiceManager 中再添加一行代碼。我們在加入 FieldUndoer 混入後添加這行代碼。
'//Specify join point save, execute the AcceptChanges method
encaser.AddPointcut(Save, AcceptChanges)
AddPointcut 方法通過幾個不同的簽名進行重載，這為指定切點提供了更大的靈活性。我們調用的 AddPointcut 接收了一個字元串類型的接合點名，它表示為 Save 方法，然後又接收了一個名為 AcceptChanges 的方法作為執行的通知。要查看這是否起作用，可以分別在 FieldUndoer.AcceptChanges 方法和 ContactSave.Save 方法前設置一個斷點。單擊 MainForm 上的 Save 按鈕將截獲接合點，您首先將中斷至通知 — 即 AcceptChanges 方法。通知執行後將執行 Save 方法。
這個簡單的示例說明如何添加貫穿整個應用程序的新行為，其功能強大無比。盡管有此功能，但它不僅僅是添加功能的一種很好的新方法。在眾多優點中，只有幾個涉及代碼重用，以及通過簡化新需求帶來的系統進化來改進系統的可維護性。與此同時，誤用 AOP 會對系統的可維護性造成顯著的負面效應，因此了解使用 AOP 的時機和方法很重要。
AOP 走了多遠？
將 AOP 用於多數大型系統或關鍵的生產系統還不完全成熟，但是隨著語言支持的提高，AOP 的應用將更容易。另外，提高支持也是新的軟體開發範例，例如利用面向方面的編程的軟體工廠。在 .NET 領域中有幾種可用的 AOP 框架，每個框架都有其自己的方法、正面屬性和負面屬性。
Encase — 本代碼示例中的 Encase 框架只是一個工具，幫助您快速了解並運行 AOP，以及理解 AOP 背後的概念。Encase 在運行時期間應用能夠單獨添加到對象的方面。
Aspect# — 一個針對 CLI 的 AOP 聯合兼容框架，提供聲明和配置方面的內置語言。
RAIL — RAIL 框架在虛擬機JIT 類時應用方面。
Spring.。。。 — 流行的 java Spring 框架的一個 .NET 版本。在下一個版本中將實現 AOP。
Eos — 用於 C# 的一個面向方面的擴展。

⑷ 什麼叫做面向薪水編程

編程界有句行話「面向對象編程」，這是Java的編程思想。你現在說的「面向薪水編程」有戲謔的意思，就是那邊給的薪水高就往那邊去編程！！

⑸ 面向方面編程的簡介

在考慮對象及對象與其他對象的關系時，我們通常會想到繼承這個術語。例如，定義某一個抽象類— Dog 類。在標識相似的一些類但每個類又有各自的獨特行為時，通常使用繼承來擴展功能。舉例來說，如果標識了 Poodle，則可以說一個 Poodle 是一個 Dog，即 Poodle繼承了 Dog。到此為止都似乎不錯，但是如果定義另一個以後標識為 Obedient Dog 的獨特行為又會怎樣呢？當然，不是所有的 Dogs 都很馴服，所以 Dog 類不能包含 obedience 行為。此外，如果要創建從 Dog繼承的 Obedient Dog 類，那麼 Poodle 放在這個層次結構中的哪個位置合適呢？Poodle 是一個 Dog，但是 Poodle 不一定 obedient；那麼 Poodle 是繼承於 Dog 還是 Obedient Dog 呢？都不是，我們可以將馴服看作一個方面，將其應用到任何一類馴服的 Dog，我們反對以不恰當的方式強制將該行為放在 Dog 層次結構中。
在軟體術語中，面向方面的編程能夠獨立於任何繼承層次結構而應用改變類或對象行為的方面。然後，在運行時或編譯時應用這些方面。舉一個關於AOP的示例，然後進行描述，說明起來比較容易。首先，定義四個關鍵的 AOP 術語，這很重要，因為我將反復使用它們：
接合點 (Joinpoint) — 代碼中定義明確的可識別的點。
切點 (Pointcut) — 通過配置或編碼指定接合點的一種方法。
通知 (Advice) — 表示需要執行交叉切割動作的一種方法
混入 (Mixin) — 通過將一個類的實例混入目標類的實例引入新行為。
為了更好地理解這些術語，可以將接合點看作程序流中定義好的一點。說明接合點的一個很好的示例是：在代碼調用一個方法時，發生調用的那一點被認為是一個接合點。切點用於指定或定義希望在程序流中截獲的接合點。切點還包含一個通知，該通知在到達接合點時發生。因此，如果在一個調用的特定方法上定義一個切點，那麼在調用該方法或接合點時，AOP 框架將截獲該切點，同時還將執行切點的通知。通知有幾種類型，但是最常見的情況是將其看作要調用的另一個方法。在調用一個帶有切點的方法時，要執行的通知將是另一個要調用的方法。要調用的這個通知或方法可以是對象中被截獲的方法，也可以是混入的另一個對象中的方法。我們將在後面進一步解釋混入。

⑹ 什麼叫面向變數編程

1.其實程序的傳遞就是變數的傳遞，變數是任何編程中不可缺少的因素。隨著很多模式和編程方式的出現,應用設計可能層次比較清楚，更宜人理解。然而變數將變得很多，同樣作用的變數在不同的層中可能不一樣，而且隨著不同開發人員在同一時間開發不同的層或者不同時間開發同一模塊都可能根據自己的想法聲明或者定義某個變數，而他們所定義的這個變數其實都是一樣的， 理論上應該是一個變數，或者說至少命名應該一樣。如果能歸為同樣命名的變數，那就能很大程度上減少維護和開發的工作。所以能否將同樣功能的變數進行統一命名就很有必要。 2.了解變數其實就是了解業務，雖然很早就強調文檔，強調業務知識的學習，然而我覺得看程序其實是了解業務的最好方法，但條件是程序比較清楚， 這里包括應用的構架清晰，具有相應的備注以及變數的含義清晰。 變數一個很重要的屬性是她的scope， 根據scope我們可以將用到的變數進行分類，幫助我們理解。下面我就web應用將變數scope進行分類(其實同樣適用於其他應用)： 我們把變數分為兩大類， 一類是 面向變數所關心的，他具有跨越型傳遞性，他這里的跨越型傳遞性表示該變數的所附屬的值會傳遞到下個地方，這個地方可以是下個頁面， 可以是伺服器 可以是資料庫中我們稱該類變數為前鋒型變數 。另一類是 面向對象所不關心的， 他不具有跨越型傳遞性， 他只是作為臨時中介，比如某個頁面的中的臨時變數，java 方法中的臨時變數. 他們不是我們所關心的，我們稱這里變數為候補型變數 。對於面向對象的編程我們的原則是： 前鋒型變數命名要很清晰，要能夠聯動，能串成串，不要冗餘；候補型變數命名要簡潔，最好不要游離在方法外，在方法中產生，在方法中消亡。 而對於前鋒型變數 我認為因為他承載著有效數據，他的理解往往反映了業務，並且它是全局性的，具有跨越型的傳遞，所以他的重要性會更大一點，那麼針對他能有很多tool 可以做。 Tool 1：前鋒變數聯動機功能描述：在頁面上定義一個前鋒型變數，那麼可以自動在資料庫中添加該欄位 在DAO層 Business層添加該變數，同時可以實現修改某個頁面變數 同時資料庫以及各個層都能改變該變數。 或者 在資料庫層添加某個欄位 對應能產生頁面,DAOBusiness的前鋒型變數. Tool2: 前鋒變數檢查工具功能描述：可以對某個頁面,某個配置文件,資料庫 查找所有的前鋒型變數。將這些變數陳列出來給開發人員或者管理人員來分析。 是否還有其他idea？ 請幫忙想想。。。

⑺ 什麼是面向過程編程

面向過程:把一個問題分解成若干小問題,再對每個小問題進行分解(分模塊),知道每個問題的難度都足以小,能夠解決為止,然後再把這些小問題合並,就解決了大問題

==========================================================

面向過程
面向過程」是一種以事件為中心的編程思想。

「面向對象」是一種以事務為中心的編程思想。

比如以公共汽車而言。

「面向過程」就是汽車啟動是一個事件，汽車到站是另一個事件。在編程序的時候我們不關心的是某一個事件。而不是汽車本身。我們分別對啟動和到站編寫程序。類似的還有修理等等。

到了編程就是:

public class 運營

{

void 汽車啟動

{

}

void 汽車到站

{

}

}

「面向對象」需要建立一個汽車的實體，由實體引發事件。我們關心的是一個汽車而不是汽車的沒個事件。

public class 汽車

{

void 到站()

{

}

void 啟動()

{

}

}

使用的時候需要建立一個汽車對象，然後進行應用。

⑻ 面向組件編程是什麼

所有的軟體技術和思想的出現都是為了解決所在的那個年代軟體開發的復雜性，對象技術和組件技術也不例外。當然還有很多其它技術，像DBC（契約式編程）、AOP、MDA等，這些思想都在影響我們設計/實現程序的方式，但無可否認的是，當今最主流的編程技術是對象技術和組件技術。 面向對象技術已經成熟的發展將近20年了，關於這方面的經典書籍和論文也隨處可見。為了解決更大的系統的復雜度，組件技術應運而生，在windows平台上，組件從最初的動態鏈接庫到COM，在到現在的中間件、.NET，就是組件思想走過的軌跡。
面向對象技術的基礎是封裝－－介面與實現分離，面向對象的核心是多態－－這是介面和實現分離的更高級升華，使得在運行時可以動態根據條件來選擇隱藏在介面後面的實現，面向對象的表現形式是類和繼承。面向對象的主要目標是使系統對象化，良好的對象化的結果，就是系統的各部分更加清晰化，耦合度大大降低。

面向組件技術建立在對象技術之上，它是對象技術的進一步發展，類這個概念仍然是組件技術中一個基礎的概念，但是組件技術更核心的概念是介面。組件技術的主要目標是復用－－粗粒度的復用，這不是類的復用，而是組件的復用，如一個dll、一個中間件，甚至一個框架。一個組件可以有一個類或多個類及其它元素（枚舉、）組成，但是組件有個很明顯的特徵，就是它是一個獨立的物理單元，經常以非源碼的形式（如二進制，IL）存在。一個完整的組件中一般有一個主類，而其它的類和元素都是為了支持該主類的功能實現而存在的。為了支持這種物理獨立性和粗粒度的復用，組件需要更高級的概念支撐，其中最基本的就是屬性和事件，在對象的技術中曾一度困擾我們的類之間的相互依賴問題/消息傳遞問題，迄今為止我所知道最好的解決方案就是事件。要理解組件思想，首先要理解事件的思想和機制。

我一直堅持以為，一個組件的外形/外貌應該是簡單的、應該是清晰的、沒有冗餘的東西、也沒有無關緊要的東西，這個外貌通過介面來描述，介面中可以發布事件、屬性和方法。這三種元素就足以描述一個組件外貌的所有特徵。比如，我曾經用封裝的一個完成埠組件，其外貌介面中只有四個方法，三個事件，三個屬性而已，而該組件的內部實現卻有幾千行代碼。所以在設計一個組件的時候，需要做很多的權衡，哪些需要通過介面暴露出來，哪些應當作為私有實現。有時，你會處於兩難的境地，因為讓組件更容易使用，所以需要給出很多默認的參數，但為了使該組件更通用，你又需要暴露更多的屬性可以讓人設定、暴露更多的方法和事件滿足更復雜的功能。你需要抉擇，你需要權衡。難怪有人會說，軟體的設計更像是藝術，因為藝術的美在於恰當的抉擇和平衡。我的經驗是，在保持低耦合度的前提下，組件的介面足以對付當前的應用就好。如果日後需要加強功能，那就重構然後增強它，這是很容易的，因為早就說了嘛，保持組件的低耦合度。

需要說明一下的是，我們通常所說的控制項（如按鈕）也是一種組件，可以這么認為，控制項是一種具有UI形式的組件。插件（Addin/Plugin）也是一種特殊的組件，插件的單獨存在是沒有意義的，它是由兼容該插件協議的框架所使用。

最後強調一點，組件的目標是粗粒度的復用，組件的核心是介面。

⑼ 面向切面編程和面向介面編程的區別

談談自己的理解吧：

面向切面編程:

手段：分離業務的主邏輯和次邏輯的一種思想。

目的：解決的是邏輯分離問題（主邏輯和次邏輯分開，其實主要是分離業務邏輯和非業務邏輯分開）。

案例：我們開發項目的時候基本都要去連接資料庫操作數據等，但是都會涉及到事務的提交，這時我們就用到了面向切面編程，我們在業務層只寫自己的業務邏輯，提交事務這一塊統一的動作我們就濃縮到了一塊兒統一處理，形象一點比喻就是我們做什麼事之前都以一個准備動作或結束動作的時候就把它統一起來，只關注我們要完成的事，這些准備動作統一完成！

類似的面向切面編程案例還有：系統日誌的記錄、請求的攔截等

面向介面編程：

手段：通過介面規約對象的屬性和方法，是面向對象一部分。

目的：統一標准問題,讓大家不至於各行其事而對代碼的可讀性造成影響（公用部分行為）。

案例：其實這個比較好解釋，就是有一件事，需要大家去完成，但是給你規定了完成的方式，你只能怎麼去做，這時我們當中任何一個人都能去完成這件事，只不過因人而異會有效率和風格的差異，但是都是按照事先的規定來的！比如：讓你去給資料庫添加一行數據返回受影響的行數，這里大家都去實現介面寫SQL，中間可能會有差異，但是最後都得返回一個int類型的受影響行數回來

大體意思就是說：介面給我們規定了完成一個任務的標准，但是具體過程不限制，任何人都能通過遵循的規定去完成這件事！這樣擴展性就很強！

個人水平有限，如果不滿意請參考：網頁鏈接

⑽ C語言是面向程序設計語言的是什麼

C語言是一門通用計算機編程語言，應用廣泛。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。

盡管C語言提供了許多低級處理的功能，但仍然保持著良好跨平台的特性，以一個標准規格寫出的C語言程序可在許多電腦平台上進行編譯，甚至包含一些嵌入式處理器（單片機或稱MCU）以及超級電腦等作業平台。

二十世紀八十年代，為了避免各開發廠商用的C語言語法產生差異，由美國國家標准局為C語言訂定了一套完整的國際標准語法，稱為ANSI C，作為C語言最初的標准。