La programación basada en clases , o más comúnmente orientación a clases , es un estilo de programación orientada a objetos (POO) en el que la herencia se produce mediante la definición de clases de objetos , en lugar de que la herencia se produzca únicamente a través de los objetos (compárese con la programación basada en prototipos ).
El modelo de programación orientada a objetos más popular y desarrollado es un modelo basado en clases, en lugar de un modelo basado en objetos. En este modelo, los objetos son entidades que combinan estado (es decir, datos), comportamiento (es decir, procedimientos o métodos ) e identidad (existencia única entre todos los demás objetos). La estructura y el comportamiento de un objeto están definidos por una clase , que es una definición , o modelo , de todos los objetos de un tipo específico. Un objeto debe crearse explícitamente en función de una clase y un objeto así creado se considera una instancia de esa clase. Un objeto es similar a una estructura , con la adición de punteros a métodos, control de acceso a miembros y un miembro de datos implícito que ubica instancias de la clase (es decir, objetos de la clase) en la jerarquía de clases (esencial para las características de herencia en tiempo de ejecución).
La encapsulación evita que los usuarios rompan las invariantes de la clase, lo cual es útil porque permite cambiar la implementación de una clase de objetos en aspectos no expuestos en la interfaz sin afectar el código del usuario. Las definiciones de encapsulación se centran en la agrupación y empaquetado de información relacionada ( cohesión ) más que en cuestiones de seguridad.
En la programación basada en clases, la herencia se realiza definiendo nuevas clases como extensiones de clases existentes: la clase existente es la clase principal y la nueva clase es la clase secundaria . Si una clase secundaria tiene solo una clase principal, esto se conoce como herencia única , mientras que si una clase secundaria puede tener más de una clase principal, esto se conoce como herencia múltiple . Esto organiza las clases en una jerarquía , ya sea un árbol (si es de herencia única) o una red (si es de herencia múltiple).
La característica definitoria de la herencia es que tanto la interfaz como la implementación se heredan; si solo se hereda la interfaz, esto se conoce como herencia o subtipo de interfaz. La herencia también se puede realizar sin clases, como en la programación basada en prototipos .
Los lenguajes basados en clases, o, para ser más precisos, los lenguajes tipificados , donde la subclases es la única forma de subtipificar , han sido criticados por mezclar implementaciones e interfaces, el principio esencial en la programación orientada a objetos. Los críticos dicen que se podría crear una clase de bolsa que almacene una colección de objetos y luego ampliarla para crear una nueva clase llamada clase de conjunto donde se elimine la duplicación de objetos. [1] [2] Ahora, una función que toma un objeto de la clase bolsa puede esperar que agregar dos objetos aumente el tamaño de una bolsa en dos, sin embargo, si uno pasa un objeto de una clase establecida, entonces agregar dos objetos puede o No se podrá aumentar en dos el tamaño de una bolsa. El problema surge precisamente porque la subclasificación implica subtipificación incluso en los casos en que el principio de subtipificación, conocido como principio de sustitución de Liskov , no se cumple. Barbara Liskov y Jeannette Wing formularon el principio sucintamente en un artículo de 1994 de la siguiente manera:
Requisito de subtipo : Sea una propiedad demostrable sobre objetos de tipo . Entonces debería ser cierto para objetos de tipo donde hay un subtipo de .
Por tanto, normalmente hay que distinguir entre subtipificación y subclasificación. La mayoría de los lenguajes orientados a objetos actuales distinguen subtipos y subclases, sin embargo, algunos enfoques de diseño no lo hacen.
Además, otro ejemplo común es que un objeto persona creado a partir de una clase secundaria no puede convertirse en un objeto de la clase principal porque una clase secundaria y una clase principal heredan una clase personal, pero los lenguajes basados en clases en su mayoría no permiten cambiar el tipo de clase de el objeto en tiempo de ejecución. Para los lenguajes basados en clases, esta restricción es esencial para preservar una vista unificada de la clase para sus usuarios. Los usuarios no deberían preocuparse si una de las implementaciones de un método provoca cambios que rompan las invariantes de la clase. Estos cambios pueden realizarse destruyendo el objeto y construyendo otro en su lugar. El polimorfismo se puede utilizar para preservar las interfaces relevantes incluso cuando se realizan dichos cambios, porque los objetos se ven como abstracciones de caja negra y se accede a ellos a través de la identidad del objeto . Sin embargo, normalmente el valor de las referencias a objetos que hacen referencia al objeto cambia, lo que provoca efectos en el código del cliente.
Aunque Simula introdujo la abstracción de clases, el ejemplo canónico de un lenguaje basado en clases es Smalltalk . Otros incluyen PHP , C++ , Java , C# y Objective-C .
