Desde que comencé a estudiar programación orientada a objetos, leo con frecuencia artículos/blogs diciendo que las funciones son mejores, o no todos los problemas deben modelarse como objetos. A partir de tus aventuras de programación personal, ¿cuándo crees que un problema se resuelve mejor con OOP?¿Cuándo es mejor OOP?
No hay una regla difícil. Un problema se resuelve mejor con OOP cuando es mejor para resolver problemas y pensar en una mentalidad de OO. La orientación a objetos es solo otra herramienta que ha surgido al tratar de hacer de la informática una mejor herramienta para resolver problemas.
Sin embargo, puede permitir una mejor reutilización del código y también puede generar un código más ordenado. Pero a menudo estas cualidades altamente elogiadas son, en realidad, de poco valor real. Aplicar técnicas OO a una aplicación funcional existente realmente podría causar muchos problemas. La habilidad radica en aprender muchas técnicas diferentes y aplicar lo más apropiado al problema en cuestión.
OO a menudo se cita como una solución tipo Nirvana para el desarrollo de software, donde muchas veces no es apropiado aplicarlo al problema en cuestión. Con frecuencia, puede conducir a una sobreingeniería de un problema para llegar a la solución perfecta, cuando a menudo no es realmente necesario.
En esencia, OOP no es realmente Programación Orientada a Objetos, sino que asigna el Pensamiento Orientado a Objetos a un lenguaje de programación capaz de soportar Técnicas OO. Las técnicas OO pueden ser compatibles con idiomas que no son inherentemente OO, y existen técnicas que puede usar dentro de los lenguajes funcionales para aprovechar los beneficios.
Como ejemplo, he estado desarrollando software OO durante aproximadamente 20 años, así que tiendo a pensar en términos OO cuando resuelvo problemas, independientemente del idioma en el que estoy escribiendo. Actualmente estoy implementando el polimorfismo usando Perl 5.6, que no lo admite de forma nativa. He elegido hacer esto, ya que hará que el mantenimiento y la extensión del código sean una tarea de configuración simple, en lugar de un problema de desarrollo.
No estoy seguro de si esto está claro.Hay personas que son duras en el tribunal de OO, y hay personas que son duras en el tribunal funcional. Y luego hay personas que han probado ambos y tratan de sacar lo mejor de cada uno. Ninguno de los dos es perfecto, pero ambos tienen algunos rasgos muy buenos que puedes utilizar sin importar el idioma.
Si está intentando aprender OOP, no se concentre únicamente en OOP, sino que intente utilizar Object Oriented Analysis y los principios generales de OO en todo el espectro de la solución del problema.
Creo que se adapta mejor cuando se está modelando algo coherente con el estado y las acciones asociadas en esos estados. Supongo que es un poco vago, pero no estoy seguro de que haya una respuesta perfecta aquí.
Lo que pasa con OOP es que le permite encapsular y abstraer datos e información, lo cual es una gran ayuda en la construcción de un sistema grande. Puedes hacer lo mismo con otros paradigmas, pero parece que OOP es especialmente útil en esta categoría.
También depende del idioma que está utilizando. Si se trata de un lenguaje con un rico soporte OOP, probablemente debería usar eso para su ventaja. Si no es así, puede que necesite encontrar otros mecanismos para ayudar a dividir el problema en piezas más pequeñas y fáciles de probar.
Me vendieron a OOP.
Cada vez que puede definir un concepto para un problema, probablemente puede ser envuelto en un objeto.
El problema con OOP es que algunas personas abusaron de él e hicieron su código aún más difícil de entender. Si tiene cuidado con lo que coloca en objetos y lo que pone en servicios (clases estáticas), se beneficiará al usar objetos.
Simplemente no ponga algo que no pertenezca a un objeto en el objeto porque necesita que su objeto haga algo nuevo que no pensó inicialmente, refactorice y encuentre la mejor manera de agregar esa funcionalidad.
Algunos lugares donde OO no es tan bueno es donde se trata de "conjuntos" de datos como en SQL. OO tiende a dificultar las operaciones basadas en conjuntos porque en realidad no está diseñado para tomar de manera óptima la intersección de dos conjuntos o el superconjunto de dos conjuntos.
También, hay veces en que un enfoque funcional tendría más sentido como este ejemplo tomado de MSDN:
Consideremos, por ejemplo, escribir un programa para convertir un documento XML en una forma diferente de datos . Si bien sería posible escribir un programa C# que analizara el documento XML y aplicara una variedad de sentencias if para determinar qué acciones tomar en diferentes puntos del documento, un enfoque posiblemente superior sería escribir la transformación como una hoja de estilo extensible. Programa de Transformación de Lenguaje (XSLT). No es sorprendente que XSLT tenga una gran racha de funcionalismo en su interior
Me resulta útil pensar en un problema determinado en términos de 'cosas'.
Si se puede pensar que el problema tiene una o más 'cosas', donde cada 'cosa' tiene una serie de atributos o datos que hacen referencia a su estado, y una cantidad de operaciones que se pueden realizar en ¡entonces, OOP es probablemente el camino a seguir!
Soy un temporizador antiguo, pero también he programado OOP durante mucho tiempo. Personalmente estoy en contra de usar OOP solo para usarlo. Prefiero que los objetos tengan razones específicas para existir, que modelen algo concreto, y que tengan sentido.
El problema que tengo con muchos de los desarrolladores más nuevos es que no tienen ningún concepto de los recursos que están consumiendo con el código que crean. Cuando se trata de una gran cantidad de datos y acceder a las bases de datos, el modelo de objeto "perfecto" puede ser lo peor que puede hacer por el rendimiento y los recursos.
Mi línea de fondo es si tiene sentido como objeto y luego programarlo como un objeto, siempre que considere el impacto de rendimiento/recursos de la implementación de su modelo de objetos.
La clave para aprender Programación Orientada a Objetos es aprender sobre Diseño de Patrón. Al aprender sobre patrones de diseño puede ver mejor cuando las clases son necesarias y cuando no lo son. Al igual que cualquier otra cosa utilizada en la programación, el uso de clases y otras características de los lenguajes OOP depende de su diseño y requisitos. Me gusta los algoritmos Los patrones de diseño son un concepto de nivel superior.
Un patrón de diseño desempeña un papel similar al de los algoritmos para lenguajes de programación tradicionales. Un patrón de diseño le dice cómo crear y combinar objetos para realizar alguna tarea útil. Al igual que los mejores algoritmos, los mejores patrones de diseño son lo suficientemente generales como para aplicarse a una variedad de problemas comunes.
En mi humilde opinión, la mayoría de las personas que usan OOP no aprenden patrones de diseño hasta mucho tiempo después (o nunca) ... tal vez los patrones de diseño ilustran buenos usos de OOP pero definitivamente no la clave - * comprensión * los principios de Encapsulación, Polimorfismo y Herencia son la esencia – Gishu
Para los programas de procedimientos, los algoritmos son fundamentales para aprender cómo armar declaraciones y funciones dispares para hacer un trabajo útil. Los patrones de diseño cumplen la misma función para OOP. Los algoritmos de aprendizaje y los patrones de diseño son lo más importante que se debe aprender para sus respectivos métodos de programación. –
En mi opinión, es más una pregunta sobre usted como persona. Ciertas personas piensan mejor en términos funcionales y otros prefieren clases y objetos. Yo diría que OOP es más adecuado cuando coincide con su modelo mental interno (subjetivo) del mundo.
Depende del problema: el paradigma OOP es útil en el diseño de sistemas distribuidos o framework con mucha entidad que vive durante las acciones del usuario (ejemplo: aplicación web).
Pero si tiene un problema de matemáticas, preferirá un lenguaje funcional (LISP); para sistemas críticos para el rendimiento, utilizará ADA o C, etc. etc.
El idioma OOP es útil porque también usa probabilmente el recolector de basura (uso automático de la memoria) durante la ejecución del programa: usted programa en C una gran cantidad de tiempo debe depurar y corregir manualmente un problema de memoria.
El código orientado a objetos y el código de procedimiento tienen diferentes puntos de extensibilidad. Las soluciones orientadas a objetos hacen que sea más fácil agregar nuevas clases sin modificar las funciones existentes (consulte el Principio de Open-Closed), mientras que el código de procedimiento le permite agregar funciones sin modificar las estructuras de datos existentes. Muy a menudo diferentes partes de un sistema requieren diferentes enfoques dependiendo del tipo de cambio que se anticipe.
OOP es útil cuando tiene cosas. Un socket, un botón, un archivo. Si termina una clase en er, casi siempre es una función que pretende ser una clase. Es muy probable que TestRunner sea una función que ejecuta pruebas (y probablemente se denomina pruebas de ejecución).
Existen 5 criterios para decidir si se debe favorecer el objeto orientado sobre el código basado en objeto, funcional o de procedimiento. Recuerde que todos estos estilos están disponibles en todos los idiomas, son estilos. Todos estos están escritos en un estilo de "¿Debo favorecer a OO en esta situación?"
El sistema es muy complejo y tiene aproximadamente 9k LOC (solo un nivel arbitrario). - A medida que los sistemas se vuelven más complejos, los beneficios obtenidos al encapsular la complejidad aumentan bastante. Con OO, a diferencia de las otras técnicas, tiende a encapsular cada vez más la complejidad, que es muy valiosa en este nivel. Objeto basado o de procedimiento debe ser favorecido antes de esto. (Esto no aboga por un lenguaje en particular.) OO C encaja en estas características más que OO C++ en mi mente, un lenguaje con una notoria reputación de extravagantes abstracciones y la capacidad de comer en tiendas con incluso 1 programador mediocre/obstinado para el almuerzo).
Su código no funciona en base a datos (es decir, basado en la base de datos o basado en la matemática/análisis). El código basado en la base de datos a menudo se representa más fácilmente a través del estilo de procedimiento. El código basado en análisis a menudo se representa más fácilmente en un estilo funcional.
Su modelo es una simulación de algo (OO sobresale en las simulaciones).
Está haciendo algo para lo cual el envío de subtipo basado en objetos de OO es valioso (es decir, debe enviar un mensaje a todos los objetos de un tipo determinado y varios subtipos y obtener una reacción apropiada pero diferente de todos ellos).
Su aplicación no tiene múltiples subprocesos, especialmente en un tipo de código de método de método de tarea no de trabajo. OO es bastante problemático en programas que tienen múltiples subprocesos y requieren diferentes subprocesos para realizar tareas diferentes. Si su programa está estructurado con uno o dos subprocesos principales y muchos subprocesos de trabajo haciendo lo mismo, el flujo de control confuso de los programas OO es más fácil de manejar, ya que todos los subprocesos estarán aislados en lo que tocan y pueden considerarse como una sección monolítica de código. Considera cualquier otro paradigma en realidad. Funcional sobresale en multiprocesamiento (la falta de efectos secundarios es una gran ventaja), y la programación basada en objetos puede darle grandes beneficios con parte de la encapsulación de OO, sin embargo, con más código de procedimiento trazable en secciones críticas de su base de código. El procedimiento, por supuesto, también sobresale en esta arena.
Personalmente, creo que OOP es prácticamente una necesidad para cualquier aplicación grande. No puedo imaginarme tener un programa de más de 100k líneas de código sin usar OOP, sería una pesadilla de mantenimiento y diseño.
Te digo cuándo OOP es malo.
Cuando el arquitecto escribe código OOP realmente complicado y no documentado. Se va a la mitad del proyecto. Y muchos de sus códigos comunes que utilizó en varios proyectos tienen código faltante. Gracias a Dios por .NET Reflector.
Y la organización no estaba ejecutando Visual Source Safe o Subversion.
Y lo siento. 2 páginas de código para iniciar sesión es bastante ridículo, incluso si se trata de OOPed curiosamente ....
OO permite que la lógica relacionada con un objeto se coloque en un solo lugar (la clase u objeto) para que pueda ser desacoplado y más fácil de depurar y mantener.
Lo que he observado es que cada aplicación es una combinación de OO y código de procedimiento, donde el código de procedimiento es el pegamento que une todos los objetos (como mínimo, el código en su función principal). Cuanto más puedas convertir tu código de procedimiento en OO, más fácil será mantener tu código.
Por qué programación orientada a objetos se utiliza para la programación:
¿por qué perl 5.6 hombre? y estoy bastante seguro de que Perl puede hacer polimorfismo, al menos creo que el libro Perl Orientado a Objetos lo describe. El OO de Perl es realmente poderoso, si realmente feo y barebones. – xenoterracide
Perl 5.6 porque esa era la infraestructura de las empresas. Para actualizarlo en ese momento habría implicado un cambio masivo a una gran cantidad de servidores y toda la infraestructura de soporte. Sin embargo, todo eso ha cambiado ahora, dos años después. – Xetius