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

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

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

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

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

Se você ainda não pensa em "OOP", sugiro que leia alguns livros sobre o assunto e aplique na empresa que não tem projetos realmente grandes; se acostumar com a OOP, fazendo trabalho útil para o seu empregador (e, desde que ele / ela esteja lhe dando seu salário, isso também será útil para você).

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

E por trás da técnica OOP, algo está escondido: design de software. Design de software, é realmente útil, em C como em qualquer outro idioma. Muitos recrutadores testarão suas competências de design de software, e a pergunta de OOP é boa para isso, mas a 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 da programação de computadores é lidar com a complexidade, e programas modernos podem ser muito complexos, e isso parece aumentar.

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

Exemplos:

• Modularização: Você torna os programas conceitualmente mais simples tendo módulos de código, onde cada módulo só sabe um pouco sobre outros módulos (em vez de, por exemplo, um roteamento de ícones de mouse sendo permitido manipular buffers de placas de rede diretamente).
• 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 do objeto. Isso permite que você reutilize o código existente e faça com que ele funcione de forma transparente com o novo código adicionado, enquanto ainda oculta toda a complexidade subjacente.

Em outras palavras, conhecer muitos truques é necessário se você quiser trabalhar com softwares não triviais, sozinho ou (mais provavelmente) com outros.

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 sim, OO é muito usado (incluindo polimorfismo, herança e tudo mais).

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

Mas eu 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ê os programadores deixando a universidade (em qualquer nível) como o artigo finalizado. 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 daquela na teoria.

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

Infelizmente, o mundo real tem isso:

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

Em um trabalho real, você precisa trabalhar com os problemas acima. Isso parece desmoralizante. Mas, trate isso como um heads up. Contratar empresas dão muita importância à OO durante a contratação. É fácil perceber porquê. A única maneira de testar o candidato é perguntando sobre o entendimento do OO. E, infelizmente, muitos candidatos apenas retificam essas questões antes de comparecer para uma entrevista.

OO da vida real vem devagar. Isso ajuda se você continuar lendo e continuar melhorando ao longo do tempo.

Eu tive o mesmo sentimento ao terminar 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ê dê uma espiada, está escrito de uma forma muito divertida e faz vários pontos válidos de por que uma abordagem OOP é desejável quando se trabalha com sistemas em grande escala, que mudam constantemente.

Mesmo para alguns trabalhos em C, talvez seja necessário conhecer o projeto orientado a objetos (e provavelmente ser melhor do que se o compilador fizesse isso por você), conforme evidenciado por uma recente série 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 algum desacordo com essa noção de que OO é tudo - pode-se dizer que OO permite que você construa cidades, mas programas processuais são os tijolos.

Para dar a minha resposta na forma de uma analogia, um general precisa de objetos, o soldado precisa de procedimentos. Uma vez que você fura o suficiente em OO, você encontra procedimentos, e se essa é sua especialidade e você é bom o suficiente, não se preocupe com OO, porque é fácil o suficiente para alguém escrever este código de jogo de xadrez OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

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

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

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

Jon Hopkins escreveu:

Yes, primarily because perhaps the two most popular development platforms used in commercial development (Java and .NET) are object oriented and that means yes, OO is used a lot (including polymorphism, inheritance and everything else).

O que eu diria, 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 muitos mais têm foco na orientação a objetos. Muitas linguagens mais recentes são multiparadigm, então algo como F # é basicamente uma linguagem funcional, mas também suporta orientação a objetos. Está em toda parte, e ter pelo menos alguma compreensão é muito útil. Não se preocupe muito com isso, tendo acabado de concluir cursos universitários significa que você está pronto para começar a aprender sobre o desenvolvimento de código no mundo real:)

Eu faço programação há muito tempo e acho que os conceitos de OO são úteis mesmo quando estou programando em C - mesmo que, se testados, eu provavelmente não consiga descrever esses conceitos em cada detalhe minúsculo. Em um ponto, eu até criei uma linguagem OO, ainda que rudimentar, para entender meus conceitos e encontrar prazer em OO de um novo ângulo.

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

Sobre as entrevistas, eles se tornaram um show de horror - de ambos os lados da mesa. A maioria dos entrevistados está muito assustada com eles. A maioria dos gerentes de contratação fica impressionada com a quantidade de pessoas que falham em testes de programação muito básicos.

Dito isto, há alguns enormes babás trabalhando atualmente na indústria de software que não conhecem NADA e ainda esperam o mundo de possíveis funcionários.

O OOP de aprendizagem não é tão útil quanto o desenvolvimento de software de aprendizado. Vá ler Código Concluído 2 .

Claro que é uma ferramenta útil, mas a própria OOP é muito pequena. Em geral, quando empresas e recrutadores dizem "OOP", eles querem dizer "desenvolvimento de software". Está sendo usado como um termo genérico.

Os recrutadores reais vão dizer a diferença entre você saber como desenvolver software e combinar com a caixa de seleção "Tem 3 anos em 'OOP'".

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

MAS, se você quiser trabalhar em pilhas de código espaguete não-OO, você pode descobrir isso também. Eu acho que você vai preferir o trabalho OO.

EDIT: Perdoe o meu caso de cinismo e senso de humor do pistoleiro. Como Raynos disse, só porque algo é OO não significa que seja bom. A aplicação apropriada de OO requer trabalho e pensamento reais; apenas ter ocorrências disso não significa automaticamente que um aplicativo é bem feito. E, inversamente, tenho certeza de que existe um código processual bem escrito por aí. Minha experiência em lojas de TI corporativas durante os anos 90 e 2000 foi a de que muitos códigos ruins foram escritos e provavelmente ainda existem. Mas, mais próximo da pergunta do OP, notei que os desenvolvedores mais espertos, quando lhes é dada a oportunidade, mudam 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 isso (pensando que ficará claro mais tarde), porque você terá que ler o resto mais uma vez, assim que captar a visão.

Depois de pegar o jeito, você nunca vai querer passar sem isso. Eu não sou purista quando se trata de encapsulamento, padrões, frameworks 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 construindo objetos do lado do servidor baseados na web que levavam uma vida curta.

O próximo trabalho foi totalmente oposto. Objetos viviam dentro de um aplicativo de desktop (baseado no Excel). Tanto quanto possível, a inicialização deve estar no construtor (ou uma das muitas sobrecargas do construtor). Construtores vazios não eram permitidos, já que os objetos vazios não tinham direito de existência (o que tornava a persistência um grande desafio). Além disso, tive que me adaptar aos seus "padrões de estilo de codificação" (onde abrir parênteses, adicionar espaço em branco depois de comentários, etc ...), porque meu código não poderia ser verificado se não passasse por style-pol.

Atualmente, estou trabalhando em uma empresa na qual nenhum desenvolvedor tentou entender o OO. É difícil expressar o quanto isso é extremamente frustrante. Eu tive que melhorar minhas habilidades em Grep, na verdade eu tenho uma macro HotScripts atribuída à minha chave F12 para fazer um grep no texto selecionado. Vou poupar as outras frustrações ...

Depois de obter habilidades OO, você quase será alérgico a 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 preferirá escolher você quando se trata de jogar fora. Infelizmente, "fabricar 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 é necessário. Algo que lida com a capacidade de abstrair e isolar, agrupar coisas juntos, expor apenas as partes que são necessárias para interagir juntos.

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

Esses "conceitos de engenharia" foram tentados para serem mantidos no software desenvolvimento a partir do momento em que o produto de software se tornou maior do que o "capacidade de desenvolvedor único", exigindo assim uma maneira de fazer com que os desenvolvedores trabalhem em peças independentes, e deixe essas peças interagirem juntas.

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

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

Pense no OOP primeiro não como um " recurso de idioma ", mas como um " léxico comum " que faz com que os engenheiros de software abordem o design de software.

O fato de que uma determinada linguagem tem ou não primitivos que aplicam diretamente essa léxico garantindo, por exemplo, que uma "cápsula" não é aberta inadvertidamente por quem não é deveria fazer isso é um aspecto secundário do design de OOP. É por isso que mesmo grandes projetos C são frequentemente "gerenciados como" OOP, mesmo se o idioma em si não oferece suporte direto para isso.

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

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

Entã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 de modelos / especialização etc, enquanto em D uma cápsula é um "módulo" (e substituição passa por classes etc.), assim fazendo certo paradigma ou padrão diretamente disponível em uma determinada língua e não em outro e assim por diante.

O que os recrutadores buscam ao fazer a pergunta da OOP é apenas verificar sua capacidade de Resumo e projeto de software para futuros projetos e desenvolvimento de grande porte. OOP, para eles é apenas um "dicionário" eles supostamente você e eles sabem para que você pode 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 tal design pode ser obtido com qualquer outra linguagem paradigmática: a razão da popularidade (especialmente entre empresas) de linguagens OO está provavelmente no sucesso comercial de java e c #.

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

Resposta curta é Sim

A versão mais longa porque você se sente ou em um dilema a respeito de por que sua importância é apenas devido ao fato de você não ter trabalhado em nenhum projeto ou implementação que tenha algum propósito. É perfeitamente válido nas salas de aula ter exemplos em Automóveis, depois estendidos a Car, Caminhões ... mas quando você entra no desenvolvimento de software, é uma solução direcionada para facilitar algumas tarefas. Agora, se não fosse por OO , teríamos todos escrevendo códigos semelhantes na base de código ou reinventando as rodas todos os dias. Imagine que bagunça seria se alguém mergulhasse nessa base de código para consertar alguma coisa. Os exemplos de sala de aula são para uma definição vaga ou representação de como / por que isso é feito. O teste real é lançado quando você começa a criar seu aplicativo, sem dúvida, como qualquer coisa que poderia ser terrivelmente usado, mas pesa muito a sanidade, devido ao seu uso claro e conciso. Então é melhor começar a trabalhar nessas áreas fracas, pelo menos você produz códigos de pesadelo.

Depende. Uma razão pela qual você precisa conhecer a OO porque é a lingua franca do mundo da programação. Como outra resposta aponta, quase todas as principais línguas são OO de alguma forma, o que significa que basicamente qualquer empresa que possa contratá-lo está usando uma linguagem OO. Já tentou contratar programadores do OCaml? É impossível; o pool de talentos é muito pequeno. Se você iniciou sua empresa usando o OCaml e sua empresa se torna bem-sucedida, você não poderá contratar programadores com rapidez suficiente e sairá do mercado. 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 sua plataforma, você precisa ter uma compreensão da OO.

Dependendo da linguagem específica 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 estourar 10 padrões de projeto GoF e uma estrutura de injeção de dependência. Java é uma das linguagens mais utilizadas, portanto, os princípios OO são realmente importantes para muitas empresas que usam Java.

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

Se a herança e o polimorfismo não forem importantes para a empresa, ainda assim é provável que você receba perguntas 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, você faz multitarefa, etc.
• Você é entrevistado por um engenheiro que quer ter certeza de que você não vive sob uma rocha. OO é a língua franca, então você será perguntado algumas questões superficiais sobre isso.
• Você é entrevistado por um engenheiro que não é muito hábil em entrevistar. Em geral, os engenheiros adoram trivialidades e complexidades, então 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 achar 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.