none
Diferencias entre Interfaces y Clases Abstractas. Y un ejemplo RRS feed

  • Pregunta

  • Hola, por mas que leo en internet lo sigo viendo igual... Me pueden explicar de manera sencilla las diferencias entre interfaces y clases abstractas y cuando debo usar una u otra... Tambien por favor un ejemplo de cada una de ellas.

    Gracias

    jueves, 21 de marzo de 2013 19:59

Respuestas

  • En general, las clases abstractas y las interfaces se pueden usar para las mismas cosas, por eso te parecen iguales. Hay algunas diferencias importantes:

    - Las clases abstractas pueden contener código, mientras que las interfaces no. Aunque los métodos extensionales te permiten "hacer trampas" en este tema.

    - Una clase solo puede heredar de otra clase, mientras que puede implementar todas las interfaces que quiera. Normalmente una interfaz representa una funcionalidad que puede ser simplemente una parte de todo lo que hace un objeto. Por ejemplo, en una List<T> puedes añadir objetos, quitar objetos, acceder a los objetos... pero la interfaz IEnumerable representa un concepto más concreto y específico: algo que se puede recorrer. Puede ser un List, un Tree, o a saber. Las clases abstractas normalmente suelen estar un poco más relacionadas con las clases que las heredan que una interfaz (pero esto es un poco conceptual en el fondo).

    - Es posible versionar una clase abstracta sin romper a otras clases que las implementen, pero no es posible hacer lo mismo con una interfaz. Es decir, si tu tienes una clase abstracta, y le añades un método normal y corriente, las clases que heredan de esa clase abstracta siguen compilando (a menos que tengan un método que se llama igual). Si tu a una interfaz le añades un método, todas las clases que implementan esa interfaz dejarán de compilar porque no implementan ese método. Esto es algo importante si estás escribiendo librerías que usarán terceros. 

    Un ejemplo típico de este último punto es Linq y porque Linq se implementó usando métodos extensionales. Si Linq se hubiera implementado extendiendo la interfaz IEnumerable, todo el código que existía ya que usaba IEnumerable habría dejado de compilar, y encima toda la gente que utilizara IEnumerable tendría que implementar todos los métodos nuevos (y hay muchísimos métodos en Linq). Usando métodos extensionales la gente de .NET se evitó un breaking change (romper código ya existente) y además no obligó a la gente a implementar esos operadores por si mismos.

    Un saludo!


    Vicente Cartas Espinel - MVP XNA/DirectX

    Blog about C# and XNA Development

    Blog about Role Playing Games

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:13
    sábado, 23 de marzo de 2013 5:55
  • Agrego algo más de teoría a ver si te sirve:

    Todo esto de las Clases Abstractas e Interfaces está pensado no tanto para que lo arme el programador si no el Diseñador de la aplicación o el Arquitecto del sistema.

    Cuando uno trabaja en una empresa de Software Factory, es común tener un equipo de analistas, analistas de diseño, arquitectos de sistemas, etc.

    En dónde van definiendo las diferentes capas del soft o sistema o la solución a desarrollar.

    Es común que un equipo esté diseñando la capa de datos y/o el modelo de Entidad/Relación de la misma una vez que el equipo de Analistas Funcionales tengan todas las clases y algunos diagramas más o menos armados. O si no es un gran equipo, al menos ir definiendo por módulos el sistema y cada módulo va llevando a un conjunto de Clases iniciales (que pueden llegar o no hasta el final del desarrollo) y si es una aplicación con base de datos, ir definiendo la capa de datos.

    Entonces uno ya va teniendo la capa de Base de Datos. Bien, ahora es el turno de la Capa de Negocio, ahí es dónde uno va armando las Clases y las Clases Manager que son las que se relacionan con la Base de Datos. Ejemplo: clsAlumno (Es la Clase Alumno) y clsAlumnoDB o clsAlumnoManager (Es la clase que relaciona la clase alumno con la base de datos)

    Ahora bien, uno puede definir que el sistema va a trabajar solamente con Access, o SQL SERVER o con MySQL o la base de datos que se te antoje.

    O, uno arma la Clase clsAlumnoManager con métodos para diferentes bases de datos. El método conexión a Oracle, el método conexión a MySQL etc.

    Pero si yo le entrego acceso al programador de la capa CLIENTE TODA la CLASE clsAlumnoManager, es probable que se vuelva loco buscando cual es el método que mejor le conviene usar. Entonces es ahí donde mejor entran las Interfaces y creo la iAlumnoDbOracle dónde le da visibilidad sólo a los métodos para la base de datos ORACLE. Creo la iAlumnoDbSQL para SQL SERVER, etc.

    Ahora el programador de la capa cliente puede encontrar mejor los métodos que se ajusten a la base de datos que quiere trabajar desde la capa de negocio.

    En cuanto a una clase abstracta. Generalmente se utilizan para dar una extensibilidad a la capa de negocios. Uno puede definir una clase abstracta clsAlumnosExport como abstracta. Se puede definir que hereda de clsAlumnoManager pero definiendo a sus métodos como abstractos para dejar que el programador de la capa cliente decida de que forma quiere que se exporten los Alumnos. Entonces como es una clase Abstracta de otra clase existente, yo voy a tener a mi disposición sus propiedades, no así los métodos. En si, si voy a tener los nombres de los métodos que quiero que el programador de la capa Cliente, vea que deberá codificar.

    Bueno, espero no haberme extendido demasiado y no haberme embarullado.


    Robbie Bozzacchi ----------------

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:13
    sábado, 23 de marzo de 2013 3:17
  • si solo pones eso si, pero tambien podrias hacer

    abstract class ShapesClass {
    
       protected x, y;
    
       protected void Draw(){
    
           //aqui codigo
    
        } 
    
      abstract public int Area(); 
    
    }


    class Square : ShapesClass { 
    
        public override int Area() {
    
            base.Draw(); 
            return x * y; 
        } 
    
    }

    y esto con las interfaces no puedea hacerlo

    o sea si lo limitas a un ejemplo minimo seguro se parecen, pero debes extender un poco mas para ver la utilidad

    saludos



    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:18
    viernes, 22 de marzo de 2013 20:33

Todas las respuestas

  • hola

    las interfaces solo definenel contrato

    interface (Referencia de C#)

    las clase abstractas contienen codigo, pero no puede instanciarse, requiere que una clase las herede

    abstract (Referencia de C#)

    Abstract and Sealed Classes and Class Members (C# Programming Guide)

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    jueves, 21 de marzo de 2013 20:22
  • hola

    las interfaces solo definenel contrato

    interface (Referencia de C#)

    las clase abstractas contienen codigo, pero no puede instanciarse, requiere que una clase las herede

    abstract (Referencia de C#)

    Abstract and Sealed Classes and Class Members (C# Programming Guide)

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    Hola

    Segun el ejemplo de la pagina que me das

    abstract class ShapesClass { abstract public int Area(); } class Square : ShapesClass { int x, y; // Not providing an Area method results // in a compile-time error. public override int Area() { return x * y; } }

    Veo exactamente como una interface... Si hago esto, seria lo mismo...

    interface ShapesClass { int Area(); } class Square : ShapesClass { int x, y; public int Area() { return x * y; } }

    Osea asi no sea el concepto el metodo Area en la clase abstrasta es como un contrato...

    viernes, 22 de marzo de 2013 20:21
  • si solo pones eso si, pero tambien podrias hacer

    abstract class ShapesClass {
    
       protected x, y;
    
       protected void Draw(){
    
           //aqui codigo
    
        } 
    
      abstract public int Area(); 
    
    }


    class Square : ShapesClass { 
    
        public override int Area() {
    
            base.Draw(); 
            return x * y; 
        } 
    
    }

    y esto con las interfaces no puedea hacerlo

    o sea si lo limitas a un ejemplo minimo seguro se parecen, pero debes extender un poco mas para ver la utilidad

    saludos



    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:18
    viernes, 22 de marzo de 2013 20:33
  • si solo pones eso si, pero tambien podrias hacer

    abstract class ShapesClass {
    
       protected x, y;
    
       protected void Draw(){
    
           //aqui codigo
    
        } 
    
      abstract public int Area(); 
    
    }


    class Square : ShapesClass { 
    
        public override int Area() {
    
            base.Draw(); 
            return x * y; 
        } 
    
    }

    y esto con las interfaces no puedea hacerlo

    o sea si lo limitas a un ejemplo minimo seguro se parecen, pero debes extender un poco mas para ver la utilidad

    saludos



    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    Ah ok, osea es como una mezcla entre una interface y una clase normal "con la limitante de no poder instanciarse"... Ahora si creo que entiendo la cosa, osea a diferencia de una interface los metodos de las clases abstractas pueden contener o no implementaciones...
    viernes, 22 de marzo de 2013 20:40
  • Tengo otra pregunta, aunque no se si va dentro del tema... En tu ejemplo colocaste:

    public override int Area() {
    
            base.Draw(); 
            return x * y; 
        } 

    Que significa esa palabra "base"...

    base.Draw();

    • Editado Zr-.- viernes, 22 de marzo de 2013 20:51
    viernes, 22 de marzo de 2013 20:51
  • hace referencia a la clase de la cula se hereda en este caso ShapesClass

    si haces referencia a this hace referencia  la instancia en la cual te encuentras

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina

    viernes, 22 de marzo de 2013 21:14
  • Agrego algo más de teoría a ver si te sirve:

    Todo esto de las Clases Abstractas e Interfaces está pensado no tanto para que lo arme el programador si no el Diseñador de la aplicación o el Arquitecto del sistema.

    Cuando uno trabaja en una empresa de Software Factory, es común tener un equipo de analistas, analistas de diseño, arquitectos de sistemas, etc.

    En dónde van definiendo las diferentes capas del soft o sistema o la solución a desarrollar.

    Es común que un equipo esté diseñando la capa de datos y/o el modelo de Entidad/Relación de la misma una vez que el equipo de Analistas Funcionales tengan todas las clases y algunos diagramas más o menos armados. O si no es un gran equipo, al menos ir definiendo por módulos el sistema y cada módulo va llevando a un conjunto de Clases iniciales (que pueden llegar o no hasta el final del desarrollo) y si es una aplicación con base de datos, ir definiendo la capa de datos.

    Entonces uno ya va teniendo la capa de Base de Datos. Bien, ahora es el turno de la Capa de Negocio, ahí es dónde uno va armando las Clases y las Clases Manager que son las que se relacionan con la Base de Datos. Ejemplo: clsAlumno (Es la Clase Alumno) y clsAlumnoDB o clsAlumnoManager (Es la clase que relaciona la clase alumno con la base de datos)

    Ahora bien, uno puede definir que el sistema va a trabajar solamente con Access, o SQL SERVER o con MySQL o la base de datos que se te antoje.

    O, uno arma la Clase clsAlumnoManager con métodos para diferentes bases de datos. El método conexión a Oracle, el método conexión a MySQL etc.

    Pero si yo le entrego acceso al programador de la capa CLIENTE TODA la CLASE clsAlumnoManager, es probable que se vuelva loco buscando cual es el método que mejor le conviene usar. Entonces es ahí donde mejor entran las Interfaces y creo la iAlumnoDbOracle dónde le da visibilidad sólo a los métodos para la base de datos ORACLE. Creo la iAlumnoDbSQL para SQL SERVER, etc.

    Ahora el programador de la capa cliente puede encontrar mejor los métodos que se ajusten a la base de datos que quiere trabajar desde la capa de negocio.

    En cuanto a una clase abstracta. Generalmente se utilizan para dar una extensibilidad a la capa de negocios. Uno puede definir una clase abstracta clsAlumnosExport como abstracta. Se puede definir que hereda de clsAlumnoManager pero definiendo a sus métodos como abstractos para dejar que el programador de la capa cliente decida de que forma quiere que se exporten los Alumnos. Entonces como es una clase Abstracta de otra clase existente, yo voy a tener a mi disposición sus propiedades, no así los métodos. En si, si voy a tener los nombres de los métodos que quiero que el programador de la capa Cliente, vea que deberá codificar.

    Bueno, espero no haberme extendido demasiado y no haberme embarullado.


    Robbie Bozzacchi ----------------

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:13
    sábado, 23 de marzo de 2013 3:17
  • En general, las clases abstractas y las interfaces se pueden usar para las mismas cosas, por eso te parecen iguales. Hay algunas diferencias importantes:

    - Las clases abstractas pueden contener código, mientras que las interfaces no. Aunque los métodos extensionales te permiten "hacer trampas" en este tema.

    - Una clase solo puede heredar de otra clase, mientras que puede implementar todas las interfaces que quiera. Normalmente una interfaz representa una funcionalidad que puede ser simplemente una parte de todo lo que hace un objeto. Por ejemplo, en una List<T> puedes añadir objetos, quitar objetos, acceder a los objetos... pero la interfaz IEnumerable representa un concepto más concreto y específico: algo que se puede recorrer. Puede ser un List, un Tree, o a saber. Las clases abstractas normalmente suelen estar un poco más relacionadas con las clases que las heredan que una interfaz (pero esto es un poco conceptual en el fondo).

    - Es posible versionar una clase abstracta sin romper a otras clases que las implementen, pero no es posible hacer lo mismo con una interfaz. Es decir, si tu tienes una clase abstracta, y le añades un método normal y corriente, las clases que heredan de esa clase abstracta siguen compilando (a menos que tengan un método que se llama igual). Si tu a una interfaz le añades un método, todas las clases que implementan esa interfaz dejarán de compilar porque no implementan ese método. Esto es algo importante si estás escribiendo librerías que usarán terceros. 

    Un ejemplo típico de este último punto es Linq y porque Linq se implementó usando métodos extensionales. Si Linq se hubiera implementado extendiendo la interfaz IEnumerable, todo el código que existía ya que usaba IEnumerable habría dejado de compilar, y encima toda la gente que utilizara IEnumerable tendría que implementar todos los métodos nuevos (y hay muchísimos métodos en Linq). Usando métodos extensionales la gente de .NET se evitó un breaking change (romper código ya existente) y además no obligó a la gente a implementar esos operadores por si mismos.

    Un saludo!


    Vicente Cartas Espinel - MVP XNA/DirectX

    Blog about C# and XNA Development

    Blog about Role Playing Games

    • Marcado como respuesta Zr-.- miércoles, 27 de marzo de 2013 15:13
    sábado, 23 de marzo de 2013 5:55
  • hola

    las interfaces solo definenel contrato

    interface (Referencia de C#)

    las clase abstractas contienen codigo, pero no puede instanciarse, requiere que una clase las herede

    abstract (Referencia de C#)

    Abstract and Sealed Classes and Class Members (C# Programming Guide)

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina



    Hola, gracias...
    miércoles, 27 de marzo de 2013 15:10
  • Agrego algo más de teoría a ver si te sirve:

    Todo esto de las Clases Abstractas e Interfaces está pensado no tanto para que lo arme el programador si no el Diseñador de la aplicación o el Arquitecto del sistema.

    Cuando uno trabaja en una empresa de Software Factory, es común tener un equipo de analistas, analistas de diseño, arquitectos de sistemas, etc.

    En dónde van definiendo las diferentes capas del soft o sistema o la solución a desarrollar.

    Es común que un equipo esté diseñando la capa de datos y/o el modelo de Entidad/Relación de la misma una vez que el equipo de Analistas Funcionales tengan todas las clases y algunos diagramas más o menos armados. O si no es un gran equipo, al menos ir definiendo por módulos el sistema y cada módulo va llevando a un conjunto de Clases iniciales (que pueden llegar o no hasta el final del desarrollo) y si es una aplicación con base de datos, ir definiendo la capa de datos.

    Entonces uno ya va teniendo la capa de Base de Datos. Bien, ahora es el turno de la Capa de Negocio, ahí es dónde uno va armando las Clases y las Clases Manager que son las que se relacionan con la Base de Datos. Ejemplo: clsAlumno (Es la Clase Alumno) y clsAlumnoDB o clsAlumnoManager (Es la clase que relaciona la clase alumno con la base de datos)

    Ahora bien, uno puede definir que el sistema va a trabajar solamente con Access, o SQL SERVER o con MySQL o la base de datos que se te antoje.

    O, uno arma la Clase clsAlumnoManager con métodos para diferentes bases de datos. El método conexión a Oracle, el método conexión a MySQL etc.

    Pero si yo le entrego acceso al programador de la capa CLIENTE TODA la CLASE clsAlumnoManager, es probable que se vuelva loco buscando cual es el método que mejor le conviene usar. Entonces es ahí donde mejor entran las Interfaces y creo la iAlumnoDbOracle dónde le da visibilidad sólo a los métodos para la base de datos ORACLE. Creo la iAlumnoDbSQL para SQL SERVER, etc.

    Ahora el programador de la capa cliente puede encontrar mejor los métodos que se ajusten a la base de datos que quiere trabajar desde la capa de negocio.

    En cuanto a una clase abstracta. Generalmente se utilizan para dar una extensibilidad a la capa de negocios. Uno puede definir una clase abstracta clsAlumnosExport como abstracta. Se puede definir que hereda de clsAlumnoManager pero definiendo a sus métodos como abstractos para dejar que el programador de la capa cliente decida de que forma quiere que se exporten los Alumnos. Entonces como es una clase Abstracta de otra clase existente, yo voy a tener a mi disposición sus propiedades, no así los métodos. En si, si voy a tener los nombres de los métodos que quiero que el programador de la capa Cliente, vea que deberá codificar.

    Bueno, espero no haberme extendido demasiado y no haberme embarullado.


    Robbie Bozzacchi ----------------

    Excelente explicación, muy agradecido!!!
    miércoles, 27 de marzo de 2013 15:12
  • En general, las clases abstractas y las interfaces se pueden usar para las mismas cosas, por eso te parecen iguales. Hay algunas diferencias importantes:

    - Las clases abstractas pueden contener código, mientras que las interfaces no. Aunque los métodos extensionales te permiten "hacer trampas" en este tema.

    - Una clase solo puede heredar de otra clase, mientras que puede implementar todas las interfaces que quiera. Normalmente una interfaz representa una funcionalidad que puede ser simplemente una parte de todo lo que hace un objeto. Por ejemplo, en una List<T> puedes añadir objetos, quitar objetos, acceder a los objetos... pero la interfaz IEnumerable representa un concepto más concreto y específico: algo que se puede recorrer. Puede ser un List, un Tree, o a saber. Las clases abstractas normalmente suelen estar un poco más relacionadas con las clases que las heredan que una interfaz (pero esto es un poco conceptual en el fondo).

    - Es posible versionar una clase abstracta sin romper a otras clases que las implementen, pero no es posible hacer lo mismo con una interfaz. Es decir, si tu tienes una clase abstracta, y le añades un método normal y corriente, las clases que heredan de esa clase abstracta siguen compilando (a menos que tengan un método que se llama igual). Si tu a una interfaz le añades un método, todas las clases que implementan esa interfaz dejarán de compilar porque no implementan ese método. Esto es algo importante si estás escribiendo librerías que usarán terceros. 

    Un ejemplo típico de este último punto es Linq y porque Linq se implementó usando métodos extensionales. Si Linq se hubiera implementado extendiendo la interfaz IEnumerable, todo el código que existía ya que usaba IEnumerable habría dejado de compilar, y encima toda la gente que utilizara IEnumerable tendría que implementar todos los métodos nuevos (y hay muchísimos métodos en Linq). Usando métodos extensionales la gente de .NET se evitó un breaking change (romper código ya existente) y además no obligó a la gente a implementar esos operadores por si mismos.

    Un saludo!


    Vicente Cartas Espinel - MVP XNA/DirectX

    Blog about C# and XNA Development

    Blog about Role Playing Games

    Excelente explicación tambien, muchas gracias!!!
    miércoles, 27 de marzo de 2013 15:13
  • buenas tardes. sr Bozzacchi me puede informar donde encuentrar información sobre lo que menciona en su respuesta me explico comollevo yo una base de datos a un un lenguaje ojala c#para crear clases interfaces y todo lo relacionado con el diseño. mi correo es javier araque 8@ Hotmail.com

    gracias

    sábado, 11 de febrero de 2017 21:31
  • buenas tardes. sr Bozzacchi me puede informar donde encuentrar información sobre lo que menciona en su respuesta me explico comollevo yo una base de datos a un un lenguaje ojala c#para crear clases interfaces y todo lo relacionado con el diseño. mi correo es javier araque 8@ Hotmail.com

    gracias

    Hola javier, te recomiendo el uso de Entity Framework.

    lunes, 19 de noviembre de 2018 9:38