Delphi zählt falsch

[SirThornberry]

@Hansa: Man sollte aber nicht alles in Protected packen sondern nur das was für abgeleitete Klassen wirklich nötig ist. Wenn man zum beispiel einen grafischen Button als Komponente programmiert so braucht man in aller regel nur die Canvas unter Protected lassen (was ja glaub ich schon von je her so ist). Alles andere braucht nicht mehr angerührt werden. Naja, warum schreib ich das überhaupt, so wie sich dein Post anhört bist du einer der wenigen die das Konzept der OOP richtig verstanden haben und auch umsetzen (ich bin leider einer der nicht so ganz konsquenten - ich änder dann wenn ich abgeleitet habe erst die Basisklassen um wenn ich mitbekomme das ich doch auf irgend eine private-variable/methode zugreifen muss)

[jbg]

Zitat:

Zitat von Hansa

Dann wäre ich aber ein ganz seltener Ideologe.

Ich schrieb von Felder/Attribute und nicht von Eigenschaften (property)

Sowas wie

Delphi-Quellcode:

protected
  FMyField: TMyType;
end;

meinte ich.

Delphi-Quellcode:

protected
  property MyField: TMyType read FMyField;
end;

ist natürlich erlaubt :wink:

[IngoD7]

[OFF-Topic]

Zitat:

Zitat von jbg

Zitat:

Zitat von Coder

warum darf ich nicht Application.terminate nehmen?

Weil Application.Terminate einige Events auslässt, weil es mehr für einen abrupten Programmabbruch gedacht ist.

Was durchaus beabsichtigt sein kann. Von einer verbotenen Nutzung im Sinne von "nicht dürfen" kann also keine Rede sein. Allerdings sollte man sich dann auch nicht wundern, wenn z.B. die Form.OnClose-Routine nicht abgearbeitet wird. :wink:

[/OFF-Topic]

[Hansa]

Zitat:

Zitat von jbg

Ich schrieb von Felder/Attribute und nicht von Eigenschaften (property)

Sowas wie

Delphi-Quellcode:

protected
  FMyField: TMyType;
end;

meinte ich.

Was soll den damit sein ? :shock:

Konkretes Beispiel :

Delphi-Quellcode:

  protected
    ArtNr : string;
    ArtGef : boolean;
    VonArtNr,
    BisArtNr : integer;
...
    KommaCols : set of byte;
...

Das ist bei weitem nicht alles. Ungefähr so sieht die class aus, die ich verwende, um einen Artikel zu erfassen. Ob das sich jetzt um den Lagerbestand oder eine Rechnungsposition handelt, das ist völlig egal. Der Artikel muß nur da sein.

Es ist doch wohl schon mal grundlegend, zu wissen, ob ein Artikel vorhanden ist. Ist das nicht der Fall so kann ich eben keinen Lagerbestand usw. abspeichern. Und anderes auch nicht. Die Variable "ArtGef" muß also auch dem Lagerbestand zugänglich sein. Ansonsten müßte sie neu definiert und ausgewertet werden, was die vorhandene Form aber so oder so schon macht. Ergo : Rad neu erfinden und zig-fach verwalten. Es ist schon erschreckend, zu sehen, daß das OOP Konzept so gut wie nirgends berücksichtigt und offensichtlich auch ncht gelehrt wird.

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

[moritz]

So, hier mal mein Kommentar dazu:
1) Was ist an dem Programm so toll, dass man es mit einem Passwort schützen muss?
2) Du pack's JPEG-Dateien... Das ist in etwa so sinnvoll, wie eine ZIP-Datei zweimal zu packen
3) Der Code sollte etwas formatiert sein, sonst kann man da nichts lesen
4) Was soll das Programm machen?

[jbg]

Zitat:

Zitat von Hansa

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

Die vielen Felder in protected sind die "Tippfaule" Variante, die ich zugegebenermaßen auch manchmal verwendet. Man tippt eben nicht gerne viel.

Die (reine) Theorie der Kapselung würde das aber lieber so sehen.

Delphi-Quellcode:

private
    FArtNr : string;
    FArtGef : boolean;
    FVonArtNr,
    FBisArtNr : integer;
...
    FKommaCols : TByteSet;
  protected
    property ArtNr: string read FArtNr write FArtNr;
    property ArtGef: Boolean read FArtGef write FArtGef;
...

Dadurch wäre es nämlich möglich, die Datenstruktur neu zu organisieren, ohne das nach außen etwas verändert wird. (Tritt aber bei End-Anwendungen nicht so häufig auf. Bei Komponentenbibliotheken hingegen sehr oft).

Wobei Leute, die keine Ahnung von Delphi haben, sich hierbei auch Fragen würden, ob das denn wirklich gekapselt ist, da man doch

Delphi-Quellcode:

MyInstance.ArtNr := '1234';

schreiben kann und nicht wie in Java ein

Code:

MyInstance.setArtNr("1234");

nutzt. (habe ich erst kürzlich gehört).

[Robert_G]

Zitat:

Zitat von Hansa

Was soll den damit sein ? :shock:

Konkretes Beispiel :

Delphi-Quellcode:

  protected
    ArtNr : string;
    ArtGef : boolean;
    VonArtNr,
    BisArtNr : integer;
...
    KommaCols : set of byte;
...

Das ist bei weitem nicht alles. Ungefähr so sieht die class aus, die ich verwende, um einen Artikel zu erfassen. Ob das sich jetzt um den Lagerbestand oder eine Rechnungsposition handelt, das ist völlig egal. Der Artikel muß nur da sein.

Gutes Beispiel wie es nicht gehen sollte. :mrgreen:
Warum haben die Nachfahren von Artikel schreibenden Zugriff auf die Artikelnummer? :shock:
Im allgemeinen lasse ich Nachfahren nur dann auf Felder zugreifen, wenn ich es für konsistent halte. (Wobei ich auch dann höchsten den Setter als virtual deklariere ;) )
Denn hast du auf einmal einen falschen Schlüssel geht die Sucherei los. Haben die Nachfahren keinen schriebenden Zugriff, kann er nur beim Erzeugen der Instanz oder in TArticle zersägt worden sein.

Zitat:

Zitat von Hansa

Die Variable "ArtGef" muß also auch dem Lagerbestand zugänglich sein. Ansonsten müßte sie neu definiert und ausgewertet werden, was die vorhandene Form aber so oder so schon macht. Ergo : Rad neu erfinden und zig-fach verwalten.

Wie du unten siehst stellt es kein Problem dar. ;)

Zitat:

Zitat von Hansa

Es ist schon erschreckend, zu sehen, daß das OOP Konzept so gut wie nirgends berücksichtigt und offensichtlich auch ncht gelehrt wird.

Finde ich auch. :P

Zitat:

Zitat von Hansa

Und wie so was mit private gehen soll, das soll mir erst mal einer sagen. :mrgreen:

Bitte schön: ;)

Delphi-Quellcode:

type TArticle = class
private
  fArtNr : string;
...
published
  property ArtNr :string read fArtNr;
...
public constructor Create(const aArtNNr :string);
end;

type TSomeDescendant = class(TArticle)
...
public constructor Create(const: aArtNr: string; aSomeProperty :TSomeType);
...
end;
implementation

constructor TArticle.Create(const: aArtNr: string);
begin
  inherited Create();
  fArtNr := aArtNr;
end;

constructor TSomeDescendant.Create(const: aArtNr: string; aSomeProperty :TSomeType);
begin
  inherited Create(aArtNr);
  fSomeProperty := aSomeProperty;
end;

Wobei published properties nur Sinn machen, wenn man auf RTTI-Funktionen zurückgreifen möchte oder das Delphi-Streaming-System verwendet. (zum Beispiel in der Kombi TReader/TWriter & TCollection oder als persistente Einstellungen im OI).
Im Normalfall sollte public reichen. (Oder halt protected, wenn es nur die Nachfahren sehen sollen)

Zitat:

Wobei Leute, die keine Ahnung von Delphi haben, sich hierbei auch Fragen würden, ob das denn wirklich gekapselt ist, da man doch

Delphi-Quellcode:

MyInstance.ArtNr := '1234';

schreiben kann und nicht wie in Java ein

Zitat:

MyInstance.setArtNr("1234");

nutzt. (habe ich erst kürzlich gehört).

Hihi Java und seine expliziten Properties. :mrgreen: Ohne die wäre Java eine recht hübsche Sache. ;)

[Hansa]

@jbg : verstehe jetzt, was du meinst. 8) Und das in der Tat etwas Ideologie. Ich mache die Felder gleich protected und Du machst sie private, aber brauchst noch zusätzliche protected Zugriffsprozeduren. Bei Komponenten siehts auch wieder anders aus. Ich habe allerdings nur ca. 10 eigene. Zumindest sind soviele da, in eigenem Registerreiter. Die habe ich auch in diesem Stil gemacht. Allerdings kommt das eher von den Beispielen, die ich als Anregung genutzt habe. Und das ist auch wieder ein anderes Thema. Wenn z.B. nur die DCU, oder überhaupt etwas weitergegeben wird, was ableitbar sein soll, dann siehts total anders aus. Bei mir ist das aber egal, weil sowieso nur die EXE raus geht. :mrgreen:

Zitat:

Zitat von Robert_G

Gutes Beispiel wie es nicht gehen sollte. :mrgreen:

Du hast gerade noch gefehlt. :zwinker: Tja, was nicht gehen sollte, das geht aber trotzdem. Manchmal hat die Praxis eben schon ihre Vorzüge vor der Theorie. Und die protected Felder aufzusplitten in private Felder und protected Property-Prozeduren bringt keinen Zusatznutzen. Ich befürchte fast, die Wahrscheinlichkeit ist sogar höher, daß sich ein bloßer Tipfehler schlimmer auswirkt und schlechter ausfindig zu machen ist. Produktiver ist es wohl kaum.

Im Zusammenhang ist auch wieder die Objektablage interressant. Meine protected Felder liegen nämlich auf der Form. Und eine davon abstammende führt eventuell noch was neues ein, muß es aber nicht. Der Rest stammt vom Vorgänger. Wenn das Ganze nun sorgfältig hierarchisch aufgebaut ist, dann sehe ich kein Problem.

[Coder]

1) ich verschlüssel prinzipiell, wenn ich Daten woanders ablege. s.o. 7zip
2) das Zip hatte nur die Aufgabe alle Dateien zusammenzuhalten.
Du möchtest doch nicht jede Datei einzeln herunterladen, oder?
daß jpg schon maximal komprimiert ist (ok, bis auf 1-2% die da noch rauszuholen sind)
3) ich weiß.. ich hatte es aber nicht verändern wollen
3) es erstellt einen String aus dem nachher ein Bild [punkte,farbe] berechnet wird.