1.はじめに

ABAP CLASSに限らず、「クラス」を学ぼうとしたときに最初にぶつかる壁がオブジェクト指向という考え方ではないでしょうか。
調べてみると「クラスは設計図」「機能の集合体」といった説明がよく見つかりますが、ABAP初学者にとっては「それって結局どういうこと？」と❓が浮かぶはずです。
※私がそうでした

本記事では、単なる定義やお作法の紹介ではなく、「クラスとはそもそも何なのか」をできるだけかみ砕いて解説します。
特に SAP の文脈に沿って、

　•　なぜABAPでクラスを使うのか
　•　手続き型と何が違うのか
　•　クラスの本質は「機能の集合体」ではなく「現実をモデル化する仕組み」である

以上を整理していきます。

2.クラスは「世界を抽象化したもの」

「クラスは設計図」これはオブジェクト指向を学ぶときによく聞く説明です。
もちろん間違いではないのですが、初めて学ぶときには少しイメージがつかみにくいことがあります。

私自身がしっくりきたのは、もう少し違う捉え方でした。
それは「クラスとは、この世界にあるモノや概念を、必要な部分だけ切り取ってプログラムに書き起こしたもの」という考え方です。

3.抽象化ってどういうこと？

「抽象化」と聞くと難しく感じるかもしれませんが、実はとてもシンプルな考え方です。

たとえば「車」というモノを思い浮かべてみましょう。
現実の車には、ボディの形、シートの素材、タイヤの種類、エンジンの仕組み、さらにはオーディオやカーナビまで、数え切れないほどの要素があります。

しかし、もしプログラムの中で「車」を扱いたいときに、それらすべてを表現する必要はありません。
たとえば「色」「速度」「燃料残量」といった、プログラム上で本当に必要な情報だけを切り出して表します。

さらに、「走る」「止まる」「曲がる」といった基本的な動きだけを定義しておけば、プログラム上で車を扱うには十分です。

このように膨大な情報の中から必要な部分だけを抜き出し、シンプルに整理することが「抽象化」です。
そしてクラスは、この抽象化をプログラムの中で実現するための仕組みなのです。

4.「モノ」を生成する

ここまでで「クラスは抽象化によって必要な情報だけをまとめたもの」というイメージができてきました。
では、そのクラスを実際にどう使うのでしょうか？

答えは「インスタンスを生成する」ことです。

設計図から実物へ

クラスはあくまで「設計図」です。設計図そのものは飾っておけても、動くことはありません。
車の設計図があっても、それを見て乗ることはできないのと同じです。

そこで設計図（クラス）をもとに、実際に「モノ」を作り出します。
このモノこそがインスタンス（オブジェクト）です。

　•　クラス（設計図） → 車の作り方を定義しただけ
　•　インスタンス（実物） → 実際に作られた一台の車

複数のインスタンスを作れる

同じクラスからは、何台でも車を作ることができます。

　•　1台目: 赤いスポーツカー、速度 120km/h
　•　2台目: 青いファミリーカー、速度 80km/h
　•　3台目: 黒いSUV、速度 100km/h

これらはすべて「車クラス」から生まれていますが、それぞれ独立した存在です。
つまり「同じ設計図から、異なる性質を持った実物をいくつも作れる」ことが、クラスとインスタンスの大きなポイントです。

5.SAPの例で考えてみる

さて、ここからはSAPの世界で考えてみましょう。
実際の「購買発注伝票」には、伝票番号や仕入先、品目、数量、金額など、さまざまな情報が含まれています。
もしこの「購買発注」という概念をプログラムで表現するとしたら、必要な要素を整理して、こんな情報を持たせることになるでしょう。

　•　仕入先
　•　品目
　•　数量、金額
　•　発注日、納期

さらに動き（メソッド）としては、
　•　承認する
　•　削除する

といった流れを定義してみます。
ここまでが「購買発注クラス＝設計図」です。

しかし、設計図だけではシステムに伝票は存在しません。
実際に伝票を扱えるようにするには、この設計図をもとにインスタンス（実物の伝票）を作り出す必要があります。

たとえば、同じ購買発注クラスから次のようなインスタンスを生成できます。

　•　伝票①：仕入先Aから品目Xを100個、納期は来月末
　•　伝票②：仕入先Bから品目Yを50個、納期は今週中

どちらも同じ「購買発注クラス」から作られていますが、それぞれ独立した伝票として扱われます。
そして、クラスには「承認」「削除」といった動き（メソッド）を定義していました。
ここで重要なのは、メソッドはオブジェクトごとに働くということです。

　•　伝票①に対して「承認」を実行すれば、その伝票だけが承認済みになります。
　•　伝票②は何もしていなければ、依然として「未承認」のままです。

つまり、「承認」や「削除」といった動きは設計図（クラス）に共通で書かれていますが、実際に実行された結果はインスタンスごとに独立して反映されるのです。
※インスタンスに依存しないメソッドもありますが、ここでは割愛。

この仕組みのおかげで、同じクラスから作られたオブジェクトであっても、伝票①と伝票②は別々の状態を持ち、それぞれ独立して業務を進められるようになります。
このように、クラスは購買発注共通の設計図、インスタンスはそれぞれの伝票と考えると、オブジェクト指向のイメージが一気に具体的になります。

手続き型との違い

従来、SE38で書かれていた ABAPプログラムは「手続き型プログラミング」と呼ばれる手法で実装されていました。
「手続き型プログラミング」とは、その名のとおり処理を「手順（手続き）」として順番に書き並べていく考え方です。

　•　まずAをする
　•　次にBをする
　•　そのあとCをする

といったように、上から順に命令を実行していくスタイルです。

この方法はシンプルで理解しやすく、小規模な処理を書くにはとても向いています。
しかし、複雑な処理を扱うようになると、データと処理がバラバラに存在するために保守が難しくなるという課題が出てきます。
仕様変更の際、プログラムのどこを修正すればいいんだ！となったことは誰でもあるのではないでしょうか？

この課題を解決するのがオブジェクト指向プログラミングです。
先ほどの「購買発注クラス」を例に考えてみましょう。

もし仕様追加で「購買発注に承認拒否という動きを追加したい」となった場合、

　•　手続き型では、新しいサブルーチンや関数を追加し、既存の処理フローに組み込む必要があります。処理が増えるたびにプログラム全体の流れを追い直さなければならず、既存コードへの影響範囲も見えにくくなります。

　•　オブジェクト指向では、「購買発注クラス」に「承認拒否」という新しいメソッドを追加すればOKです。すでに「承認」「削除」といった動きをクラスの中にまとめているため、購買発注に関する処理はこのクラスを見ればすべて把握できる状態になっています。

こうすることで、業務の対象（購買発注）と、それにまつわる動き（承認、削除、承認拒否…）が一箇所に整理され、拡張や保守が格段にやりやすくなるのです。

6.まとめ

本記事では「クラスとはそもそも何なのか？」を、車やSAPの購買発注を例にしながら解説しました。
ABAPの世界でも、RAPやFioriアプリ開発など「クラスベース」で考える場面がどんどん増えています。
ぜひ今回の内容を足がかりに、実際のABAPクラス定義やインスタンス生成のコードに触れてみてください。
「設計図」と「実物」の関係を意識すれば、クラスの理解がぐっと深まるはずです。
今回は概念編でしたが、次は実際のソースコードを紹介しながら書き方や詳細な定義について記事にできたらと思っています。