Qué aprender sobre la programación orientada a objetos

Los conceptos de programación orientada a objetos incluyen principalmente: objetos, clases, abstracción de datos, herencia, enlace dinámico, encapsulación de datos, polimorfismo y paso de mensajes.

Las tres características principales de la programación orientada a objetos son el polimorfismo, la herencia y la encapsulación.

1. Polimorfismo

La idea central del polimorfismo es que una referencia de una clase principal puede apuntar a un objeto de una subclase, o una referencia de un tipo de interfaz puede apuntar. a una instancia de una clase que implementa la interfaz. La razón por la que el polimorfismo funciona así es porque la clase secundaria es la clase principal.

2. Herencia

Java tiene herencia única, que es diferente de C++. Esto significa que una clase solo puede heredar de una clase, y la clase heredada se llama clase padre. , o la clase base, y la clase heredada se llama subclase.

La herencia en Java utiliza la palabra clave extends. Sin embargo, una clase puede implementar múltiples interfaces y varias interfaces están separadas por comas. Implemente la interfaz utilizando la palabra clave implements.

3. Encapsulación (Encapsulación)

La encapsulación es relativamente simple. Una clase contiene métodos y datos. Poner métodos y datos en una clase constituye encapsulación. Las ventajas de la encapsulación: aislar cambios, facilitar el uso, mejorar la reutilización y mejorar la seguridad. Desventajas de la encapsulación: utilizar modificaciones privadas para las variables o encapsularlas en métodos para que no se pueda acceder a ellas directamente, lo que aumenta los pasos de acceso y la dificultad.

Seis principios básicos de la programación orientada a objetos:

1. Principio de responsabilidad única

No tener más de un motivo para un cambio de clase, es decir, una clase Solo tiene una responsabilidad.

2. Principio Abierto-Cerrado

Abierto a la expansión pero cerrado a la modificación. No importa qué tan cerrado esté el módulo, siempre habrá algunos cambios que no se pueden cerrar. Dado que no se puede cerrar por completo, debemos elegir a qué cambios se debe cerrar el módulo que diseñamos. Primero debemos adivinar el tipo de. cambios que es más probable que ocurran y luego construir abstracciones para aislar estos cambios.

3. Principio Dimit

Un objeto debe tener el menor conocimiento sobre otros objetos para reducir el acoplamiento entre clases. Si dos clases no tienen que comunicarse entre sí, entonces las dos clases no deberían interactuar directamente. Cuanto más débil sea el acoplamiento entre clases, más propicio será la reutilización. Si se modifica una clase débilmente acoplada, no afectará a las clases relacionadas.

4. Principio de inversión de dependencia

Los módulos de nivel superior no deben depender de los módulos de nivel inferior, todos dependen de la abstracción. La abstracción no puede depender de los detalles; los detalles deben depender de la abstracción. Programa para interfaces, no implementaciones.

5. Principio de sustitución de Liskov

Los subtipos deben poder reemplazar sus tipos principales. Solo cuando la subclase puede reemplazar a la clase principal y las funciones de la unidad de software no se ven afectadas, la clase principal se puede reutilizar realmente y la subclase también puede agregar nuevos comportamientos basados ​​en la clase principal.

6. Principio de aislamiento de interfaz

El cliente no debe depender de interfaces que no necesita. La dependencia de una clase de otra clase debe basarse en la interfaz más pequeña. No dejes que modificaciones que no tengan nada que ver contigo afecten los cambios en tus módulos funcionales.