私たちの SAP プログラマーのほとんどは、オブジェクト指向のものより前の古いバージョンの ABAP を使用しているようです。また、オブジェクト指向により、言語がよりクリーンでモダンになっていることにも気付きました (非推奨のものを取り除く機会を得たようです)。
システムはまだ展開されていないため、再設計を行うのは後ではなく今です。
新しいコードを OO ABAP プログラムとして作成するように要求する価値はありますか? それを経営陣に売り込むには？OO 以外のプログラムとのインターフェースはうまく機能しますか?
（特に来年に向けて計画されている、新しいコードについて具体的に話していることに注意して更新してください）
本番環境で動作している場合は、コードを書き直さないでください。時間とお金の価値がなく、(SAP を運用できるほど大きな会社の) 経営陣もそれに同意しないでしょう。
グリーン フィールド環境に移行しない限り、OO ですべてを書き直すことはできません。SAP は、コア ECC モジュールでさえそれを行っていません。カスタムのものでそれができると期待するのは非現実的です.
OO ABAP を読んで、それを使って新しいプログラムを書き始めます。
OO ABAP と手続き型 ABAP はうまく連携します。手続き型プログラムからクラスとメソッドを呼び出すことができ、(より制限されていますが) その逆も可能です。
私たちは顧客向けに多くの新しい新鮮な ABAP コードを開発しており、ABAP OO の使用はゆっくりではありますが、まだ成長しています。
学ぶことが少ないため、新しい開発者に ABAP OO を使用するよう説得するのは簡単です。また、OO ABAP を使用してコードを記述すると、設計パターンの正しい使用、非常に効果的な単体テスト、UI の抽象化 (SAPgui および WebDynpro または SAP コンソールなど) が可能になり、ドキュメントが大幅に削減されます。
また、前に何人かが言ったように、SAP はコードベースを ABAP OO に書き直していません。しかし、ME51からME51N、ME21からME21N、SO01からSBWPを書き換えてみた。
また、ABAP Unit、ABAP Proxy、新しい ALV、ABAP 用の WebDynpro、まったく新しい Enhancement and Switch Framework など、SAP のすべての新しい API は、なぜそれに注意を払うべきかを示す良い例です (私はそう思います)。
作成するプログラムのサイズによって異なります。データベースとのやり取りがあまりない大規模な「システム」である場合、いくつかの利点があるかもしれません。小規模なプログラムの場合、コードを「オブジェクト化」する利点は見当たりません。
また、開発者のスキルと好みにも依存します。彼らが「OO」したいのなら、もっと良い環境があるかもしれません。「古い手続き型」の考え方にとらわれている場合は、オブジェクト指向に切り替える以外にコードを改善する方法があるかもしれません。
私がよく目にする 1 つの例は、「データベースは何をすべきか」(結合、ソート、グループ化など) と「コードで何をすべきか」という議論です。
SAP SDN で言及されている Esti のホワイト ペーパーのコピーを見つけました:まだ ABAP オブジェクトを使用していませんか? すべての ABAP 開発者が見直す必要がある 8 つの理由
このホワイト ペーパーでは、ABAP OO を使用する利点について簡単に説明します。
古い古典的なレポートには、多くの場合、冗長なコーディングが含まれています。さまざまなレポートが、多くの「コピー アンド ペースト」で作成されています。冗長なものを見つけ出し、これらのレポートから段階的に引き出して、適切に設計されたグローバルで再利用可能な新しいクラスにし、既存のコードを中央定義への「呼び出しメソッド」に置き換えることで、古いレポートをより厳密にします。十分にテストされた OO ロジック。
ホワイト ペーパーのコピーを見つけてみてください。
ABAP オブジェクトをまだ使用していませんか? Horst Keller と Gerd Klugerに よる、すべての ABAP 開発者が見直す必要がある 8 つの理由。
SAP OO の最大の利点のいくつかは、特に新しい SAP 開発者にとって、手続き型の ABAP よりもはるかに明示的になる必要があることです。これにより、記述されたコードがより保守しやすくなり、より主流のバックグラウンドを持つプログラマーにとってより親しみやすく感じるかもしれません。