Understanding the difference between classes and objects in ABAP is one of the most important and most confusing steps for developers moving into ABAP Objects.
If you come from procedural ABAP or from fully object-oriented languages like Java, it’s easy to mix up what a class actually is versus what an object represents at runtime.
In simple terms, a class defines what an object can be, while an object is a specific instance created from that class. However, in ABAP’s hybrid programming model, this relationship isn’t always explained clearly, especially when compared to familiar concepts like structures and internal tables.
This post breaks down classes vs. objects in ABAP in practical terms. You’ll learn what objects really represent, how classes define object behavior and structure, how ABAP classes compare to other abstract data types, and why methods form the public interface of an object. By the end, you’ll have a clear mental model of how ABAP Objects work at both design time and runtime.
From a technical perspective, an object is a special kind of variable that has distinct characteristics and behaviors. The characteristics (or attributes) of an object are used to describe the state of an object. For example, a Car object might have attributes to capture information such as the color of the car, its make and model, or even its current driving speed. Behaviors (or methods) represent the actions performed by an object. In our Car example, there might be methods that can be used to drive, turn, and stop the car, for instance.
With these two concepts in mind, our initial definition of an object would read something like this: “An object is a variable that combines data and behaviors together in a self-contained package.” However, if we were to stop there, our definition would be rather limiting. In his book, Design Patterns Explained: A New Perspective on Object-Oriented Design, Second Edition (Addison-Wesley, 2004), Alan Shalloway emphasizes that objects make it possible to “...package data and functionality together by concept, so you can represent an appropriate problem-space idea rather than being forced to use the idioms of the underlying machine.” This distinction, though subtle, is important in getting you where you really want to go with OOP: to create autonomous entities with defined roles and responsibilities that can think and act for themselves.
Now that you have a sense of what objects are, you might be wondering how objects are defined in the first place. Unlike other variable types that you might be accustomed to working with (e.g., integers or strings), this process requires a fair amount of thought. Since an object, by definition, can literally refer to anything (i.e., a person, place, thing, or idea), you first need to figure out the types of objects you need to model your problem domain. For example, if you’re building a financial accounting solution, you would probably need objects to represent items like accounts and ledgers.
Sometimes this analysis process is intuitive; other times, not so much. In these latter cases, you must collect your thoughts using an ordered and methodical process. A common approach for initiating this process is to go through requirements documents and underline all the nouns that are used to describe various aspects of the problem domain. Then, from there, you can further organize the objects by examining their roles and responsibilities as well as their relationships to other objects. Early OOP researchers observed that the nature of this analysis process bore many similarities to the classification techniques used by biologists to identify, categorize, and understand the relationships between plants and animals. Consequently, the term class was used to describe (or classify) these abstract data types, and over the years the name has stuck.
In practical terms, you can think of a class as being rather like a specialized type declaration. This is to say that a class declaration defines the type of an object. This typing concept should feel intuitive for ABAP developers who are accustomed to working with structures and internal tables. For example, below you can see how we’ve defined a structure variable called LS_PERSON in terms of a custom type we’ve declared called TY_PERSON. This custom type declaration tells the ABAP compiler what the LS_PERSON structure will look like at runtime (i.e., what component fields the structure will have).
TYPES: BEGIN OF ty_person,
first_name TYPE string,
last_name TYPE string,
END OF ty_person.
DATA ls_person TYPE ty_person.
With class type declarations, you’re essentially trying to accomplish the same thing; The only difference is that you’re declaring a class of objects as opposed to a structure or internal table. For example, in the next listing you can see how we’ve defined a custom class type called LCL_PERSON. Notice the similarities between this class type declaration and the TY_PERSON type declaration from before. This is not by accident, since classes are, in many respects, just another form of ADTs.
CLASS lcl_person DEFINITION.
PRIVATE SECTION.
DATA mv_first_name TYPE string.
DATA mv_last_name TYPE string.
ENDCLASS.
DATA lo_person TYPE REF TO lcl_person.
When you look at class type declarations in this light, you can begin to appreciate the relationship between classes and objects. Conceptually speaking, it’s appropriate to think of classes like templates (or blueprints) that an OOP runtime environment can use to figure out how to create object instances at runtime. Therefore, the relationship between an object and a class is normally described as an object is an instance of a class in OOP lingo.
This relationship is illustrated from a runtime perspective in the figure below. Here, you can see how an arbitrary number of instances of the LCL_PERSON class are created (or instantiated) at runtime. Each created object instance is unique and independent in its own right (i.e., it has its own memory space). For example, notice how each object instance contains its own values for the FIRST_NAME and LAST_NAME attributes. If you were to change the FIRST_NAME attribute for the first object instance, the other object instances would not be affected because they’re independent entities. Indeed, the only thing that these objects really have in common at runtime is their shared definition class.
In the previous section, we highlighted some of the similarities between class types and other familiar ADTs such as structures or internal tables. While this analogy is useful in understanding how objects are defined conceptually, it starts to break down when you approach the specification of a class’s methods. Methods, which are conceptually like subroutines (forms in ABAP parlance) or functions in procedural programming, define the interaction points that make it possible to communicate with object instances at runtime. In more formal terms, methods make up a class’s interface.
To illustrate the idea of a class’s interface, consider the revised LCL_PERSON class type declaration.
CLASS lcl_person DEFINITION.
PUBLIC SECTION.
METHODS:
talk,
walk.
PRIVATE SECTION.
DATA mv_first_name TYPE string.
DATA mv_last_name TYPE string.
ENDCLASS.
CLASS lcl_person IMPLEMENTATION.
METHOD talk.
WRITE: / 'Hello'.
ENDMETHOD.
METHOD walk.
...
ENDMETHOD.
ENDCLASS.
With the addition of methods such as talk() and walk(), instances of the LCL_PERSON class suddenly take on quite a bit more personality. In effect, you can use these methods to (programmatically) tell your objects what to do. For example, you can tell a person instance to talk by calling the talk() method or to walk around by invoking the walk() method. Such behaviors transform objects from inanimate data structures to living, breathing entities that are self-aware and, to a certain extent, autonomous. Plus, with their attribute data in context, objects inherently know what they are, what their current state is, and what sort of operations they can perform.
The difference between classes and objects in ABAP becomes clear once you separate design-time definitions from runtime behavior. A class is a blueprint that defines an object’s structure and available actions, while an object is a concrete instance created from that blueprint during program execution.
In ABAP Objects, classes play a role similar to custom type declarations, but with one crucial enhancement: they define not only data, but also behavior through methods. Objects, in turn, encapsulate both state and functionality, allowing ABAP programs to model real-world entities as independent, self-contained units.
Once you understand that objects are instances of classes, and that methods form the interface through which objects interact with the rest of your program, object-oriented ABAP starts to feel far more intuitive. This mental model lays the foundation for advanced concepts like encapsulation, polymorphism, and clean, maintainable ABAP application design.
Editor’s note: This post has been adapted from sections of the books Object-Oriented Programming with ABAP Objects by Jeffrey Boggess, Colby Hemond, James Wood, and Joseph Rupert. Jeffrey is an enterprise integration specialist at Bowdark Consulting focused on building seamless integrations between SAP, Azure, and Dataverse to solve complex business challenges and provide dependable solutions for clients. Colby is a senior technical consultant at Bowdark Consulting, where he is dedicated to bringing innovative ideas and solutions to clients and supporting them in their digital transformation. James is the founder and CEO of Bowdark Consulting, Inc., a consulting firm specializing in technology and custom development in the SAP landscape. Joseph is a senior data architect at Bowdark Consulting, Inc. with expertise in migrating complex SAP landscapes to cloud platforms, enabling scalable, secure, and high-performance data ecosystems.
This post was originally published 1/2026.