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程序員而言，了解和運用面向對象技術的能力已經變得十分必要。最后，引用一句名言作為結束：最好的生物不是最強的也不是最聰明的，而是最適應變化的。