OO Abstraction ocurre durante el diseño del nivel de clase, con el objetivo de ocultar la complejidad de la implementación de cómo se implementaron los las características ofrecidas por un/diseño/sistema API, en cierto sentido la simplificación de la 'interfaz' para acceder a la implementación subyacente.
Este proceso puede repetirse a niveles (capas) de abstracción cada vez más "elevados", lo que permite construir sistemas grandes sin aumentar la complejidad del código y la comprensión, en capas superiores.
Por ejemplo, un desarrollador de Java puede hacer uso de las características de alto nivel de FileInputStream sin preocuparse de cómo funciona (es decir, los identificadores de archivo, los controles de seguridad del sistema de archivos, la asignación de memoria y almacenamiento temporal serán administrados internamente, y están ocultos a los consumidores) Esto permite cambiar la implementación de FileInputStream, y mientras la API (interfaz) a FileInputStream permanezca constante, el código creado con las versiones anteriores seguirá funcionando.
Del mismo modo, al diseñar sus clases, querrá ocultar la implementación interna de los demás en la medida de lo posible.
En la definición Booch , OO Encapsulación se logra a través Information Hiding, y específicamente alrededor de ocultar datos internos (campos/miembros que representan el estado) propiedad de una instancia de clase, mediante la aplicación de acceso a los datos internos en una de manera controlada, y evitando el cambio directo y externo a estos campos, así como la ocultación de cualquier método de implementación interna de la clase (p. ej. haciéndolos privados).
Por ejemplo, los campos de unas clases se pueden hacer private por defecto, y sólo si se requiere el acceso externo a estos, serían un get() y/o set() (o Property) estar expuestos de la clase. (En los idiomas OO actuales, los campos se pueden marcar como readonly/final/immutable lo que restringe aún más el cambio, incluso dentro de la clase).
Ejemplo en el que se ha aplicado NO ocultación de información (mala práctica):
class Foo {
// BAD - NOT Encapsulated - code external to the class can change this field directly
// Class Foo has no control over the range of values which could be set.
public int notEncapsulated;
}
Ejemplo en el que la encapsulación de campo se ha aplicado:
class Bar {
// Improvement - access restricted only to this class
private int encapsulated;
// The state of Bar (and its fields) can now be changed in a controlled manner
public void setEncapsulatedField(int newValue) {
if (newValue < 100) {
encapsulated = newValue;
}
// else throw ... out of range
}
}
Ejemplo de inmutable/constructor- solo inicialización de un campo:
class Baz {
private final int onlyValue;
public void Baz(int immutableValue) {
// ... can check that immutableValue is valid
onlyValue = immutableValue;
}
// Further change of `onlyValue` outside of the constructor is NOT permitted
// even within the same class
}
Re: Abstracción vs Resumen Clase
Abstract classes son clases que promueven la reutilización de elementos comunes entre las clases, pero que por sí mismos no pueden directamente ser instanciada con new() - clases abstractas deben tener subclases, y sólo concrete (no abstracta) las subclases pueden ser instanciadas. Posiblemente una fuente de confusión entre Abstraction y abstract class fue que en los primeros días de OO, la herencia se usaba más para lograr la reutilización del código (por ejemplo, con clases base abstractas asociadas).Hoy en día, composition is generally favoured over inheritance, y hay más herramientas disponibles para lograr la abstracción, como a través de interfaces, eventos/delegados/funciones, rasgos y/o mixins etc.
Re: La encapsulación vs ocultación de la información
Más recientemente encapsulation es comúnmente también se usa en un sentido más general al determinar qué métodos, campos, propiedades, eventos y otros a bundle en una clase.
Citando a Wikipedia:
En el ajuste más concreta de un lenguaje de programación orientado a objetos, la noción se utiliza para significar un mecanismo de ocultación de la información, un mecanismo de agrupación, o la combinación de los dos.
Por ejemplo, en la declaración "He encapsulado el código de acceso de datos en su propia clase", la interpretación de encapsulación es más o menos equivalente a la Separation of Concerns principal (el S en estado sólido), y Podría decirse que podría usarse como sinónimo de refactorización.
[1] vez que haya visto Booch de encapsulation cat picture nunca serás capaz de olvidar la encapsulación - p46 de Análisis y Diseño Orientado a Objetos con aplicaciones, 2ª Ed
por lo que la API de Java que utilizamos es una abstracción? – sras
Sí, a un alto nivel, una API proporciona una abstracción más simple para que un consumidor la use, felizmente ajena a la complejidad subyacente detrás de su diseño interno. Java es obviamente un lenguaje, con muchos marcos de alto nivel asociados. Sin embargo, creo más específicamente, en el momento en que se acuñó el diseño de OO [terminología de los directores] (https://en.wikipedia.org/wiki/Object-oriented_design), esa abstracción se refería más específicamente al diseño y la descomposición del nivel de clase. , en lugar de referirse al diseño de marco o de nivel empresarial. – StuartLC