A programação OO é realmente tão importante quanto a contratação de empresas? [fechadas]

Estou apenas terminando meu mestrado (em computação) e me candidatando a empregos. Notei que muitas empresas pedem especificamente um entendimento da orientação a objetos. As perguntas populares da entrevista são sobre herança, polimorfismo, acessadores etc.

OO é realmente tão crucial? Eu até tive uma entrevista para um trabalho de programação em C e metade da entrevista foi OO.

No mundo real, desenvolvendo aplicativos reais, a orientação a objetos é quase sempre usada? Os principais recursos, como o polimorfismo, são MUITO usados?

Eu acho que minha pergunta vem de uma das minhas fraquezas. Embora eu conheça o OO, parece que não consigo incorporá-lo bastante aos meus programas.

OOP é um paradigma que permite que seu programa cresça sem se tornar impossível de manter / entender. Esse é um ponto que os alunos quase nunca entendem porque apenas realizam pequenos projetos com duração de duas semanas a dois meses, no máximo.

Esse curto período não é suficiente para tornar claro o objetivo da OOP, especialmente se as pessoas no projeto são iniciantes. Mas manter alguma modelagem é crucial para grandes projetos, eu diria> 50.000 linhas de código. OOP não é a única solução para isso, mas é a mais amplamente usada na indústria.

É por isso que as pessoas querem que você conheça OOP.

Eu acrescentaria, por experiência, que quase todos os programadores juniores têm uma falha séria na modelização e POO. A maioria deles sabe escrever classes, herdar delas e coisas básicas como essa, mas não pensa em "OOP" e acaba fazendo mau uso. É por isso que qualquer recrutador sério sempre procurará quais são suas competências no domínio OOP.

Como essas coisas não são aprendidas na escola, há uma enorme variação de conhecimento entre os diferentes candidatos. E sejamos sinceros: não acho que alguém com pouco conhecimento em OOP possa trabalhar em qualquer grande projeto, simplesmente porque exigiria mais tempo para os desenvolvedores líderes gerenciarem essas pessoas do que simplesmente escrever o código por si próprio.

Se você ainda não pensa em "OOP", sugiro que você leia alguns livros sobre ele e se inscreva em empresas que não têm projetos realmente grandes; se acostumar com o POO continuando fazendo um trabalho útil para o seu empregador (e enquanto ele / ela estiver lhe dando seu salário, isso será útil para você também).

EDIT: ha, e gostaria de acrescentar que já escrevi o código OOP em C, mesmo que não seja o uso mais comum de C, isso é possível com forte conhecimento. Você só precisa criar o vtables manualmente.

E por trás da técnica OOP, algo está oculto: design de software. O design do software é realmente útil, tanto em C como em qualquer outro idioma. Muitos recrutadores testarão suas competências de design de software, e as perguntas de OOP são boas para isso, mas OOP não é a principal coisa que está sendo testada aqui. É por isso que você tem essas perguntas mesmo para um trabalho em C.

O grande problema com a programação de computadores é lidar com a complexidade, e os programas modernos podem ser muito complexos, e isso parece apenas aumentar.

Grande parte do trabalho realizado na engenharia de software de programas de computador não triviais concentra-se em domar a complexidade e torná-la acessível ao maior número possível, sem dedicar uma vida inteira ao aprendizado primeiro.

Exemplos:

• Modularização: você torna os programas conceitualmente mais simples, possuindo módulos de código, nos quais cada módulo conhece apenas um pouco sobre outros módulos (em vez de, por exemplo, um roteamento de desenho do ícone do mouse ter permissão para manipular diretamente os buffers da placa de rede).
• APIs: eles fornecem um caminho de uso simples para os programas complexos por trás das APIs. Quando você abre um arquivo, não se importa que os compartilhamentos de rede sejam tratados de maneira diferente de um disco USB. A API é a mesma.
• Orientação a objetos. Isso permite reutilizar o código existente e fazê-lo funcionar de forma transparente com o novo código adicionado, enquanto ainda oculta toda a complexidade subjacente.

Em outras palavras, é necessário conhecer muitos truques se você deseja trabalhar com partes de software não triviais, sozinho ou (provavelmente) com outras pessoas.

Sim, principalmente porque talvez as duas plataformas de desenvolvimento mais populares usadas no desenvolvimento comercial (Java e .NET) sejam orientadas a objetos e isso significa que sim, o OO é muito usado (incluindo polimorfismo, herança e tudo mais).

As empresas não se preocupam especificamente com a orientação a objetos como tecnologia - isso não é uma questão de ideologia, elas se preocupam com pessoas que podem desenvolver soluções para seus problemas de maneira alinhada à sua estratégia de TI.

Mas não me preocuparia muito em sentir que é uma fraqueza. Sem desrespeitar sua educação, a maioria das pessoas no mundo comercial não vê programadores saindo da universidade (em nenhum nível) como o artigo final. Você ainda tem muito a aprender e isso é compreendido (provavelmente melhor pelas empresas do que pelos estudantes).

Como na vida real, a programação da vida real difere da teoria.

Sim, se você mantiver o paradigma OO polido e sempre no fundo da sua mente, poderá fazer melhor escrevendo código que é gerenciável, compreensível e facilmente extensível.

Infelizmente, o mundo real tem isso:

• pressões de tempo do projeto
• membros da equipe orientados a procedimentos
• equipes cruzadas, vários fornecedores
• código legado sem qualquer orientação
• contanto que funcione, alguns se preocupam com a forma como o código é escrito
• mesmo que o código não funcione, a motivação é corrigi-lo, não "OO"
• módulos, limitações de plataforma, estruturas que simplesmente não permitem que você faça o bom OO

Em um trabalho real, você precisa trabalhar com os problemas acima. Isso parece desmoralizante. Mas, trate isso como um aviso. As empresas de contratação dão muita importância ao OO durante a contratação. É fácil ver o porquê. A única maneira de testar o candidato é perguntar sobre o entendimento do OO. E, infelizmente, muitos candidatos apenas retiram essas perguntas antes de aparecer para uma entrevista.

OO da vida real vem lento. Ajuda se você continuar lendo e continuar melhorando ao longo do tempo.

Tive a mesma sensação ao terminar o meu bacharelado, e um ótimo livro que me mostrou por que e como a OOP é relevante para aplicações do mundo real é Head First: Design Patterns . Eu sinceramente recomendo que você espreite, está escrito de uma maneira realmente divertida e faz muitos pontos válidos sobre por que uma abordagem OOP é desejável ao trabalhar com sistemas em larga escala e em constante mudança.

Mesmo para alguns trabalhos em C, talvez você precise conhecer o design orientado a objetos (e provavelmente seja melhor nisso do que se o seu compilador fizesse isso por você), como evidenciado por uma série recente de artigos sobre design orientado a objetos no kernel do Linux. ( Parte 1 , Parte 2 )

O GTK + também usa muitos padrões de design orientados a objetos.

Eu tenho que expressar alguma discordância com essa noção de que OO é tudo - pode-se dizer que OO permite que você construa cidades, mas programas procedurais são os tijolos.

Para dar minha resposta na forma de uma analogia, um general precisa de objetos, o soldado precisa de procedimentos. Depois de detalhar o OO, você encontra procedimentos e, se esse é o seu conhecimento e você é bom o suficiente, não se preocupe com o OO, pois é fácil o suficiente para alguém escrever esse código do jogo de xadrez OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

mas alguém precisa escrever o código por trás de -findBestMove e você pode ter certeza de que não é apenas isso:

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

Por outro lado, se você não souber ler o código OO, preocupe-se. Porque você pode ter certeza (quase) de que seu código estará mexendo com objetos de algum tipo. A menos que você trabalhe no gigante legado fortran de 12000 vars globais e 1200 "módulos" de linha que atualmente mantenho.

Jon Hopkins escreveu:

Sim, principalmente porque talvez as duas plataformas de desenvolvimento mais populares usadas no desenvolvimento comercial (Java e .NET) sejam orientadas a objetos e isso significa que sim, o OO é muito usado (incluindo polimorfismo, herança e tudo mais).

O que é basicamente o que eu ia dizer, mas não é apenas Java e .Net, C ++ está em toda parte, Objective-C está em todo OSX, todas as crianças legais estão fazendo Ruby ou Python, e todas essas coisas e muitas outras. mais têm foco na orientação a objetos. Muitas linguagens mais recentes são multiparadigmas, portanto, algo como o F # é principalmente uma linguagem funcional, mas também suporta a orientação a objetos. Está em toda parte, e ter pelo menos alguma compreensão é muito útil. Não se preocupe muito com isso, ter acabado de concluir os cursos universitários significa que você está pronto para começar a aprender sobre o desenvolvimento de código no mundo real :)

Eu pratico programação há muito tempo e acho que os conceitos de OO são úteis mesmo quando programamos em C - embora, se testado, provavelmente falharia em descrever esses conceitos em todos os mínimos detalhes. Em um ponto, eu até criei uma linguagem OO, embora rudimentar, para entender meus conceitos e encontrar prazer em OO sob um novo ângulo.

BTW, C ++ fez uma bagunça enorme e feia de OO, enquanto o Objetivo C faz o certo.

Sobre as entrevistas, eles se tornaram um show de horror - dos dois lados da mesa. A maioria dos entrevistados está muito assustada com eles. A maioria dos gerentes de contratação se surpreende com o número de pessoas que falham nos testes de programação muito básicos.

Dito isto, existem alguns imensos imbecis trabalhando atualmente na indústria de software que não sabem NADA e ainda esperam o mundo de possíveis empregados.

Aprender OOP não é tão útil quanto aprender desenvolvimento de software. Leia o código completo 2 .

Claro que é uma ferramenta útil, mas o OOP em si é realmente pequeno. Em geral, quando empresas e recrutadores dizem "OOP", significam "desenvolvimento de software". Está sendo usado como um termo genérico.

Recrutadores de verdade dirão a diferença entre você saber como desenvolver software e combinar a caixa de seleção "Tem 3 anos em 'OOP'".

A resposta é sim, como vários outros observaram.

MAS, se você quiser trabalhar com pilhas de códigos espaguetes procedurais que não sejam OO, também poderá encontrar isso lá fora. Eu acho que você prefere o trabalho OO.

EDIT: Perdoe meu caso de cinismo e senso de humor do pistoleiro. Como Raynos disse, apenas porque algo é OO não significa que é bom. A aplicação adequada de OO exige trabalho e pensamento reais; apenas ter instâncias não significa automaticamente que um aplicativo é bem feito. E, inversamente, tenho certeza de que há um código processual bem escrito por aí. Minha experiência em lojas de TI corporativas nos anos 90 e 2000 foi que muitos códigos ruins foram escritos e provavelmente ainda existem. Mas mais perto da pergunta do OP, notei que os desenvolvedores mais inteligentes estão, quando têm a chance, se mudando para mais sistemas OO.

OO é uma base fundamental sobre a qual outras técnicas são construídas. Um ponto chave é primeiro entender completamente a diferença entre um tipo (classe) e uma instância desse tipo. Não tente ler sem entender completamente (pensando que ficará claro mais tarde), porque você terá que ler o resto novamente quando tiver a visão.

Depois de pegar o jeito, você nunca vai querer ficar sem ele. Não sou purista quando se trata de encapsulamento, padrões, estruturas ou qualquer outra coisa. No trabalho, você terá que se adaptar a várias visões e conceitos. Vou listar algumas experiências de trabalho anteriores:

Em uma empresa, meus colegas queriam o máximo possível de carregamento lento (construtores vazios, propriedades volumosas que precisavam verificar valores nulos em todos os lugares). Eles estavam criando objetos do lado do servidor baseados na Web que tiveram uma vida curta.

O próximo trabalho foi totalmente oposto. Objetos vividos dentro de um aplicativo da área de trabalho (baseado no Excel). O máximo de inicialização possível deve estar no construtor (ou em uma das muitas sobrecargas do construtor). Construtores vazios não eram permitidos, pois objetos vazios não tinham direito de existência (o que tornava a persistência um grande desafio). Além disso, eu tive que me adaptar aos seus "padrões de estilo de codificação" (onde abrir parênteses, adicionar espaço em branco após comentários etc ...), porque meu código não pôde ser verificado se não passasse pelo policial de estilo.

Atualmente, estou trabalhando em uma empresa em que nenhum dos desenvolvedores tentou entender OO. É difícil expressar como isso foi extremamente frustrante. Eu tive que melhorar minhas habilidades de Grep, na verdade, tenho uma macro HotScripts atribuída à minha tecla F12 para fazer uma grep no texto selecionado. Vou poupar as outras frustrações ...

Depois de obter as habilidades OO, você quase será alérgico ao espaguete! No entanto, em todos os casos, OO - ou não, seja paciente e se adapte. Seja relutante em "jogá-lo fora e começar de novo". Seu chefe prefere escolher você quando se trata de jogar fora. Infelizmente, "fazer dinheiro" é mais importante que um código elegante.

Desculpe pela resposta longa, mas tentei cobrir a maior parte do escopo da sua pergunta :-)

OOP não é importante por si só, mas por causa do que é preciso. Algo que lida com a capacidade de abstrair e isolar, agrupar as coisas e expor apenas as partes necessárias para interagir.

Essa é uma técnica de engenharia comum chamada "modularização", que permite criar sistemas complexos como agregação de sistemas mais simples, sem cuidar de todos os detalhes de alto nível e exigir que os componentes sejam substituíveis, mesmo sem serem exatamente os mesmos. mesmo.

Esses "conceitos de engenharia" foram mantidos no desenvolvimento de software desde o momento em que o produto de software se tornou maior que o "recurso de desenvolvedor único", exigindo, assim, uma maneira de fazer com que os desenvolvedores trabalhem em peças independentes e deixem essas peças interagir juntos.

Dito isto, esses princípios não são necessariamente encontrados apenas em OOP (se a teoria da computação é válida, existem infinitos métodos possíveis para chegar a esses resultados).

OOP é simplesmente uma tentativa bem-sucedida de reunir essas coisas, dando a esses termos gerais (como módulos, encapsulamento, substituição) definições mais precisas e conceitualização elaborada sobre essas definições (padrões) que podem se encaixar nas linguagens de programação.

Pense no POO primeiro não como um " recurso de linguagem ", mas como um " léxico comum " que faz os engenheiros de software abordarem o design do software.

O fato de uma determinada linguagem ter ou não primitivas que imponham diretamente esse léxico, assegurando, por exemplo, que uma "cápsula" não seja aberta inadvertidamente por quem não deveria fazer isso é um aspecto secundário do design de POO. É por isso que mesmo grandes projetos C geralmente são "gerenciados como" OOP, mesmo que o idioma em si não ofereça suporte direto a isso.

A vantagem de tudo o que não é reconhecível até que o tamanho de um projeto permaneça no recurso de desenvolvedor único para entender e acompanhar tudo o que ele faz (na verdade, nessas situações, pode até ser visto como "sobrecarga") ou em um pequeno grupo desenvolvendo algo em um curto período. E essa é a principal razão pela qual os juniores que estudaram OOP em termos de um "recurso de idioma" geralmente interpretam mal o fato de produzir código mal projetado.

Como o POO se encaixa nas linguagens depende de como os designers de linguagem interpretam o princípio do POO em sua própria construção.

Assim, o "encapsulamento" em C ++ se torna "membros privados" (e uma "cápsula" se torna uma classe), "substituição" se torna substituição de funções virtuais ou parametrização / especialização de modelo etc., enquanto em D uma cápsula é um "módulo" (e a substituição ocorre através de aulas etc.), tornando certo paradigma ou padrão diretamente disponível em um determinado idioma e não em outro e assim por diante.

O que os recrutadores procuram ao fazer perguntas sobre OOP é apenas verificar sua capacidade de abstrair e conceder o design de software para futuros grandes projetos e desenvolvimento. OOP, para eles é apenas um "dicionário" que eles supõem que você e eles conhecem para que você possa falar sobre outras coisas mais gerais ou concretizar em uma implementação específica.

Uma linguagem orientada a objetos ajuda a manter um design orientado a objetos em seu código, o que é bom. Mas também é verdade que esse design pode ser obtido com qualquer outra linguagem de paradigma: a razão da popularidade (especialmente entre as empresas) das linguagens OO está provavelmente no sucesso comercial de java e c #.

Se o Sr. Gates tivesse iniciado sua empresa da maneira certa, provavelmente estaríamos estudando o ESQUEMA antes de se candidatar a um emprego.

Resposta curta é Sim

A versão mais longa, por que você se sente ou em um dilema, por que é importante, é apenas devido ao fato de você não ter trabalhado em nenhum projeto ou implementação que atenda a algum propósito. É perfeitamente válido nas salas de aula ter exemplos no automóvel e depois estender para carros, caminhões ... mas quando você entra no desenvolvimento de software, é uma solução direcionada para facilitar algumas tarefas. Agora, se não fosse OO, teríamos todo mundo escrevendo códigos semelhantes na base de código oureinventar as rodas todos os dias. Imagine que confusão seria se alguém mergulhasse em uma base de código para corrigir alguma coisa. Os exemplos da sala de aula são para uma vaga definição ou representação de como / por que isso é feito. O verdadeiro teste foi lançado quando você começou a criar seu aplicativo, sem dúvida, como qualquer coisa que pudesse ser terrivelmente usada, mas pesa muito a sanidade devido ao seu uso claro e conciso. Portanto, é melhor começar a trabalhar nessas áreas fracas, a menos que você produza códigos de pesadelo.

Depende. Uma razão pela qual você precisa conhecer OO, porque é a língua franca do mundo da programação. Como outra resposta aponta, quase todos os idiomas principais são OO de alguma forma, o que significa que basicamente qualquer empresa que possa contratá-lo está usando um idioma OO. Já tentou contratar programadores OCaml? É impossível; o pool de talentos é muito pequeno. Se você iniciou sua empresa usando o OCaml e sua empresa obtém sucesso, você não poderá contratar programadores com rapidez suficiente e sairá do negócio. Portanto, quase todas as empresas com mais de 3 programadores usam uma linguagem OO e, para se comunicar com seus colegas de trabalho e usar as bibliotecas da plataforma, você precisa entender o OO.

Dependendo do idioma específico que a empresa está usando, a herança e o polimorfismo são extremamente importantes ou apenas moderadamente relevantes. Você não pode fazer nada em Java sem interromper 10 padrões de design do GoF e uma estrutura de injeção de dependência. Java é uma das linguagens mais usadas, portanto, os princípios de OO são realmente importantes para muitas empresas que usam Java.

Se a empresa estiver usando uma linguagem OO / funcional híbrida moderna que possui lambdas e ponteiros de função, como Scala ou C #, a herança de repente se torna menos importante porque você tem funções de ordem superior para lidar com muitas coisas realmente simples que, de outra forma, exigiriam muitas cerimônia. No entanto, você ainda precisa trabalhar com material OO, porque a maioria das bibliotecas que você usa será gravada de maneira OO.

Se a herança e o polimorfismo não são importantes para a empresa, é provável que você receba perguntas de OO porque:

• Você é entrevistado por uma pessoa de RH que não sabe nada sobre programação e está fazendo perguntas em uma lista de verificação. Você tem 3 anos de X, multitarefa etc.
• Você é entrevistado por um engenheiro que quer ter certeza de que não viveu debaixo de uma pedra. OO é a língua franca, então você terá algumas perguntas superficiais sobre isso.
• Você é entrevistado por um engenheiro que não é muito hábil em entrevistar. Em geral, os engenheiros adoram curiosidades e complexidade; portanto, você terá muitas perguntas sobre polimorfismo, herança e padrões de design do GoF apenas porque essas coisas são interessantes para a pessoa que está entrevistando você.

Em uma palavra "Sim".

Você pode pensar que conhece a teoria, mas precisa escrever um código e colocá-lo em prática. Existem - literalmente - milhares de exemplos e exercícios disponíveis on-line.