Page 2 of 2 FirstFirst 1 2
Results 16 to 20 of 20

Thread: Gratis E-Book van GDKSoftware

  1. #16
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,329
    Die typesafety (van GDK) leek mij dat als een object je meerdere interfaces implementeert, je dan de business code die een aspect daarvan gebruikt (TCEO in het voorbeeld) geheel kan uitdrukken in dat aspect ipv de het hele object.

    Maar refcounting disablen in tcomponent afgeleiden als TForm (nieuw voor mij Overigens). Wel logisch natuurlijk, omdat het stukje VCL en form initializatie in de .dpr van voor de introductie van interfaces stamt. Let wel, de overhead is er nog steeds, want de method calls worden dan gegeneerd. Ik dacht dat ze dat hadden aangepast.

    Ik dacht dat de overhead nu ook uit te schakelen was (Alexandria, of die ervoor). Als dat alleen kan door bergen foeilelijke [weak]'s rond te strooien, dan valt dat tegen.

    Refcounting is primair wat ik tegen interface gebruik hebt, want het maakt het een alles of niets beslissing die ik doorgaans de moeite niet waard vindt. Als de refcounting niet bestaat, kan je delen van je programma (businesscode) in interfaces uitdrukken zonder de rest te beïnvloeden. Zoals je dat bij Java kan, zonder er over na te denken.


    Als je een classe hebt met meerdere interfaces, hoe krijg je die dan in een nette manier?

    Dus als je

    izoogdier :=TKoe.create;

    en dan van izoogdier proberen IEierleggend te verkrijgen voor het geval je een vogelbekdier hebt. Als er geen relatie tussen de interfaces is, dan moet dat toch over de originele classe.

    Hack manieren met zelf refcount increasen, componentreference enz ken ik wel, maar hoe doe je dit netjes voor je businesscode in de praktijk?

  2. #17
    > Zoals je dat bij Java kan, zonder er over na te denken.

    Ik kom maar zelden situaties tegen waarin die overhead een issue is, en als dat zo is, gaat het meestal om grote hoeveelheden data-dragers met weinig logica. Die kan je inderdaad prima als class gebruiken, of desnoods als record.

    Maar bij Java hoef je je objecten überhaupt niet vrij te geven, toch? Geen idee of daar ARC of een andere manier van garbage collection achter zit, maar er is in ieder geval een systeem, dus kosten voor tracking heb je dan toch sowieso?

    > izoogdier :=TKoe.create;
    > en dan van izoogdier proberen IEierleggend te verkrijgen voor het geval je een vogelbekdier hebt. Als er geen relatie tussen de interfaces is, dan moet dat toch over de originele classe.

    Dat kan via de interface. De `supports` functie, en de `as` typecast gebruiken achter de schermen de `QueryInterface` method. Je hoeft dus niet eerst de originele class te achterhalen.

    Daarbij kan je volgens mij ook nog hele interfaces delegeren aan een sub-object. Je zou dus een TVogelbekdier kunnen maken die vrijwel geen logica bevat, maar die alleen IZoogdier en IEierleggend implementeert, en die simpelweg doorsluist naar een TEierleggend waar hij een referentie naar heeft.
    1+1=b

  3. #18
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,329
    Quote Originally Posted by GolezTrol View Post
    >
    Maar bij Java hoef je je objecten überhaupt niet vrij te geven, toch? Geen idee of daar ARC of een andere manier van garbage collection achter zit, maar er is in ieder geval een systeem, dus kosten voor tracking heb je dan toch sowieso?
    (Java en .NET gebruiken generationele movable Boehm GCs. Generationeel zorgt voor goedkope allocatie/deallocatie van kortlevende objecten, movable zorgt dat allocaties verplaatst kunnen worden en langer levende objecten bij elkaar gezet kunnen worden voor efficiënter beheer)

    Mijn Java referentie ging meer het gedachteloos door elkaar gebruiken dan performance. Geen gedoe met een root zoeken die ref counting disabled etc. Geen klasses in de libraries die je dan niet kan gebruiken e.d.

    En bij Java is GC de norm, bij delphi niet. Interfaces zijn reference counted vanwege COM, niet omdat dat op taal niveau zo'n goed idee is.

    Dat kan via de interface. De `supports` functie, en de `as` typecast gebruiken achter de schermen de `QueryInterface` method. Je hoeft dus niet eerst de originele class te achterhalen.
    Ok, ik dacht dat AS alleen werkte voor van elkaar afgeleide interfaces.

    Daarbij kan je volgens mij ook nog hele interfaces delegeren aan een sub-object. Je zou dus een TVogelbekdier kunnen maken die vrijwel geen logica bevat, maar die alleen IZoogdier en IEierleggend implementeert, en die simpelweg doorsluist naar een TEierleggend waar hij een referentie naar heeft.
    Delegatie met "Implements" ja. Je kan overigens ook bestaande methods gebruiken om een interface te implementeren waar je pas later van erft. (met = iinterface.method achter de method declaratie geloof ik)

    --------

    Wat betreft performance kan je wel gelijk hebben. Sommige van mijn panische neigingen zijn gebaseerd op oude ervaring. Al mijn ervaring (toen ik relatief complexe business code had) is uit Pentium 3/4 tijden en vaak met multi CPU systemen (pre multi core).

    Behalve dat systemen sowieso sneller zijn, zijn synchronisatie primitieven ook nog relatief goedkoper geworden, zowel op RTL/OS niveau (TMonitor spinlocks voor de scheduler primtiieven, maar ik geloof dat Vista dat zelf ook al doet) als hardware matig (HT/QPI SMP implementaties en uncore)

  4. #19
    Maar met zo veel dingen, is het ook een kwestie van proberen. Het voelt soms een beetje onwennig, wanneer gebruik je het en wanneer niet. Wat is nou echt het verschil tussen een interface en een abstract baseclass...
    Soms moet je het gewoon een poosje proberen toe te passen om te kijken wat werkt en wat niet.

    Dependency injection en unit testing zijn overigens twee onderwerpen die de boventoon voeren in de boeken van Nick Hodges. Als je daar geen brood in ziet, dan is de stelling 'altijd tegen interfaces programmeren' misschien wel heel strict.

    En daarbij, een 'interface' is een concrete implementatie van een idee. In algemene zin is een interface een contract, een afspraak, van hoe iets zal werken. In zekere zin is een abstract base class, of zelfs een callback procedure zoals een TNotifyEvent, ook een soort interface. Je kan dus best programmeren tegen een 'interface' in talen die niet eens interfaces implementeren.
    1+1=b

  5. #20
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,329
    Ik heb toch wel in totaal een jaartje of 2-3 Java en C# gedaan, dus ik weet wat een interface is :-) Aan de Java kant zelfs een semester Corba (waar interfaces shims zijn voor objecten in een ander proces/machine).

    Mijn interesse voor mijn dagelijks werk is meer voor beperkt gebruik om oplossingen te vinden om bepaalde objecten op te breken. Ik heb een vrij netjes framework, met alles keurig in objecten, met alleen hopeloze centrale classes, wat je niet eens god-classes kan noemen. Het zijn meer Archgod classes. Aan de ene kant kan me dat niet zoveel schelen (het zijn met name de applicatie specifieke controllers die initializatie en wat hoofd verbindende logica doen, niet echt reduceerbaar). Aan de andere kant, alle beetjes overzicht helpen.

    Het andere aspect is feeling houden met meer recht toe rechtaan IT., en ook in de meer OOP delen van de FPC libraries komt meer en meer unittesting voor gebaseerd op dunit derivaten.

Page 2 of 2 FirstFirst 1 2

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
  •