Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Unit Aufbau (https://www.delphipraxis.net/65843-unit-aufbau.html)

Ruffy87 21. Mär 2006 17:38

Re: Unit Aufbau
 
Weiß einer auch was Published bedeutet(also vom CodeExplorer, siehe oberes Bild)?
oder welche Unterschiede es zwischen Public und Published gibt?

Denn vom Englischen her bedeuten Sie fast das selbe.

ichbins 21. Mär 2006 17:45

Re: Unit Aufbau
 
In der Hilfe steht da eine ellenlanger Artikel dazu...



achja, NIEMALS die Prozedur einfach so in die Unit schreiben sondern IMMER auch im Interface-Bereich reinschreiben. Sonst kann die Prozedur von anderen Prozeduren, die über der einen stehen, nicht aufgerufen werden etc.

Hansa 21. Mär 2006 18:04

Re: Unit Aufbau
 
Zusammenfassung :

1. private : gültig nur innerhalb der Klasse und nur von dieser zu "sehen" bzw. zu manipulieren. Nix drin mit
Delphi-Quellcode:
Form1.i := 0;
sofern i als private in Form2 deklariert wurde.

2. protected : hier vorerst keine Erklärung. Sehr wichtig bei größeren Programmen, die OOP auch nutzen.

3. public : von überall her zugreifbar auch außerhalb der Unit, wo das definiert wurde. Also :
Delphi-Quellcode:
Form2.i := Form2.j;
geht damit sehr wohl.

4. published : ähnlich wie public, allerdings hauptsächlich für OI gedacht und wichtig bei Entwicklung eigener Komponenten.

Aber all das ist nur die Spitze des Eisbergs, denn jetzt kommt noch vor allem virtual und override ins Spiel. Unerläßlich in Zusammenhang mit 2. protected. Das ganze ist nicht ganz so trivial, wie es vielleicht aussieht !

Der_Unwissende 21. Mär 2006 18:10

Re: Unit Aufbau
 
Zitat:

Zitat von ichbins
achja, NIEMALS die Prozedur einfach so in die Unit schreiben sondern IMMER auch im Interface-Bereich reinschreiben. Sonst kann die Prozedur von anderen Prozeduren, die über der einen stehen, nicht aufgerufen werden etc.

Sorry, aber das stimmt so auch nicht. Wie bereits erwähnt kannst du Prozeduren auch nur im Implementationteil benutzen, wenn es Prozeduren sind, die eben nie von aussen aufgerufen werden sollen. Sagen wir mal (ganz stupide) du baust einen Rechner (wie kreativ). Deine Idee wäre es jetzt, dass deine Unit eine Methode Compute hat, die bekommt 3 Strings (eingegebene Zahlen + Rechenzeichen). Compute gibt dir den String zurück, der das Ergebnis repräsentiert.
Jetzt überlegst du dir, du möchtest als erstes mal die Strings auf Gültigkeit prüfen (deshalb sind's hier auch erstmal Strings). Dazu möchtest du entscheiden ob die Zahlen gültig sind und du das Rechenzeichen kennst. Nehmen wir nun an, du entscheidest dich das in Methoden auszulagern, dann könnte es zu folgendem kommen:

Delphi-Quellcode:
interface
  function compute(const Number1, Number2, Operator : String) : String;

implementation
 
  // forwarded, da die Implementierung nach dem ersten Aufruf folgt
  function isValidNumber(const Number : String) : Boolean; forward;
  function isValidOperator(const Operator : String) : Boolean; forward;

  function compute(const Number1, Number2, Operator : String) : String;
    begin
      // testen ob gültige Nummern und Operator
      if isValidNumber(Number1) and isValidNumber(Number2) and isValidOperator(Operator) then
        begin
          ...
        end; // if isValidNumber(Number1) and isValidNumber(Number2) and isValidOperator(Operator)
    end; // function compute(const Number1, Number2, Operator : String) : String;

  function isValidNumber(const Number : String) : Boolean;
    begin
      ...
    end;
Wichtig ist halt nur, dass Methoden die folgen mit forward deklariert oder halt vor dem ersten Aufruf implementiert werden müssen. Es macht aber durchaus Sinn Methoden nur im Implementationteil zu halten.


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:28 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz