Nichts, zum einen weil Public/Private im
OOP Bereich schlicht standard ist und es meiner Meinung nach wenig bringt hier Namen zu ändern - das auf was Du raus willst kannst Du auch mit Interface/Implementation machen (oder ich habe es nicht verstanden
)
Der Punkt ist, dass momentan unitprivate Deklarationen alle im implementation-Teil liegen, wo dann Deklarationen und Implementierungen querbeet gemischt sind. In meinem Modell geht es darum, im implementation-Teil möglichst auch nur die implementation zu haben. Nicht exportierte Typen, Konstanten und Variablen kommen dann in den private-Teil. Die Reihenfolge der private- und public-Abschnitte ist nicht festgelegt, und es kann auch mehrere geben, um bspw. Global Properties zu ermöglichen, ohne den Getter/Setter auch veröffentlichen zu müssen.
Zitat:
was sind für dich Methoden? Was sind für dich "nichtmethodische Routinen"? Und wie soll die Methodengruppierung aussehen? Oder habe ich da auch was nicht verstanden / übersehen?
Methoden = Prozeduren und Funktionen von Klassen (und erweiterten Records)
nichtmethodische Routinen = Prozeduren und Funktionen, die keiner Klasse angehören
Delphi-Quellcode:
procedure TXyz.DoSmthng; // Methode
function IntToStr(AValue: Integer): string; // keine Methode
Wie die Gruppierung aussehen soll, steht nicht fest (wie allgemein noch nichts), im Entwurf im oberen Post sah sie so aus:
Delphi-Quellcode:
implementation
TXyz: begin
procedure Xyz;
begin
// Do something
end;
end;
end.
Im Prinzip eigentlich nicht notwendig.
Interface = Public
Implementation = Private
Da stört es mich aber, dass der implementation-Teil zugleich für unitprivate-Deklarationen und Implementierungen gleichzeitig benutzt wird. Schöner fände ich es, wenn man das trennen würde und im implementation-Teil keine Deklarationen mehr zugelassen würden.
Zitat:
Die Methodengruppierung finde ich unübersichtlich.
Seh ich irgendwo in der Implementation ein procedure irgendwas;
, dann denke ich das wäre eine Prozedur und nicht daß sich da irgendwo noch ein begin
verstecken könnte, welches dieses zu einer Methode macht.
Zwei Klassen, mit einer gleichnamigen Methode, dann stehen unten zwei Prozeduren, welche man nicht direkt einer der Klassen zuordnen kann, ohne vorher nach einem "begin" zu suchen, um zu sehn ob und wenn ja zu welcher Klasse es gehört.
Das stimmt natürlich, da ist sie kontraproduktiv. Schön wäre es, irgendwie eine Syntax zu finden, die dieses Problem nicht hat, aber das dürfte schwierig werden.
Zitat:
Aber da man solche Globalen sowieso besser vermeiden sollte, bringt es eigentlich nicht viel.
Stimmt durchaus, vllt. fliegen die Global Properties doch noch ausm Entwurf raus.