¿El punto fuerte del diseño OO es la semántica o la encapsulación?

Question

El diseño orientado a objetos (OOD) combina datos y sus métodos.Esto, hasta donde puedo ver, logra dos grandes cosas:proporciona encapsulación (por lo que no me importa qué datos haya, solo cómo obtengo los valores que quiero) y semántica (relaciona los datos con los nombres, y sus métodos usan consistentemente los datos como se pretendía originalmente).

Entonces, ¿dónde reside la fuerza de OOD?Por el contrario, la programación funcional atribuye la riqueza a los verbos más que a los sustantivos, por lo que tanto la encapsulación como la semántica son proporcionadas por los métodos y no por las estructuras de datos.

Trabajo con un sistema que está en el extremo funcional del espectro y anhelo continuamente la semántica y la encapsulación de OO.Pero puedo ver que la encapsulación de OO puede ser una barrera para la extensión flexible de un objeto.Entonces, en este momento, puedo ver la semántica como una fortaleza mayor.

¿O es la encapsulación la clave de todo código que valga la pena?

Editar:Me refiero específicamente al tipo de encapsulación que OO proporciona aquí. changeColor(door,blue) se convierte door.changeColor(blue).

Answer 1

Parece que está utilizando una definición más estrecha de “encapsulación”. ¿Sería justo en la presunción de que la encapsulación se define como: “La combinación de datos con métodos?”

Si estoy equivocado, por favor ignorar el resto de esta entrada.

encapsulación no es un término suelto; de hecho, se define la Organización Internacional de Normalización. Modelo de Referencia de la norma ISO de procesamiento distribuido abierto - se definen los siguientes cinco 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

Podemos hacer una propuesta más evidente: como alguna información es accesible a través de estas interfaces, alguna información debe estar oculto e inaccesible dentro del objeto. 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, consulte uno de los grandes trabajos de computación difíciles:

http://www.cs.umd.edu/ clase / spring2003 / cmsc838p / Diseño / criteria.pdf

Es importante tener en cuenta que no es sólo los datos que contiene información oculta-:. Es un subconjunto del comportamiento asociado con el objeto de que es difícil o que puedan cambiar

En su mensaje, que parece estar diciendo que la diferencia entre la encapsulación en OO y en la programación funcional se deriva de la gestión de datos, pero al menos de acuerdo con la norma ISO y Parnas, la gestión de datos no es la clave de la encapsulación. Así que no veo por qué la encapsulación en la programación funcional tiene por qué ser diferente de la OO.

Usted menciona, además, en su puesto de que la programación funcional proporciona la encapsulación, “... por los métodos en lugar de las estructuras de datos.” Esto, creo, es una diferencia de escala y no la de la absoluta. Si utilizo la palabra “objeto” en lugar de “estructura de datos” (de nuevo, por favor hágamelo saber si estoy interpretando mal), a continuación, a usted parece importancia en la encapsulación de OO por el objeto y la encapsulación de la programación funcional según el método.

Sin embargo, por la definición de la ISO anterior, un objeto es lo que yo quiera para modelar. Por lo tanto las clases se pueden encapsular dentro de un paquete, siempre y cuando algunas de esas clases contribuyen a la interfaz del paquete (es decir, las clases públicas del paquete) y algunos son información oculta (las clases particulares en el paquete).

Por la misma razón, los métodos están encapsulados dentro de una clase - algunos métodos son públicos y algunos privados. Incluso se puede tomar a esto una muesca inferior y decir que las secuencias de código secuenciales McCabian están encapsulados dentro de los métodos. Cada forma un gráfico de nodos encapsuladas dentro de las regiones encapsuladas; y todas estas gráficas formar una pila gráfico. Por lo tanto la programación funcional puede bien encapsulado en el nivel de función / archivo, pero esto no es diferente de la gráfica método / clase de OO, y esencialmente ninguna diferencia en el gráfico de la clase / paquete de OO tampoco.

Además, tenga en cuenta que la palabra Parnas utiliza anteriormente: el cambio. El ocultamiento de información se refiere a eventos posibles, tales como el cambio de las decisiones de diseño difíciles en el futuro. Le preguntas donde la mentira de la fuerza de OO; así, la encapsulación es sin duda una fuerza de OO, pero la pregunta es, “hace la fuerza mentira de encapsulación Dónde?” y la respuesta es un rotundo de claridad: chagestión del ENS. En particular, la encapsulación reduce la carga potencial máxima de cambio.

El concepto de “acoplamiento potencial”, es útil en este caso.

“Coupling,” en sí se define como “una medida de la fuerza de asociación establecida por una conexión desde un módulo a otro,” en otro de los grandes papeles de computación:

http://www.research.ibm.com/journal/ sj / 382 / stevens.pdf

Y como dice el documento, en palabras nunca ya superada, “Reducción al mínimo de las conexiones entre los módulos también minimiza los caminos por los cuales los cambios y los errores se propagan a otras partes del sistema, eliminando de esta manera desastrosa,‘Ripple’, efectos, donde los cambios en una parte causar errores en otra, necesitando cambios adicionales en otros lugares, que dan lugar a nuevos errores, etc “.

Como se define aquí, sin embargo, existen dos limitaciones que pueden ser fácilmente levantada. En primer lugar, el acoplamiento no mide las conexiones intra-módulo, y estas conexiones intra-módulo puede dar lugar a otras tantas, “Ripple” efectos como las conexiones entre módulos (el papel no define, “Cohesión”, que se refieren intra-módulo elementos, pero esto no se definen en términos de conexiones entre elementos (es decir, las referencias a las etiquetas o direcciones) con el que se definió acoplamiento). En segundo lugar, el acoplamiento de cualquier programa de ordenador es un hecho, en que los módulos están conectados o; hay poco margen dentro de la definición de acoplamiento para gestionar los cambios potenciales de los cuales Parnas habla.

Estos dos problemas se resuelven, en cierta medida, con el concepto de acoplamiento potencial: el número máximo posible de conexiones conformables entre todos los elementos de un programa. En Java, por ejemplo, una clase que es el paquete-privada (el descriptor de acceso por defecto) dentro de un paquete no pueden haber conexiones formada en él (es decir, no hay fuera de las clases pueden depender de ello, la reflexión no obstante), pero una clase pública dentro de un paquete puede tienen dependencias en él. Esta clase pública contribuiría al acoplamiento potencial incluso si no hay otras clases dependen de él en el momento -. Clases podrían depender de ello, en el futuro, cuando los cambios de diseño

Para ver la fuerza de encapsulación, considerar el principio de la carga. El principio de la carga toma dos formas.

La forma fuerte establece que la carga de la transformación de una colección de entidades es una función del número de entidades transformadas. La forma débil indica 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.

La carga de la creación o modificación de cualquier sistema de software es una función del número de clases creados o modificados (aquí usamos, “Clases”, presumiendo un sistema orientado a objetos, y nos preocupa con la encapsulación a nivel de clase / paquete, nosotros igualmente podría haber afectado a nosotros mismos con el nivel de función / archivo de programación funcional). (Tenga en cuenta que la “carga” es el desarrollo de software moderno es por lo general el costo, o el tiempo, o ambos.) Las clases que dependen de una clase en particular, modificado tienen una probabilidad más alta de ser impactado de clases que no dependen de la clase modificada.

La carga potencial máximo de una clase modificado puede imponer es la de impacto de todas las clases que dependen de ella.

La reducción de las dependencias de una clase modificada, por tanto, reduce la probabilidad de que su actualización tendrá un impacto en otras clases y por lo tanto reduce la carga potencial máxima que puede imponer esa clase. (Esto es poco más que una reformulación de la “Diseño estructurado,” el papel.)

La reducción del número máximo potencial de dependencias entre todas las clases en un sistema por lo tanto reduce la probabilidad de que un impacto a una clase particular causará cambios a otras clases, y por lo tanto reduce la carga potencial máximo de todas las actualizaciones.

encapsulación, mediante la reducción del número máximo potencial de dependencies entre todas las clases, por lo tanto, mitiga la forma débil del principio de la carga. Todo esto es cubierto por “teoría encapsulación”, que intenta probar matemáticamente estas afirmaciones, usando un acoplamiento potencial como los medios lógicos de la estructuración de un programa.

Tenga en cuenta, sin embargo, que cuando se pregunta, “¿Es la encapsulación la clave para todo el código que vale la pena”, la respuesta debe ser sin duda: no. No hay una sola tecla a todo el código que vale la pena. La encapsulación es, en ciertas circunstancias, más que una herramienta para ayudar a mejorar la calidad de código de modo que se convierta en “Merece la pena.”

También escribe que “... encapsulación puede ser una barrera para la extensión flexible de un objeto.” Sí, sin duda puede: está de hecho diseñado para ser una barrera en contra de extender las decisiones de diseño de un objeto que son difíciles o que pueden cambiar. Esto no es, sin embargo, piensa que es una mala cosa. Un enfoque alternativo sería tener todas las clases públicas y tener un programa de expresar su acoplamiento máximo potencial; pero entonces la forma débil del principio de la carga afirma que las actualizaciones serán cada vez más costosa; Estos son los costos contra la cual las barreras a la extensión se van a medir.

Por último, se hace la comparación interesante entre la encapsulación y la semántica, y que, en su opinión, la semántica de OO son su mayor fortaleza. No soy semántico o bien (yo no sabía ni una palabra tan existido antes que el bien señor Ramsey hizo alusión a ella en su comentario), pero supongo que quiere decir, “Semántica”, en el sentido de, “el significado, o un interpretación del significado de una palabra,”y muy básicamente que una clase con una, trama () método debe ser llamado un perro.

Hay una gran fuerza precisamente en esta semántica.

Lo que es curioso para mí es que enfrentar a la semántica contra la encapsulación y buscar un ganador; Dudo que encuentre uno.

En mi opinió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, y en particular el estudio de acoplamiento potencial, mencionado anteriormente. La teoría encapsulación realmente proporciona ecuaciones para el número de paquetes que se debe utilizar para encapsular una serie de clases con el fin de minimizar el acoplamiento potencial.

Para mí, la encapsulación en su conjunto es el compromiso entre este enfoque semántico y lógico: Voy a permitir el acoplamiento potencial de mis programas se eleve por encima del mínimo si esto hace que el programa semánticamente más fácil de entender; pero los niveles enormes y derrochadoras de acoplamiento potencial será una advertencia de que mi programa necesita ser re-estructurado no importa cómo semánticamente obvio que es.

(Y si bien el señor Ramsey todavía está leyendo, ¿podría usted o sus amigos en semántica dame una palabra mejor para los “Semántica”, fase que estoy usando aquí? Sería bueno utilizar un término más apropiado. )

Saludos, Ed.

Answer 2

La encapsulación y la abstracción resultante son claramente los principales puntos fuertes de OO. El predicado "cosas" qué "acciones" se puede invocar en ellos, por lo que los sustantivos adquieren una importancia semántica más alto que los verbos.

En última instancia, es difícil imaginar el diseño de un sistema complejo en una forma consistente y fácil de mantener sin un cierto nivel de encapsulación.

Answer 3

Como programador Lisp, cuyo sistema de objetos podría decirse que proporciona ninguno de estos, me dicen:. Ninguno de los anteriores

JWZ: "el modelo de objetos pseudo-Smalltalk pierde y que las funciones genéricas (adecuadamente limitada por la no-externa-anulaciones regla) ganar"

Creo que los atributos deseables que usted y otros enumeran aquí (encapsulación, modularidad, etc.) no son tan inherente a OO como usted piensa. A menudo son proporcionados junto OO-estilo de Java, pero no meramente la consecuencia de ello.

Answer 4

El aislamiento de Complejidad es la OMI el objetivo principal de cualquier diseño. Encapsular funcionalidad detrás de una interfaz que es más fácil de usar de la funcionalidad en sí

OO proporciona diversos mecanismos para que - la mención de dos oyu:

La encapsulación permite diseñar una superficie a medida que es independiente de la implementación real. (Parafraseando, "más simple significa diferente").

Semántica permite modelar las entidades que representan elementos del dominio del problema, por lo que son más fáciles de entender.

---

Cualquier proyecto de llegar a un cierto tamaño se convierte en un ejercicio de gestión de la complejidad. Apostaría a la afirmación de que en los últimos años, la programación ha desnatada a lo largo de los límites de complejidad que VE # aprendido a manejar.

No he incursionado en la programación funcional durante años, pero en mi entendimiento que puede ser mejor descrito por el significado de un matemático de las palabras de gran alcance, elgant, AMD hermosas. "Beautiful" y "elegante", en este contexto, trata de describir una brillante idea de la verdadera o la estructura relevante de un sistema complejo, mirándolo desde un punto de vista donde es sorprendentemente simple. se acepta la complejidad como un dado, y trata de navegar en ella.

La flexibilidad que usted menciona es a mi entender la capacidad de cambiar el PDV de acuerdo a sus necesidades - pero eso va en contra de encapsulación: ¿qué es un detalle sin sentido de una posición puede ser la única relevante en otro

.

OO, otoh, es el enfoque reduccionista: cambiamos POV por ir a un nivel más alto. En la "vieja OO", hay una jerarquía de una sola POVs, interfaces son - en este modelo - una forma de modelar diferentes POVs.

Si se me permite decirlo así, la fuerza de OO es ser más adecuado para la "gente normal".

Answer 5

Una cierta forma de modularidad es la clave para cualquier diseño escalable. Las limitaciones de los seres humanos impide a las personas "Grokking" demasiada información a la vez, por lo que tenemos para subdividir los problemas en partes manejables, cohesivos, tanto para proporcionar una base para comprensión un gran proyecto, así como una forma de subdividir las asignaciones de trabajo de un gran proyecto entre muchas personas.

¿Cómo elegir la "división" más efectivo / "partición" de un gran proyecto para cumplir con los objetivos anteriormente? La experiencia ha demostrado que OO es el gran ganador aquí, y creo que mucha gente estaría de acuerdo en que dos atributos clave de OO que lo hacen bueno en esto son:

• encapsulado : cada clase encapsula un "secreto" - un conjunto de específicos de la implementación supuestos que-son--probable-tener-a-cambio-sobre-tiempo acerca de su implementación - y expone una interfaz que es agnóstico a estos supuestos; capas de tales abstracciones encapsulados hace posible arquitecto un diseño robusto que los componentes / implementaciones pueden ser fácilmente intercambiados en la cara de los cambios previstos.
• Sustantivo centradas : en la mayoría de los dominios, los seres humanos parecen mejor en la primera descomposición de un modelo de dominio por pensar en los nombres / datos de un dominio, seguido de la identificación de los verbos de apoyo que están asociados con cada sustantivo .

En cuanto a la programación funcional (FP) versus OO, he blogueado sobre esto, pero brevemente Creo que el FP es más acerca de las técnicas de aplicación, mientras que OO es más sobre la estructura del programa y el diseño, y por lo tanto los dos son complementarios, con OO ser más dominante en el extremo 'grande' de la escala y FP siendo más dominante en el extremo 'pequeño'. Es decir, en un gran proyecto, la estructura de alto nivel se describe mejor por el diseño de la clase OO, pero muchos de los detalles de nivel de módulo (implementaciones, y los detalles de las formas de las interfaces de los módulos) están mejor conformados por FP influencias.

Answer 6

La fuerza de diseño orientado a objetos es proporcional a la cantidad de el enlace en tiempo se produce en el diseño. Esta es la noción de Kay OO, no la noción Nygaard. Alan Kay escribió :

  

programación orientada a objetos para mí significa que sólo la mensajería, locales   la retención y la protección y escondite   de estado-proceso, y extremo   tarde en la unión de todas las cosas. Puede ser   hecho en Smalltalk y en LISP. Ahí   son posiblemente otros sistemas en los cuales   esto es posible, pero no estoy al tanto de   ellos.

La mayor parte de la literatura ignora el enlace en tiempo a favor de la idea de C ++ de la orientación a objetos.

Answer 7

Vamos a dar un paso atrás y mirar esto desde un nivel superior. Las ventajas de cualquier característica del lenguaje se encuentran en la capacidad de expresar de manera sucinta el problema / solución de una manera más natural con respecto al dominio del problema.

La mecánica de OOP se implementan fácilmente en C llano con estructuras y punteros de función. Incluso se puede conseguir un poco de programación orientada a objetos se sienten hacerlo de esa manera. Sin embargo, los modismos programación orientada a objetos no son tan próxima en dicho entorno. Cuando hay soporte de idiomas para la programación orientada a objetos reales entonces la expresividad del paradigma sale, y la forma en que un lenguaje implementa una idea tiene un impacto muy real sobre lo que está "dicho" y cómo. Por ejemplo, ver las diferencias en código mediante cierres / lambdas en Lisp, pitón, rubí, etc.

Así que al final no se trata de los componentes y conceptos subyacentes, sino más bien cómo se ponen juntos y utilizados que hacen OO en C ++ lo que es.

Answer 8

encapsulación en conjunción con el polimorfismo. La capacidad de las clases en la mayoría de lenguajes de POO para implementar una o más interfaces ha tenido el mayor impacto en el desarrollo de mi software. Esta característica permite me definir con precisión la interacción entre los dos objetos.

No sólo definir las interacciones pero documentarla para que años después puedo volver a esa sección del código y ver lo que está sucediendo con claridad.

Esta característica es la razón principal por la que prefiero usar lenguajes de programación orientada a objetos sobre los lenguajes funcionales. Mientras que el software muy potente que he hallado escrito en lenguajes funcionales a ser un dolor de mantener cuando el ciclo de mantenimiento se mide en décadas. (Software de AutoLisp encontrado en AutoCAD)

Answer 9

mi humilde opinión, OO simplemente significa objetos que interactúan con otros objetos. La encapsulación significa simplemente la abstracción de un concepto. Así, se crea un socket y .Connect () para algo. ¿Cómo se conecta, que realmente no importa (que es básicamente mi definición de encapsulación).

Y, la programación funcional pura puede utilizar el objeto de comunicar .. pero esos objetos tienen que ser inmutable. Así, de nuevo en mi humilde opinión, FP puede utilizar fácilmente concepto OO; lenguaje imperativo como C aún puede utilizar el concepto de OO .. por ejemplo, un archivo para cada "clase" con una sección privada que no debe ser utilizado.

Answer 10

Su pregunta se lee como si quiera obtener los beneficios de una casa analizando un ladrillo.

Tener la capacidad de proporcionar contexto semántico y encapsulación son solo las capacidades básicas de una clase en OO.(Al igual que un ladrillo puede resistir una cierta fuerza y ​​reclamar un cierto espacio).

Para continuar con la analogía:Para aprovechar al máximo los ladrillos, simplemente júntelos.Lo mismo se aplica a clases y objetos.

Allá Hay muchos patrones de diseño. que se puede usar para la programación OO.La mayoría de ellos confían en las habilidades "encapsulación" y "semántica", que mencionaste.

Algunos de esos patrones son incluso una respuesta al tercer párrafo de su pregunta:

• Si desea ampliar el comportamiento de una clase existente, puede crear una clase derivada.
• Si desea ampliar o cambiar el comportamiento de un objeto existente, puede considerar la opción patrón decorador.

Answer 11

El poder real de OO radica en el polimorfismo en lugar de encapsulación. Encapsulación, en cierta medida, es alcanzable y se utiliza en los lenguajes funcionales, pero polimorfismo sería muy incómodo si se implementa en un lenguaje funcional.

(Lea "patrón de diseño" por banda de los cuatro a entender el poder de OO.)

@Phil, la diferencia que usted ha mencionado, si he entendido bien, es entre la forma en que el programa invoca datos / Método: oo, hay primero un objeto / instancia, y luego los datos / se invoca el método del objeto a través del objeto; en funcional, el método se invoca directamente.

Sin embargo, mirando a la implementación de un programa funcional, vemos que los datos y el método están envueltos (en un archivo, pero no en una clase). Por ejemplo, un programa de C tiene el archivo de cabecera que declara las funciones accesibles por otro archivo, y los datos es un dato privado, si sólo se puede acceder a través de estas funciones declaradas. Mientras un programador es lo suficientemente cuidadoso, la mayor parte de la encapsulación en OO se pueden implementar en programas funcionales. (Incluso la herencia está disponible mediante el uso de ciertos trucos puntero.)