http://www.webtechcorp.co.uk/web-dev...rticle-oop.htm
Een eenvoudige uitleg over OOP in Delphi in het Engels.
http://www.webtechcorp.co.uk/web-dev...rticle-oop.htm
Een eenvoudige uitleg over OOP in Delphi in het Engels.
Last edited by Marcel; 21-Feb-07 at 00:49.
Groetjes,
Don
Newbie in Delphi.
Leuk document.
Als er interesse is hier, dan vertaal ik dat wel even, met toevoegen van een aantel andere technieken zoals dynamische documentatie
De verbazing begint waar de kennis ophoudt
Ik heb hem ook gelijk even in de link sectie gezet van de beginning delphi page op de wikia site.
Het maakt anders al de fout "inheritance" als vereist OOP kenmerk aan te merken.
Dat is alleen zo bij statische typing. (wat overigens in het geval van Delphi wel zo is)
Zie ook deze thread:
http://www.nldelphi.com/forum/showth...t=instantiatie
Er staan nog meer fouten in waar me de haren van te berge rijzen,zoals:
Standaard Delphi object pascal misschien ja. Pre Delphi Object Pascal's hadden het niet. Maar "standaard pascal" (ISO 7185) is _geheel_ iets anders.Try / Finally construct is part of standard Pascal,
en de definitie van private:
Dit is een wijdverbreidde fout. private is vziw exclusief ten opzichte van de unit waar de klasse in gedefinieerd is, niet de klasse zelf. Probeer zelf maar, definieer een losse procedure in een unit met form met private velden, en haal iets uit de form's private velden in die procedure.The private section of the class contains things that class users cannot see. The only code that can see private instance variables and methods are other methods of this class.
Voor zover ik gehoord heb, is dit een fout in de IDE van Delphi 7 en lager, omdat dit niet volgens de OOP regels is. Een fout die in Delphi 9 en 10 is gefixed. Ik zal eens kijken of dit ook daadwerkelijk zo is...Private is vziw exclusief ten opzichte van de unit waar de klasse in gedefinieerd is, niet de klasse zelf. Probeer zelf maar, definieer een losse procedure in een unit met form met private velden, en haal iets uit de form's private velden in die procedure.
EDIT:
Het is in delphi 10 niet verholpen (als het een geldige fout is). Zelfs een private variabele in class1 kan vanuit class2 nog aangeroepen worden, mits ze in dezelfde unit staan. En wat ik dus gehoord heb, was dat niet de bedoeling?
Last edited by Cornelis; 21-Feb-07 at 14:20.
Het is vziw altijd zo geweest in Delphi. De taal definitie van Delphi is niet echt formeel of gedetaileerd, dus beoordelen of dit oorspronkelijk een fout was, is moeilijk.
Het is wel al heel lang bekend, (minstens sinds D2), en vrijwel zeker sinds minstens die tijd al expliciet zo gehouden vanwege backwards compability.
Veel mensen zullen dit "fout", en "niet (echt) OOP" enz noemen, maar dat is met een bril van andere OOP talen, die doorgaans het hele unit concept missen, en daarom is zo'n beoordeling nogal kortzichtig.
De unit geeft een extra vorm van information hiding, en te strikt enforcen van private a la Java zou het unit concept uithollen. Het is dus een gevolg van het hebben van een zg mixed paradigmE taal (modulair procedureel en oop).
Is er daarom (vanaf D8?) niet een strict private bijgekomen?
(Sender as TNLDUser).Signature := 'Groeten van Albert';
Dat is enkel voor .Net
DeX 3 Delphi := The ease of VB with the power of C; Zoekt en gij zult vinden
Even inhaken. Strict private werkt ook in Win32
Code:unit Unit7; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls; type TClasse1 = class(TObject) strict private FMijnStrictPrivateField: string; private FMijnPrivateField: string; end; TForm7 = class(TForm) Button1: TButton; Button2: TButton; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private FClasse1: TClasse1; public { Public declarations } end; var Form7: TForm7; implementation {$R *.dfm} procedure TForm7.Button1Click(Sender: TObject); begin { Dit compileert wel } FClasse1 := TClasse1.Create; try ShowMessage(FClasse1.FMijnPrivateField); finally FClasse1.Free; end; end; procedure TForm7.Button2Click(Sender: TObject); begin { Dit compileert niet } FClasse1 := TClasse1.Create; try ShowMessage(FClasse1.FMijnStrictPrivateField); finally FClasse1.Free; end; end; end.
Om toch aan de JAVA/C++/C#/Enz. OOP regels te voldoen denk ik
Je hebt gelijk Dees, in D2005 is het een ondocumented feature maar het is dus degelijk mogelijk.Originally Posted by BDS4 Help
DeX 3 Delphi := The ease of VB with the power of C; Zoekt en gij zult vinden
Ik zou hier `Welke "regels"` op kunnen antwoorden, maar dat is ook niet productief :-)
Het is ook meer mode dan een onderbouwde stelling. De helft van de Delphi programmeurs, zo niet meer weet het niet eens, wat wel aangeeft hoe weinig het in de praktijk er toe doet.
Laten we maar stellen dat het de geldende mode is. Of dit soort detail controle echt is wat de originators van OO in gedachten hadden betwijfel ik ten zeerste. (die waren sowieso meer met het modelleren bezig dan overdetaillering van OO talen, wat in hun ogen maar een hulpmiddel was)
(zure mode aan)
Het lijkt soms wel een varkenscyclus:
1. iemand stelt dat software engineering moeilijk is vanwege bugs.
2. iemand stelt als oplossing een strictere informatiehiding voor, met een of ander randgeval als voorbeeld. (realisme of een statistische onderbouwing of dit echt bugs vermijdt wordt niet gegeven)
3. De puristen denken dat ze eindelijk gelijk krijgen.
4. De toolvendors zien een nieuw verkoopargument of zelfs -prodcut.
(invoeren/migratie)
5. de additionele complexiteit om al deze extra features te managen leidt tot meer bugs.
6. goto 1
Als het zo door gaat, hebben we op den duur een programmeertaal met een ACL list waar ie aan mag in elke regel.
(zure mode uit)
Andere mensen denken dat software engineering lastig is vanwege de complexiteit van de problemen die we ermee proberen op te lossen en dat het toevoegen van complexiteit aan de taalkant daar niet bij helpt. Een tijdje smalltalk gebruiken kan daar heel illustratief zijn.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks