Differenza tra “rigorosa privato” e “protette” Modificatori di Accesso in Delphi?

ma ho imparato a programmare e dopo strutturato di programmazione con linguaggio Pascal, sto cominciando a conoscere OOP con Delphi.

Così, io non capisco la differenza tra il strict private istruzione e la protected .. Quindi ecco il mio codice, si tratta di un “sacchetto” di creazione, è solo l’introduzione di mio Delphi lezione, l’insegnante ci mostrano come siamo in grado di creare oggetti:

    uses
  SysUtils;

Type

  Tbag= class (Tobject)                                                          
    strict private                                                                
      FcontenM : single;
      Fcontent : single;
    protected
      function getisempty : boolean;
      function getisfull: boolean;
    public
      constructor creer (nbliters : single);
      procedure add     (nbliters : single);
      procedure clear   (nbliters : single);
      property contenM : single read FcontenM;
      property content : single read Fcontent;
      property isempty : boolean read getisempty;
      property isfull : boolean read getisfull;
    end;


function Tseau.getisempty;
  begin
    result := Fcontent = 0;
  end;

function Tseau.getisfull;
  begin
    result := Fcontent = FcontenM;
  end;

constructor Tseau.creer(nbliters: Single);
  begin
    inherited create;
    FcontenM := nbliters;
  end;

procedure Tbag.add (nbliters: Single);
  begin
    if ((FcontenM - Fcontent) < nbliters) then fcontent := fcontenM
      else Fcontent := (Fcontent + nbliters);
  end;

procedure Tbag.clear (nbliters: Single);
  begin
    if (Fcontent > nbliters) then Fcontent := (Fcontent - nbliters)
      else Fcontent := 0;
  end;

Quindi è solo un esempio di creazione di un oggetto; capisco che cosa è una dichiarazione pubblica (interfaccia accessibile dall’esterno) ma non vedo qual è la differenza tra privato e protetto dichiarazioni.. Grazie per aver cercato di aiutarmi..

InformationsquelleAutor bAN | 2009-10-04

 

5 Replies
  1. 32

    La differenza tra privato, protetto e pubblico è piuttosto semplice:

    • Soci privati/metodi sono visibili solo all’interno della classe che dichiara di loro.
    • Membri protetti/metodi sono visibili all’interno della classe, e a tutte le sottoclassi.
    • Membri pubblici e metodi sono visibili a tutte le altre classi.

    In Delphi c’è un “bug” che rende la visibilità di tutti i soci pubblici all’interno della stessa unità. Il rigorosa parola chiave per correggere questo comportamento, in modo che il privato è in realtà private, anche all’interno di una singola unità. Per buona incapsulamento mi sento di raccomandare di utilizzare sempre la rigorosa parola chiave.

    Codice di esempio:

    type
      TFather = class
      private
        FPriv : integer;
      strict private
        FStrPriv : integer;
      protected
        FProt : integer;
      strict protected
        FStrProt : integer;
      public
        FPublic : integer;
      end;
    
      TSon = class(TFather)
      public
        procedure DoStuff;
      end;
    
      TUnrelated = class
      public
        procedure DoStuff;
      end;
    
    procedure TSon.DoStuff;
    begin
      FProt := 10;       // Legal, as it should be. Accessible to descendants.
      FPriv := 100;      // Legal, even though private. This won't work from another unit!
      FStrictPriv := 10; // <- Compiler Error, FStrictPrivFather is private to TFather
      FPublic := 100;    // Legal, naturally. Public members are accessible from everywhere.
    end;
    
    procedure TUnrelated.DoStuff;
    var
      F : TFather;
    begin
      F := TFather.Create;
      try
        F.FProt := 10;     // Legal, but it shouldn't be!
        F.FStrProt := 100; // <- Compiler error, the strict keyword has "made the protection work"
        F.FPublic := 100;  // Legal, naturally.
      finally
        F.Free;
      end;
    end;
    • Non è un bug, è il comportamento previsto e la VCL utilizza un bel po’.
    • Ecco perché ho scritto “bug” 🙂 e ‘ il modo in Delphi funziona, ma non è standard OOP.
    • Così oms ha definito la cosa “standard OOP” è? Non sapevo che c’era qualche OOP standards board. OOP limita a definire un paradigma centrato intorno incapsulamento, ereditarietà e polimorfismo. C’è uno stretto (pun intended) regola su come modificatori di accesso devono essere attuate. Per chiarire meglio, le regole di accesso implementare implicita “amicizia” al livello di unità, senza aggiunta di sintassi esplicita di farlo.
    • OK, io trovo corretto. E ‘ lecito dire che Delphi comportamento non conforme al “mio” OOP standard? 😉 A parte gli scherzi, ritengo che dare significati diversi per i modificatori di accesso basato su quello file una classe è definita è una brutta cosa. Meglio quindi utilizzare una sorta di amico dichiarazione (come hai detto).
    • IMHO la cura con la introduzione di ulteriori “stretto” livelli di visibilità è stato di peggio (localizzata in una sola unità) problema. Io non uso mai rigoroso, perché IMHO la probabilità è più grande che mi darà la portabilità del mal di testa (per le versioni precedenti) di quello che è davvero la volontà di evitare i bug etc.
    • rigorosa è necessaria a causa del .NETTO di compatibilità. Ma questo ha i suoi vantaggi.
    • Ciò che non è standard C++. La maggior parte di noi ritengono che una buona cosa in generale. 😛
    • Se il comportamento di default non è “standard” OOP, perché altre lingue sono “l’amico” (o simile) della direttiva? È solo un altro metodo utile di incapsulamento.
    • Gamecat: speriamo che ciò che è stato.

  2. 5

    Si potrebbe avere guardato questo ovunque (la parola chiave sarà “modificatori di accesso”)

    Fondamentalmente, protetta significa che i membri saranno visibili nel bambino le classi e in tutta l’unità. rigorosa privato significa che si ha accesso agli stati membri i metodi di questa classe SOLO.

  3. 4

    Un caso manca, in altre risposte: private e anche strict private campi di altre istanze possono essere raggiunte da un codice all’interno della loro classe:

    type
      TSO1516493= class
      strict private
        A: Integer;
      public
        procedure ChangeOther(Param: TSO1516493);
      end;
    
    { TSO1516493 }
    
    procedure TSO1516493.ChangeOther(Param: TSO1516493);
    begin
      Param.A := -1; // accessing a strict private variable in other instance !
    end;

    (Questo è lo stesso comportamento in Java.)

  4. 1

    Un altro caso mancanti nelle altre risposte.
    C’è anche la possibilità di “estendere” la classe di incapsulamento regole.

    Con classe helper, introdotto in Delphi 8 (ad .NETTO di compatibilità), è possibile eludere il
    differenza di visibilità tra privati,protetti e pubblici (e anche rigoroso notazioni).
    La classe helper dichiarazione può essere in un’altra unità rispetto all’originale classe.

    Questo è un esempio :

    type
      TMyOrgClass = class
      strict private
        FMyPrivateProp: Integer;
      strict protected
        property MyPrivateProp: Integer read FMyPrivateProp;
      end;
    
      TMyClassHelper = class helper for TMyOrgClass
      private
        function GetMyPublicProp: Integer;
      public
        property MyPublicProp: Integer read GetMyPublicProp;
      end;
    
    function TMyClassHelper.GetMyPublicProp: Integer;
    begin
      Result:= Self.FMyPrivateProp;  // Access the org class members with Self
    end;

    Vedere questo post per ulteriori informazioni :accesso-a-rigoroso-protette-immobili-di-un-delphi-classe.

Lascia un commento