¿Es la programación OO realmente tan importante como la contratación de empresas? [cerrado]

OOP es un paradigma que permite que su programa crezca sin que sea imposible de mantener / entender. Este es un punto que los estudiantes casi nunca entienden porque hacen proyectos pequeños 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 apegarse a una cierta modernización es crucial para grandes proyectos, diría que > 50,000 líneas de código. La OOP no es la única solución para eso, pero es la más utilizada en la industria.

Es por eso que la gente quiere que sepas la POO.

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

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

Si aún no piensa en "OOP", le sugiero que lea algunos libros sobre el tema y presente una solicitud en una empresa que no tiene proyectos realmente grandes; para acostumbrarse a la programación orientada a objetos (OOP) y seguir haciendo un trabajo útil para su empleador (y mientras él / ella le esté dando su salario, esto también será útil para usted).

EDIT: 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 conocimiento sólido. Solo tienes que construir vtables manualmente.

Y detrás de la técnica OOP, algo está oculto: el diseño de software. El diseño de software, es realmente útil, en C como en cualquier otro idioma. Muchos reclutadores pondrán a prueba sus competencias de diseño de software, y la pregunta de la POO es buena para eso, pero la POO no es lo principal que se está probando aquí. Esta es la razón por la que tiene esas preguntas incluso para un trabajo de C

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

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

Ejemplos:

• Modularización: hace que los programas sean más simples conceptualmente al tener módulos de código, donde cada módulo solo conoce un poco sobre otros módulos (en lugar de, por ejemplo, un enrutamiento de dibujo de ícono de ratón que permite manipular buffers de tarjetas de red directamente).
• API's: proporcionan una ruta de uso simple a los programas complejos detrás de las API's. 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, a la vez que oculta toda la complejidad subyacente.

En otras palabras, es necesario conocer muchos trucos si desea trabajar en software no trivial, ya sea solo o (lo más probable) 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, se preocupan por las personas que pueden desarrollar soluciones a sus problemas de manera que se alineen con su estrategia de TI.

Pero no me preocuparía demasiado 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 final. Aún te queda mucho por aprender y eso se entiende (probablemente mejor por parte de las empresas que de los estudiantes).

Al igual que 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 un 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 ubicados en diferentes lugares, múltiples proveedores
• el código heredado no tiene ninguna orientación en absoluto
• mientras funcione, a algunos les importa cómo se escribe el código
• incluso si el código no funciona, la motivación es solucionarlo, no "OO",
• módulos, limitaciones de la plataforma, marcos que simplemente no le permiten hacer un buen OO

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

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

Tenía el mismo sentimiento al finalizar mi licenciatura, y un gran libro que me mostró por qué y cómo OOP es relevante para las aplicaciones del mundo real es Head First: Design Patterns . Sinceramente, le recomiendo que eche un vistazo, está escrito de una manera muy divertida y hace muchos puntos válidos de por qué un enfoque OOP es deseable 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 usa muchos patrones de diseño orientados a objetos.

Tengo que expresar algún desacuerdo con esta idea de que OO lo es todo; se podría decir que OO te permite construir ciudades, pero los programas de procedimientos son los ladrillos.

Para dar mi respuesta en forma de analogía, un general necesita objetos, el soldado necesita un procedimiento. 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, ya que es bastante fácil para alguien escribir este código de juego de ajedrez OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

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

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

Por otra parte, si no sabes cómo leer el código OO, preocupate. 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 legado 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).

Eso 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á sobre OSX, todos los chicos geniales están haciendo Ruby o Python, y todas estas cosas y muchos muchos más tienen un enfoque en la orientación a objetos. Muchos de los lenguajes más nuevos son multiparadigm, por lo que algo como F # es principalmente un lenguaje funcional, pero también es compatible con 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, ya que acabas de completar los cursos universitarios significa que estás listo para comenzar a aprender cómo desarrollar código en el mundo real :)

He programado durante mucho tiempo y creo que los conceptos de OO son útiles incluso cuando programo en C, aunque si los probara, es probable que no los describa en cada detalle. En un momento dado, incluso creé un lenguaje OO, aunque rudimentario, para entender mejor los conceptos y encontrar el disfrute en OO desde un nuevo ángulo.

Por cierto, C ++ ha hecho un enorme y feo lío de OO, mientras que el Objetivo 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ánta gente falla incluso en las pruebas de programación muy básicas.

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

Learning OOP no es tan útil como el desarrollo de software de aprendizaje. Vaya a leer Code Complete 2 .

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

Los reclutadores reales notarán la diferencia entre que usted sepa cómo desarrollar software y haga coincidir la casilla de verificación "Tiene 3 años en" OOP ".

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

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

EDITAR: Perdona mi caso de cinismo y sentido del humor del pistolero. Como dijo Raynos, solo porque algo sea OO no significa que sea bueno. La aplicación adecuada de OO requiere trabajo y pensamiento reales; el solo hecho de tener instancias 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 por ahí. Mi experiencia en tiendas corporativas de TI a través de los años 90 y 2000 ha sido que se escribieron muchos códigos erróneos y que probablemente todavía existan. Pero más cerca de la pregunta del OP, me he dado cuenta de que, cuando se les da la oportunidad, los desarrolladores más inteligentes se están moviendo a más sistemas OO.

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

Una vez que aprendas a hacerlo, 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 varias vistas y conceptos. Enumeraré algunas de mis experiencias laborales anteriores:

En una empresa, mis compañeros querían tanto como fuera posible la carga perezosa (constructores vacíos, propiedades voluminosas que tenían que verificar los valores nulos en todas partes). Estaban construyendo objetos del lado del servidor basados en la web que tenían 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 debería estar en el constructor (o una de las muchas sobrecargas de constructores). No se permitían constructores vacíos, ya que los objetos vacíos no tenían derecho de existencia (lo que hacía 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 paréntesis, agregar espacios en blanco después de los comentarios, etc.), porque mi código no se podía registrar si no se podía pasar por style-cop.

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

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

Lo siento 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 conlleva. Algo que trata con la capacidad de abstraer y aislar, agrupar cosas. En conjunto, exponga solo las partes que deben interactuar entre sí.

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

Esos "conceptos de ingeniería" se han intentado mantener en el software desarrollo desde el momento en que los productos de software se habían vuelto más grandes que los "capacidad de desarrollador único", que requiere una forma de hacer que los desarrolladores trabajen en piezas independientes, y deje que esas piezas interactúen entre sí.

Dicho esto, esos principios no se encuentran necesariamente solo en la POO (es la 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 juntar esas cosas, dando a esos términos generales (como módulos, encapsulación, sustitución) más Definiciones precisas y conceptualización elaborada sobre esas definiciones. (patrones) que puede encajar en los lenguajes de programación.

Piense en OOP primero no como " función de idioma " sino como " léxico común " que Hace que los ingenieros de software se acerquen al diseño del software.

El hecho de que un idioma dado tenga o no primitivas que lo apliquen directamente El léxico garantiza, por ejemplo, que una "cápsula" no se abra de forma involuntaria por quien no está Se supone que hacer eso es un aspecto secundario del diseño 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 lo que no se puede reconocer hasta que el tamaño del proyecto permanezca en La capacidad del desarrollador individual para comprender y rastrear todo lo que hace. (de hecho, en esas situaciones puede incluso verse como "gastos generales") o en una pequeña Grupo desarrollando algo en poco tiempo. Y esa es la razón principal por la cual los juniors que estudiaron OOP en términos de una "característica de lenguaje" a menudo lo malinterpretan produciendo código mal diseñado.

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

Entonces, "encapsulación" en C ++ se convierte en "miembros privados" (y una "cápsula" se convierte en una clase), "sustitución" se convierte en funciones virtuales anuladas o parametrización / especialización de la plantilla, etc. mientras que en D una cápsula es un "módulo" (y la sustitución pasa por clases, etc.), por lo tanto poniendo 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 una pregunta de POO es simplemente verificar su capacidad para Resuma y conciba el diseño de software para futuros grandes proyectos y desarrollos. OOP, para ellos es solo un "diccionario" que supusieron que tanto usted como ellos saben para que puede hablar sobre otras cosas más generales o concretar 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 un diseño de este tipo puede obtenerse con cualquier otro lenguaje de paradigma: la razón de la popularidad (especialmente entre las empresas) de OO-languages probablemente se encuentre en el éxito comercial de java y c #.

Si el Sr. Gates hubiera iniciado su compañía 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 por la cual se siente o en un dilema por qué es importante solo se debe al hecho de que no ha 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 que luego se extienden a Automóviles, Camiones ... pero cuando se lanza al desarrollo de software, se trata de una solución orientada a la facilidad de algunas tareas. Ahora, si no fuera por OO tendríamos a todos escribiendo códigos similares en la base de códigos o reinventando las ruedas todos los días. Imagínese el desastre que sería si uno se sumergiera en una base de código para arreglar algo. Los ejemplos en el aula son para una definición o representación vaga de cómo y por qué se hace. La prueba real está fuera cuando comienzas a construir tu aplicación, sin duda como algo que podría ser terriblemente usado 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 y, al menos, generar códigos de pesadilla.

Depende. Una razón por la que necesitas 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 contratarte 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 utilizando OCaml y su empresa se vuelve exitosa, no podrá contratar programadores lo suficientemente rápido y quedará fuera del negocio. Por lo tanto, casi todas las empresas con más de 3 programadores utilizan un lenguaje OO, y para comunicarse con sus compañeros de trabajo y usar las bibliotecas de su plataforma, deberá tener un entendimiento de 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 destruir los patrones de diseño de 10 GoF y un marco de inyección de dependencias. Java es uno de los lenguajes más utilizados, por lo tanto, los principios OO son realmente importantes para las muchas compañías que usan Java.

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

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

• Usted es entrevistado por una persona de recursos humanos que no sabe nada sobre programación y está haciendo preguntas fuera de una lista de verificación. ¿Tienes 3 años de X, haces multitarea, etc.
• Eres entrevistado por un ingeniero que quiere asegurarse de que no has estado viviendo debajo de una roca. OO es la lingua franca, por lo que se te harán algunas preguntas rápidas al respecto.
• Eres entrevistado por un ingeniero que no es muy experto en las entrevistas. En general, a los ingenieros les encantan las trivialidades y la complejidad, por lo que recibirás 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 te 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.