Precies, maar wel lastig uit te leggen. Het klinkt zo heel makkelijk. Maar om aan een leek uit te leggen wat het verschil is tussen VB en Delphi is toch lastig. Je moet dan namelijk eerst uit zien te leggen wat OO is, en dat is vaak wel lastig.
1+1=b
Is er wel een fundamenteel verschil? Of zijn het een boel graduele en een andere cultuur van gebruik?
Toch niet moeilijk?Maar om aan een leek uit te leggen wat het verschil is tussen VB en Delphi
VB = Microsoft
Delphi = anti Microsoft
Delphi is great. Lazarus is more powerfull
Weinig keus als 95% van de markt daarop gericht is.Redelijk lastig om anti-Microsoft te zijn als je effectief Windows only bent.
Zelf zoek ik ook altijd een alternatief, maar het kan niet altijd.
Delphi is great. Lazarus is more powerfull
Ik heb het nooit zo op tegenstemmers, dus de enige anti die ik ben is anti-anti
Verder mag ik hopen dat we marcov niet hoeven uit te leggen dat er daadwerkelijk wel een fundamenteel verschil is tussen Delphi en VB. Al was het alleen maar de visual form inheritance die deze week weer eens door een forumlid werd ontdekt. Maar ja, is dat nou OO of RAD?
Maar inderdaad, OO en RAD tegenover elkaar zetten is wat lastig. Al was het alleen maar omdat OO iets is van ontwerpers en programmeurs en RAD veel verder in een team doorlekt. Maar om het artikel nou "Versimpel je Dephi code door OO techniek te gebruiken in plaats van alleen wat componenten te slepen" is ook weer niet alles
Voor de rest: ELKE discussie en ELK artikel over gestructureerd programmeren juich ik van harte toe. Ik maak in onderhoud van oude projecten dagelijks mee wat de gevolgen (en met name de kosten!) zijn als je dat niet doet.
Marcel
En is het een missende feature of een fundamenteel verschil.
Maar het beestje moet wel een zinnige naam hebben. "Een eind aan trial-and-error programmeren" is dan een zinnigere titel. Het is het ontwerp en planning die het um doen, niet die language extensions.Maar om het artikel nou "Versimpel je Dephi code door OO techniek te gebruiken in plaats van alleen wat componenten te slepen" is ook weer niet alles
Net deel 3 uitgetyped ... moet wel alles nog even nalezen / proofreaden.
Heb zo de indruk dat het een lang stukje wordt. Er zullen weer een aantal mensen zijn die denken dat ik het veel te ver ga zoeken, ...
Maar daarop kan ik nu al zeggen, wacht maar op deel 10 of zo en dan zal je zien dat alle puzzelstukjes mooi in elkaar passen :-P
Groeten,
Stefaan
Oh, en wat betreft het verschil tussen RAD en OO wil ik het volgende meegeven :
Ik zie heel vaak mensen op een snelle manier een app bouwen in Delhi door heel snel een hoop componenten op een form te droppen alles aan elkaar te linken en klaar. Op zich is dat RAD, maar ze beseffen niet dat ze met een OO programmeertaal / tool aan het werken zijn.
RAD is maar al te vaak 'quick en dirty' heb ik al vaak gemerkt.
Oh, ik drop een TQuery, een TDataSource en een TDBEdit op mijn form voor de Naam van een artikel en de prijs, ik codeer daar in de OnExit of zo even dat de waarden groter moet zijn dan 0.
2 weken later hebben ze hetzelfde nodig op niveau van een OrderLijn waar ook artikels gebruikt worden, dus snel nog even een TQuery, TDataSource, TDBEdit op de form droppen, code copy / pasten en klaar is kees.
2 jaar laten kom ik een probleem oplossen omdat de programmeur ondertussen niet meer bij het bedrijf werkt en zie ik 57 keer dezelfde controls / en copy / pasted code in 1 applicatie en zeg ik volmondig :
JA, er is een verschil tussen RAD en OO !
Neen, het ene sluit het andere niet uit !
Neen, het is niet omdat je RAD bezig bent dat je ook echt OO bezig bent !
Naar mijn mening is er dus wel wezenlijk een verschil, een GROOT verschil zelfs :-) En ik ondervind vaak dat de klik van RAD naar OO niet zo eenvoudig is. Waarom immers OO programmeren als ik op 10 minuten de controls op mijn form gedroped krijg.
Groeten,
Stefaan
Om een of andere reden kreeg ik op mijn website deel 3 niet in 1 post en heb ik die moeten opsplitsen in deel 3 en deel 4.
Waarschijnlijk iets te veel HTML code voor de Delphi sources in een post ...
Simplify your Delphi Code using some OO techniques (Part 3)
Simplify your Delphi Code using some OO techniques (Part 4)
Alle feedback is welkom natuurlijk. Ik probeer in de loop van de komende 2 weken een vertaalde versie te hebben in PDF formaat of zo.
Groeten,
Stefaan
Stefaan, als ik als een beginner er naar kijk, zal ik de draad kwijt zijn.
Je maakt deze class aan: TdvSetting = class( TObject ). Daar staat bij elke procedure / functie het woord 'virtual' achter. Maar er staat niet beschreven waarvoor je het doet. Bij deel 4 maak je een Class TdvStringSetting aan, die alles erft van TdvSetting. Op zich niets mis mee, maar vertel dan wel waarom het zo moet. Maak je eigenlijk niet gebruik van een abstracte class?
Verder op maak je deze: TdvSettings = class( TObjectList )
Geef die klass een andere naam. Het lijkt erg veel op de vorige namen, waardoor je niet goed kan zien om welke class het nu gaat.
Ik hoop niet dat je mij een zeurpiet vind
Delphi is great. Lazarus is more powerfull
Dag John,
Ja, uw opmerkingen zijn terecht. Als je echt een complete beginner bent, dan zal je misschien hier en daar iets missen. Misschien moet ik in Part 5 wel een en ander uitleggen naar aanleiding van de feedback die ik krijg.
Virtual Procedures
Eigenlijk vooral bedoeld om later in descendant classes overerving te kunnen gebruiken en toch uw polymorfisme te behouden. Als ik dat erbij vertel dan zullen beginners volledig de draad kwijt zijn vrees ik. En het is eigenlijk ook niet zo eenvoudig uit te leggen.
Zonder virtual of dynamic is de procedure gebonden aan de class. Je kan ze wel overriden, maar als je dan bv extensief gebruik maakt van Type Casting dan wordt het iets complexer. (zal daar ook eens een stukje over schrijven).
Waarschijnlijk vraag je nu 'wat is het verschil dan tussen virtual en dynamic'. Wel om hier kort op te antwoorden is het enige verschil de manier waarop het intern in de method table geduwd word. Virtual is dacht ik beter als je weet dat je het vaak zal overerven.
Waarom geen Abstracte class
Naar analogie van TField en TStringField, TIntegerField, ... En wat bedoel jij dan juist met een Abstract class ?
TdbSettings
Tja, het klopt wat je zegt. Vermoeddellijk opnieuw naar analogie van TField en TFields. Uiteindelijk ga je later zelf in uw applcatie nooit gebruik maken van een TdvSetting. Trouwens, je zal ook niet rechtstreeks gebruik maken van een TdvSettings maar een afgeleide ervan.
Misschien moet ik inderdaad nog eens nadenken over de namen. Ik had eerst TdvApplicationSettings in plaats van TdvSettings, maar tijdens het programmeren kwam ik al snel tot de vaststelling dat de uiteindelijke classes voor veel meer dan enkel Application Settings kunnen gebruikt worden.
Feedback
Neen, ik vind je geen zeurpiet ... het zijn trouwens terechte opmerkingen. Persoonlijk hou ik ook van feedback, het laat mij immers zien dat het nog altijd beter kan. En mijn leuze luidt nog altijd :
If we would all help eachother, we could all become experts !
Groeten,
Stefaan
Stefaan,
kan het zijn dat er iets misgelopen is met de HTML op je site?
Vanaf "... well almost..." op part-3 verschijnt in Internet Explorer alles in gigantische letters.
Sam.
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.
Sam Witse.Delphi & OO in Vlaanderen
Sam,
Tiens; ik kan het niet zien hoor. Welke browser gebruik je ? Ik heb al gekeken met Safari op mijn Mac en FireFox op de PC. Zal deze avond voor alle zekerheid de HTML nog eens bekijken. Het is immers best mogelijk dat ik ergens een verkeerde close tag gebruikt heb.
Groeten;
Stefaan
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks