Es una función de un ejemplo de encapsulación?

Question

Al poner funcionalidad en una función, hace que por sí sola constituye un ejemplo de encapsulación o necesita utilizar objetos para tener encapsulación?

Estoy tratando de entender el concepto de encapsulación. Lo que pensé fue si voy a algo como esto:

n = n + 1

que se ejecuta en la naturaleza como parte de un gran cuerpo de código y entonces tomo que, y ponerlo en una función como este, entonces he encapsulado que la adición lógica en un método:

addOne(n)
    n = n + 1
    return n

o es más el caso de que sólo encapsulación si yo estoy ocultando los detalles de addOne del mundo exterior - como si se trata de un método de objeto y lo uso de un modificador de acceso privado / protegido

Answer 1

Tal vez usted está confundiendo la abstracción con la encapsulación, que se entiende en el contexto más amplio de la orientación a objetos.

La encapsulación incluye adecuadamente los tres de los siguientes:

• abstracción
• Implementación de ocultación
• División de Responsabilidad

La abstracción es sólo un componente de encapsulación. En el ejemplo que ha abstraído la funcionalidad añadiendo desde el cuerpo principal de código en la que en un tiempo residencia. Esto se hace mediante la identificación de una cierta normalización en el código - el reconocimiento de un concepto (suma) sobre un caso específico (sumando el número uno a la variable n). Debido a esta capacidad, abstracción hace un componente encapsulado - un método o un objeto -. Reutilizable

De igual importancia a la noción de encapsulación es la idea de su escondite aplicación. Esta es la razón por la encapsulación se discute en el ámbito de la orientación a objetos. escondite aplicación protege un objeto de sus usuarios y viceversa. En OO, esto se hace mediante la presentación de una interfaz de métodos públicos a los usuarios de su objeto, mientras que la ejecución del objeto tiene lugar dentro de los métodos privados.

Esto tiene dos ventajas. En primer lugar, al limitar el acceso a su objeto, a evitar una situación en la que los usuarios del objeto puede dejar el objeto en un estado no válido. En segundo lugar, desde la perspectiva del usuario, cuando utilizan el objeto que sólo son débilmente acoplados a él -. Si cambia de aplicación más adelante, no se ven afectados

Por último, la división de responsility - en el contexto más amplio de un diseño orientado a objetos - es algo que debe ser considerado para abordar adecuadamente la encapsulación. No sirve de nada que encapsula una colección aleatoria de funciones - la responsabilidad tiene que estar limpia y lógicamente definida de modo que no es tan poca superposición o ambigüedad posible. Por ejemplo, si tenemos un objeto Aseo vamos a querer blindar su dominio de las responsabilidades de nuestro objeto de la cocina.

En un sentido limitado, sin embargo, estás en lo correcto que una función, digamos, 'modulariza' algunas funciones mediante la abstracción de ella. Pero, como he dicho, 'encapsulación' como un término se entiende en el contexto más amplio de la orientación a objetos para aplicar a una forma de modularización que cumple los tres criterios mencionados anteriormente.

Answer 2

Voy a ser el primero en estar en desacuerdo con lo que parece ser la tendencia respuesta. Sí, una función encapsula una cierta cantidad de aplicación. No es necesario un objeto (que creo que se utiliza para referirse a una clase).

Meyers también.

Answer 3

Claro que lo es.

Por ejemplo, un método que opera sólo en sus parámetros se consideraría "mejor encapsulado" que un método que opera sobre datos estáticos globales.

La encapsulación ha existido mucho antes de programación orientada a objetos:)

Answer 4

Un método no más es un ejemplo de encapsulación que un coche se muestra un ejemplo de buena conducción. La encapsulación no es sobre el SYNAX, es una cuestión de diseño lógico. Ambos objetos y métodos pueden exhibir buenas y malas encapsulación.

La forma más sencilla de pensar en ello es si el código se esconde / abstrae los detalles de otras partes del código que no tienen una necesidad de saber / cuidado acerca de la aplicación.

Volviendo al ejemplo del coche: transmisión automática ofrece una buena encapsulación: Como conductor usted se preocupa por delante / atrás y velocidad. La transmisión manual es mala encapsulación:. Desde la perspectiva del conductor de la transmisión específica requerida para la alta velocidad / baja es generalmente irrelevante para la intención del conductor

Answer 5

No, no son objetos es obligatorio para la encapsulación. En el sentido más amplio, "encapsulación" sólo significa "ocultar los detalles de la vista", y en ese sentido es un método de encapsulación de sus detalles de implementación.

Eso no significa realmente que puede salir y decir que su código está bien diseñado sólo porque se lo dividió arriba en métodos, sin embargo. Un programa consta de 500 métodos públicos no es mucho mejor que el mismo programa implementado en un método 1000 de línea.

En la construcción de un programa, independientemente de si se está utilizando técnicas orientadas a objetos o no, es necesario pensar en la encapsulación en muchos lugares diferentes: ocultar los detalles de implementación de un método, ocultando los datos de código que no necesita saber sobre él, lo que simplifica las interfaces con los módulos, etc.

Actualización:. Para responder a su pregunta actualizada, tanto "poner el código en un método" y "el uso de un modificador de acceso" son diferentes formas de la lógica encapsular, pero cada uno actúa en un nivel diferente

poner el código en un método oculta las líneas de código individuales que componen ese método para que las personas que llaman no tienen que preocuparse por lo que esas líneas son; que sólo se preocupan por la firma del método.

Cómo marcar a un método en una clase como (por ejemplo) "privado" se esconde ese método para que un consumidor de la class no tiene que preocuparse por ello; que sólo se preocupan por los métodos públicos (o propiedades) de su clase.

Answer 6

Es una cosa a nivel de componentes

este a cabo:

  

En informática, encapsulación es la ocultación de los mecanismos internos y las estructuras de datos de un componente de software detrás de una interfaz definida, de tal manera que los usuarios del componente (otras piezas de software) sólo tienen que saber lo que hace el componente , y no puede hacerse depender de los detalles de cómo lo hace. El propósito es lograr potencial de cambio:. Los mecanismos internos del componente se pueden mejorar sin impacto en otros componentes, o el componente pueden ser sustituidos con uno diferente que soporta la misma interfaz público

(yo no entiendo muy bien su pregunta, quiero saber si ese enlace no cubre sus dudas)

Answer 7

El concepto abstracto de encapsulación significa que usted oculta los detalles de implementación. La orientación a objetos es sólo un ejemplo de la utilización de ecnapsulation. Otro ejemplo es el lenguaje llamado módulos módulos de aplicación de módulo-2 que utiliza (o usado) y definición. Los módulos de definición escondieron la implementación real y por lo tanto siempre encapsulación.

La encapsulación se utiliza cuando se puede considerar algo un cuadro negro. Los objetos son un cuadro negro. Usted sabe que los métodos que proporcionan, pero no la forma en que se implementan.

[EDIT] Como para el ejemplo de la cuestión actualización: depende de lo estrecha o ancha se define la encapsulación. Su ejemplo AddOne no oculta nada de lo que creo. Sería ocultación de la información / encapsulación si su variable sería un índice de matriz y que le llame a su método MoveNext y tal vez tener otra función y setValue getValue. Esto permitiría a las personas (en conjunto quizá con algunas otras funciones) para navegar por su estructura y configuración y las variables que consiguen con ellos siendo conscientes de que el uso de una matriz. Si lenguaje de programación apoyaría otros conceptos o más ricos que podría cambiar la implementación de MoveNext, setValue y getValue con cambiar el significado y la interfaz. Para mí eso es la encapsulación.

Answer 8

Vamos a simplificar esto de alguna manera con una analogía: se gira la llave de su vehículo y se pone en marcha. Usted sabe que hay más a él que sólo la llave, pero no lo hace Tienes para saber lo está pasando allí. Para que, a su vez clave = arranque del motor. La interfaz de la clave (es decir, por ejemplo, la llamada de función) se esconde la implementación del motor de arranque hace girar el motor, etc ... (la aplicación). Eso es encapsulación. Estás salvo de tener que saber lo que está pasando bajo el capó, y está contenta por ello.

Si ha creado una mano artificial, digamos, al girar la llave para ti, eso es no encapsulación. Usted está girando la llave con costra intermediario adicional sin ocultar nada. Eso es lo que tu ejemplo me recuerda - no es encapsular los detalles de implementación, a pesar de que tanto se llevan a cabo a través de llamadas a funciones. En este ejemplo, cualquiera de recoger su código no será gracias por ello. Ellos, de hecho, es más probable que usted club con su mano artificial.

Cualquier método que se pueda imaginar para ocultar la información (clases, funciones, bibliotecas dinámicas, macros) se puede utilizar para la encapsulación.

Answer 9

La encapsulación es un proceso en el que los atributos (miembro de datos) y el comportamiento (función miembro) de un objetos en combinado juntos como una sola entidad se refiere como clase.

Answer 10

El modelo de referencia de procesamiento distribuido abierto - escrito por la Organización Internacional de Normalización - se definen los siguientes conceptos:

Entidad:. Cualquier cosa concreta o abstracta de interés

Objeto: Un modelo de una entidad. Un objeto se caracteriza por su comportamiento y, dualmente, por su estado.

Comportamiento (de un objeto):. Una colección de acciones con un conjunto de restricciones sobre cuándo pueden producirse

Interfaz:. Una abstracción del comportamiento de un objeto que consiste en un subconjunto de las interacciones de ese objeto, junto con un conjunto de restricciones sobre cuándo pueden producirse

Encapsulación:. La propiedad de que la información contenida en un objeto es accesible sólo a través de las interacciones en las interfaces soportadas por el objeto

Estos, usted podrá apreciar, es bastante amplio. Veamos, sin embargo, ya sea poniendo funcionalidad dentro de una función lógica se puede considerar que constituyen hacia encapsulación en estos términos.

En primer lugar, una función es claramente un modelo de una 'cosa de interés', ya que representa un algoritmo que (presumiblemente) el deseo ejecutado y que el algoritmo pertenece a algún problema que está tratando de resolver (y por lo tanto es un modelo de la misma).

¿Tiene una función tiene un comportamiento? Ciertamente hace: contiene un conjunto de acciones (que podría ser cualquier número de sentencias ejecutables) que se ejecuta bajo la restricción de que la función debe ser llamada desde algún lugar antes de que pueda ejecutar. Una función no puede espontáneamente ser llamado en cualquier momento, sin factor causal. Suena como jerga legal? Puedes apostar. Pero vamos a arar en adelante, no obstante.

¿Tiene una función tiene una interfaz? Ciertamente, no: tiene un nombre y un conjunto de parámetros formales, que a su vez se asignan a las sentencias ejecutables contenidos en la función en la que, una vez que se invoca una función, la lista de nombres y el parámetro se entienden para identificar de forma exclusiva la colección de ejecutable declaraciones que se ejecutan sin que la parte de la especificación de llamar a esos estados reales.

¿Tiene una función tiene la propiedad de que la información contenida en la función es accesible sólo a través de las interacciones en las interfaces soportadas por el objeto? Hmm, bueno, se puede.

A medida que alguna información es accesible a través de su interfaz, alguna información debe estar oculto e inaccesible dentro de la función. (La propiedad, tales exhibiciones de información se llama ocultación de información, que Parnas definida por el argumento de que los módulos deben estar diseñados para ocultar tanto las decisiones y decisiones que pueden cambiar difíciles.) Entonces, ¿qué información se oculta dentro de una función?

Para ver esto, debemos considerar primero la escala. Es fácil decir que, por ejemplo, las clases de Java se pueden encapsular dentro de un paquete: algunas de las clases será público (y por lo tanto ser la interfaz del paquete) y algunos serán paquete-privada (y por lo tanto la información oculta dentro del paquete) . En teoría la encapsulación, las clases forman nodos y los paquetes forman regiones encapsuladas, con la formación de la totalidad de un gráfico de encapsulado; la gráfica de las clases y los paquetes se llama el tercer gráfico.

También es fácil afirmar que las funciones (o métodos) ellos mismos están encapsulados dentro de las clases. Una vez más, algunas funciones serán públicas (y, por tanto, ser parte de la interfaz de la clase) y algunos serán privadas (y por lo tanto oculta en la información dentro de la clase). La gráfica de funciones y clases se llama el segundo gráfico.

Ahora llegamos a las funciones. Si las funciones son a ser un medio de encapsulación sí mismos que deben contener cierta información pública a otras funciones y alguna información que es la información oculta dentro de la función. ¿Cuál podría ser esta información?

Uno de los candidatos es dada a nosotros por McCabe. En su papel de la señal de la complejidad ciclomática, Thomas McCabe describe código fuente, donde, 'Cada nodo en el gráfico corresponde a un bloque de código en el programadonde el flujo es secuencial y los arcos corresponden a ramas tomadas en el programa. '

Tomemos el bloque McCabian de ejecución secuencial como unidad de información que puede ser encapsulado dentro de una función. A medida que el primer bloque dentro de la función es siempre la primera y única garantizada bloque a ejecutar, podemos considerar el primer bloque sea público, ya que puede ser llamado por otras funciones. Todos los otros bloques dentro de la función, sin embargo, no pueden ser llamados por otras funciones (excepto en los idiomas que permiten saltar en funciones a mediados de flujo) y por lo que estos bloques pueden ser considerados información oculta dentro de la función.

A partir de estos definiciones (quizás un poco tenues), entonces podemos decir que sí: poner funcionalidad dentro de una función no constituye a la encapsulación. La encapsulación de bloques dentro de las funciones es la primera gráfica.

Hay una caveate, sin embargo. ¿Consideraría un paquete en el que cada clase se pública a encapsular? De acuerdo con las definiciones anteriores, se hace pasar la prueba, como se puede decir que la interfaz para el paquete (es decir, todas las clases públicas) no ofrece de hecho un subconjunto del comportamiento del paquete a otros paquetes. Pero el subconjunto en este caso es el comportamiento de todo el paquete, ya que no son clases de información oculta. Así que a pesar satisfacer regorously las definiciones anteriores, nos parece que no satisface el espíritu de las definiciones, como sin duda algo tiene que haber información oculta la verdadera encapsulación para ser reclamado.

Lo mismo es cierto para el exampe que das. Desde luego, podemos considerar n = n + 1 a ser un solo bloque McCabian, ya que (y la instrucción de retorno) son un único flujo, secuencial de las ejecuciones. Pero la función en la que se pone esto lo tanto, contiene un solo bloque, y que el bloque es el único bloque pública de la función, y por lo tanto no hay bloques de información oculta dentro de su función propuesta. Por lo que puede satisfacer la definición de encapsulación, pero yo diría que no satisface el espíritu.

Todo esto, por supuesto, es académica menos que pueda probar tal beneficio encapsulación.

Hay dos fuerzas que motivan la encapsulación:. La semántica y de la lógica

encapsulación Semántica meramente medios de encapsulación basado en el significado de los nodos (para usar el término general) encapsulados. Así que si te digo que tengo dos paquetes, uno llamado, 'animal', y uno llamado 'mineral', y luego le dan tres clases de perro, gato y de cabra y pido en el que los paquetes de estas clases deben ser encapsulados, a continuación, dados ninguna otra información, que sería perfectamente correcto afirmar que la semántica del sistema de sugerirían que las tres clases pueden encapsular dentro del paquete, 'animal', en lugar del 'mineral'.

La otra motivación para la encapsulación, sin embargo, es la lógica.

La configuración de un sistema es la identificación precisa y exhaustiva de cada nodo del sistema y la región encapsulada en la que reside; una configuración particular de un sistema de Java es - en el tercer gráfico -. para identificar todas las clases del sistema y especificar el paquete en el que reside cada clase

Para encapsular lógicamente significa un sistema para identificar una propiedad matemática del sistema que depende de su configuración, y después configurar ese sistema para que la propiedad se reduce al mínimo matemáticamente.

teoría Encapsulación propone que todos los gráficos encapsuladas expresan un número máximo potencial de bordes (MPE). En un sistema de Java de clases y paquetes, por ejemplo, el error máximo permitido es el número máximo potencial de las dependencias de código fuente que puede existir entre todas las clases de ese sistema. Dos clases dentro del mismo envase no puede ser información oculta entre sí y por lo tanto puede potencialmente formar depdencies una sobre otra. Dos clases del paquete y privado en paquetes separados, sin embargo, no pueden formar dependencias entre sí.

La encapsulación teoría nos dice cuántos paquetes que debemos tener para un número determinado de clases de manera que se reduzca al mínimo el error máximo permitido. Esto puede ser útil porque la forma débil del principio de la carga establece que la carga máxima potencial de transformar una colección de entidades es una función del número máximo potencial de las entidades transformadas - en otras palabras, los más posibles dependencias de código fuente que tiene entre sus clases, mayor es el costo potencial de realizar cualquier actualización en particular. Reducir al mínimo el error máximo permitido por lo tanto minimiza el coste máximo potencial de cambios.

Dadas n clases y un requisito de p clases públicas por paquete, la teoría de encapsulación muestra que el número de paquetes, r, que debe tener para minimizar la MPE está dada por la ecuación:. R = sqrt (n / p)

Esto también se aplica al número de funciones que debe tener, dado el número total, n, de McCabian bloques en su sistema. Funciones siempre tienen un solo bloque pública, como hemos mencionado anteriormente, y por lo que la ecuación para el número de funciones, R, para tener en su sistema se simplifica a:. R = sqrt (n)

Es cierto que algunos consideran el número total de bloques en su sistema cuando la práctica de encapsulación, pero es fácilmente realizado a nivel de clase / paquete. Y, además, minimizando MPE es casi en su totalidad Entuitive: se hace reduciendo al mínimo el número de clases públicas y tratar de distribuir uniformemente las clases sobre los paquetes (o al menos evitar que la mayoría de los paquetes con, digamos, 30 clases, y uno thepacakge monstruo con 500 clases, en cuyo caso el MPE interna de este último puede abrumar fácilmente el MPE de todos los demás).

así encapsulación implica un equilibrio entre la semántica y la lógica.

Todo muy divertido.

Answer 11

en estricta terminología orientada a objetos, uno podría estar tentado a decir que no, una "simple" función no es suficientemente potente como para ser llamado encapsulación ... pero en el mundo real la respuesta obvia es "sí, una función encapsula algún código"

para los puristas OO que se erizan en esta blasfemia, considere una clase anónima estática sin estado y un solo método; si la función AddOne () no es la encapsulación, que, ni esta clase!

y justo para ser pedante, encapsulación es una forma de abstracción, no viceversa. ; -)

Answer 12

No es normalmente muy significativo para hablar de encapsulación sin referencia a propiedades en lugar de únicamente métodos - se puede poner controles de acceso en los métodos, sin duda, pero es difícil ver cómo eso va a ser otra que sin sentido sin ningún dato como alcance el método encapsulado. Probablemente se podría hacer algún argumento validarlo, pero sospecho que sería tortuoso.

Así que no, que es más probable que no utilizan la encapsulación con sólo poner un método en una clase en lugar de tenerlo como una función global.