我們知道面向?qū)ο缶幊?OOP：Object Oriented Programming)是一種面向?qū)ο蟮某绦蛟O計方法。所謂“對象”就是一個或一組數(shù)據(jù)以及處理這些數(shù)據(jù)的方法和過程的集合。面向?qū)ο蟮某绦蛟O計完全不同于傳統(tǒng)的面向過程的程序設計，它大大地降低了應用程序開發(fā)的難度，使編程就像搭積木一樣簡單，是當今計算機編程的一股勢不可擋的潮流。
圖1：類
面向?qū)ο缶幊踢_到了軟件工程的三個主要目標：重用性、靈活性和擴展性。為了實現(xiàn)整體運算，每個對象都能夠接收信息、處理數(shù)據(jù)和向其它對象發(fā)送信息。面向?qū)ο笾饕幸韵碌母拍詈徒M件：
? 組件：數(shù)據(jù)和功能一起在運行著的計算機程序中形成的單元，組件在面向?qū)ο蟮木幊讨惺悄K和結構化的基礎。
? 抽象：程序有能力忽略正在處理中信息的某些方面，即對信息主要方面關注的能力。
? 封裝：也叫做信息封裝，確保組件不會以不可預期的方式改變其它組件的內(nèi)部狀態(tài);只有在那些提供了內(nèi)部狀態(tài)改變方法的組件中，才可以訪問其內(nèi)部狀態(tài)。每類組件都提供了一個與其它組件聯(lián)系的接口，并規(guī)定了其它組件進行調(diào)用的方法。
? 多態(tài)：組件的引用和類集會涉及到其它許多不同類型的組件，而且引用組件所產(chǎn)生的結果得依據(jù)實際調(diào)用的類型。
? 繼承：允許在現(xiàn)存的組件基礎上創(chuàng)建子類組件，這統(tǒng)一并增強了多態(tài)性和封裝性。典型地來說就是用類來對組件進行分組，而且還可以定義新類為現(xiàn)存的類的擴展，這樣就可以把類組織成樹形或網(wǎng)狀結構，這體現(xiàn)了動作的通用性。
圖2：繼承
最近，一家德國的媒體把精力集中到控制系統(tǒng)工程的主題上，特別是關于編程的問題。讓他們對這個問題如此大的投入原因是軟件編程在自動化工程中占有很大的比重。在編程問題上，他們又特別對面向?qū)ο缶幊痰脑掝}最感興趣。你可能同意這樣的觀點：面向?qū)ο蟮木幊桃呀?jīng)不知不覺地進入了自動化，并且建立了它們自己的領地。
有些題目不值得爭論?？刂葡到y(tǒng)的面向?qū)ο缶幊趟坪跏瞧渲械闹弧＿@家媒體的編輯馬丁?布克維茨一直在拜訪幾個控制器的生產(chǎn)商，與他們探討控制工程的問題。到現(xiàn)在，已經(jīng)進行了若干次會面，得出的信息如下：
圖3：封裝
至今為止，我已經(jīng)看到一些有趣的發(fā)展。我還沒有遇到一位供應商對面向?qū)ο蟮木幊虥]有興趣。但控制器生產(chǎn)商之間的不同只是實施策略和實現(xiàn)級別。有些公司已經(jīng)在廣告中聲稱他們使用了面向?qū)ο缶幊痰姆椒?他們的產(chǎn)品使用了這種方法編程的結果，而且可以看出它的競爭優(yōu)勢。另外有些公司沒有一直使用這項技術，而且今后很少或者不再使用這個概念。
第三組生產(chǎn)商的情況是，軟件工程師只是為了工作更有趣和增加編碼的重用性，在這兒或那兒使用面向?qū)ο缶幊?，不作為常態(tài)或要求來使用。雖然這組的聲音不大，但卻在靜靜地使用。
如果對準了控制器編程人員的巨大市場，為他們一步一步地介紹面向?qū)ο蟮木幊淌潜容^明智的。有些概念，諸如類、繼承、實例化，明顯會讓 PLC系統(tǒng)的編程人員嚇壞。 使用程序調(diào)用來替換程序的手動輸入已經(jīng)有很多年了，因此，使用面向?qū)ο蟮木幊淌且环N進化，不會令人驚訝。
其實，在國際電工委員會頒布了可編程控制器的標準IEC61131-3標準后，很多控制器生產(chǎn)商都在兩種圖形編程語言：梯形圖(LD)和功能塊圖(FB)中支持一種稱為自編功能塊(Add-On Instructions)或?qū)С龉δ軌K(Derived Function Block)它就具有前面所說的封裝、繼承和實例化的特性。所以，雖然沒有聲明是否采用了面向?qū)ο蟮木幊碳夹g，但實際上在用戶熟悉的編程環(huán)境中，已經(jīng)采用了這項技術和概念。這種方法可能更容易被自動化和控制工程師所采用，因為電氣工程師最習慣梯形圖，而流程工程師最偏好功能塊圖，只有軟件編程人員比較熟悉面向?qū)ο蟮募夹g。
圖4：自編功能塊
這項技術具有很多的先進性：
? 大大提高了編碼的重用性;
? 程序具有良好的質(zhì)量;
? 在團隊中工作更簡化;
? 管理編程也更加簡單;
? 對程序修改也很簡單。
不管用戶個人對面向?qū)ο缶幊痰倪x擇是什么，在自動化中已經(jīng)繞不開面向?qū)ο蟮木幊塘?。盡快設計和打包這項技術，展示它的用途，消除概念和理論中不必要的障礙是生產(chǎn)商的責任。建議用戶在自動化中盡早使用面向?qū)ο蟮木幊谭椒?，因為OOP是未來的發(fā)展方向。
（轉(zhuǎn)載）
