Definition und Implementierung von statischem Polymorphismus [closed]
Lesezeit: 4 Minuten
Ich habe einige Fragen zum Konzept von statischer Polymorphismus Ich höre manchmal davon; Sie können sie hauptsächlich im Kontext von C ++ interpretieren, aber ich würde mich über sprachunabhängige Antworten freuen, sofern zutreffend (daher sowohl C++ als auch sprachunabhängig markieren).
Wie machen wir definieren statischer Polymorphismus im Allgemeinen? Als Beispiel glaube ich, dass die std::sort Die Funktion von C++ sollte als statisch polymorph angesehen werden, da sie von einer Schnittstelle abhängt, die von einigen Objekten bereitgestellt wird verhalten sich wie Iteratorenund das genaues Verhalten unter der Schnittstelle bereitgestellter Iteratoren kann in der Kompilierzeit bestimmt werden. Ist diese Erklärung, wie wir statischen Polymorphismus definieren, oder ist es nur eine Beschreibung eines bestimmten Falls und es steckt mehr dahinter?
Was sind die gängigen Codemuster? der Verwendung von statischem Polymorphismus in C++? Außerdem: Ist SP nur erreicht über Vorlagen in C++?
Ist es wahr dass ein bestimmtes UML-Klassendiagramm nicht direkt beschreiben, wie Polymorphismus gehandhabt wird und somit zumindest teilweise entweder statisch oder dynamisch implementiert werden kann? Mit anderen Worten: Ist die Wahl zwischen statischem und dynamischem Polymorphismus unabhängig vom OOP-Modell und somit Sache des Implementierers?
Ist statischer Polymorphismus nur C++-spezifisch und im Zusammenhang mit der Funktionsweise von Vorlagen? Wenn nicht, ist es in einem anderen vorhanden Mainstream-Sprachen außer C++? Können wir ein Äquivalent zum statischen Polymorphismus in Java, C# … irgendetwas haben, und wird es irgendwelche Vorteile bringen?
Das wichtigste… Was sind die tatsächlichen Vorteile der Verwendung von statischem Polymorphismus? Ich denke, wir können uns darauf einigen, dass es die Flexibilität des Codes verringert; Was sind die Vorteile, außer – im Fall von C++ – das Einsparen einer Zeigerdereferenzierung (virtuelle Funktion / Zeiger auf Funktion / Delegatkosten)? Was ist der Klasse von Problemen wo statischer Polymorphismus besonders nützlich ist, die richtige Wahl für die Implementierung?
Wir sind uns einig, dass es die Flexibilität des Codes verringert?
– Edward Seltsam
29. Dezember 2010 um 19:30 Uhr
Ich denke, er meinte “Komplexität” oder möglicherweise “Redundanz”.
– Zac Howland
29. Dezember 2010 um 19:33 Uhr
Nein, ich meinte Flexibilität; Unter der Annahme, dass alle Designs mit statischem Polymorphismus mit dynamischem Polymorphismus implementiert werden können, aber nicht umgekehrt, bedeutet die Verwendung von statischem Polymorphismus für einen bestimmten Fall, dass in Zukunft die Notwendigkeit entstehen könnte, ihn dynamisch umzuschreiben, wenn sich die Anforderungen ändern. Nur mein Denken
– Kos
29. Dezember 2010 um 21:24 Uhr
aber es funktioniert auch in die andere Richtung: Sie müssen möglicherweise auch in die andere Richtung gehen (z. B. um Typinformationen beizubehalten). Ich denke, die meisten Leute würden darüber nachdenken std::vector<T> flexibler als ein Java-ähnlicher Vektor von einigen allgemeinen und nutzlosen Object Basisklasse.
– jalf
29. Dezember 2010 um 23:56 Uhr
Statisches polymorphes Verhalten ist Typ Polymorphismus Dies geschieht zur Kompilierzeit und nicht zur Laufzeit.
Jawohl.
Bei UML geht es darum, wie Klassen zur Laufzeit interagieren – ich glaube nicht, dass es ein UML-Format zur Beschreibung von Vorlagen gibt, aber ich könnte mich irren.
Soweit mir bekannt ist, ist es C++ spezifisch, aber ich bin nicht sicher, da ich nicht jede Sprache verwendet habe, die jemals erfunden wurde. 🙂 Allerdings sind JIT-Sprachen wie C# und Java oft sehr gut darin, die Auswirkungen indirekter Aufrufe auf die Leistung zu beseitigen, in einigen Fällen mithilfe von Informationen, die zur Laufzeit und nicht zur Kompilierzeit gesammelt werden. Ob dies zur Kompilierzeit ist oder nicht, ist jedoch in der Luft … schließlich heißt es Just-In-Time Compiler.
Der Hauptvorteil ist einfach die Leistung. Laufzeitpolymorphismus kann alles tun, was statischer Polymorphismus tun kann (tatsächlich kann er mehr), aber er trägt die Kosten indirekter Aufrufe (die teuer sein können, wenn es genug davon gibt).
Nun, Vorlagen selbst haben viele Verwendungen, die über das Erreichen von Polymorphismus zur Kompilierzeit hinausgehen – zum Beispiel die SFINAE-Magie, die macht boost::bind Arbeit ist sicherlich nicht polymorph – sie ist lediglich dazu da, Inkonsistenzen in der Sprache selbst auszugleichen.
“2. Ja.” Was ist mit Funktionsüberladung?
– CB Bailey
29. Dezember 2010 um 19:48 Uhr
@Charles: Ich habe noch nie jemanden gehört, der “statischen Polymorphismus” überladen hat (obwohl ich denke, dass es passt).
– Billy ONeal
29. Dezember 2010 um 19:51 Uhr
Es hängt natürlich davon ab, wie Sie antworten (1).
– CB Bailey
29. Dezember 2010 um 19:53 Uhr
@Charles: Nun, in 1 habe ich aus genau diesem Grund ausdrücklich nur “Typpolymorphismus” gesagt (und nicht den allgemeinen Fall).
– Billy ONeal
29. Dezember 2010 um 19:54 Uhr
Nawaz
Wie definieren wir statischen Polymorphismus im Allgemeinen?
Am besten versteht man es anhand von Beispielen. Richtlinienbasiertes Design ist ein Beispiel für statischen Polymorphismus. Und meiner Meinung nach ist es eine sehr leistungsfähige Technik, um einen statischen Polymorphismus zu erreichen.
Wir sind uns einig, dass es die Flexibilität des Codes verringert?
– Edward Seltsam
29. Dezember 2010 um 19:30 Uhr
Ich denke, er meinte “Komplexität” oder möglicherweise “Redundanz”.
– Zac Howland
29. Dezember 2010 um 19:33 Uhr
Nein, ich meinte Flexibilität; Unter der Annahme, dass alle Designs mit statischem Polymorphismus mit dynamischem Polymorphismus implementiert werden können, aber nicht umgekehrt, bedeutet die Verwendung von statischem Polymorphismus für einen bestimmten Fall, dass in Zukunft die Notwendigkeit entstehen könnte, ihn dynamisch umzuschreiben, wenn sich die Anforderungen ändern. Nur mein Denken
– Kos
29. Dezember 2010 um 21:24 Uhr
aber es funktioniert auch in die andere Richtung: Sie müssen möglicherweise auch in die andere Richtung gehen (z. B. um Typinformationen beizubehalten). Ich denke, die meisten Leute würden darüber nachdenken
std::vector<T>
flexibler als ein Java-ähnlicher Vektor von einigen allgemeinen und nutzlosenObject
Basisklasse.– jalf
29. Dezember 2010 um 23:56 Uhr