私の会社が 4.6c から ECC6.0 にアップグレードしてから数か月が経過しましたが、プログラマーのチームは依然として従来の 4.7c の方法でコーディングしています。私は ABAP の新しい OO アプローチを試してみたいと思っていますが、残念なことに、ここにいるほとんどの人は与えられた最短の時間枠で物事を成し遂げることだけを強調しています。
私の質問は次のとおりです
。1) 組織内の人々が実際に OO ABAP でコーディングを開始したのはいつですか?
2) オブジェクト指向の方法でコーディングしたいと思う重大な理由はありますか? たとえば、Call Method は PERFORM ステートメントよりも高速ですか?
1) 組織内の人々が実際に OO ABAP でコーディングを開始したのはいつですか?
私の組織のほとんどの開発者は、ABAP OO を導入する前に従来の ABAP を習得しています。彼らのほとんどは、適切な OOP および OOD の原則を学ぶことを控えている上級開発者です。彼らはまだほとんど手続き型のABAP機能を使用しています。さらに、私たちはレガシー環境で働いています。私たちのバックエンドの基本は、4.6C の時代に構築されました。適切な OO 設計をレガシー システムに導入するのは困難です。
一方、プロシージャル機能は引き続き機能します。トランザクション データベースの更新などの一部の機能は、主に ABAP の手続き部分から使用されます。データベース トランザクション専用の Update Function Modules または Subroutines (呼び出し可能なもの) をご存知かもしれません IN UPDATE TASK。これらは、ABAP 基本コンポーネントの不可欠な部分です。手続き型の ABAP 部分がまだ必要であることは否定できません。
2) オブジェクト指向の方法でコーディングしたいと思う重大な理由はありますか? たとえば、Call Method は PERFORM ステートメントよりも高速ですか?
CALL METHOD と PERFOM の実行時間をどのように比較しましたか? プログラム RSHOWTIM を試しましたか? または、ABAP ワークベンチからいくつかのパフォーマンス テストを行いましたか? 単一のサブルーチン呼び出しは、メソッド呼び出しと大きく異なりません。ただし、大量のテストメソッド呼び出しで呼び出された場合、パフォーマンスがわずかに向上します (マイクロ秒単位で)。
全体として、以前に投稿したユーザーと同じ議論で、OOD と OOP をお勧めします。ただし、古い ABAP の世界に精通している上級開発者は、ABAP OO を書き始める前に OO の原則を理解する必要があることを覚えておく必要があります。そうでなければ、逆に、組織は ABAP OO によって利益を得ることはできません。オブジェクト指向の知識がない経験豊富な ABAP 開発者が、クラスを作成するように強いられています。彼らが実際に行っているのは、手続きの原則をクラスで模倣することです (たとえば、関数モジュール/サブルーチンの代わりとして、静的メソッドのみを持つクラスなど)。
ABAP OO に挑戦する組織の幸運を祈ります! 言語の問題ではなく、オブジェクト指向の原則をスタッフの心に植え付けることが重要です。
○○か○○かは問題じゃない!!
問題は、どこが OO でどこが NOT OO かです。
OO アプローチ (OOD および OOP) のすべての利点は、顧客の名前空間にいる限り、十分に活用できます。ただし、SAP の標準機能にアクセスするたびに、大きな頭痛の種になります。トランザクションの整合性、オブジェクトの一貫性と同期、DB コミット、画面 (モジュール プールと選択画面)、権限チェック、バッチ入力。これらは、OO アプローチに統合するのが難しい (または不可能でさえある) オブジェクトのほんの一部です。SAP 標準モジュールの統合により、これはさらに複雑になります。
ユーザー出口、イベント: ほとんどのデータはインターフェイスで提供されます。顧客固有のデータへのアクセスまたはカスタマイズをオブジェクトに配置できます。
レポート: ほとんどのデータは標準 FM によって読み取られます。特定のデータ処理をオブジェクトに配置できます。他のレポートで簡単に再利用できます。SAP エンジョイ コントロールは、オブジェクト シェルでラップして、簡単に使用および再利用できます。スクリーンは、オブジェクト内の場所にすることはできません。:-((((
コア処理: SAP ビジネス オブジェクトのメンテナンスまたは SAP プロセスの置き換えは、SAP によって推奨されていません。しかし、これが患者のケースであり、多大な努力の準備ができている場合. よく見てみましょう。シングルトン パターン、DB アクセスの最適化、ロック、同期など、多くの技術的な課題があります。技術機能とビジネス機能の分離に対処する必要があります。オブジェクトは大量処理 (DB 負荷が高い) にはあまり適していないため、大量処理に対処する必要があります。
ABAP OO に切り替える正当な理由は次のとおりです。
Taureanによってリストされた利点にこれを追加します。
ABAP OO の使用開始:
CL_ABAP*またはCL_GUI_FRONTEND*クラスでいくつかの標準メソッドを呼び出してみてください資力：
ABAP については知りませんが、VB 開発者が .Net プラットフォームに移行する際に同じことが起こるのを見てきました。
プログラマーは古いプログラミング方法に満足しており、古い方法は今でも機能しています。プログラミングの新しい方法は、会社からだけでなく、快適な領域から不確実な領域に移動しなければならない人々からも多くの投資を必要とします。あなたの会社がトレーニングや研究の時間に投資することを望まない場合、この問題はさらに大きくなります。
Taurean が既に示したように、オブジェクト指向のやり方に移行する説得力のある理由があります。それらは主にパフォーマンスに関するものではなく、システム内のコンポーネントをより適切に分離して、システムをより保守しやすくすることに関するものです。
しかし、私の経験では、そのような合理的な議論を使用して、人々を快適ゾーンから出させるのは難しい. 通常は、道を示す方が効果的です。自分のコードで OO 構造をゆっくりと使い始めて、それがいかにきれいに見えるかを人々に示してください。これは、数か月で達成できるものではありません。人々が異なる考え方や働き方をするようになるには、何年もかかる場合があります。
経験豊富な手続き型開発者のチームがすぐにオブジェクト指向スタイルでの開発を開始する可能性は低いです。
これには多くの理由があります。
結果として、新しいコードはおそらく手続き型になりますが、クラスとメソッドになります。彼らは OO の利点に感銘を受けることはありません。
以下は、知っておく必要がある OOP の利点の一部です。
これらを利用して、「可能な限り」OO ABAP を使用する重要な理由が数多くあります。OO プログラミングを使用したくない場合でも、ABAP オブジェクトを使用することをお勧めします。手続き型プログラミングでは提供されない機能がいくつかあるためです。
手続き型 ABAP よりも ABAP オブジェクトが提供するものは次のとおりです。
手続き型 ABAP が不可欠であると考えられる目的は 2 つだけです。
ここでそれらについて詳しく調べると、OO ABAP に移行することを自分自身に納得させるために重要な運用上または実証上の理由は必要ないことがわかります。これらの理由はすべて、すでに非常に重要です。
簡単に言うと、新しいプログラミング パラダイムを熱心に学習する準備ができている比較的若いチームがいる場合に使用します。上級管理職のチームでは、OO の採用は困難な場合があります。プログラムの保守性が低下するため、なおさらです。組織は、OO コードを維持するために新しい従業員を必要とする場合があります。
デザインの観点からは、(このフォーラムでも多くの人が言っているように) これが最高であり、長年にわたって使用されてきたことに疑いの余地はありません。SAP はテクノロジーの面で遅れをとっています。彼らの ECC DB 設計はまだ 2-NF です。標準の 3-NF は、彼らが「3D」データベースと呼んでいるものです。主なトピックから大きく逸脱することはありません。決定に至るには、適切な回答が多すぎると思います。