Programación basada en clases - Class-based programming

Paradigmas de programación
Acción Orientado al agente Orientado a matrices Basado en autómatas Computación concurrente Programación relativista Basado en datos Declarativo (contraste: imperativo ) Funcional Lógica funcional Puramente funcional Lógica Lógica abductiva Conjunto de respuestas Lógica concurrente Lógica funcional Lógica inductiva Restricción Lógica de restricción Lógica de restricción concurrente Flujo de datos Basado en flujo Reactivo Reactivo funcional Ontología Diferenciable Dinámico / scripting Evento conducido Nivel de función (contraste: nivel de valor ) Estilo sin puntos Concatenativo Genérico Imperativo (contraste: declarativo ) Procesal Orientado a objetos Polimórfico Intencional Orientado al lenguaje Específico de dominio Alfabetizado Programación en lenguaje natural Metaprogramación Automático Programación inductiva reflexivo Orientado a atributos Macro Modelo No estructurado (contraste: estructurado ) Formación No determinista Computación paralela Orientado al proceso Probabilístico Cuántico Teórico de conjuntos Basado en pila Estructurado (contraste: no estructurado ) Estructurado en bloque Simultaneidad estructurada Orientado a objetos Basado en actores Basado en clases Concurrente Basado en prototipos Por separación de preocupaciones : Orientado a aspectos Orientado a roles Orientado al sujeto Recursivo Simbólico Nivel de valor (contraste: nivel de función )
v t mi

La programación basada en clases , o más comúnmente la orientación de 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 (compare la programación basada en prototipos ).

El modelo más popular y desarrollado de OOP 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 de método, control de acceso de 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).

Encapsulamiento

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 para aspectos no expuestos en la interfaz sin impacto en el código de usuario. Las definiciones de encapsulación se centran en la agrupación y el empaquetado de información relacionada ( cohesión ) más que en cuestiones de seguridad. Los lenguajes de programación orientada a objetos normalmente no ofrecen restricciones de seguridad formales para el estado del objeto interno. El uso de un método de acceso es una cuestión de convención para el diseño de la interfaz.

Herencia

En la programación basada en clases, la herencia se realiza definiendo nuevas clases como extensiones de las 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 reticular (si es de herencia múltiple).

La característica que define 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 .

Crítica de modelos basados ​​en clases

Los lenguajes basados ​​en clases, o para ser más precisos, los lenguajes mecanografiados , donde la subclasificación 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 uno podría crear una clase de bolsa que almacene una colección de objetos y luego extenderla para crear una nueva clase llamada clase de conjunto donde se elimina la duplicación de objetos. 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, pero si uno pasa un objeto de una clase establecida, entonces agregar dos objetos puede aumentar o no el tamaño de la bolsa. una bolsa por dos. El problema surge precisamente porque subclasificar implica subtipificar incluso en los casos en los 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 de manera sucinta 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 es un subtipo de .${\ Displaystyle \ phi (x)}$${\ Displaystyle x}$${\ Displaystyle T}$${\ Displaystyle \ phi (y)}$${\ Displaystyle y}$${\ Displaystyle S}$${\ Displaystyle S}$${\ Displaystyle T}$

Por lo tanto, normalmente se deben distinguir subtipos y subclases. 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 de 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 de persona, 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 la vista unificada de la clase para sus usuarios. Los usuarios no deberían tener que preocuparse de que una de las implementaciones de un método provoque cambios que rompan las invariantes de la clase. Estos cambios se pueden realizar destruyendo el objeto y construyendo otro en su lugar. El polimorfismo se puede utilizar para preservar las interfaces relevantes incluso cuando se realizan tales 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 se cambia el valor de las referencias a objetos que se refieren al objeto, lo que provoca efectos en el código del cliente.

Idiomas de ejemplo

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 .

Ver también

• Programación basada en prototipos (contraste)
• Paradigmas de programación
• Clase (programación informática)

Referencias