為什麼ABAP開發者需要使用面向對象技術？

ABAP對面向對象的支援已有十多年的曆史，然而在生産實踐中，我們對這門技術的應用十分有限。

一方面，面向過程的慣性長期存在着；另一方面，對于大部分二次開發工作而言，似乎并沒有足夠的理由促使開發者使用面向對象技術。二者結合的結果，就是目前大部分ABAP開發者還在隻寫面向過程的代碼。

我不認為面向對象是可以解決開發中各種問題的“銀彈”，但是它畢竟是一項經過了考驗的技術。在2017年的現在，多數人已經承認面向對象給我們帶來了相當的好處。面向對象的三個基本特性、五個基本原則（SOLID）已經成為路人皆知的事情。關于它的通常的好處，本文不打算再複述，畢竟相關的文章讨論已經太多。

此外，對于ABAP開發而言，它還有一些額外的好處。在下文，我會分别介紹它們。

本文連結：http://www.cnblogs.com/hhelibeb/p/7641965.html

轉載請注明

1, 避免過時文法

我們知道，在abap的聲明文法中，type是直接聲明類型，like是參考聲明類型。很多新手在入門時會被like與type的差別弄暈，甚至為了不出錯，完全使用like代替type。而abap是支援為變量起一個和類型名相同的變量名的，如果程式存在着和類型名相同的變量名，開發者又不懂得like和type的差別的話，代碼中難免會出錯。類似的“小知識”給開發者帶來了不小的負擔。雖然這種特性已經在文檔中标記為obsolete，但是，出于相容性之類的考慮，SAP依然允許它們的使用。

然而在OO語境中，文法檢查器會對過時文法報錯，這使得開發者可以安心抛開某些ABAP中存在的曆史包袱，不需要再勉強自己記住那些無謂的規則。

2, 了解标準程式

相對于客戶自定義開發的内容，SAP系統中已有的程式被我們稱為标準程式。SAP已經在系統标準程式中大量使用了面向對象技術，在某些産品和子產品中，可以說面向對象成為了主流。比如CRM中的BOL，還有SAP正在推廣的架構BOPF，功能強大的業務規則架構BRF+等。

ABAP的開發工作是基于SAP系統的，對标準程式的閱讀了解、調試、修改（增強）是ABAP程式員工作的重要内容。如果開發者沒有一定的面向對象程式設計經驗的話，就很難對這些大量使用了面向對象技術的程式進行增強開發，也難以對它們進行跟蹤與調試，進而給工作帶來困難。

在自己編寫面向對象程式的過程中，我們可以逐漸了解內建、多态等概念，熟悉與面向對象相關相關的文法，借此提高自己對标準代碼的了解能力。

3, 從另一個角度自省

随着工作的進行和個人掌握的知識的變化，我們會對同一段功能産生新的看法，進而用新的代碼來進行表達，是以很多人有重構甚至重寫代碼的習慣。不過人的耐心總是有限的，重構幾次，感覺自己的代碼已經“差不多了”，已經可複用、便于擴充，甚至已經“接近完美”，無需再改。這是難以避免的事情，因為，人的大腦有忽略熟悉的事物的傾向，同樣的男/女朋友，看久了，便會忽略他們的美醜。如何促進自己進一步自省？使用新技術可能是一個辦法。

在嘗試把代碼轉換為面向對象的過程中，新技術的使用會促使我們從另一個角度看待曾經過于熟悉以至于被忽略的代碼，激發大腦進一步運作，進而得到新的看法和啟發。原本已經固定的代碼，又可以再次重構了。當然，這種改變不一定總是好的。面向對象的一個引起争議的地方，就是它導緻很多程式員、特别是中等水準的程式員，會不自覺地傾向于“過度設計”，無必要地設計多餘的接口和繼承關系、使用各種設計模式，為增加程式的複雜度。但對于個人而言，相比收益，這一點代價還是可以接受的，畢竟，沒有犯錯，又何來進步呢？

4, 更友善的重構/測試

使用ADT時可以友善地對OO代碼重構和生成單元測試方法。具體内容可以參考 Writing Testable Code for ABAP 。

5, 分解開發任務

基于面向對象的開發可以使開發任務的分解更加友善，因為它能提供良好的解耦和隔離能力，比如，讓資深的開發者進行接口、類的設計，而讓新手進行單一方法的開發。

我們進行過一點這方面的實踐：AMDP + XLSX Workbench 報表開發模式

總結

在SAP的世界裡，面向對象技術已經有着不亞于面向過程的地位，并且還在穩步地提升中。本文無意鼓吹其中的一個替代另一個，但是，對ABAP程式員而言，了解和運用面向對象技術的能力已經變得十分必要。最後，引用一句名言作為結束：最好的生物不是最強的也不是最聰明的，而是最适應變化的。