Desafiantes importantes para la programación orientada a objetos
https://stackoverflow.com/questions/944977
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Por lo que tengo entendido, la programación orientada a objetos es el paradigma más utilizado para proyectos a gran escala.También sé que algunos subconjuntos más pequeños de grandes sistemas utilizan otros paradigmas (por ejemplo,SQL, que es declarativo), y también me doy cuenta de que en niveles más bajos de computación, la programación orientada a objetos no es realmente factible.Pero me parece que, por lo general, las piezas de las soluciones de nivel superior casi siempre se ensamblan en forma de programación orientada a objetos.
¿Existen escenarios en los que un paradigma verdaderamente no orientado a objetos sea en realidad un mejor elección para una solución a gran escala?¿O es algo inaudito hoy en día?
Me he preguntado esto desde que comencé a estudiar informática;Es fácil tener la sensación de que la programación orientada a objetos es un nirvana de programación que nunca será superado.
Solución
En mi opinión, la razón por la programación orientada a objetos se utiliza tan ampliamente no es tanto que es la herramienta adecuada para el trabajo. Creo que es más que una solución puede ser descrito al cliente de una manera que ellos entienden.
A CAR es un vehículo que tiene un motor. Esa es la programación y el mundo real, todo en uno!
Es difícil de comprender todo lo que puede caber el mundo de la programación y real tan elegante.
Otros consejos
Linux es un proyecto a gran escala que es en gran medida no programación orientada a objetos. Y no tendría mucho que ganar con ella tampoco.
Creo programación orientada a objetos tiene un buen anillo a ella, ya que se ha asociado con las buenas prácticas de programación como encapsulación, ocultación de datos, la reutilización de código, et.c. modularidad Pero estas virtudes son de ninguna manera única de la POO.
Es posible que tenga una mirada en Erlang, escrita por Joe Armstrong.
Wikipedia:
"Erlang es una de propósito general lenguaje de programación concurrente y sistema de ejecución. El subconjunto secuencial de Erlang es un lenguaje funcional, con evaluación estricta, solo asignación, y tipado dinámico. "
Joe Armstrong:
“Debido a que el problema lenguajes orientados a objetos es ellos tienen tengo todo este entorno implícita de que que llevan consigo. Tú quería un plátano, pero lo que se obtuvo fue una gorila que sostiene el plátano y la toda la selva “.
La promesa de la programación orientada a objetos fue la reutilización de código y un mantenimiento más fácil. No estoy seguro de que entregan. Veo cosas tales como la red del punto de ser lo mismo que las bibliotecas de C que utilizamos para llegar aquí para allá varios vendedores. Usted puede llamar a que la reutilización de código si lo desea. En cuanto al mantenimiento de código mal es mal código. Programación orientada a objetos no ayudó.
Soy el mayor fanático de la programación orientada a objetos y la practico todos los días.Es la forma más natural de escribir código, porque se parece a la vida real.
Sin embargo, me doy cuenta de que la virtualización de la programación orientada a objetos puede causar problemas de rendimiento.Por supuesto, eso depende de su diseño, el lenguaje y la plataforma que elija (los sistemas escritos en lenguajes basados en recolección de basura como Java o C# pueden funcionar peor que los sistemas escritos en C++, por ejemplo).
Supongo que en los sistemas en tiempo real, la programación de procedimientos puede ser más apropiada.
Zyx, que escribió: "La mayoría de los sistemas utilizan bases de datos relacionales ..."
Me temo que no hay tal cosa. El modelo relacional será de 40 años de edad el próximo año y todavía no ha sido implementado. Creo que quieres decir, "bases de datos SQL." Debe leer nada por Fabian Pascal para entender la diferencia entre un DBMS relacional y un DBMS SQL.
"... modelo relacional suele ser elegido debido a su popularidad,"
Es verdad, es muy popular.
"... disponibilidad de herramientas,"
Por desgracia, sin la herramienta principal, es necesario:. Una implementación del modelo relacional
"apoyo"
Sí, el modelo relacional ha de soporte bien, estoy seguro, pero es totalmente soportado por una aplicación DBMS.
"y el hecho de que el modelo relacional es en realidad un concepto matemático,"
Sí, es un concepto matemático, pero, no siendo implementado, se limita en gran medida a las torres de marfil. La teoría de cuerdas es también un concepto matemático pero no implementaría un sistema con él.
De hecho, a pesar de que está siendo un concepto methematical, desde luego, no es una ciencia (como en la informática), ya que carece el primer requisito de cualquier ciencia: que es falsable: no hay implementación de un DBMS relacional contra el cual nos puede comprobar sus afirmaciones.
Es puro aceite de serpiente.
"... al contrario de programación orientada a objetos."
Y al contrario de programación orientada a objetos, el modelo relacional nunca se ha aplicado.
Comprar un libro en SQL y obtener productivo.
Deja el modelo relacional para los teóricos improductivas.
este y esta . Aparentemente se puede utilizar C # con cinco diferentes paradigmas de programación, C ++ con tres, etc.
construcción de software no es afín a la Física Fundamental. Physics esfuerzan por describir la realidad usando paradigmas que pueden ser desafiados por nuevos datos y / o teorías experimentales. La física es una ciencia que busca una "verdad", de manera que la construcción del software no lo hace.
construcción de software es un negocio . Tienes que ser productiva , es decir, para lograr algunos de los objetivos para los que alguien va a pagar dinero. Paradigmas se usan porque son útiles a software de productos de manera efectiva . No es necesario que todo el mundo de acuerdo. Si hago programación orientada a objetos y que está funcionando bien para mí, no me importa si es un "nuevo" paradigma podría ser potencialmente un 20% más útil para mí si tuviera el tiempo y dinero para aprender y más tarde reconsiderar toda la estructura del software I' m trabajando en y rediseñar desde cero.
Además, puede que esté utilizando otro paradigma y todavía estaré feliz, de la misma manera que puedo ganar dinero ejecutando un restaurante de comida japonesa y se puede ganar dinero con un restaurante de comida mexicana al lado. No necesito discutir con usted si la comida japonesa es mejor que la comida mexicana.
Dudo POO va a desaparecer en el corto plazo, sólo se ajusta a nuestras problemas y modelos mentales demasiado bien.
Lo que estamos empezando a ver, aunque es enfoques multi-paradigma, con ideas declarativas y funcionales que se incorporan en el diseño orientado a objetos. La mayoría de los idiomas JVM nuevos son un buen ejemplo de esto (JavaFX, Scala, Clojure, etc.), así como LINQ y F # en la plataforma .NET.
Es importante tener en cuenta que no estoy hablando de reemplazar OO aquí, sino de complementarla.
-
JavaFX ha demostrado que un declarativa solución va más allá de SQL y XSLT, y también puede ser utilizado para la unión propiedades y eventos entre visual componentes en una interfaz gráfica de usuario
-
Para tolerante a fallos y altamente sistemas concurrentes, funcional programación es un muy buen ajuste, como se demuestra por el Ericsson AXD301 (programado usando Erlang)
Así que ... como la concurrencia se vuelve más importante y FP se hace más popular, imagino que las lenguas no apoyar este paradigma se verá afectada. Esto incluye muchos que son actualmente populares, tales como C ++, Java y Ruby, aunque JavaScript debe hacer frente muy bien.
El uso de programación orientada a objetos hace que el código sea más fácil de manejar (como en Modificar / actualizar / añadir nuevas características) y entender. Esto es especialmente cierto con los proyectos más grandes. Debido a que los módulos / objetos encapsulan sus datos y las operaciones en esos datos, es más fácil comprender la funcionalidad y el cuadro grande.
El beneficio de la programación orientada a objetos es que es más fácil discutir (con otros desarrolladores / gestión / cliente) un LogManager o OrderManager, cada uno de los cuales abarca una funcionalidad específica, a continuación, que describe 'un grupo de métodos que volcar los datos en el archivo' y 'los métodos que mantienen un registro de los detalles de la orden.
Así que supongo programación orientada a objetos es muy útil sobre todo con grandes proyectos, pero siempre hay nuevos conceptos que dan vuelta hacia arriba a fin de mantener el puesto de observación para cosas nuevas en el futuro, evaluar y mantener lo que es útil.
La gente le gusta pensar en varias cosas como "objetos" y clasificarlos, por lo que no cabe duda de que la POO es tan popular. Sin embargo, hay algunas áreas en las que la POO no ha ganado una popularidad más grande. La mayoría de los sistemas utilizan bases de datos relacionales en lugar de objetivo. Incluso si los segundos sostienen algunos registros notables y son mejores para algunos tipos de tareas, el modelo relacional se elige unsually debido a su popularidad, la disponibilidad de herramientas, soporte y el hecho de que el modelo relacional es en realidad un concepto matemático, en contra de programación orientada a objetos.
Otra área en la que nunca he visto programación orientada a objetos es el proceso de construcción de software. Toda la configuración y hacen scripts son de procedimiento, en parte debido a la falta de apoyo para la programación orientada a objetos en los idiomas de la cáscara, en parte porque OOP es demasiado complejo para tales tareas.
Un poco controvertido opinión de mí, pero no encuentro programación orientada a objetos, al menos, de un tipo que se aplica popularmente ahora, a ser que útiles en la producción de software de mayor escala en mi dominio particular (VFX , que es algo similar en la organización de escena y el estado de aplicación como los juegos). Me resulta muy útil en un medio a menor escala. Tengo que ser un poco cuidadoso aquí, ya he invitado a algunos monstruos en el pasado, pero debería matizar que esto es en mi experiencia en mi estrecho tipo particular de dominio.
La dificultad que he encontrado a menudo es que si usted tiene todos estos pequeños objetos concretos que encapsulan los datos, que ahora quieren todos hablan el uno al otro. Las interacciones entre ellos pueden llegar a ser extremadamente compleja, al igual que (excepto mucho, mucho más complejo en una aplicación real que abarca miles de objetos):
Y esto no es un gráfico dependencia directamente relacionados con el acoplamiento de tanto como un "gráfico de interacción". Podría haber abstracciones a desvincular estos objetos concretos de la otra. Foo no podría hablar con Bar directamente. En su lugar, podría hablar con él a través IBar o algo por el estilo. Esta gráfica todavía conectar a Foo Bar ya que, si bien está desacoplado, que todavía hablan el uno al otro.
Y todo ello la comunicación entre las pequeñas y medianas objetos que componen su propio pequeño ecosistema, si se aplica a toda la escala de una gran base de código en mi dominio, puede llegar a ser extremadamente difícil de mantener. Y se hace tan difícil de mantener, ya que es difícil de razonar acerca de lo que sucede con todas estas interacciones entre los objetos con respecto a cosas como efectos secundarios.
En su lugar lo que he encontrado útil es organizar el código base global en subsistemas completamente independientes, fuertes que tienen acceso a una "base de datos" central. Cada subsistema continuación, las entradas y salidas de datos. Algunos otros subsistemas pueden acceder a los mismos datos, pero sin ningún sistema de hablar directamente entre sí.
... o esto:
... y cada sistema individual ya no intenta encapsular estado. No trata de convertirse en su propio ecosistema. En su lugar, lee y escribe datos en la base de datos central.
Por supuesto, en la ejecución de cada subsistema, puede ser que utilicen una serie de objetos para ayudar a ponerlas en práctica. Y ahí es donde me encuentro programación orientada a objetos es muy útil en la implementación de estos subsistemas. Pero cada uno de estos subsistemas constituye un medio relativamente al proyecto de pequeña escala, no demasiado grande, y es en ese medio a escala más pequeña que me parece muy útil programación orientada a objetos.
"Programación de la cadena de montaje" con el conocimiento mínimo
Esto permite a cada subsistema sólo se centran en hacer lo suyo con casi ningún conocimiento de lo que está pasando en el mundo exterior. Un desarrollador centrado en la física simplemente puede sentarse con el subsistema de la física y saber poco acerca de cómo funciona el software, excepto que hay una base de datos central a partir del cual se puede recuperar cosas como componentes de movimiento (sólo datos) y transformarlas mediante la aplicación de la física a esos datos. Y eso hace que su trabajo muy sencillo y lo hace para que pueda hacer lo que mejor sabe hacer con el conocimiento mínimo de cómo funciona todo lo demás. datos central de entrada y salida de datos central: Eso es todo cada subsistema tiene que hacer correctamente para todo lo demás a trabajar. Es lo más parecido que he encontrado en mi campo de "programación cadena de montaje"donde cada desarrollador puede hacer de las suyas con mínimos conocimientos sobre cómo funciona el sistema en su conjunto.
La prueba es todavía bastante simple también debido a la estrechez de cada subsistema. Ya no estás burlando de objetos concretos con la inyección de dependencia tanto como la generación de una cantidad mínima de datos relevantes para un sistema en particular y probar si el sistema particular proporciona la salida correcta para una entrada dada. Con tan pocos sistemas a prueba (solo docenas pueden compensar un software complejo), sino que también reduce el número de pruebas requeridas sustancialmente.
Fractura encapsulación
Entonces, el sistema se convierte en una tubería más bien plano transformando estado de la aplicación central a través de subsistemas independientes que son prácticamente ajeno a la existencia del otro. A veces se puede apartar a un evento central en la base de datos que otros procesos del sistema, pero que otro sistema sigue siendo ajeno acerca de dónde ese evento vino. He encontrado que esto es la clave para hacer frente a la complejidad, al menos en mi dominio, y es efectiva a través de un sistema de entidad-componente.
Sin embargo, se parece algo más cercano a la programación de procedimiento o funcional en la escala amplia para desacoplar todos estos subsistemas y dejar que ellos trabajan con un mínimo conocimiento del mundo exterior ya que estamos rompiendo la encapsulación con el fin de alcanzar este objetivo y evitar requerir a los sistemas hablar entre sí. Al acercar el zoom, entonces usted puede encontrar su parte de los objetos que se utiliza para poner en práctica cualquiera de estos subsistemas, pero a una escala más amplia, los sistemas se asemeja a algo distinto de programación orientada a objetos.
datos globales
Tengo que admitir que estaba muy dudas acerca de la aplicación de ECS en un primer momento a un diseño arquitectónico en mi dominio, ya que, en primer lugar, que no se había hecho antes que yo sepa en competidores comerciales populares (3DS Max, Softimage, etc) y, segundo, se ve como un montón de datos globalmente accesible.
He encontrado, sin embargo, que esto no es un gran problema. Todavía podemos mantener de manera muy eficaz invariantes, tal vez incluso mejor que antes. La razón se debe a la forma en que el ECS organiza todo en los sistemas y componentes. Puede estar seguro de que un sistema de audio no tratará de mutar un componente de movimiento, por ejemplo, ni siquiera bajo la hackiest de situaciones. Incluso con un equipo pobremente coordinada, es muy improbable que el ECS se degradará en algo donde ya no se puede razonar sobre la cual el acceso sistemas de qué componente, ya que es bastante evidente en el papel y prácticamente no hay razón alguna para un determinado sistema de acceso un componente apropiado.
Por el contrario, a menudo elimina muchas de las antiguas tentaciones de cosas hacky con los datos abiertos ya que muchas de las cosas hacky hecho en nuestro antiguo código base bajo la coordinación y la escasez de tiempo suelta se hizo en los intentos apresurados a abstracciones de rayos x y tratar de acceder a la parte interna de los ecosistemas de los objetos. Las abstracciones comenzaron a presentar fugas como resultado de la gente, a toda prisa, tratando de obtener sólo y hacer cosas con los datos que querían acceder. básicamente que estaban saltando a través de aros tratando de acceder a los datos sólo que conducen a la interfaz diseños degradar rápidamente.
Hay algo vagamente parecido encapsulación siendo sólo debido a la forma en que el sistema está organizado ya menudo hay sólo un sistema de modificación de un tipo particular de componentes (dos en algunos casos excepcionales). Pero ellos no son dueños de esos datos, que no proporcionan funciones para recuperar esos datos. Los sistemas no se comunican entre sí. Todos ellos operan a través de la base de datos central ECS (que es la única dependencia que tiene que ser inyectado en todos estos sistemas).
flexibilidad y extensibilidad
Esto es ya ampliamente discutido en los recursos externos sobre los sistemas de la entidad-componente, sino que son extremadamente flexibles para adaptarse a las nuevas ideas de diseño radicalmente en hindsight, incluso concepto innovador queridos como una sugerencia para una criatura que es un mamífero, insecto, planta y que deja a los brotes bajo la luz solar a la vez.
Una de las razones es porque no hay abstracciones centrales de romper. Se introduce algunos componentes nuevos si necesita más datos para esta cuenta o crear una entidad que ensarta los componentes necesarios para una planta, mamíferos y de insectos. Los sistemas diseñados para procesar insectos, mamíferos y componentes de la planta, luego tome automáticamente y se puede producir el comportamiento que desea sin cambiar nada además de añadir una línea de código para crear instancias de una entidad con una nueva combinación de componentes. Cuando se necesita una funcionalidad completamente nueva, que acaba de añadir un nuevo sistema o modificar una existente.
Lo que no he encontrado discutido tanto en otros lugares es lo mucho que esto facilita el mantenimiento incluso en situaciones cuando no hay concepto innovador cambios de diseño que fue incapaz de prever. Incluso haciendo caso omiso de la flexibilidad de la ECS, lo que realmente puede simplificar las cosas cuando su código base alcanza una cierta escala.
Volviendo objetos en datos
En una base de código anterior OOP-pesado donde vi la dificultad de mantener una base de código más cerca de la primera gráfica anterior, la cantidad de código requerida explotó porque el Car analógico en este diagrama:
... tenía que ser construido como un subtipo completamente separado (clase) implementar múltiples interfaces. Así que tuvimos un número explosivo de objetos en el sistema: un objeto separado para las luces de punto de las luces direccionales, un objeto separado para una cámara de ojo de pez de otro, etc. tenido miles de objetos implementando unas pocas docenas de interfaces abstractas en un sinfín de combinaciones.
Cuando comparé a ECS, que requiere solamente cientos y hemos sido capaces de hacer exactamente las mismas cosas antes de usar una pequeña fracción del código, ya que convirtió la entidad Car analógica en algo que ya no requiere su clase. Se convierte en una simple colección de datos de los componentes como un ejemplo generalizado de un solo tipo Entity.
Alternativas programación orientada a objetos
Así que hay casos como este en programación orientada a objetos se aplican en exceso en el nivel más amplio del diseño puede empezar a degradarse muy mantenibilidad. En la vista de pájaro más amplia de su sistema, puede ayudar a aplanar y no tratar de modelar tan "profunda" con objetos interactuar con objetos que interactúan con los objetos, sin embargo, de manera abstracta.
La comparación de los dos sistemas en los que trabajé en el pasado y ahora, el nuevo tiene más características, pero tiene cientos de miles de LOC. El primero requiere más de 20 millones LOC. Por supuesto no es la comparación más justa ya que el primero tenía un enorme legado, pero si se toma una rebanada de los dos sistemas que son funcionalmente bastante igual sin el bagaje heredado (al menos lo más cercano a la igualdad como podríamos conseguir), la ECS toma una pequeña fracción de la código para hacer la misma cosa, y en parte debido a que reduce drásticamente el número de clases hay en el sistema, al convertirlos en colecciones (entidades) de datos en bruto (componentes) con los sistemas de fuertes para procesarlos en vez de un bote lleno de objetos pequeños / medios.
¿Hay situaciones donde un paradigma de programación orientada a objetos verdaderamente no es en realidad una mejor opción para una solución a gran escala? O es que estos insólito días?
Está lejos de ser desconocida. El sistema que estoy describiendo anteriormente, por ejemplo, es ampliamente utilizado en los juegos. Es bastante raro en mi campo (la mayoría de las arquitecturas en mi campo son COM-como con interfaces puros, y ese es el tipo de arquitectura que trabajé en el pasado), pero me he dado cuenta que mirando por encima de lo que los jugadores están haciendo cuando el diseño de una arquitectura hecha awundo de la diferencia en ser capaz de crear algo que todavía sigue siendo muy comprensible en el que crece y crece.
Dicho esto, algunas personas consideran ECS para ser un tipo de programación orientado a objetos por su propia cuenta. Si es así, no se asemeja a una especie de programación orientada a objetos la mayoría de nosotros se le ocurriría, ya que los datos (componentes y entidades que componen ellos) y funcionalidad (sistemas) están separados. Se requiere abandonar encapsulado a nivel de sistema amplio que a menudo se considera uno de los aspectos más fundamentales de la programación orientada a objetos.
Alto Nivel de codificación
Sin embargo, me parece que por lo general las piezas de soluciones de alto nivel casi siempre se ponen juntos de manera programación orientada a objetos.
Si se puede reconstruir una aplicación con código muy alto nivel, entonces tiende a ser más bien pequeña o mediana escala por lo que el código de su equipo tiene que mantener y, probablemente, se puede montar de manera muy eficaz el uso de programación orientada a objetos.
En mi campo de VFX, a menudo tenemos que hacer cosas que son relativamente de bajo nivel como el trazado de rayos, el procesamiento de imágenes, procesamiento de malla, la dinámica de fluidos, etc, y no podemos piece estos juntos a partir de productos de terceros, ya que' re realmente competir más en términos de lo que podemos hacer por el bajo nivel (los usuarios obtener más entusiasmados de vanguardia, competitivos mejoras de renderizado de producción que, por ejemplo, una interfaz gráfica de usuario más agradable). Por lo tanto no puede haber montones y montones de código que van desde un nivel muy bajo de barajado de bits y bytes a muy código de alto nivel que programadores escriben a través de los lenguajes de script incrustado.
Interweb de Comunicación
Pero llega un punto con un gran escala suficiente con cualquier tipo de aplicación, de alto nivel o de bajo nivel o un combo, que gira en torno a un estado de aplicación central muy complejo en el que he descubierto que ya no es útil para tratar para encapsular todo en objetos. Si lo hace, tiende a multiplicar la complejidad y la dificultad para razonar sobre lo que sucede debido a la cantidad multiplicada de interacción que tiene lugar entre todo. Ya no se hace tan fácil de razonar sobre miles de ecosistemas que hablan entre sí, si no hay un punto de ruptura a gran escala lo suficientemente donde dejamos modelar cada cosa como ecosistemas encapsuladas que tienen que hablar entre sí. Incluso si cada uno es simple forma individual, todo tomada en su conjunto puede comenzar a más de abrumar a la mente, y que a menudo tiene que tomar un montón de que, en hacer cambios y añadir nuevas funciones y cosas de depuración y así sucesivamente si tratar de girar en el diseño de todo un sistema a gran escala únicamente en torno a principios de POO. Puede ayudar a liberarse de encapsulación en algún escala para al menos algunos dominios.
En ese punto no es necesariamente tan útil ya que, por ejemplo, tiene un sistema de física encapsular sus propios datos (de lo contrario muchas cosas podrían querer hablar con ella y recuperar esos datos, así como inicializarlo con los datos de entrada apropiados), y ahí es donde me encontré con esta alternativa a través de ECS tan útil, ya que convierte el sistema de física analógica, y todos esos sistemas fuertes, en un "transformador de la base de datos central" o un "lector de base de datos central que da salida a algo nuevo", que ahora puede ser ajeno acerca El uno al otro. Cada sistema luego empieza a parecerse más como un proceso en una tubería plana de un objeto que forma un nodo en un gráfico muy compleja de comunicación.
