¿Las cosas orientadas a objetos son realmente tan importantes? [cerrado]

Durante años, he estado haciendo cosas algorítmicas, escribiendo estructuras de datos escalables para la búsqueda en Internet, por ejemplo, árboles de búsqueda binaria aleatoria para recomendación automática, mapas de bits, algoritmos basados ​​en la sabiduría de la multitud que usan gráficos, escribiendo algunos algoritmos interesantes de aprendizaje automático como agrupación, detección de anomalías, trabajando en cosas de recuperación de información, etc.

Hay una cosa común en las cosas que he mencionado anteriormente. Todo lo anterior; cada uno si está codificado en un lenguaje como C ++ requiere un puñado de clases. Quiero decir que son problemas interesantes, pero no son complejos en términos de material orientado a objetos muy cargados. Nunca he usado herencia, material virtual, etc. Aunque he usado mucho la programación genérica, las plantillas, etc.

Me encanta C ++ (- Cosas voluminosas de OO, como me gusta lo que dice Joe Armstrong, creador de Erlang, en OO World si pides un plátano, obtienes una gran jungla junto con un gorila que sostiene el plátano). Disfruto codificando en otros lenguajes como Java, Python también.

Ahora mi pregunta es, ya que estoy disfrutando el tipo de proyectos / Algoritmos en los que estoy trabajando, ¿realmente necesito aprender cosas OO, seré un mejor codificador / diseñador simplemente usando cosas como Herencia, Polimorfismo dinámico (virtuales)? O puedo pasar al mundo de la programación funcional (no lo he hecho hasta ahora) que me atrae más, ya que puedo centrarme en las tareas / algoritmos y no dejar que las cosas de OO basadas en Kingdom Of Noun sean una regla ¿yo?

En resumen, ¿pueden / pueden ayudarme las cosas de OO para el tipo de proyectos / Algoritmos que he mencionado anteriormente?

EDITAR:

Un enlace extremadamente interesante para agregar aquí:

http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-nouns.html

La programación orientada a objetos es realmente buena para ocultar sus complejas cosas de matemáticas detrás de palabras fáciles de entender y facilita a los menores entre ustedes usar las cosas que ha escrito. No reemplaza la programación funcional ... solo le brinda una forma realmente fácil de cambiar implementaciones o agregar comportamiento.

En su ejemplo de Árboles de búsqueda binaria aleatorizados anterior, ¿qué sucedería si le dieran el requisito de que en el Día de los Inocentes, el Aleatorizador fue reemplazado por un orden por distancia de tres chiflados? Es realmente útil crear StoogeBinaryTree : RandomBinaryTreey anular el protected int GetSortOrder (Tree a, Tree b)método, por lo que el 2 de abril, puede cambiar la implementación nuevamente RandomBinaryTreesin tener que haber cambiado nada de ese código.

En un ejemplo simple, he mostrado que agrego una pequeña porción de comportamiento y cambiamos la implementación ...

Si vas a hacer FP todavía con lenguajes como Haskell y Erlang que lo hacen bien, no hay necesidad de tomar el refresco OOP. FP es muy poderoso y puede hacer mucho incluso en el mundo real

Dicho esto, aprender un idioma OOP no sería algo malo. Entender múltiples formas de programar y varias metodologías funcionará a su favor. Además, si te mudas de Haskell o Erlang a Java puedes preguntarte cómo en el mundo cualquiera puede trabajar sin REPL y lambdas.

Parece que solo te has centrado en resolver un solo problema a la vez, es decir, escribir algoritmos. Pero considere cómo escribiría una aplicación GUI, por ejemplo, o alguna otra aplicación enorme que posiblemente requiera que use mucho de su algoritmo. En ese caso, conocer OO será esencial, ya que lo ayudará a simplificar su código para hacerlo más legible y más fácil de usar para otros desarrolladores, por ejemplo, creando una biblioteca que pueda cargarse como un objeto.

Uno de los patrones de diseño más importantes en la Programación Orientada a Objetos es el Patrón de Estrategia , que en el escenario anterior también lo ayudará mucho. Considere un ejemplo en el que el usuario le presentaría una entrada en la que le permitiría realizar un algoritmo. Esto podría ser fácilmente un desastre si / de lo contrario o la construcción del interruptor / caja. Al crear una interfaz común para su algoritmo y usar el Patrón de estrategia, su código sería mucho más flexible, legible, más fácil de extender y, por lo tanto, más fácil de mantener.

El enfoque orientado a objetos tuvo éxito debido a un aspecto crucial: le permite abordar sistemas de complejidad esencial significativa sin introducir demasiada complejidad accidental . Esto puede ser casi ignorado cuando trabajas en sistemas de cosecha propia, pero se vuelve muy importante cuando construyes sistemas a gran escala.

Los elementos clave del enfoque orientado a objetos se pueden explicar a un programador con una amplia exposición a la programación de procedimientos en cuestión de días, lo que ayudó a que la técnica ganara popularidad rápidamente (esto no quiere decir que pueda convertirse en un experto en un Un par de días: es similar a aprender ajedrez: puedes aprender a mover tus piezas en menos de diez minutos, pero lleva años dominar el juego).

Las técnicas de programación funcional están ganando más importancia con la introducción de soporte de lenguaje para ellas en los lenguajes principales (lambdas y delegados anónimos de C #, lambdas de C ++ e incluso clases anónimas de Java, hasta cierto punto). Es muy útil comprender estas técnicas, pero están diseñadas para abordar problemas más localizados en la escala táctica . Las técnicas orientadas a objetos, por otro lado, siguen siendo relevantes en la escala estratégica , especialmente en el contexto de equipos más grandes.

Haga una programación funcional, será una muy buena experiencia para usted, incluso si decide no continuar. Como puede leer en algunas de las respuestas aquí, muchas personas ni siquiera saben lo que es.

Los conceptos de lenguajes funcionales, por ejemplo, evaluación perezosa y transparencia referencial, son muy, muy buenos para aprender. Especialmente si te gusta la recursividad.

por ejemplo:

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

es una función haskell muy simple que se repite a través de una lista y calcula la longitud. Si está interesado en números más grandes que largos y desea usar Listas infinitas y otras cosas elegantes, pruebe la programación funcional.

Como otros han dicho, la orientación a objetos es el paradigma dominante en la industria. Usted ha dicho que ha trabajado principalmente con programas que pueden ser abordados por un puñado de clases, pero en una aplicación industrial hay cientos o miles de casos de uso que deben abordarse y la orientación a objetos ha demostrado ser muy confiable. y una forma ampliamente comprensible de estructurar bases de código tan grandes.

Hablas de programación funcional, que es un competidor sólido para The Next Big Paradigm, pero FP aún no está familiarizado en la industria. Especialmente como usted es un programador de C ++, debe saber que la industria puede ser conservadora y que el mundo de C / C ++, con su énfasis en el rendimiento, es un lugar donde la naturaleza imperativa del hardware se considera una consideración muy real. En general, los programadores de sistemas integrados son extremadamente escépticos de FP, en mi experiencia.

Incluso si FP se convierte en un paradigma más dominante en la industria, es cierto que tendrá éxito en forma de lenguajes híbridos con función de objeto como F # y Scala y no en forma de lenguajes FP "puros" como Haskell.

Todo lo cual significa que sí, las "cosas" orientadas a objetos son importantes para las bases de códigos profesionales y su carrera.

OO ganó tracción porque fue una gran mejora para manejar la complejidad, como antes también lo era la programación estructurada / procesal.

Los beneficios de usar OO aumentan a medida que aumenta el tamaño del proyecto. Para un programa 1KLOC, no importa mucho qué paradigma use, todos ellos funcionarán bien. Pero para un programa 200KLOC +, simplemente no hay competencia viable para OO. Eso no significa que no pueda escribir un programa 200KLOC en C, solo que tendrá que ser mucho más disciplinado para evitar terminar con un desastre que nadie (ni siquiera usted) puede entender. Eso no significa que OO evitará tal desorden, solo que te facilitará la vida para evitarlo.

La programación funcional es un paradigma que se desvió en cierta medida del patrón anterior, porque no vino a ayudar a manejar aún más complejidad que OO, sino a abordar un tipo diferente de problemas: la programación paralela. Esa fue la primera vez, también, que un paradigma de programación intentó hacerlo: todos los mecanismos que existían antes en OO y / o SP / PP no eran parte del paradigma, sino solo entidades del sistema operativo (hilos, mutexes, etc.) encapsulado de acuerdo con las reglas del paradigma.

En ese sentido, la PF es mucho más natural que las otras, pero eso tiene el costo de revertir la forma en que generalmente pensamos sobre los problemas. Y debido a eso, tiene una capacidad limitada para manejar la misma complejidad a la misma escala que OO.

Supongo que esto limitará la adopción de FP en el futuro cercano a sistemas muy especializados, en general, secciones no muy grandes o especializadas de sistemas más grandes. Y el resto aún se hará con OO. Cuál de los que planea desarrollar (o aprender sobre el desarrollo) determinará cuál debería ser su enfoque de aprendizaje, IMO.

Aunque he usado mucho la programación genérica, las plantillas, etc.

Podría decirse que las plantillas son simplemente una forma diferente de OOP. Las funciones virtuales y la herencia explícita tienen un caso de uso específico, tiempo de ejecución, intercambiabilidad binaria. Las plantillas son intercambiables en tiempo de compilación. Sin embargo, en el nivel más básico, ofrecen la misma abstracción de características sobre cualquier tipo que ofrezca la interfaz correcta. El uso excesivo de la herencia en tiempo de ejecución es un olor de código significativo, y en este caso, estoy de acuerdo con usted, simplemente no es necesario durante la mayor parte del tiempo.

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

Estos dos fragmentos son efectivamente idénticos, aunque uno usa plantillas exclusivamente y el otro usa herencia en tiempo de ejecución y clases como su implementación. Ambos resumen sobre la función que estás llamando. Esta es trivialmente obvio cuando sustituyes Tpara std::function<void(int)>, por ejemplo. La única diferencia es el momento en que se hace esa abstracción. La versión de la plantilla es excelente para las funciones, y std::functiongeneralmente es mejor como variables miembro. No desea tener que crear una nueva clase cada vez que desea una nueva devolución de llamada.

OOP no es particularmente adecuado para algoritmos. Está más destinado a construcciones a gran escala, desglosando las piezas del programa. Si está escribiendo un algoritmo específico que opera en datos específicos, entonces es poco probable que necesite clases.

Es fácil y genial componer algoritmos de funciones. Sin embargo, tan pronto como superas eso, las clases emergen como el método dominante.

Sí, es importante, por esta única razón: comprender OOP te convierte en un mejor programador. Como regla general: la comprensión siempre te convierte en un mejor programador.

Cabe señalar que ni is-a, ni las clases, y mucho menos la herencia, tienen algo que ver con OOP. De lo que se trata realmente OOP es del desacoplamiento a través de la indirección, según lo formulado por el principio de inversión de dependencia . Se puede argumentar que este también es un aspecto importante de la PF. Si estudia tanto OOP como FP, se dará cuenta cada vez más de que en realidad son dos lados de un continuo. Cuanto más amplio y profundo lo entiendas, mejor serás.

Para comprender OOP, pruebe Io y quizás Smalltalk y Ruby.

En el mundo del desarrollo, los lenguajes son herramientas, los paradigmas de programación son herramientas y las bibliotecas son herramientas. Cuantas más herramientas tenga, mejor podrá seleccionar la herramienta adecuada para el trabajo. Entonces eso argumentaría para que usted aprenda la programación OO, AOP y funcional, según lo permita el tiempo.

El mundo del desarrollo sigue creciendo más y más (en términos de lenguajes, marcos, etc.), por lo que no puede esperar aprender todo. Sin embargo, el objetivo de todas estas innovaciones es ayudar a los desarrolladores a ser más productivos (velocidad de desarrollo y reutilización) y hacer que el código sea más fácil de mantener (facilidad de comprensión, facilidad de extensión y modificación).

Lo mejor que puede hacer es hacer un aprendizaje continuo y dirigido, con la esperanza de que algo nuevo que acaba de aprender lo ayude a completar algo mejor y más rápido de una manera que nunca esperó.

He estado leyendo el libro de Steve Jobs y hay una historia sobre cómo Steve vio SmallTalk en los laboratorios Xerox PARC. Ese fue uno de los primeros idiomas OO. Sin OO hubiera sido horrendo desarrollar algo como una interfaz gráfica de usuario (GUI). Con toda la entrada asincrónica y poder saltar de una tarea a otra mientras trabaja con un "Objeto" u otro.

Entonces, si bien puedes hacer mucho con un lenguaje funcional y definitivamente tiene sus casos de uso. Cuando comienzas a lidiar con sistemas más complejos que interactúan más con problemas del mundo real, encuentras que OO es un diseño superior.