Как да споделяме местни класове?

Ето пример за това как можете да получите достъп до локален клас, дефиниран в отчет.

Докладът с класа.

REPORT ZZZ_PJ1.

CLASS lcl_test DEFINITION FINAL.
  PUBLIC SECTION.
    METHODS:
      test.
ENDCLASS.

CLASS lcl_test IMPLEMENTATION.
  METHOD test.
    WRITE 'test'.
  ENDMETHOD.
ENDCLASS.

Докладът, който използва класа.

REPORT ZZZ_PJ2.

CLASS lcl_main DEFINITION FINAL CREATE PRIVATE.
  PUBLIC SECTION.
    CLASS-METHODS:
      main.
ENDCLASS.

CLASS lcl_main IMPLEMENTATION.
  METHOD main.
    DATA:
      lr_object TYPE REF TO object.

    CREATE OBJECT lr_object
      TYPE ('\PROGRAM=ZZZ_PJ1\CLASS=LCL_TEST')

    CALL METHOD lr_object->('TEST').
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.
  lcl_main=>main( ).

Разбира се, това не е умно решение, тъй като всяко извикване на метод трябва да бъде динамично извикване.

CALL METHOD lr_object->('TEST').

Това обаче може да бъде решено чрез използване на глобални интерфейси, които биха дефинирали методите на вашите класове (разбира се, ако не са статични, което предполагам, че не са). След това трябва да контролирате всеки от екземплярите чрез интерфейса. Вашата цел ще бъде изпълнена тогава, тъй като само интерфейсът ще бъде изложен глобално, реализациите ще останат в локални класове.

Може да искате да прочетете малко модели за проектиране на модел-изглед-контролер. Показване на данни в потребителски интерфейс - би било "изглед". Както събирането, така и актуализирането на данни ще бъдат включени в „Модел“. Бизнес логиката вероятно трябва да бъде внедрена като взаимодействие между изгледа и модела в „Контролер“.

Въпреки това, един подход към това е да се използва функцията за приятелство, предлагана в ABAP OO.

Като пример: създайте модела и прегледайте класовете глобално, но им позволете само да бъдат инстанцирани частно, след което дайте достъп на частен компонент до контролера. Дефинициите на класовете ще бъдат следните:

CLASS zcl_example_view DEFINITION
  PUBLIC
  FINAL
  CREATE PRIVATE
  GLOBAL FRIENDS zcl_example_controller


CLASS zcl_example_model DEFINITION
  PUBLIC
  FINAL
  CREATE PRIVATE
  GLOBAL FRIENDS zcl_example_controller


CLASS zcl_example_controller DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC

Освен това може да е добра идея да направите контролера сингълтън и да съхранявате препратка към него както в изгледа, така и в модела. Като налагаме, че контролерът IS BOUND, когато изгледът и моделът са инстанцирани, можем ефективно да гарантираме, че тези три класа съществуват както желаете само вие.

Връщайки се към първоначалния ви проблем: Звучи ми така, сякаш вече използвате нещо като MVC модел във вашата разработка, така че единственият ви проблем е, че някои процедури трябва да се използват публично и от двата модела, изгледи и контролери.

В този случай силно препоръчвам да поставите тези рутинни процедури в глобални налични класове или да приложите getter методи във вашите вече съществуващи класове за достъп до тези функции.

Всякакви хакове като \PROGRAM=ZZZ_PJ1\CLASS=LCL_TEST понякога са от съществено значение, но не и тук imho.

Ако вашето приложение е толкова голямо, колкото го представяте, трябва да го организирате с помощта на множество пакети. Със сигурност ще трябва да се справите с неща, които не са OO, като функционални модули, обекти от речник на данни и други неща, които не могат да бъдат част от клас, така че използването на класове като основно средство за организиране на вашето приложение няма да работи извън много малки и специализирани приложения.

Освен това, изглежда, че имате някои наистина сериозни недостатъци, вградени в плана ви, ако смятате, че „логиката за достъп до DB“ е нещо, което трябва да бъде „споделено между класове“. Трудно е да се отгатне без допълнителна информация, но силно бих препоръчал да привлечете някой, който има опит в проектирането и внедряването на приложения от такъв мащаб - поне за да разберете правилно основната концепция.