¿Es realmente tan importante la programación OO como la ubican las empresas contratantes? [cerrado]

Estoy terminando mi maestría (en informática) y postulo para trabajos. He notado que muchas compañías piden específicamente una comprensión de la orientación a objetos. Las preguntas populares de la entrevista son sobre herencia, polimorfismo, accesores, etc.

¿OO es realmente tan crucial? Incluso tuve una entrevista para un trabajo de programación en C y la mitad de la entrevista fue OO.

En el mundo real, desarrollando aplicaciones reales, ¿se usa casi siempre la orientación a objetos? ¿Se utilizan MUCHAS características clave como el polimorfismo?

Creo que mi pregunta proviene de una de mis debilidades. Aunque sé acerca de OO, parece que no puedo incorporarlo mucho en mis programas.

OOP es un paradigma que permite que su programa crezca sin ser imposible de mantener / comprender. Este es un punto que los estudiantes casi nunca obtienen porque solo hacen pequeños proyectos que duran de dos semanas a dos meses como máximo.

Este breve período no es suficiente para aclarar el objetivo de la POO, especialmente si las personas en el proyecto son principiantes. Pero mantener cierta modelación es crucial para grandes proyectos, diría> 50,000 líneas de código. OOP no es la única solución para eso, pero esta es la más utilizada en la industria.

Es por eso que la gente quiere que sepas POO.

Yo agregaría, por experiencia, que casi todos los programadores junior tienen fallas serias en la modelación y POO. La mayoría de ellos saben cómo escribir clases, heredar de ellos y cosas básicas como esa, pero no piensan en "OOP" y terminan abusándolo. Es por eso que cualquier reclutador serio siempre verá cuáles son sus competencias en el dominio OOP.

Como estas cosas no se aprenden en la escuela, existe una enorme variación de conocimiento entre los diferentes candidatos. Y seamos sinceros: no creo que alguien con poco conocimiento en OOP pueda trabajar en un gran proyecto, simplemente porque requeriría más tiempo para que los desarrolladores principales manejen a estas personas que simplemente escribir el código ellos mismos.

Si todavía no piensa en "OOP", le sugiero que lea algunos libros al respecto y se postule en una empresa que no tiene proyectos realmente grandes; para acostumbrarse a que OOP siga haciendo un trabajo útil para su empleador (y mientras él / ella le esté dando su salario, esto también será útil para usted).

EDITAR: ha, y agregaría que ya escribí el código OOP en C, incluso si no es el uso más común de C, esto es posible con un gran conocimiento. Solo tienes que construir vtables manualmente.

Y detrás de la técnica OOP, hay algo oculto: diseño de software. El diseño de software es realmente útil, tanto en C como en cualquier otro lenguaje. Muchos reclutadores pondrán a prueba sus competencias de diseño de software, y las preguntas de OOP son buenas para eso, pero OOP no es lo principal que se está probando aquí. Es por eso que tiene esas preguntas incluso para un trabajo en C.

El problema abrumador con la programación de computadoras es manejar la complejidad, y los programas modernos pueden ser muy complejos, y esto parece aumentar.

Gran parte del trabajo realizado en la ingeniería de software de programas informáticos no triviales se concentra en la complejidad de la domesticación y la hace accesible a la mayor cantidad posible sin dedicar una vida de aprendizaje primero.

Ejemplos:

• Modularización: hace que los programas sean más simples desde el punto de vista conceptual al tener módulos de código, donde cada módulo solo sabe un poco sobre otros módulos (en lugar de, por ejemplo, un enrutamiento de dibujo de icono de mouse que permite manipular los buffers de tarjetas de red directamente).
• API: dan una ruta de uso simple a los programas complejos detrás de las API. Cuando abre un archivo, no le importa que los recursos compartidos de red se manejen de manera diferente a un disco USB. La API es la misma.
• Orientación a objetos. Esto le permite reutilizar el código existente y hacer que funcione de manera transparente con el nuevo código que agregue, al tiempo que oculta toda la complejidad subyacente.

En otras palabras, es necesario conocer muchos trucos si desea trabajar en piezas de software no triviales, ya sea solo o (muy probablemente) con otros.

Sí, principalmente porque quizás las dos plataformas de desarrollo más populares utilizadas en el desarrollo comercial (Java y .NET) están orientadas a objetos y eso significa que sí, OO se usa mucho (incluido el polimorfismo, la herencia y todo lo demás).

Las empresas no se preocupan específicamente por la orientación a objetos como tecnología: esto no es una cuestión de ideología, sino de personas que pueden desarrollar soluciones a sus problemas de manera que se alineen con su estrategia de TI.

Pero no me preocuparía demasiado por sentir que es una debilidad. Sin faltarle el respeto a su educación, la mayoría de las personas en el mundo comercial no ven a los programadores que abandonan la universidad (en ningún nivel) como el artículo terminado. Todavía te queda mucho por aprender y eso se entiende (probablemente mejor para las empresas que para los estudiantes).

Como en la vida real, la programación de la vida real difiere de la teoría.

Sí, si mantiene el paradigma OO pulido y siempre en el fondo de su mente, puede hacerlo mejor escribiendo código que sea manejable, comprensible y fácilmente extensible.

Desafortunadamente, el mundo real tiene esto:

• presiones de tiempo del proyecto
• miembros del equipo orientados a los procedimientos
• equipos cruzados, múltiples proveedores
• código heredado que no tiene ninguna orientación
• mientras funcione, a algunos les importa cómo se escribe el código
• incluso si el código no funciona, la motivación es arreglarlo, no "OO"
• módulos, limitaciones de plataforma, marcos que simplemente no le permiten hacer un buen OO

En un trabajo real, tienes que trabajar con los problemas anteriores. Esto suena desmoralizador. Pero, trata esto como un aviso. Las empresas contratantes le dan demasiada importancia a OO durante la contratación. Es fácil ver por qué. La única forma en que pueden evaluar al candidato es preguntando sobre la comprensión de OO. Y desafortunadamente, muchos candidatos simplemente repasan esas preguntas antes de presentarse para una entrevista.

La vida real OO viene lento. Ayuda seguir leyendo y seguir mejorando con el tiempo.

Tuve la misma sensación al terminar mi licenciatura, y un gran libro que me mostró por qué y cómo OOP es relevante para aplicaciones del mundo real es Head First: Design Patterns . Le recomiendo sinceramente que eche un vistazo, está escrito de una manera realmente divertida y hace muchos puntos válidos de por qué es deseable un enfoque OOP cuando se trabaja con sistemas a gran escala y en constante cambio.

Incluso para algunos trabajos en C, es posible que necesite conocer el diseño orientado a objetos (y probablemente sea mejor que si su compilador lo hiciera por usted), como lo demuestra una serie reciente de artículos sobre diseño orientado a objetos en el kernel de Linux. ( Parte 1 , Parte 2 )

GTK + también utiliza muchos patrones de diseño orientados a objetos.

Tengo que expresar un cierto desacuerdo con esta idea de que OO lo es todo; se podría decir que OO le permite construir ciudades, pero los programas de procedimiento son los ladrillos.

Para dar mi respuesta en forma de analogía, un general necesita objetos, el soldado necesita procedimientos. Una vez que profundice lo suficiente en OO, encontrará procedimientos, y si esa es su experiencia y es lo suficientemente bueno, no se preocupe por OO, porque es bastante fácil para alguien escribir este código de juego de ajedrez OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

pero alguien tiene que escribir el código detrás de -findBestMove y puedes estar seguro de que no es solo esto:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

Por otro lado, si no sabes cómo leer el código OO, preocúpate. Porque puede estar seguro (casi) de que su código estará jugando con objetos de algún tipo. A menos que trabaje en el gigante heredado de Fortran de 12000 vars globales y 1200 "módulos" de línea que mantengo actualmente.

Jon Hopkins escribió:

Sí, principalmente porque quizás las dos plataformas de desarrollo más populares utilizadas en el desarrollo comercial (Java y .NET) están orientadas a objetos y eso significa que sí, OO se usa mucho (incluido el polimorfismo, la herencia y todo lo demás).

Lo cual es más o menos lo que iba a decir, pero no es solo Java y .Net, C ++ está en todas partes, Objective-C está en todo OSX, todos los niños geniales están haciendo Ruby o Python, y todas estas cosas y muchas otras más se centran en la orientación a objetos. Muchos lenguajes más nuevos son multiparadigm, por lo que algo como F # es principalmente un lenguaje funcional, pero también admite la orientación a objetos. Está en todas partes, y tener al menos algo de comprensión es muy útil. Sin embargo, no te preocupes demasiado por eso, haber completado los cursos universitarios significa que estás listo para comenzar a aprender sobre el desarrollo de código en el mundo real :)

He programado durante mucho tiempo, y encuentro que los conceptos de OO son útiles incluso cuando programo en C, aunque si los probara probablemente no podría describir esos conceptos en cada pequeño detalle. En un momento, incluso creé un lenguaje OO, aunque rudimentario, para entender los conceptos y disfrutar del OO desde un nuevo ángulo.

Por cierto, C ++ ha hecho un gran y feo desastre de OO, mientras que Objective C lo hace bien.

Sobre las entrevistas, se han convertido en un espectáculo de terror, desde ambos lados de la mesa. La mayoría de los entrevistados están muy asustados por ellos. La mayoría de los gerentes de contratación están asombrados de cuántas personas fallan incluso en las pruebas de programación muy básicas.

Dicho esto, en este momento hay algunas enormes bolsas de ducha que trabajan en la industria del software que no saben NADA y esperan el mundo de los posibles empleados.

Learning OOP no es tan útil como el desarrollo de software de aprendizaje. Ve a leer el Código completo 2 .

Claro que es una herramienta útil, pero la POO en sí es realmente pequeña. En general, cuando las empresas y los reclutadores dicen "OOP", se refieren al "desarrollo de software". Se está utilizando como un término genérico.

Los reclutadores reales notarán la diferencia entre saber cómo desarrollar software y combinar la casilla de verificación "Tiene 3 años en 'OOP'".

La respuesta es sí, como han señalado varios otros.

PERO, si desea trabajar en pilas de código de espagueti de procedimiento no OO, también puede encontrarlo allí. Creo que preferirás el trabajo de OO.

EDITAR: Perdone mi caso del cinismo y el sentido del humor del pistolero. Como dijo Raynos, solo porque algo es OO no significa que sea bueno. La aplicación adecuada de OO requiere trabajo y pensamiento reales; solo tener instancias de esto no significa automáticamente que una aplicación esté bien hecha. Y a la inversa, estoy seguro de que hay un código de procedimiento bien escrito. Mi experiencia en tiendas de TI corporativas durante los años 90 y 2000 ha sido que se escribió mucho código incorrecto y probablemente todavía existe. Pero más cerca de la pregunta del OP, he notado que los desarrolladores más inteligentes, cuando se les da la oportunidad, se están mudando a más sistemas OO.

OO es una base fundamental sobre la cual se construyen otras técnicas. Un punto clave es primero comprender completamente la diferencia entre un tipo (clase) y una instancia de ese tipo. No intentes seguir leyendo sin comprenderlo (pensando que se aclarará más tarde), porque tendrás que leer el resto una vez que captes la visión.

Una vez que lo domines, nunca querrás prescindir de él. No soy un purista cuando se trata de encapsulación, patrones, marcos o lo que sea. En el trabajo, tendrás que adaptarte a varios puntos de vista y conceptos. Enumeraré algunas de mis experiencias laborales anteriores:

En una empresa, mis compañeros querían la mayor cantidad de carga diferida (constructores vacíos, propiedades voluminosas que tenían que verificar valores nulos en todas partes). Estaban construyendo objetos del lado del servidor basados ​​en la web que vivieron una vida corta.

El siguiente trabajo fue totalmente opuesto. Los objetos vivían dentro de una aplicación de escritorio (basada en Excel). La mayor inicialización posible debe estar en el constructor (o una de las muchas sobrecargas del constructor). Los constructores vacíos no estaban permitidos ya que los objetos vacíos no tenían derecho de existencia (lo que hizo que la persistencia fuera todo un desafío). Además, tuve que adaptarme a sus "estándares de estilo de codificación" (dónde abrir los paréntesis, agregar espacios en blanco después de los comentarios, etc.), porque mi código no se podría registrar si no pasaba por style-cop.

Actualmente estoy trabajando en una empresa en la que ninguno de los desarrolladores intentó comprender OO. Es difícil expresar lo extremadamente frustrante que ha sido. He tenido que mejorar mis habilidades de Grep, de hecho, tengo una macro HotScripts asignada a mi tecla F12 para hacer un grep en el texto seleccionado. Ahorraré las otras frustraciones ...

Una vez que obtengas habilidades de OO, ¡casi serás alérgico al espagueti! Sin embargo, en todos los casos, OO o no, sea paciente y adáptese. Sea reacio a "tirarlo y comenzar de nuevo". Tu jefe preferirá elegirte a la hora de tirar. Desafortunadamente "hacer dinero" es más importante que el código elegante.

Perdón por la respuesta larga, pero traté de cubrir la mayor parte del alcance de su pregunta :-)

OOP no es importante por sí mismo, sino por lo que lleva consigo. Algo que se ocupa de la capacidad de abstraer y aislar, agrupar cosas juntas y exponer solo las partes que se requieren para interactuar juntas.

Esta es una técnica de ingeniería común llamada "modularización", que permite crear sistemas complejos como agregación de sistemas más simples, sin ocuparse de todos los detalles a alto nivel, y que requieren que los componentes sean reemplazables, incluso sin que sean exactamente mismo.

Esos "conceptos de ingeniería" se han tratado de mantener en el desarrollo de software desde el momento en que el producto de software se ha vuelto más grande que la "capacidad de desarrollador único", lo que requiere una forma de hacer que los desarrolladores trabajen en piezas independientes, y dejar que esas piezas interactuar juntos

Dicho esto, esos principios no se encuentran necesariamente solo en OOP (si la teoría de la computación es válida, hay infinitos métodos posibles para llegar a esos resultados).

OOP es simplemente un intento exitoso de poner esas cosas juntas, dando a esos términos generales (como módulos, encapsulación, sustitución) definiciones más precisas y conceptualización elaborada sobre esas definiciones (patrones) que pueden encajar en los lenguajes de programación.

Piense primero en OOP no como una " característica del lenguaje " sino como un " léxico común " que hace que los ingenieros de software se acerquen al diseño del software.

El hecho de que un lenguaje dado tenga o no primitivas que impongan directamente ese léxico asegurando, por ejemplo, que una "cápsula" no se abra inadvertidamente por quién no se supone que lo haga, es un aspecto secundario del diseño de OOP. Es por eso que incluso los grandes proyectos de C a menudo se "gestionan como" OOP, incluso si el lenguaje en sí no ofrece soporte directo para eso.

La ventaja de todo eso no es reconocible hasta que el tamaño de un proyecto permanezca en la capacidad de desarrollador único para comprender y rastrear todo lo que hace (de hecho, en esa situación, incluso puede verse como "sobrecarga") o en un pequeño grupo que desarrolla algo en Un corto período. Y esa es la razón principal por la cual los estudiantes de tercer año que estudiaron OOP en términos de una "característica del lenguaje" a menudo lo malinterpretan produciendo código mal diseñado.

La forma en que OOP se ajusta a los idiomas depende de cómo los diseñadores de idiomas interpretan el principio de OOP en su propia construcción.

Entonces, la "encapsulación" en C ++ se convierte en "miembros privados" (y una "cápsula" se convierte en una clase), la "sustitución" se convierte en anulación de funciones virtuales o en la parametrización / especialización de plantillas, etc., mientras que en D una cápsula es un "módulo" (y la sustitución continúa a través de clases, etc.), haciendo así cierto paradigma o patrón directamente disponible en un idioma dado y no en otro y así sucesivamente.

Lo que buscan los reclutadores al hacer preguntas de OOP es simplemente verificar su capacidad para abstraer y concebir el diseño de software para futuros proyectos y desarrollos de gran tamaño. OOP, para ellos es solo un "diccionario" que supusieron que tanto usted como ellos conocen para que puedan hablar sobre otras cosas más generales o concretarlas en una implementación específica.

Un lenguaje orientado a objetos lo ayuda a mantener un diseño orientado a objetos en su código, lo cual es bueno. Pero también es cierto que dicho diseño se puede obtener con cualquier otro lenguaje paradigmático: la razón de la popularidad (especialmente entre las empresas) de los lenguajes OO probablemente se deba al éxito comercial de Java y C #.

Si el Sr. Gates hubiera comenzado su empresa de la manera correcta, probablemente estaríamos estudiando SCHEME antes de solicitar un trabajo.

La respuesta corta es sí

La versión más larga de por qué te sientes o en un dilema de por qué es importante solo se debe al hecho de que no has trabajado en ningún proyecto o implementación que tenga algún propósito. Es perfectamente válido en las aulas tener ejemplos en Automóvil y luego extenderse a Automóviles, Camiones ... pero cuando se lanza al desarrollo de software, es una solución dirigida a facilitar algunas tareas. Ahora, si no fuera porque OOtendríamos a todos escribiendo códigos similares en toda la base de códigos oreinventando las ruedas todos los días. Imagínense qué desastre sería si uno se sumergiera en una base de código para arreglar algo. Los ejemplos del aula son para una definición o representación vaga de cómo / por qué se hace. La verdadera prueba está fuera cuando comienzas a construir tu aplicación, sin duda, puede usarse terriblemente, pero pesa mucho la cordura debido a su uso claro y conciso. Por lo tanto, es mejor comenzar a trabajar en estas áreas débiles para no generar códigos de pesadilla.

Depende. Una razón por la que necesita saber OO porque es la lengua franca del mundo de la programación. Como señala otra respuesta, casi todos los idiomas principales son OO de alguna manera, lo que significa que básicamente cualquier compañía que pueda contratarlo está usando un idioma OO. ¿Alguna vez intentaste contratar programadores de OCaml? Es imposible; El grupo de talentos es demasiado pequeño. Si comenzó su empresa con OCaml y su empresa tiene éxito, no podrá contratar programadores lo suficientemente rápido y cerrará su negocio. Por lo tanto, casi todas las empresas con más de 3 programadores usan un lenguaje OO, y para comunicarse con sus compañeros de trabajo y usar las bibliotecas de su plataforma, necesitarán comprender OO.

Dependiendo del lenguaje particular que esté usando la compañía, la herencia y el polimorfismo son extremadamente importantes o moderadamente relevantes. No puede hacer nada en Java sin romper 10 patrones de diseño de GoF y un marco de inyección de dependencias. Java es uno de los lenguajes más utilizados, por lo tanto, los principios de OO son realmente importantes para las muchas empresas que usan Java.

Si la compañía está utilizando un lenguaje híbrido / funcional moderno híbrido que tiene lambdas y punteros de función, como Scala o C #, entonces la herencia de repente se vuelve menos importante porque tiene funciones de orden superior para manejar muchas de las cosas realmente simples que de lo contrario requerirían muchas ceremonia. Sin embargo, aún debe poder trabajar con material OO porque la mayoría de las bibliotecas que usa se escribirán de forma OO.

Si la herencia y el polimorfismo no son importantes para la empresa, es probable que reciba preguntas OO porque:

• Usted es entrevistado por una persona de Recursos Humanos que no sabe nada sobre programación y hace preguntas fuera de la lista de verificación. ¿Tienes 3 años de X, haces múltiples tareas, etc.
• Usted es entrevistado por un ingeniero que quiere asegurarse de que no haya estado viviendo debajo de una roca. OO es la lengua franca, por lo que se le harán algunas preguntas superficiales al respecto.
• Usted es entrevistado por un ingeniero que no es muy experto en entrevistas. En general, a los ingenieros les encantan las curiosidades y la complejidad, por lo que recibirá muchas preguntas sobre el polimorfismo, la herencia y los patrones de diseño de GoF solo porque estas cosas son interesantes para la persona que lo entrevista.

En una palabra "Sí".

Puede pensar que conoce la teoría, pero necesita escribir un código y ponerlo en práctica. Hay, literalmente, miles de ejemplos y ejercicios disponibles en línea.