Definición e implementación de polymorphism estático

Tengo algunas preguntas sobre el concepto de polymorphism estático que escucho a veces ; puede interpretarlos principalmente en el contexto de C ++, pero apreciaría las respuestas independientes del idioma cuando corresponda (de ahí que etiquete tanto C ++ como el lenguaje independiente ).

  1. ¿Cómo definimos el polymorphism estático en general? Como ejemplo, creo que la función std::sort de C ++ se considerará estáticamente polimórfica ya que depende de alguna interfaz proporcionada por algunos objetos que se comportan como iteradores , y el comportamiento exacto bajo la interfaz de los iteradores proporcionados se puede determinar en el tiempo de comstackción. ¿Es esta explicación cómo definimos el polymorphism estático, o es solo una descripción de un caso específico y hay más que eso?

  2. ¿Cuáles son los patrones de código comunes para usar polymorphism estático en C ++? Además: ¿SP solo se logra a través de plantillas en C ++?

  3. ¿Es cierto que un diagtwig de clase UML dado no describe directamente cómo se maneja el polymorphism y, por lo tanto, se puede implementar al menos parcialmente de forma estática o dinámica? En otras palabras: ¿la elección del polymorphism estático frente al dynamic es independiente del modelo OOP y, por lo tanto, depende del implementador decidir?

  4. ¿El polymorphism estático solo es específico de C ++ y está relacionado con el funcionamiento de las plantillas? Si no, ¿está presente en otros lenguajes principales además de C ++? ¿Podemos tener un equivalente de polymorphism estático en Java, C # … cualquier cosa, y traerá algún beneficio?

  5. Lo más importante … ¿Cuáles son los beneficios reales del uso de polymorphism estático? Creo que podemos estar de acuerdo en que reduce la flexibilidad del código; ¿Cuáles son las ventajas, además, en el caso de C ++, de salvar una referencia de referencia (función virtual / puntero a función / costo de delegado)? ¿Cuál es la clase de problemas donde el polymorphism estático es especialmente útil, la elección correcta para la implementación?

  1. El comportamiento polimórfico estático es un tipo de polymorphism que se produce en tiempo de comstackción en lugar de tiempo de ejecución.
  2. Sí.
  3. UML trata sobre cómo las clases interactúan en tiempo de ejecución. No creo que haya un formato UML para describir plantillas, pero podría estar equivocado.
  4. Por lo que sé, es específico de C ++, pero no estoy seguro dado que no he usado todos los lenguajes que se hayan inventado. 🙂 Dicho esto, los lenguajes JIT como C # y Java a menudo son muy buenos para eliminar el impacto en el rendimiento de las llamadas indirectas en algunos casos al usar información obtenida en tiempo de ejecución en lugar de en tiempo de comstackción. Si esto está en tiempo de comstackción o no está algo en el air … después de todo, se llama comstackdor Just-In-Time.
  5. El principal beneficio es simplemente el rendimiento. El polymorphism en tiempo de ejecución puede hacer todo lo que el polymorphism estático puede hacer (de hecho, puede hacer más), pero conlleva el costo de las llamadas indirectas (que puede ser costoso si hay suficiente de ellos)

Ahora, las plantillas en sí mismas tienen muchos usos más allá de lograr el polymorphism en tiempo de comstackción, por ejemplo, la magia SFINAE que hace que el trabajo boost::bind no sea polimórfico, simplemente está ahí para suavizar inconsistencias en el lenguaje en sí.

¿Cómo definimos el polymorphism estático en general?

La mejor manera de entenderlo usando ejemplos. El diseño basado en políticas es un ejemplo de polymorphism estático. Y en mi opinión, es una técnica muy poderosa para lograr el polymorphism estático.

Otro ejemplo es el patrón de plantilla curiosamente recurrente (CRTP) que también es una técnica poderosa.

  1. No. Además de plantillas, el método de desarrollo también es polymorphism estático. https://en.wikipedia.org/wiki/Function_overloading