Ansicht
Dokumentation

ABENINHERITANCE_VISIBILITY - INHERITANCE VISIBILITY

TXBHW - Original Tax Base Amount in Local Currency   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

- Vererbung und Sichtbarkeit

Die Zuordnung einer Komponente zum Sichtbarkeitsbereich einer Klasse kann durch Vererbung nicht geändert werden. Die Sichtbarkeit von Komponenten hat in der Vererbung folgende Konsequenzen:

Öffentliche Komponenten

Der öffentliche Sichtbarkeitsbereich einer Unterklasse besteht aus allen eigenen öffentlichen Komponenten zuzüglich der öffentlichen Komponenten aller Oberklassen. Von außen sind öffentliche Komponenten uneingeschränkt sichtbar.

Geschützte Komponenten

Der geschützte Sichtbarkeitsbereich einer Unterklasse besteht aus allen eigenen geschützten Komponenten zuzüglich der geschützten Komponenten aller Oberklassen. Der geschützte Bereich ist nur in der Klasse selbst und in allen ihren Unterklassen sichtbar. Geschützt wirkt von außen gesehen wie privat.

Private Komponenten

Der private Sichtbarkeitsbereich einer Unterklasse umfasst nur die privaten Komponenten dieser Klasse. Diese sind nur in dieser Klasse sichtbar. Die privaten Komponenten von Oberklassen können nicht in Unterklassen verwendet werden. Nur von Oberklassen geerbte Methoden verwenden, so lange sie nicht redefiniert wurden, weiterhin die privaten Attribute der Oberklasse, selbst wenn die Unterklasse private Attribute mit gleichem Namen hat.

Beispiel für geschützte Komponenten

Man kann innerhalb eines Asts des Vererbungsbaums in Unterklassen immer geschützten Komponenten von Oberklassen zugreifen. Die beteiligten Klassen, z.B. die statischen Typen der Referenzvariablen, müssen aber Teil des Vererbungsbaums sein.

In folgendem Beispiel bedeutet das: Die Referenzvariablen lrefx und lref2 kennen im Kontext der Unterklasse c2 die geschützten Komponenten von cx. Der statische Typ lref1 ist c1 und liegt in einem anderen Ast des Vererbungsbaums. Er kennt im Kontext von c2 keine geschützten Komponenten von cx. In einem strengeren Modell (C++ und Java) wäre in obigem Beispiel sogar nur der Zugriff über lref2 möglich und der Zugriff über lrefx würde eine Außensicht bedeuten und wäre verboten. ABAP erweitert die Sicht von lrefx zurzeit noch kontextabhängig. Es ist aber vorgesehen auch hier die strengere Sicht einzuführen und den Zugriff über lrefx zu verbieten. Deshalb sollte diese Option nicht verwendet werden und wird von der erweiterten Programmprüfung angemahnt .

CLASS cx DEFINITION.
  PROTECTED SECTION.
    METHODS mx.
ENDCLASS.

CLASS cx IMPLEMENTATION.
  METHOD mx.
    ...
  ENDMETHOD.
ENDCLASS.

CLASS c1 DEFINITION INHERITING FROM cx.
  ...
ENDCLASS.

CLASS c2 DEFINITION INHERITING FROM cx.
  PUBLIC SECTION.
    METHODS m2.
ENDCLASS.

CLASS c2 IMPLEMENTATION.
  METHOD m2.
    DATA: lrefx TYPE REF TO cx,
          lref2 TYPE REF TO c2,
          lref1 TYPE REF TO c1.
    lrefx->mx( ). --- Warning!!
    lref2->mx( ).
    lref1->mx( ). --- Error!!
  ENDMETHOD.
ENDCLASS.

General Data in Customer Master   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 4021 Date: 20240523 Time: 155836     sap01-206 ( 73 ms )