Page 1 of 2 1 2 LastLast
Results 1 to 15 of 20

Thread: Gratis E-Book van GDKSoftware

Hybrid View

  1. #1

    Gratis E-Book van GDKSoftware

    Misschien leuk om deze hier te delen, staan handige tips in (zeker voor beginners)
    https://gdksoftware.com/wp-content/u...-Checklist.pdf

  2. #2
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Zeker. Met een stukje over interfaces. En laat ik daar nog een bloedje hekele aan hebben. Maar toch even proberen.
    Delphi is great. Lazarus is more powerfull

  3. #3
    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..

  4. #4
    Wat is het bezwaar tegen interfaces?
    1+1=b

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Omdat ik ze niet goed snap

    Daardoor ga ik ook het voorbeeld uit die PDF proberen.
    Delphi is great. Lazarus is more powerfull

  6. #6
    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.

  7. #7
    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

  8. #8
    Quote Originally Posted by luigi View Post
    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
    Dan had het OnCreate gedeelte toch beter geweest als we dit zo schrijven?

    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');
    Het blijft een moeilijk iets die Interfaces. Ik snap het ook niet goed wat voor voordeel ik er aan heb.
    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.

  9. #9
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    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.
    Delphi is great. Lazarus is more powerfull

  10. #10
    Quote Originally Posted by jkuiper View Post
    Dus eigenlijk is een interface een class, die je tussen wilt proppen, maar voor meerdere klas, sen gebruikt kan worden, omdat je een gemeenschappelijke doel hebt.
    Ik vind het wel veel coding, die je moet invoeren.
    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.
    1+1=b

  11. #11
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by GolezTrol View Post
    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

  12. #12
    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

  13. #13
    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.

  14. #14
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    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)

  15. #15
    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.
    1+1=b

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •