ABAP Objects: классы, интерфейсы и границы ответственности
Как в ABAP Objects разделять состояние и поведение, задавать публичный контракт интерфейсом и применять наследование без глубокой иерархии.
2 мин чтения·База знаний
Ревизия 1Общие понятияЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
ABAP Objects объединяет данные и операции над ними в классах. Выбор класса сам по себе не делает модель понятной: важнее решить, кому принадлежит состояние, какие операции доступны снаружи и каким способом вызывающий код зависит от реализации.
Объект - экземпляр класса со своим состоянием. Методы задают операции над этим состоянием. Разделы PUBLIC, PROTECTED и PRIVATE ограничивают видимость компонентов. Для устойчивого контракта публичные данные не должны позволять вызывающему коду обходить проверки, которые обеспечивают согласованность объекта.
В финансовом сценарии объект расчёта может принимать уже проверенные параметры и возвращать результат с описанными точностью и валютой. Он не должен скрыто загружать произвольные строки, менять продуктивные проводки или подменять правила конфигурации SAP. Источник данных, расчёт и запись результата имеют разные побочные эффекты и должны оставаться видимыми в проектировании.
Интерфейс задаёт общий набор операций. Класс реализует этот набор, а вызывающая сторона может работать через ссылку на интерфейс. Разные классы способны реализовать один контракт по-разному; это основа полиморфного вызова. Интерфейсы описывают ожидаемое поведение, но сами не задают внутреннюю реализацию.
Применяйте интерфейс, когда потребителю важна способность выполнить операцию, а не конкретный класс. Например, компонент сверки может зависеть от контракта чтения строк, не зная, пришли они из локальной фикстуры или из адаптера. Пример объясняет границу зависимости и не утверждает, что здесь реализован SAP-коннектор.
ABAP Objects поддерживает простое наследование: у класса один непосредственный суперкласс, а у интерфейса нет реализации методов. Наследование подходит, когда подкласс действительно является более специализированной разновидностью базового типа и сохраняет его контракт.
Официальная рекомендация SAP предостерегает от глубоких иерархий: поведение нижнего класса становится сложнее предсказать, а изменение базового класса затрагивает больше потребителей. Если нужна общая точка вызова нескольких реализаций, сначала проверьте, достаточно ли интерфейса. Ограничивайте наследование явно, когда дополнительные подклассы не входят в замысел типа.
Какие входы уже валидированы и кто это гарантирует?
Какие операции изменяют состояние или обращаются к внешней системе?
Что вызывающий код может ожидать при ошибке и какие исключения распространяются дальше?
Как тест заменит внешнюю зависимость и проверит результат?
В SAP-системе синтаксис, доступные API, ограничения ABAP Cloud и правила расширения зависят от версии и модели разработки. Проверяйте целевую среду отдельно. Эта статья основана на документации; классы не компилировались и не запускались в SAP runtime.
ABAP Objects unifies data and operations on that data in classes. Choosing a class alone does not make a model clear: first decide who owns state, which operations are public, and how callers depend on an implementation.
An object is an instance of a class with its own state. Methods define operations on that state. PUBLIC, PROTECTED, and PRIVATE sections restrict component visibility. For a stable contract, public data should not let callers bypass checks that keep the object consistent.
In a financial scenario, a calculation object may accept validated parameters and return a result with defined precision and currency. It should not silently load arbitrary rows, change productive postings, or substitute for SAP configuration rules. Data access, calculation, and writing a result have different side effects and should remain visible in the design.
An interface separates contract from implementation#
An interface defines a common set of operations. A class implements that set, and callers can work through an interface reference. Different classes can implement the same contract differently; this enables polymorphic calls. Interfaces describe expected behavior but do not provide the internal implementation.
Use an interface when a consumer needs a capability rather than a specific class. For example, a reconciliation component could depend on a row-reading contract without knowing whether rows came from a local fixture or an adapter. This explains a dependency boundary; it does not claim that an SAP connector is implemented here.
ABAP Objects supports single inheritance: a class has one direct superclass, while an interface does not implement methods. Inheritance fits when a subclass is truly a more specialized kind of the base type and preserves its contract.
SAP's official guidance cautions against deep hierarchies: behavior further down the hierarchy becomes harder to predict, and a base-class change affects more consumers. If several implementations need a common call point, first check whether an interface is sufficient. Restrict inheritance explicitly when more subclasses are outside the type's design.
Which inputs are already validated and who guarantees that?
Which operations change state or call an external system?
What can callers expect on failure, and which exceptions propagate?
How will a test replace an external dependency and check the result?
In an SAP system, syntax, available APIs, ABAP Cloud restrictions, and extension rules depend on the release and development model. Check the target environment. This article is based on documentation; the classes were not compiled or run in an SAP runtime.