![]() |
AW: Delphi Prism XE
Zitat:
|
AW: Delphi Prism XE
Gibts dann eigentlich auch eine IDE für Mac OS?
|
AW: Delphi Prism XE
Zitat:
Aber es ist nur ein lokaler Alias. Binde ich jetzt diese Assembly irgendwo anders ein, wird MySecondTypeName dort unbekannt sein. :wink: |
AW: Delphi Prism XE
Zitat:
![]() |
AW: Delphi Prism XE
Und seit heute
![]() |
AW: Delphi Prism XE
Fördert dieses 'duck' nicht schlampige Programmierung? Nach dem Motto: "Ich bin zu faul, es richtig zu machen und nun gibt es auch eine Programmiersprache, die Faulheit unterstützt".
|
AW: Delphi Prism XE
Wie viele andere Language Features muss man auch Duck Typing mit Verstand einsetzen.
Das Beispiel mit dem ToString macht das sehr schön deutlich. Es wird definiert, dass man diese Methode in dem übergebenen Parameter braucht. Natürlich könnte man dieses Interface auch herkömmlich implementieren und für jedes Objekt eine eigene Klasse bauen, ist aber enorm umständlich und nicht unbedingt praktikabel. |
AW: Delphi Prism XE
Ah. Aber wenn irgend jemand später mal die Methode umbenennt oder verändert, klappt das mit dem duck-Zeugs nicht mehr. Ich halte das so ebenso elegant wie typecasting, denn eigentlich ist es ja nix anderes.
Und natürlich muss man alles mit Verstand einsetzen, aber nach der Logik wäre selbst C eine tolle Programmiersprache. |
AW: Delphi Prism XE
Zitat:
Auch bietet sich z.B. Ducktyping an, wenn man die Nutzung fremder Bibliotheken testen will und diese z.B. keine Interfaces definieren. Konkret: Ich definiere mir selber ein Interface das genau so aussieht wie die fremde Komponente, und nutze diese Komponente dann mit dem eigenen Interface mittels Ducktyping. Nun habe ich meinen Code zum einen von der fremden Komponente entkoppelt. Ich habe also eine konkrete Abhängigkeit weniger, was per se mal nicht schlecht ist. Zum anderen habe ich nun eine einfache Möglichkeit die Komponente zu mocken wenn ich meinen Code mit Unit-Tests abdecken will. Die eigentliche Idee hinter Ducktyping in Prism ist aber folgende: Ich will Code für .NET und Java schreiben. Nun definiere ich mir Interfaces gegen EINE der beiden Seiten. z.B. gegen System.IO.Stream in der .NET Welt. Nun kann ich diesen mittels Ducktyping direkt verwenden. Auf der Java-Seite wrappe ich nun das Java-Stream Objekt so, dass es mein Interface erfüllt. Oder andersrum. Auf jeden Fall spare ich mir auf einer der beiden Plattformen das wrappen, und das mit einer sauberen Lösung, da Typsicher. |
AW: Delphi Prism XE
Wie jedes gute Werkzeug: In den falschen Händen ist es nicht zu gebrauchen. In den richtigen Händen jedoch ziemlich mächtig.
Ich habe verstanden. :) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz