Classes can lead a double life: they can hide in a report source as a local class, or they can sit out in the system's class repository as a global class. Difference ? Nothing internally. There is nothing that you can arrange in a global class that can not be arranged in a local class and the other way around. Local classes are written in abap coding with a DECLARATION and an IMPLEMENTATION section. Global classes are created with the class builder (transaction SE24). If you are writing a report to do a certain task, you can use the local class to profit from OO benefits, without having to worry about the world outside your report. When you are working on a class that may be of interest to other reports as well, consider setting it up as a global class.
You can also set up your class as global class, and create a local class in your report that has the global class as super class. With this setup you can choose where the method you are about to create should go. Do you expect it to be used by other reports ? Set it up on the global class. Is it specific to your report ? Make it part of the local class. Put a bit of thought into it, and move methods and attributes to their rightful location when it becomes apparent they are in the wrong spot. Add a bit of visibility (public, protected, private) and Abap software becomes upper class software.
A global class can itself also contain local classes, which live in a reserved space (include) on the class. This funtionality is only available in the class itself and can be used to support the main global class with whatever is needed.
If you play your cards right, the actual location the method (or attribute) is residing tells a tail on what it is for and how it can be used. And the other way around: when you are adding a method (or attribute) to the system, is should "feel at home" somewhere. Abap no longer needs to be a stack of routines, it can be a true guide to functionality or a guide to "reality".