Rather than having your report start somewhere, run through a series of routines to end somewhere else, the Object Oriented paradigm evolves around objects. An object is a real-world like "thing" that is being "processed". A car. A purchase order that is ready to be released. An invoice that needs to be checked. An object is an instance of a class. This article should clarify what this means.
A class describes attributes (variables) and methods (routines) which actually define what the class is and what can be done with (to) it. Attributes are defined as DATA, but they can also be defines as CLASS-DATA. The same can be applied to methods, defined as METHODS or CLASS-METHODS. A method that is defined under METHODS can only be called after instantiating the class. When the class is e.g. about an invoice, the invoice has a key (document number) and the report will need to create the object for the invoice. With the CREATE OBJECT statement, the CONSTRUCTOR of the invoice class is called which will most likely require the document number. Instantiating the class = creating an instance of the class. Such instance is called an object.
Objects are instances of a class. A report selects several invoices, and for each invoice an instance of the invoice class is created. So is every class also an object? Not exactly: a class describes attributes and methods, however these attributes could be for an instance of the class OR globally defined for the whole class (including all instances). A list of invoices is typically defined on the invoice class as a CLASS-DATA attribute, which is available as a global variabele (LCL_INVOICE=>TA_INVOICES). So how does this help organize coding: try it out: everything related to invoices is defined in the same class. It carries the full invoice functionality and data definitions. And that's only the tip of the iceberg.