OO ABAP：何時以及為什么？

Question

在我的公司從 4.6c 升級到 ECC6.0 幾個月后，我們的程序員團隊仍在使用傳統的 4.7c 方式進行編碼。 我渴望嘗試 ABAP 的新 OO 方法，但令我沮喪的是，這里的大多數人只強調在給定的最短時間框架內完成工作。

我的問題是：
1) 您組織中的人員何時真正開始使用 OO ABAP 進行編碼？
2）人們是否有任何重要的理由想要以 OO 方式對其進行編碼？ 例如，調用方法比 PERFORM 語句更快？

Answer 1

1) 您組織中的人員何時真正開始使用 OO ABAP 進行編碼？

我組織中的大多數開發人員在引入 ABAP OO 之前就已經學習了經典的 ABAP。 他們大多是高級開發人員，他們克制學習正確的 OOP 和 OOD 原理。 他們仍然主要使用程序性 ABAP 功能。 此外，我們在傳統環境中工作。 我們后端的基礎是在 4.6C 時代構建的。 很難將正確的 OO 設計引入遺留系統。

另一方面，程序功能仍然有效。 諸如事務數據庫更新之類的一些功能主要從 ABAP 的程序部分使用。 您可能知道專門用於數據庫事務的 Update Function 模塊或子例程（您可以調用IN UPDATE TASK ）。 它們是 ABAP 基本組件的組成部分。 不能否認仍然需要程序性 ABAP 部分。

2）人們是否有任何重要的理由想要以 OO 方式對其進行編碼？ 例如，調用方法比 PERFORM 語句更快？

您如何比較 CALL METHOD 與 PERFOM 的運行時間？ 您是否嘗試過 RSHOWTIM 程序/或者您是否從 ABAP 工作台進行了一些性能測試？ 單個子例程調用與方法調用沒有顯着差異。 但是，如果在大規模測試方法調用中調用，則性能稍好（以微秒為單位）。

總的來說，我推薦OOD和OOP與之前發布的用戶相同的arguments。 但是您必須記住，熟悉舊 ABAP 世界的高級開發人員在開始編寫 ABAP OO 之前必須了解 OO 原理。 否則，相反，您的組織不會從 ABAP OO 中獲利。 有很多沒有 OO 知識的有經驗的 ABAP 開發人員被迫編寫類。 他們所做的實際上是用類模仿程序原則（例如，class 和 static 方法專門用於替代 function 模塊/子例程）。

祝您的組織好運，迎接 ABAP OO 的挑戰，這與語言無關。 它更多的是讓您的員工了解 OO 原則。

Answer 2

我不了解 ABAP，但我看到 VB 開發人員遷移到 .Net 平台時也發生了同樣的情況。

程序員對他們舊的編程方式很滿意，而且舊的方式仍然有效。 新的編程方式需要大量投資，不僅來自公司，還來自那些不得不走出舒適區進入不確定領域的人。 如果您的公司不願意在培訓和研究上投入時間，這個問題就會變得更大，因為人們將不得不投入自己的時間，並不是每個人都願意這樣做。

正如 Taurean 已經表明的那樣，有令人信服的理由轉向 OO 做事方式。 它們主要不是關於性能，而是關於更好地解耦系統中的組件，使其更易於維護。

但根據我的經驗，很難說服人們使用這樣的合理 arguments 走出他們的舒適區。 給他們指路通常效果更好。 慢慢開始在你自己的代碼中使用 OO 結構，向人們展示它看起來多么干凈。 這不是您在幾個月內就能實現的目標，可能需要數年時間才能讓人們以不同的方式思考和工作。

Answer 3

一個由經驗豐富的程序開發人員組成的團隊不太可能很快開始以 OO 風格進行開發，除非付出大量（且昂貴）的努力來培訓和指導他們。

原因有很多：

• 在真正的 OO 環境（smalltalk，不是 java 或 c++）中投入大約一年的時間才能在 OO 開發方面取得任何優勢。
• 他們不能從頭開始，有很多遺留代碼和時間壓力。
• 他們所有的遺留代碼都不是面向對象的。 重組需要付出巨大的努力。
• 遺留代碼結構不完善，有很多重復，沒有單元測試。 改變它需要太多時間，所以他們沒有時間修復。 （令人驚訝的是，您可以在不了解項目的情況下從項目中推斷出。:)）。

因此，他們的新代碼很可能是程序性的，但在類和方法中。 他們不會被 OO 的優勢所折服。

Answer 4

切換到 ABAP OO 的一些充分理由是：

• ABAP OO 更明確，更易於使用
• ABAP OO 有更嚴格的語法檢查，消除了 ABAP 語言中的很多歧義
• 許多新的 Netweaver 功能僅在使用 OO 時可用

將此添加到Taurean列出的好處中：

• 更好的數據封裝
• 多重實例化
• 更好的垃圾收集
• 通過 inheritance 重用代碼
• 通過標准接口操作業務對象
• 事件驅動編程

開始使用 ABAP OO：

• 首先在代碼中調用一些 SAP 標准 OO 功能：使用 ALV 類，而不是 Function 模塊 - 這些類提供了更多功能。 嘗試調用CL_ABAP*或CL_GUI_FRONTEND*類中的一些標准方法
• 使用本地類將報告編寫為 Singleton
• 嘗試在 SE24 中為您熟悉的東西（例如文件處理程序）設計一個簡單的 class

資源：

1. Igor Barbaric 的面向對象 ABAP 中的設計模式
2. 還沒有使用 ABAP 對象？ 每個 ABAP 開發人員都應該重新審視它的八個原因。 霍斯特·凱勒和格德·克魯格

Answer 5

OO 與否 OO 不是問題！！

問題是 OO 在哪里，在哪里不是 OO。

只要您在客戶名稱空間中，就可以充分利用 OO 方法（OOD 和 OOP）的所有優勢。 然而，每次訪問 SAP 標准功能都會讓人頭疼。 事務完整性、object 一致性和同步、數據庫提交、屏幕（模塊池和選擇屏幕）、權限檢查、批量輸入。 這些只是一些難以（甚至不可能）集成到 OO 方法中的對象。 SAP 標准模塊的集成使這變得更加復雜。

用戶出口，事件：大部分數據在界面中提供。 對客戶特定數據或定制的訪問可以放在對象中。

報告：大部分數據將通過標准 FM 讀取。 具體的數據處理可以放在對象中。 可以在其他報告中輕松重復使用。 SAP enjoy 控件可以與 object shell 一起包裝，以便於使用和重用。 屏幕不能是對象中的位置。 :-(((

核心處理：SAP 不鼓勵更換 SAP 業務 object 維護或 SAP 流程。 但如果這是一個耐心的案例，並准備好付出巨大的努力。 讓我們仔細看看。 有很多技術挑戰：singleton 模式、數據庫訪問優化、鎖定、同步等。應該解決技術和業務功能的分離問題。 對象並不真正適合大規模處理（高 DB 負載），因此應該解決大規模處理。

Answer 6

簡單來說，當你有一個相對年輕的團隊渴望並准備好學習新的編程范式時使用它。 在高層主導的團隊中，采用 OO 可能具有挑戰性。 更是如此，因為程序的可維護性下降了。 組織可能需要新員工來維護 OO 代碼。

從設計的角度來看，毫無疑問（正如很多人在這個論壇上所說的那樣）它是最好的並且自古以來就一直在使用。 SAP 在技術方面遠遠落后。 他們的 ECC DB 設計仍然是 2-NF。 標准的 3-NF 就是他們所說的“3D”數據庫。 沒有偏離主題太多，我相信你現在有太多好的答案來做出決定。

Answer 7

以下是您必須知道的 OOP 的一些優點：

• 數據封裝
• 實例化
• 代碼重用
• 接口

利用這些優勢，“盡可能”使用 OO ABAP 有很多重要原因。 即使您不想使用 OO 編程，使用 ABAP 對象仍然是一個好主意，因為它提供了一些過程編程沒有的功能。

因此，ABAP 對象通過程序 ABAP 為您提供了以下功能：

• 更好的封裝
• 支持多個實例化
• 更好的代碼重用技術
• 更好的界面
• 明確的事件概念

程序 ABAP 只有兩個目的是必不可少的：

• function模塊中經典屏的封裝。
• 當您想讓功能對其他系統可用，但無法使用 XI 服務器代理使 class 方法在外部可用時。 在這種情況下，您必須使用 function 模塊。

在這里詳細研究它們，您會發現您不需要任何重要的操作/演示理由來說服自己遷移到 OO ABAP，因為所有這些理由已經非常重要。