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

55

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.

ale
fuente
3
Todo no esta perdido. Reconocer que hay un problema es el primer paso para corregirlo :)
devorado elysium el
37
Me llevó varios años entender POR QUÉ exactamente OO es un concepto útil. Podía entender todas las partes técnicas, pero simplemente no pude encontrar nada de eso útil. Supongo que gran parte de eso fue de ejemplos tontos que me han mostrado con perros que extienden mamíferos que extienden animales ... Lo que me abrió los ojos fue una mirada a los patrones de diseño de OO, especialmente los patrones de Oyente (también conocido como Observador) y Estrategia
Mchl
1
Sí lo es. Honestamente.
quant_dev el
66
Ver la respuesta de Thorbjørn Ravn Andersen. Para ser un buen programador, necesita conocer la modularidad y el diseño de API. No todos los programadores de la industria son buenos, pero la mayoría usa OOP. Desafortunadamente, la combinación de OOP y código no modular y API deficientes conduce a un software de baja calidad, y verá que funciona mucho este tipo de código. A menos que escriba una gran cantidad de código en su tiempo libre, probablemente no sepa mucho sobre la POO "real". Está bien, no estás solo en esta posición.
Joh
1
Ho sí que puede. Y créanme, si tienen el mismo conocimiento de OOP que tenían cuando obtuvieron su maestría, entonces probablemente no sepan nada sobre OOP.
deadalnix

Respuestas:

84

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.

deadalnix
fuente
2
Y sí ... como escribí en un comentario anterior, creo que necesito trabajar en un proyecto más grande para apreciar OOP :).
ale
55
No necesita vtables para ser OOP. simplemente usar structy funciones que funcionan en esa estructura en C es OOP.
edA-qa mort-ora-y
2
@ edA-qa mort-ora-y struct no te da la funcionalidad de OOP. Polimorfismo? Herencia ? ¿Eso significa algo para ti? Bien, entonces, ¿cómo implementan funciones virtuales sin una vtable?
deadalnix
2
@deadalnix: los implementa de la misma manera que .NET y Java hacen herencia múltiple. Debe saber que los primeros compiladores de C ++ no fueron compiladores, fueron traductores que tomaron el código de C ++ y lo convirtieron en código de C que se pasó a un compilador de C. Google "CFront".
gbjbaanb
3
Java y; NET no hacen herencia múltiple. Y sí, C ++ es traducible en C automáticamente, pero esto no tiene ninguna relación con el problema de usar vtable o no. De hecho, debe hacerlo: no puede implementar funciones virtuales sin una vtable.
deadalnix
38

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.

usuario1249
fuente
77
Me gusta que hayas marcado la diferencia entre modularidad, API y OO. Creo que hay una idea errónea muy extendida en la industria del software de que OO significa todas estas cosas.
Joh
3
Aun sabiendo que OO en sí mismo no es un requisito establecido, los paradigmas procesales y funcionales son suficientes en ciertas áreas (C o Haskell). Aún necesita aprender Modularización y diseño de API.
Raynos
@Raynos, en C tiene punteros de función que le permiten hacer explícitamente lo que OO hace intrínsecamente. De manera similar, Haskell usa la coincidencia de patrones para hacer explícitamente lo que hace el compilador, por ejemplo, en Java.
@ThorbjornRavnAndersen es un poco nicho para escribir estilo OO C y Haskell. Solo digo que la reutilización del código se puede hacer en el paradigma procesal y funcional.
Raynos
3
@mathepic No estoy diciendo que uno deba escribir OO haskell (o si existe). Estaba diciendo que no necesitas saber OO. Hay otras formas de manejar la complejidad (FP)
Raynos
14

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).

Jon Hopkins
fuente
2
Tengo que llamarlo sobre compañías que no se preocupan por OO: las buenas empresas se preocupan por las bases de código reutilizables / mantenibles, y los patrones de OO son la forma reconocida de hacerlo.
HorusKol
1
@HorusKol: lo hacen, pero a pesar de que Perl, Cobol y Visual Basic tuvieron éxito comercial y Smalltalk no. Tienes razón en las empresas, como el código mantenible, pero no es un requisito absoluto, lo sopesarán con otros factores.
Jon Hopkins
Bueno, Cobol ya existía antes de OO. No puedo comentar sobre Smalltalk, pero imagino que debe haber habido problemas con él si no fue recogido.
HorusKol
1
@HorusKol: en realidad, Cobol y OO comenzaron a existir aproximadamente al mismo tiempo (finales de los 50), pero incluso si asumimos que OO realmente no comenzó a afianzarse hasta los 70 o incluso los 80 (si esperas C ++) si es ESO un gran problema para las empresas por qué no se hizo popular hasta finales de los 90 (con Java). La respuesta es que hay formas de tener una base de código mantenible que no sea OO: las empresas se preocupan por el código mantenible, pero hay más de una forma de ocultar un gato y OO no es la única solución.
Jon Hopkins
Es un poco extraño llamar a las plataformas mismas OO. Clojure no es OO. Scala tiene algunos elementos OO, supongo, pero se usa mejor de manera funcional. F # es algo así como el mismo trato. escribir código OO en F # es simplemente sucio.
sara
7

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.

Amol
fuente
6

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.

David Haas
fuente
¡Me alegro de no ser el único! Gracias. Echaré un vistazo a ese libro :).
ale
6

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.

Ken Bloom
fuente
4

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.

Alex
fuente
4

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 :)

eviltobz
fuente
3

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.

Ponk
fuente
C ++ es un lenguaje de paradigmas múltiples pero maneja OO bastante bien ... ¿no?
Nikko
1
Yo diría que el C ++ te da la capacidad de hacer un gran desastre feo. Si se hace correctamente, su belleza es su simplicidad.
Martin York
Omitir lo básico siempre da un gran desorden. C ++ solo tiene una gran cantidad de conceptos básicos que debe comprender. Es por eso que es posible usar C ++ para programas grandes. Es necesario.
tp1
@Ponk: Por cierto, C ++ ha hecho un desastre enorme y feo de OO, mientras que Objective C lo hace bien. - No he probado el Objetivo C, así que no tengo motivos para dudar de ti, pero ¿dónde puedo encontrar un argumento más completo y convincente para esto?
Jim G.
3

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'".

Raynos
fuente
Sí, en este contexto, la POO es como la GUI, como en "necesitas 5 años de experiencia en la GUI para este rol".
gbjbaanb
1

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.

Bernard Dy
fuente
3
-1 por implicar código no OO es spaghetti. y que OO hace bien "no spaghetti" por magia negra.
Raynos
@Raynos Ese es un punto justo. Y solo porque algo no use OO no significa que sea malo. Voy a editar
Bernard Dy
Tampoco es solo un procedimiento vs procedimiento / OOP, también hay paradigmas funcionales.
alternativa el
He trabajado en aplicaciones OO que no se pueden mantener, donde los objetos se dispersaron como confeti. OOP no es una bala mágica, es solo una forma más definida de organizar su código.
gbjbaanb
2
¡Sí, sí, mil veces sí! Por favor vea la edición. Mi comentario fue realmente más irritante en las numerosas instancias de código heredado pobre en el que he tenido el placer de trabajar que un desaire particular de procedimiento u OO. Pero si tuviera la opción, preferiría trabajar en un sistema OO bien diseñado que en un sistema procesal bien diseñado; y un sistema bien diseñado sobre uno mal diseñado cualquier día.
Bernard Dy
1

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 :-)

Louis Somers
fuente
Muchas gracias por tus historias. ¡Disfruté leyéndolas! Actualmente estoy trabajando en un proyecto C ++ y estoy aprovechando esta oportunidad para pensar en posibles formas en que podría usar las técnicas OO. Va bien en este momento :). +1 por tu respuesta. Gracias.
ale
1

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.

Emilio Garavaglia
fuente
0

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.

Lorenzo Stella
fuente
Scheme apareció el mismo año que Microsoft (aunque ciertamente había otros LISP antes de eso). Además, Java y C # deben mucho de su éxito a Alan Kay, específicamente Smalltalk y Simula antes de eso, así como al éxito de C ++.
JasonTrue
0

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.

V4Vendetta
fuente
0

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.
dan
fuente
¿Por qué el voto negativo?
dan
-1

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.

Binario Worrier
fuente