oop - que - ¿Por qué la encapsulación es una característica importante de los lenguajes de programación orientada a objetos?
que es una clase en poo (5)
Al menos en la mayoría de los lenguajes de OO, la encapsulación es más o menos equivalente a la cerradura en la puerta de un baño.
No tiene la intención de mantener a nadie afuera si realmente insisten en entrar.
Tiene la intención de ser una cortesía para que las personas sepan que ingresar implicará principalmente:
- vergüenza y
- un desastre pestilente.
Me encontré con una entrevista diferente donde me preguntaron por qué se usa la encapsulación. Cuyo requisito en realidad es la encapsulación? ¿Es para usuarios del programa? ¿O es para compañeros de trabajo? ¿O es para proteger el código de los piratas informáticos?
Diseñé un proyecto de vía rápida. La encapsulación reduce la propagación del cambio a través del sistema. Los cambios cuestan tiempo y dinero.
Cuando el código no está encapsulado, una persona tiene que buscar muchos archivos para encontrar dónde hacer los cambios. Por el contrario, está la pregunta de "¿Encontré todos los lugares?" y el otro punto "¿qué efecto tiene todo el sistema para hacer todos estos cambios de dispersión?"
Estoy trabajando en un dispositivo médico integrado y la calidad es imperativa. Además, todos los cambios deben documentarse, revisarse, probarse en unidades y finalmente se debe realizar una prueba del sistema. Al usar la encapsulación, podemos reducir el número de cambios y su localidad, reduciendo la cantidad de archivos que se deben volver a probar.
La encapsulación ayuda a aislar los detalles de implementación del comportamiento expuesto a los clientes de una clase (otras clases / funciones que usan esta clase), y le da más control sobre el coupling en su código. Considere este ejemplo, similar al del Código de limpieza de Robert Martin:
public class Car
{
//...
public float GetFuelPercentage() { /* ... */ };
//...
private float gasoline;
//...
}
Tenga en cuenta que al cliente que utiliza la función que le proporciona la cantidad de combustible en el automóvil no le importa qué tipo de combustible usa el automóvil. Esta abstracción separa la preocupación (cantidad de combustible) de los detalles sin importancia (en este contexto): ya sea gas, petróleo o cualquier otra cosa.
La segunda cosa es que el autor de la clase es libre de hacer lo que quiera con las partes internas de la clase, por ejemplo cambiando gasolina por petróleo, y otras cosas, siempre y cuando no cambien su comportamiento. Esto es gracias al hecho de que pueden estar seguros de que nadie depende de estos detalles, porque son privados. Cuantas menos dependencias haya en el código, más flexible y fácil de mantener es.
Otra cosa, notada correctamente en la respuesta subestimada por utnapistim : el acoplamiento bajo también ayuda a probar el código y mantener esas pruebas. Cuanto menos complicada es la interfaz de la clase, más fácil es probarla. Sin encapsulación, con todo lo expuesto, sería difícil comprender qué probar y cómo.
Para reiterar algunas discusiones en los comentarios:
No, la encapsulación no es lo más importante en OOP. Incluso me atrevería a decir que no es muy importante. Las cosas importantes son alentadas por la encapsulación, como el acoplamiento flojo. Pero no es esencial: un desarrollador cuidadoso puede mantener un acoplamiento flexible sin encapsular variables, etc. Como lo señala vlastachu , Python es un buen ejemplo de un lenguaje que no tiene mecanismos para hacer cumplir la encapsulación, pero todavía es factible para OOP.
No, ocultar los campos detrás de los accesadores no es encapsulación . Si lo único que has hecho es escribir "privado" delante de las variables y luego proporcionar sin pensar el par get / set para cada una de ellas, entonces, de hecho, no están encapsuladas. Alguien en un lugar distante en el código todavía puede inmiscuirse con los aspectos internos de su clase, y todavía puede depender de ellos (bueno, por supuesto es un poco mejor que dependan de un método, no de un campo).
No, el objetivo principal de la encapsulación no es evitar errores. Los objetivos principales son al menos similares a los enumerados anteriormente, y pensar que la encapsulación lo defenderá de cometer errores es ingenuo. Hay muchas otras maneras de cometer un error además de alterar una variable privada. Y la alteración de una variable privada no es tan difícil de encontrar y corregir. Nuevamente, Python es un buen ejemplo en aras de este argumento, ya que puede tener encapsulado sin aplicarlo.
La encapsulación evita que las personas que trabajan en su código cometan errores, asegurándose de que solo accedan a las cosas a las que se supone que deben acceder.
La encapsulación le permite formalizar sus interfaces, separando los niveles de abstracción (es decir, "la lógica de la aplicación accede al código IO solo de esta manera").
Esto, a su vez, le permite cambiar la implementación de un módulo (los datos y algoritmos dentro del módulo) sin cambiar la interfaz (y afectando al código del cliente).
Esta capacidad de modificar módulos de forma independiente entre sí, mejora su capacidad para medir su rendimiento y hacer predicciones en los plazos del proyecto.
También le permite probar módulos por separado y reutilizarlos en otros proyectos (porque la encapsulación también reduce las interdependencias y mejora la modularidad de su código).
No aplicar la encapsulación tiende a llevar a una falla del proyecto (el problema crece con la complejidad del proyecto).