none
Restricciones where? RRS feed

  • Pregunta

  • Buenas noches a todos, hoy tengo una duda que tal vés y el título no está muy correcto, pero fue lo que mejor se me ocurrió y de manera corta.

    Me refiero a las restricciones que he visto en uso de genéricos (ya que lo estoy estudiando), donde por ejemplo:

     

    "class Persona<T> where T:IEnumerable", he visto eso, me refiero a la restricción "where", me podrían explicar un poco más sobre el funcionamiento de ésto y si no es mucha molestia, un poco sobre interfaces, ya que tengo entendido que es cuando una clase o varias tienen las mismas o similares funcionalidades, pero no me queda claro el uso total o el gran poder de utilizar interfaces.

     

    Saludos.

    viernes, 18 de febrero de 2011 6:40

Respuestas

  • Imagínate que usas código de alguien que ha definido una interfaz que se llama ICloneable con un método Clone que permite clonar cosas, y luego tiene varias clases que implementan ICloneable (como la clase Oveja por ejemplo).

    Una ventaja de las interfaces es que te permiten hacer lo mismo que con la herencia, es decir tratar un montón de cosas por igual. Si yo quiero clonar algo podría usar ICloneable directamente y me daría igual si es una Oveja o si es otra cosa.

    Pero las interfaces tienen una misión más importante: separar una acción de los detalles de como se lleva a cabo esa acción. Imagínate que sabes que el Clone de Ovejas funciona muy lento, así que decides que para llamar a Clne vas a usar siempre otro hilo. Tu querías clonar algo, pero te has basado en cierta información extra que seguramente no deberías saber para tomar una decisión de diseño. Si luego en el futuro ese método cambia, lo mismo tu decisión de diseño no vale y tienes que cambiarla (o lo mismo otros objetos que implementan ICloneable son rápidos, o dan problemas si se clonan en un hilo diferente del principal,...).

    En cambio si tu lo que tienes para clonar es un ICloneable y no una Oveja, no sabes absolutamente nada de él, ya que no hay código en la interfaz ICloneable. Simplemente sabes que clona, y tu programas en base solamente a ese conocimiento.

    Ese es el poder de las interfaces :) Lo mismo no se entiende el ejemplo, es un poco rebuscado, pero mirando en google te salen un millón de explicaciones.

    Vicente Cartas Espinel - MVP XNA/DirectX

    Twitter - VicenteCartas

    Blog about C# and XNA Development

    Blog about Role Playing Games

    • Marcado como respuesta GermánMC martes, 22 de febrero de 2011 1:22
    viernes, 18 de febrero de 2011 21:25

Todas las respuestas

  • El "Where" del genérico te permite exigir que el "T" cumpla ciertas condiciones. En el ejemplo que has puesto, se obliga a que el tipo T implemente la interfaz IEnumerable. De esta manera, no podrás hacer (por ejemplo) un class Persona<int>, porqeu int no es IEnumerable.

    Gracias a la restricción, dentro de la definición de la clase se puede llamar a ciertos métodos de T que sino no se podrían llamar. Por ejemplo, gracias a que T es IEnumerable, dentro del Parsona<T> se puede hacer lo siguiente:

    T variable = ...;
    foreach (var x in variable) { ... }
    

    Si no tuvieras el "where", la anterior sentencia daría un error de compilación.

     

    viernes, 18 de febrero de 2011 8:24
    Moderador
  • hola


    para aportar algo ams quizas el link del msdn extienda o confirme loa comentado por Alberto

    saludos

    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    viernes, 18 de febrero de 2011 11:57
  • Como dice Alberto, cuando usas un genérico, el compilador no sabe nada de él. Las restricciones con where se utilizan para dar más información al compilador sobre los posibles valores de T, con lo que al programar puedes usar más métodos y expresiones sobre T.

    Otro ejemplo, normalmente no podrías hacer T miT = null porque no sabes si T va a ser una clase (con lo que sí sería válido) o una estructura (con lo que no sería válido). Pero si le pones where T : class, le estás diciendo que T será una clase y la línea anterior ya será correcta.

     

     


    Vicente Cartas Espinel - MVP XNA/DirectX

    Twitter - VicenteCartas

    Blog about C# and XNA Development

    Blog about Role Playing Games

    viernes, 18 de febrero de 2011 12:08
  • Ok, muchas gracias, ya me quedó mucho más claro eso de las restricciones, pero en cuanto al verdadero poder o utilidad de las interfaces, aún no entiendo bien, si entiendo para qué son y eso, pero como para qué se puede utilizar que sería de mucha utilidad o en qué se puediera explotar bien.
    viernes, 18 de febrero de 2011 21:09
  • Imagínate que usas código de alguien que ha definido una interfaz que se llama ICloneable con un método Clone que permite clonar cosas, y luego tiene varias clases que implementan ICloneable (como la clase Oveja por ejemplo).

    Una ventaja de las interfaces es que te permiten hacer lo mismo que con la herencia, es decir tratar un montón de cosas por igual. Si yo quiero clonar algo podría usar ICloneable directamente y me daría igual si es una Oveja o si es otra cosa.

    Pero las interfaces tienen una misión más importante: separar una acción de los detalles de como se lleva a cabo esa acción. Imagínate que sabes que el Clone de Ovejas funciona muy lento, así que decides que para llamar a Clne vas a usar siempre otro hilo. Tu querías clonar algo, pero te has basado en cierta información extra que seguramente no deberías saber para tomar una decisión de diseño. Si luego en el futuro ese método cambia, lo mismo tu decisión de diseño no vale y tienes que cambiarla (o lo mismo otros objetos que implementan ICloneable son rápidos, o dan problemas si se clonan en un hilo diferente del principal,...).

    En cambio si tu lo que tienes para clonar es un ICloneable y no una Oveja, no sabes absolutamente nada de él, ya que no hay código en la interfaz ICloneable. Simplemente sabes que clona, y tu programas en base solamente a ese conocimiento.

    Ese es el poder de las interfaces :) Lo mismo no se entiende el ejemplo, es un poco rebuscado, pero mirando en google te salen un millón de explicaciones.

    Vicente Cartas Espinel - MVP XNA/DirectX

    Twitter - VicenteCartas

    Blog about C# and XNA Development

    Blog about Role Playing Games

    • Marcado como respuesta GermánMC martes, 22 de febrero de 2011 1:22
    viernes, 18 de febrero de 2011 21:25