language-agnostic - would - what is a programming paradigm in computer science
¿Es la fuerza del diseño OO en semántica o encapsulación? (11)
El diseño orientado a objetos (OOD) combina datos y sus métodos. Esto, por lo que puedo ver, logra dos grandes cosas: proporciona encapsulación (por lo que no me importa qué datos hay, solo cómo obtengo los valores que quiero) y semántica (relaciona los datos con los nombres, y su los métodos utilizan sistemáticamente los datos como se pretendía originalmente).
Entonces, ¿dónde está la fuerza de OOD? En contraste, la programación funcional atribuye la riqueza a los verbos en lugar de a los sustantivos, por lo que tanto la encapsulación como la semántica son proporcionadas por los métodos en lugar de las estructuras de datos.
Trabajo con un sistema que está en el extremo funcional del espectro, y continuamente añico 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. Así que en este momento, puedo ver la semántica como una mayor fortaleza.
¿O es la encapsulación la clave de todo código valioso?
Edición: Me refiero específicamente al tipo de encapsulación que OO proporciona aquí. changeColor(door,blue) convierte en door.changeColor(blue) .
Alguna forma de modularidad es la clave para cualquier diseño escalable. Las limitaciones de los seres humanos impiden que las personas "asimilen" demasiada información a la vez, por lo que tenemos que subdividir los problemas en partes manejables y cohesivas, tanto para proporcionar una base para comprender un proyecto grande como para subdividir las tareas laborales De un gran proyecto entre muchas personas.
¿Cómo elegir la "división" / "partición" más efectiva de un proyecto grande para cumplir los objetivos anteriores? 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 supuestos específicos de la implementación que es probable que tengan que cambiar a lo largo del tiempo sobre su implementación - y expone una interfaz que es agnóstica a estos supuestos; La superposición de estas abstracciones encapsuladas hace posible la arquitectura de un diseño robusto donde los componentes / implementaciones pueden intercambiarse fácilmente ante los cambios anticipados.
- Centrado en el nombre : en la mayoría de los dominios, los humanos parecen ser mejores al descomponer un modelo de dominio al pensar en los sustantivos / datos de un dominio, seguido de la identificación de los verbos de apoyo que están asociados con cada sustantivo.
Respecto a la programación funcional (FP) versus OO, he realizado un blogged sobre esto, pero brevemente creo que FP tiene más que ver con las técnicas de implementación, mientras que OO tiene más que ver con la estructura y el diseño del programa, y por lo tanto los dos son complementarios, con OO más dominante en El extremo "grande" de la escala y la PF son más dominantes en el extremo "pequeño". Es decir, en un proyecto grande, la estructura de alto nivel se describe mejor mediante el diseño de la clase OO, pero muchos de los detalles a nivel de módulo (implementaciones y detalles de las formas de las interfaces de los módulos) están mejor formados por FP influencias.
Como programador de Lisp, cuyo sistema de objetos posiblemente no proporcione ninguno de estos, digo: ninguno de los anteriores.
jwz: "el modelo de objetos pseudo-Smalltalk pierde y las funciones genéricas (convenientemente limitadas por la regla de no anulaciones externas) ganan".
Creo que los atributos deseables que usted y otros enlistan aquí (encapsulación, modularidad, etc.) no son tan inherentes a OO como usted piensa. A menudo se proporcionan junto con OO de estilo Java, pero no son simplemente la consecuencia de ello.
Demos un paso atrás y veamos esto desde un nivel superior. Las ventajas de cualquier característica de lenguaje radican 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 implementa fácilmente en C simple con estructuras y punteros de función. Incluso puedes sentir un poco de OOP haciéndolo de esa manera. Sin embargo, los modismos OOP no son tan próximos en un entorno de este tipo. Cuando existe un soporte de lenguaje real para la POO, entonces surge la expresividad del paradigma, y la forma en que un lenguaje implementa una idea tiene un impacto muy real en lo que se "dice" y cómo. Por ejemplo, vea las diferencias en el código usando cierres / lambdas en lisp, python, ruby, etc.
Así que al final no se trata de los componentes y conceptos subyacentes, sino de cómo se combinan y se usan para hacer de OO en C ++ lo que es.
El poder real de la OO radica en el polimorfismo en lugar de la encapsulación. La encapsulación, hasta cierto punto, es alcanzable y se usa en lenguajes funcionales, pero el polimorfismo sería muy incómodo si se implementa en un lenguaje funcional.
(Lea "patrón de diseño" por grupo de cuatro para comprender el poder de OO).
@Phil, la diferencia que mencionaste, si te entiendo correctamente, es entre la forma en que el programa invoca datos / método: en oo, primero hay un objeto / instancia, y luego los datos / método del objeto se invocan a través del objeto ; En funcional, el método se invoca directamente.
Sin embargo, al observar la implementación de un programa funcional, vemos que los datos y el método están ajustados (en un archivo pero no en una clase). Por ejemplo, un programa C tiene el archivo de encabezado que declara el acceso a las funciones de otro archivo, y los datos son datos privados si solo se puede acceder a través de estas funciones declaradas. Mientras un programador sea lo suficientemente cuidadoso, la mayor parte de la encapsulación en OO se puede implementar en programas funcionales. (Incluso la herencia está disponible mediante ciertos trucos de puntero).
En mi humilde opinión, OO simplemente significa objetos que interactúan con otros objetos. La encapsulación simplemente significa abstraer un concepto. Entonces, creas un Socket y .Connect () a algo. Cómo se conecta, realmente no te importa (que es básicamente mi definición de encapsulación).
Y, la programación funcional pura puede usar objetos para comunicarse ... pero esos objetos deben ser inmutables. Así que, de nuevo IMHO, FP puede usar fácilmente el concepto OO; Un lenguaje imperativo como C todavía puede usar el concepto de OO .. por ejemplo, un archivo para cada "Clase" con una sección privada que no debe usarse.
Encapsulación en conjunción con polimorfismo. La capacidad de las clases en la mayoría de los lenguajes OOP para implementar una o más interfaces ha tenido el mayor impacto en el desarrollo de mi software. Esta característica me permite definir con precisión la interacción entre dos objetos.
No solo defina las interacciones, sino que documéntelas para que años más tarde pueda volver a esa sección del código y ver qué está sucediendo claramente.
Esta característica es la razón principal por la que prefiero usar lenguajes OOP en lugar de lenguajes funcionales. Si bien es muy poderoso, el software escrito en lenguajes funcionales es un problema para mantener cuando el ciclo de mantenimiento se mide en décadas. (Se encuentra el software AutoLisp en AutoCAD)
La encapsulación y la abstracción resultante son claramente las principales fortalezas de OO. Las "cosas" predican qué "acciones" pueden invocarse en ellas, por lo que los sustantivos adquieren una mayor importancia semántica que los verbos.
En última instancia, es difícil imaginar el diseño de un sistema complejo en una forma consistente y mantenible sin un cierto nivel de encapsulación.
La fuerza del diseño orientado a objetos es proporcional a la cantidad de encuadernación tardía que se produce en el diseño. Esta es la noción de Kay de OO, no la noción de Nygaard. Alan Kay escribió :
Para mí, OOP significa solo mensajes, retención y protección local y ocultamiento del proceso de estado, y una vinculación final extrema de todas las cosas. Se puede hacer en Smalltalk y en LISP. Posiblemente hay otros sistemas en los que esto es posible, pero no estoy al tanto de ellos.
Gran parte de la literatura ignora la vinculación tardía en favor de la idea de orientación a objetos en C ++.
Parece que estás usando una definición bastante restringida de "Encapsulación". ¿Estaría en lo cierto al suponer que definirías la encapsulación como "Combinar datos con métodos?"
Si me equivoco, ignora el resto de esta publicación.
La encapsulación no es un término suelto; de hecho, está definido por la Organización Internacional de Normalización. El modelo de referencia de ISO de procesamiento distribuido abierto: define 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 ocurrir.
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 ocurrir.
Encapsulación: la propiedad de que la información contenida en un objeto es accesible solo a través de las interacciones en las interfaces soportadas por el objeto.
Además, podemos hacer una propuesta evidente: como se puede acceder a cierta información a través de estas interfaces, cierta información debe estar oculta e inaccesible dentro del objeto. La propiedad que exhibe dicha información se denomina ocultación de información, que Parnas define al argumentar que los módulos deben diseñarse para ocultar decisiones difíciles y decisiones que probablemente cambien, vea uno de los grandes artículos informáticos:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
Es importante tener en cuenta que no solo los datos están ocultos en la información: es un subconjunto de comportamiento asociado con el objeto lo que es difícil o probable que cambie.
En su publicación, 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 según ISO y Parnas, la gestión de datos no es la clave para la encapsulación. Así que no veo por qué la encapsulación en la programación funcional tiene que ser diferente de la de OO.
Además, menciona en su publicación que la programación funcional proporciona encapsulación, "... por los métodos en lugar de las estructuras de datos". Esto, creo, es una diferencia de escala en lugar de absoluta. Si uso la palabra "Objeto" en lugar de "Estructura de datos" (nuevamente, hágame saber si estoy malinterpretando), entonces parece encontrar importancia en la encapsulación OO por objeto y en la encapsulación por programación funcional por método.
Sin embargo, según la definición de ISO anterior, un objeto es algo que deseo modelar. Por lo tanto, las clases se pueden encapsular dentro de un paquete, siempre que algunas de esas clases contribuyan a la interfaz del paquete (es decir, las clases públicas del paquete) y algunas estén ocultas en información (las clases privadas en el paquete).
De la misma manera, los métodos se encapsulan dentro de una clase: algunos métodos son públicos y otros privados. Incluso puede tomar esto un poco más abajo y decir que las secuencias secuenciales de código de McCabian están encapsuladas dentro de los métodos. Cada uno forma una gráfica de nodos encapsulados dentro de regiones encapsuladas; y todos estos gráficos forman una pila de gráficos. Por lo tanto, la programación funcional puede encapsularse a nivel de función / archivo, pero esto no es diferente del método / gráfico de clase de OO, y esencialmente tampoco hay diferencia del gráfico de clase / paquete de OO.
Además, tenga en cuenta que la palabra Parnas utiliza arriba: cambiar. La ocultación de la información se refiere a eventos potenciales, como el cambio de decisiones de diseño difíciles en el futuro. Preguntas dónde está la fuerza de OO; Bueno, la encapsulación es ciertamente una fuerza de OO, pero la pregunta entonces es: "¿Dónde está la fuerza de la encapsulación?" y la respuesta es de una claridad rotunda: la gestión del cambio. En particular, la encapsulación reduce la carga potencial máxima de cambio.
El concepto de "acoplamiento de potencial" es útil aquí.
El "acoplamiento", en sí mismo, se define como "una medida de la fuerza de asociación establecida por una conexión de un módulo a otro", en otro de los grandes artículos de computación:
http://www.research.ibm.com/journal/sj/382/stevens.pdf
Y como dice el documento, en palabras que nunca han mejorado, "Minimizar las conexiones entre los módulos también minimiza las rutas por las cuales los cambios y errores se propagan a otras partes del sistema, eliminando así los efectos desastrosos" Rizo ", donde los cambios en una parte causan errores en otro, que requieren cambios adicionales en otros lugares, dando lugar a nuevos errores, etc. "
Sin embargo, tal como se define aquí, hay dos limitaciones que pueden eliminarse fácilmente. En primer lugar, el acoplamiento no mide las conexiones intra-módulo, y estas conexiones intra-módulo pueden dar lugar a tantos "efectos de ondulación" como las conexiones entre módulos (el documento define, "Cohesión", para relacionar intra-módulo elementos, pero esto no se define en términos de conexiones entre elementos (es decir, referencias a etiquetas o direcciones) con las que se definió el acoplamiento). En segundo lugar, el acoplamiento de cualquier programa de computadora es un hecho, ya 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 que habla Parnas.
Ambos problemas se resuelven, en cierta medida, con el concepto de posible acoplamiento: el número máximo posible de conexiones que se pueden configurar entre todos los elementos de un programa. En Java, por ejemplo, una clase que es un paquete privado (el acceso predeterminado) dentro de un paquete no puede tener conexiones formadas (es decir, ninguna clase externa puede depender de él, a pesar de la reflexión), pero una clase pública dentro de un paquete puede tener dependencias en ello. Esta clase pública contribuiría al posible acoplamiento incluso si ninguna otra clase dependiera de ella en este momento; las clases podrían depender de ella en el futuro, cuando el diseño cambie.
Para ver la fuerza de la encapsulación, considere el Principio de Carga. El principio de carga toma dos formas.
La forma sólida indica que la carga de transformar una colección de entidades es una función del número de entidades transformadas. La forma débil indica que la carga potencial máxima de transformar una colección de entidades es una función de la cantidad máxima potencial de entidades transformadas.
La carga de crear o modificar cualquier sistema de software es una función del número de clases creadas o modificadas (aquí usamos, "Clases", suponiendo un sistema OO, y nos preocupa la encapsulación a nivel de clase / paquete; preocupados por la función / nivel de archivo de la programación funcional). (Tenga en cuenta que la "carga" es que el desarrollo moderno de software suele ser el costo, el tiempo o ambos). Las clases que dependen de una clase modificada en particular tienen una mayor probabilidad de ser impactadas que las clases que no dependen de la clase modificada. .
La carga potencial máxima que puede imponer una clase modificada es el impacto de todas las clases que dependen de ella.
La reducción de las dependencias en una clase modificada, por lo tanto, reduce la probabilidad de que su actualización afecte a otras clases y, por lo tanto, reduce la carga potencial máxima que esa clase puede imponer. (Esto es poco más que una nueva declaración del documento “Diseño estructurado”).
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 en una clase particular cause actualizaciones a otras clases, y por lo tanto reduce la carga potencial máxima de todas las actualizaciones.
La encapsulación, al reducir el número máximo potencial de dependencias entre todas las clases, por lo tanto mitiga la forma débil del Principio de Carga. Todo esto está cubierto por la "teoría de la encapsulación", que intenta probar matemáticamente tales afirmaciones, utilizando el acoplamiento potencial como el medio lógico de estructurar un programa.
Sin embargo, tenga en cuenta que cuando pregunte: “¿Es la encapsulación la clave de todo código valioso?” La respuesta seguramente debe ser: no. No hay una sola clave para todo código valioso. La encapsulación es, en ciertas circunstancias, simplemente una herramienta para ayudar a mejorar la calidad del código para que se convierta en "útil".
También escribe que, "... la encapsulación puede ser una barrera para la extensión flexible de un objeto". Sí, ciertamente puede: está diseñada para ser una barrera contra la extensión de las decisiones de diseño de un objeto que es difícil o probable que cambie. Sin embargo, esto no se piensa que sea algo malo. Un enfoque alternativo sería tener todas las clases públicas y un programa que exprese su máximo potencial de acoplamiento; pero luego la forma débil del Principio de la carga establece que las actualizaciones serán cada vez más costosas; estos son los costos contra los cuales se deben medir las barreras a la extensión.
Finalmente, hace una comparación interesante entre la encapsulación y la semántica, y eso, en su opinión, la semántica de OO es su mayor fortaleza. Tampoco soy semántico (ni siquiera sabía que existía una palabra antes de que el buen señor Ramsey lo aludiera en su comentario), pero supongo que quiere decir "semántica", en el sentido de "el significado, o una interpretación del significado, de una palabra "y muy básicamente que una clase con un método, woof () debe llamarse perro.
Hay una gran fuerza de hecho en esta semántica.
Lo que me parece curioso es que usted enfrenta la semántica con la encapsulación y busca un ganador; Dudo que encuentres uno.
En mi opinión, hay dos fuerzas que motivan la encapsulación: la semántica y la lógica.
La encapsulación semántica simplemente significa encapsulación basada en el significado de los nodos (para usar el término general) encapsulados. Entonces, si le digo que tengo dos paquetes, uno llamado ''animal'' y otro llamado ''mineral'' y luego le doy tres clases: Perro, Gato y Cabra, y pregunto en qué paquetes deben encapsularse estas clases, luego no hay otra información, sería perfectamente correcto afirmar que la semántica del sistema sugeriría que las tres clases se encapsularían dentro del paquete "animal", en lugar de "mineral".
La otra motivación para la encapsulación, sin embargo, es la lógica, y en particular el estudio del posible acoplamiento, mencionado anteriormente. La teoría de la encapsulación en realidad proporciona ecuaciones para el número de paquetes que deben usarse para encapsular un número de clases con el fin de minimizar el posible acoplamiento.
Para mí, la encapsulación en su conjunto es el equilibrio entre este enfoque semántico y lógico: permitiré que el posible acoplamiento de mis programas supere el mínimo si esto hace que el programa sea semánticamente más fácil de entender; pero los enormes y derrochadores niveles de acoplamiento potencial serán una advertencia de que mi programa debe ser reestructurado, sin importar cuán semánticamente sea obvio.
(Y si el buen Mister Ramsey todavía está leyendo, ¿podría usted o sus amigos semánticos darme una palabra mejor para la fase "Semántica" que estoy usando aquí? Sería bueno usar un término más apropiado).
Saludos, Ed.
Su pregunta se lee como si quisiera 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 soportar una cierta fuerza y reclamar un cierto espacio.)
Para continuar con la analogía: para sacar el máximo provecho de los ladrillos, simplemente júntelos. Lo mismo se aplica a las clases y los objetos.
Hay muchos patrones de diseño que se pueden usar para la programación OO. La mayoría de ellos se basan en las habilidades de "encapsulación" y "semántica", que usted mencionó.
Algunos de esos patrones son incluso una respuesta al tercer párrafo de Tu pregunta:
- Si desea extender el comportamiento de una clase existente, puede crear una clase derivada.
- Si desea ampliar o cambiar el comportamiento de un objeto existente, podría considerar el patrón decorador .
El objetivo principal de cualquier diseño es aislar la complejidad. El objetivo principal de cualquier diseño es encapsular la funcionalidad detrás de una interfaz que sea más fácil de usar que la funcionalidad en sí.
OO proporciona varios mecanismos para eso, los dos oyu mencionan:
La encapsulación permite diseñar una superficie personalizada que es independiente de la implementación real. (Parafraseando, "más simple significa diferente").
La semántica permite modelar entidades que representan elementos del dominio del problema, para que sean más fáciles de entender.
Cualquier proyecto que alcance un cierto tamaño se convierte en un ejercicio de gestión de la complejidad. Apostaría un reclamo que a lo largo de los años, la programación se ha extendido a lo largo de los límites de complejidad que hemos aprendido a gestionar.
No he incursionado en la programación funcional durante años, pero a mi entender, se puede describir mejor por el significado de un matemático de las palabras poderoso, elgante, y hermoso. "Hermoso" y "elegante", en este contexto, trata de describir una visión brillante de la estructura verdadera o relevante de un sistema complejo, mirándolo desde un punto de vista donde es sorprendentemente simple. acepta la complejidad como un dado, y trata de navegarla.
La flexibilidad que menciona es, según entiendo, la capacidad de cambiar el punto de vista según sus necesidades, pero eso va en contra de la encapsulación: lo que es un detalle sin sentido desde una posición puede ser lo único relevante en otra.
OO, OTOH, es el enfoque reduccionista: cambiamos POV al ir a un nivel más alto. En "OO antiguo", hay una sola jerarquía de POV, las interfaces son, en este modelo, una forma de modelar diferentes POV.
Si puedo decirlo, la fuerza de OO se está adaptando mejor a las "personas normales".