Misschien leuk om deze hier te delen, staan handige tips in (zeker voor beginners)
https://gdksoftware.com/wp-content/u...-Checklist.pdf
Printable View
Misschien leuk om deze hier te delen, staan handige tips in (zeker voor beginners)
https://gdksoftware.com/wp-content/u...-Checklist.pdf
Zeker. Met een stukje over interfaces. En laat ik daar nog een bloedje hekele aan hebben. Maar toch even proberen.
Ja ik heb zelf ook nog niet met interfaces gewerkt (althans niet mijn eigen interface) en ik zoek al een tijdje een excuus om er niet aan te hoeven beginnen, misschien dat ik zelf ook eens ga proberen..
Wat is het bezwaar tegen interfaces?
Omdat ik ze niet goed snap ;) :D
Daardoor ga ik ook het voorbeeld uit die PDF proberen.
Idem hierzo, ik heb niks tegen interfaces, maar heb al meerdere voorbeelden gezocht - maar het blijft voor mij een beetje een vreemd beest waar ik weinig van begrijp. Zo ben ik al situaties tegen gekomen waar Interfaces een uitkomst zouden bieden (als ik het goed begrepen heb) maar lukt het mij niet om deze successvol te gebruiken.
Als je meer over interfaces wilt lezen kan ik je echt het boek "Coding in Delphi" aanbevelen van Nick Hodges.
Een simpele uitleg over interfaces kun je hier vinden: http://www.delphibasics.co.uk/Articl...Name=Interface
Dus eigenlijk is een interface een class, die je tussen wilt proppen, maar voor meerdere klassen gebruikt kan worden, omdat je een gemeenschappelijke doel hebt.
Ik vind het wel veel coding, die je moet invoeren. Want niet alleen je interface moet je defineren, maar ook de functie, gemaakt in je interface, toevoegen aan de class, die je gebruikt.
Hier de link naar youtube waar Marco Geuze een mooi voorbeeld heeft van hoe hij interfaces gebruikt.
The SOLID Principles in Delphi - Write Better Code!
https://www.youtube.com/watch?v=hFjGuNjQv_A
Het is alleen de interface, dus je declareert alleen welke methods je hebt in de interface, zonder verder implementatie. Als veel code typen een issue is, dan is Delphi toch al niet de beste taal, maar eigenlijk valt het best mee. Een voordeel van interfaced objecten, is dat deze doorgaans vanzelf opgeruimd worden. Je hebt dus minder try..finally blokjes nodig, nog afgezien van alle andere voordelen.
Dat wordt natuurlijk gevaarlijker als je onbeperkt veel interface references rond gaat jagen. Dan krijg je vroeg of laat een cycle :-)
Opmerkingen van (andere) Marco over de Garbage Collector van Delphi zijn ietwat tenenkrommend.
Hoeveelheid Code typen is overigens zelden een beperking, het voelt alleen zo. Code debuggen, daar gaat de tijd in ziten
Het typwerk kun je wel iets verkleinen door MMX CodeExplorer te gebruiken. Je kunt daar makkelijk een interface naar een class toe slepen waarna je methodes van de Interface in je class krijgt zonder aanvullend typwerk. De andere kant op werkt ook, je kunt methodes naar een interface toe slepen.
De hoeveelheid typwerk is voor mij eigenlijk nooit een bezwaar, slecht onderhoudbare code wel.
Dan had het OnCreate gedeelte toch beter geweest als we dit zo schrijven?
Het blijft een moeilijk iets die Interfaces. Ik snap het ook niet goed wat voor voordeel ik er aan heb.Code:procedure TForm1.FormCreate(Sender: TObject);
var
Vehicle: IRecyclable; // <--
begin
Vehicle := TCar.Create('Nissan bluebird');
if Vehicle.isRecyclable
then
ShowMessage('Dads car is recyclable')
else
ShowMessage('Dads car is not recyclable');
Vehicle := TBicycle.Create(false, 24);
if Vehicle.isRecyclable
then
ShowMessage('Mums bike is recyclable')
else
ShowMessage('Mums bike is not recyclable');
Nick Hodges "Coding in Delphi" schrijft dat je altijd Interfaces moet gebruiken ook al gebruik je het nog niet. En dat in een aparte UNIT.
Ik denk voor een nieuw project het wel interessant kan zijn.
Tips zijn welkom.
Groetjes.
Als ik het argument in de GDK document goed begrijp is dat je wat meer type safety in bepaalde scenario's kan inbrengen. (het manager /ceo verhaal in het document)
Ik denk dat het wel waar is, in de zin dat het wat kan helpen bij zeer complexe business code en -model, maar heb wat twijfels bij de algemeenheid daarvan, en of het waard is om dat centraal moet zetten dat je je hele codebase er naar om te zetten. Oftewel: kosten-baten.
Daarnaast heb ik ook twijfels bij het gebruik van refcounted interfaces hiervoor. Dit dwingt je tot exclusief gebruik van interfaces, en dat gaat mij wat ver. Je kan interfaces refcounting wel uitzetten (door de methods te overriden), maar dan heb je weer een eigen root class nodig, en er is wat overhead.
Ik meende overigens dat in de feature overviews van een van de laatste Delphi versies gezien te hebben dat refcounting voor interfaces nu eindelijk uitgezet kan worden? Iemand daar ervaring mee?
Ik heb op dit moment geen complexe business modellen van die aard, maar had dit in een vorige baan wel. (600-1000 entiteiten, nogal complex met elkaar verweven)
Handig voor mocken, m.b.t unit tests. De mock libraries kunnen makkelijk een implementatie nabootsen met specifiek vastgesteld gedrag, om allerlei code-paden uitgebreid te testen zonder daadwerkelijk naar een database, bestand, of API te hoeven schrijven, en zonder dat je zelf die mock code moet schrijven.
De noodzaak om die code testbaar te maken, zorgt er voor dat ik daardoor sowieso een 'betere' (vind ik dan, de meningen zijn vast verdeeld) structuur krijg in m'n code, en veel meer geneigd ben om op een simpele manier data op te halen, en de complexere handelingen erop apart te houden.
Soort van type-safety, zoals Marcov zegt. Bij Domain Driven Design (DDD) kan dat interessant zijn. Tot op zekere hoogte kan dat overigens ook met records worden bereikt.
Ik werk zelf weinig met niet-reference counted interfaces, maar ik meen dat er een attribuut is toegevoegd, waarmee je aan kunt geven dat een een field in een class, van een interface type, een [weak] refererence is, die dus niet bijdraagt aan de refcounting. De interface is dan an sich wel ref counted, maar de code voor het aanroepen van addref wordt niet gegenereerd. Volgens mij is dat met name nuttig voor circulaire verwijzingen tussen interfaces, waarvan je weet dat ze qua object ook bij elkaar horen. Een beetje zoals TComponent met z'n owner, maar dan de interface-versie. Ik zou dat alleen gebruiken als het echt niet anders kan, en standaard juist wel gebruik maken van de reference counting.
Er zijn een paar uitzonderingen, namelijk classes die nu al in de VCL als class gebruikt worden, zoals TForm. Die schakelen zelf hun reference counting uit, meen ik.
Al met al zijn er wat verschuivingen gaande in het object georienteerd programmeren. In het klassieke OO, heb je classes die hun eigen state bijhouden, en methods hebben om die state aan te kunnen passen. (Een TPersoon met een property Naam string read/write). Daarbij zag je heel vaak dat overerven haast wel de heilige graal leek. Een TDier, TZoogdier, TKoe. In de praktijk kom je erachter dat het niet zo werkt, dat niet alle zoogdieren poten hebben, en niet alle dieren met poten zoogdieren zijn, enz. Dat sluit ook aan bij dat verhaal over Employee, Manager en CEO in het GDK-boek. Dat zijn constructies die je niet met overerving kan oplossen. Interfaces bieden daar een vrij elegante manier voor.
Overigens zie ik zelden de noodzaak om interfaces en classes te mixen. D.w.z. niet elke class heeft een interface, maar classes die ik een interface (of meerdere) heb gegeven gebruik ik in principe alleen via de interface.