Apelo do empregador; OOP uso no mainstream; soluções que florescem com OOP

4

Atualmente estou no processo do que espero ser uma mudança de carreira no campo da programação. Apesar do meu vasto leque de conhecimentos no campo e da exposição adicional a conceitos na faculdade (que no final deixou muito a desejar), sinto que posso estar perdendo o que realmente importa quando se trata de empregadores.

Eu achei este post link para ser específico da minha situação. Importante:

I've seen a lot of terrible C++ code and it's not just from people who don't understand the concepts. I've seen a lot of coders who know exactly what an object is and can explain polymorphism and all those technical OOP terms perfectly. But if they don't know when to use it, they'll never be able to take full advantage of it. I know because I was like this myself. I had read a book on OOP in high school which explained all the concepts, but I went years before I actually used them because I didn't see when they'd actually benefit my code.

Estou confortável com os conceitos de OOP, mas um pouco enferrujado com linguagens de suporte como Java, C # (meu favorito para OO) e até C ++. A razão pela qual eu não posso afirmar ser pelo menos proficiente nesta área é porque eu não sou realmente vendido em design OO; toda vez que eu me proponho a resolver um problema que pode ser feito em OOP, eu me vejo forçando seu uso e acabo fazendo uma solução processual em C, que eu acredito ser um programa muito mais elegante.

Eu acho que isso envolve três perguntas: Eu ainda posso (honestamente) me vender como sendo valioso para um empregador, considerando meus pontos strongs e fracos, como explicado acima? Existe algum projeto ou problema que eu possa abordar sozinho (para prática) que seja mais inteligente com o OOP? E dado um objeto strong projeto, em que idioma devo me concentrar?

    
por cantide5ga 07.01.2012 / 17:43
fonte

7 respostas

13

Eu acho que o equívoco mais comum sobre o OOP é que ele deve tornar o software escrito muito mais fácil. É daí que vem algumas das críticas, porque ao escrever software, OOP geralmente significa mais e, às vezes, menos código natural. É isso que torna difícil ver os benefícios da OOP, já que todos que começam a programar apenas escrevem novos programas e nunca precisam manter os existentes.

No entanto, o benefício real da POO só mostra quando você precisa manter o software ao longo dos anos, enquanto muda constantemente partes do programa de maneiras que ninguém esperava quando foram escritas pela primeira vez.

Você deve ver a OOP como uma maneira de garantir que as alterações locais no software permaneçam locais e não afetem o restante do programa. Nesse sentido, as classes são uma espécie de espaços reservados explícitos para futuras mudanças. Em um programa procedural, muitas vezes é difícil ver onde você tem que alterar o código para adicionar um recurso completamente novo, sem afetar qualquer outra coisa.

Certamente você pode escrever programas procedurais que também são extensíveis, mas você precisa pensar sobre isso e projetá-lo corretamente. A POO fornece uma ideia geral de como os programas podem ser estruturados para mantê-los passíveis de manutenção, o que significa que não é preciso pensar em design tão difícil! O mesmo vale para outros paradigmas de programação, o OOP não é necessariamente o mais comum agora.

Por fim, acho que a única maneira de realmente entender a OOP é mudar e adicionar recursos ao software existente. Esta é a tarefa mais comum para os programadores de qualquer forma, e é suposto ser fácil! Não ter um bom design torna mais difícil do que tem que ser.

Isso dificulta a resposta à sua pergunta, já que qualquer projeto pode se beneficiar da POO se for complexo o suficiente e precisar ser mantido e expandido. Eu acho que projetos que podem ter qualquer número de recursos imprevistos, tais jogos ou bots, seriam bons exemplos. Você também pode trabalhar em um programa de código aberto, que geralmente é a melhor maneira de praticar a programação avançada.

    
por 07.01.2012 / 18:38
fonte
4

Primeiro, nem todas as aplicações devem ser baseadas no paradigma OO. A programação procedural está muito ativa e é uma alternativa viável para o OO em alguns casos (javascript e php, por exemplo). Se você pode de fato um código mais limpo, mais expressivo e mais eficaz em um estilo procedimental do que um colega de trabalho poderia usar objetos, então você certamente terá valor para um empregador. Tudo o que foi dito, qualquer empregador desligou palavras-chave (cujo dinheiro ainda gasta) ou quem emprega um designer de aplicativo cujo design você deve implementar, pode ser menos do que satisfeito se você estiver (incerto? Não convencido? Eu sei que eu estava não convencido por um ano ou dois) sobre conceitos OO. Eu sugiro que você tente um livro sobre padrões de design (Head First Design Patterns é ótimo) para, talvez, levar sua compreensão OO para o próximo nível. Espero que isso ajude.

    
por 07.01.2012 / 17:59
fonte
1

Não existe um programa elegante em C, a menos que você conte exemplos excessivamente triviais. As vantagens do OO tornam-se inerentemente aparentes assim que você tenta fazer algo básico, como cordas. Se você não consegue ver porque std::string é muito melhor do que C strings em todos os sentidos possíveis, então você precisa dar uma olhada mais de perto. Vou te dar uma vantagem, demonstrando alguns dos enormes benefícios:

A classe de strings padrão lida com toda a sua própria memória - especificamente, você está garantido para nunca vazar std::string . Isso está bem à frente de uma string C.

A classe de string padrão oferece o tamanho O (1). C strings oferecem apenas o tamanho O (n).

A classe de string padrão não requer a terminação NULL. Isso resolve muitos erros off-by-one que existem no código de string C.

A classe de string padrão não pode ter sua memória liberada por outro usuário. Não pode ter a memória realocada por outro usuário. A propriedade é explícita e aplicada pelo compilador. Se você passar um char* para uma função, eles poderão tentar liberá-lo quando você fizer isso, ou coisas assim.

A classe de string padrão é mais inteligente que você. Especificamente, ele pode fazer coisas como otimização de pequenas sequências sem precisar alterar seu código de usuário. Se você quisesse implementar o SSO, teria que refatorar cada bit de código que usa strings. Quando std::string implementa o SSO, você nem percebe.

A classe de string padrão é genérica. A função para ordenar um vetor de números inteiros é exatamente a mesma que para ordenar um vetor de cadeias, e é mais rápida que C's qsort também.

A classe de string padrão cresce quando precisa. Não há mais MAGIC_BUFFER_SIZE códigos que transbordam e são vulneráveis, e você pode garantir que o implementador de sua biblioteca gastou muito tempo, muito mais do que você poderia justificar, definindo e determinando a melhor maneira de crescer.

Quando você compila no modo de depuração, a classe de seqüência padrão irá verificar seus iteradores e índices, e quando você solicitá-lo, indexa no código normal também. Um char[] fará isso por você? Eu duvido.

Portanto, std::string é mais rápido, mais seguro e mais sustentável do que as cadeias C. Outras classes oferecem razões muito semelhantes para serem vastamente superiores em todas as formas possíveis. O que mais você quer da orientação a objetos além de velocidade superior, correção e facilidade de manutenção?

Portanto, praticamente por definição , qualquer programa em C ++ equivalente ao seu programa em C, mas que usa o OO para manipular strings, é inerentemente e muito superior ao seu programa em C.

O problema que você exibe é mais facilmente captado aqui:

I believe to be a much more elegant program.

Você acredita? Impressionante. Por que você não volta e verifica ? Porque acho que você descobrirá que, na verdade, os programas são problemáticos e lentos e seriam muito melhorados com uma aplicação criteriosa da orientação a objetos sólidos. Seus sentimentos subjetivos surgem por razões que nada têm a ver com a qualidade real do programa.

Você precisa reconhecer que as qualidades objetivas de velocidade, manutenção e correção de um programa não têm absolutamente nada a ver com sua opinião subjetiva sobre se é ou não elegante.

E sabe de uma coisa? Nem todo problema é melhor abordado pelo OO. Há uma razão pela qual linguagens como C # possuem lambdas e genéricos, e é porque a herança não é um canivete suíço. É apenas uma ferramenta, e há outras que servem melhor a certos propósitos. É, no entanto, uma ferramenta extraordinariamente eficaz para muitas situações, melhor usada para estruturar programas e módulos.

    
por 08.01.2012 / 17:39
fonte
0

Is there any projects or problems I can tackle solo?

Sim, muitos. Faça um projeto simples em torno de um assunto sobre o qual você sabe alguma coisa, digamos, inscrição de estudante em uma faculdade. Concentre-se em uma classe como Person. Agora a pessoa pode ser um professor, um administrador, um aluno, etc. Então, o que é necessário para manter o registro de um conjunto de cursos? Pensar nesse sentido pode ajudá-lo a definir um escopo para o seu projeto. Certifique-se de cobrir cerca de 5 classes no máximo, para que você possa se concentrar nas técnicas, e não no próprio negócio, e começar a aplicar o que você sabe para construir um aplicativo que resolva o problema. Fique longe de GUI chique, ou métodos de banco de dados sofisticados, uma vez que não é o objetivo. O objetivo é praticar os conceitos OO, independentemente de os dados serem salvos em um arquivo, arquivo XML ou banco de dados.

Outra maneira, e pode ser melhor, é escolher um livro que use um exemplo em uma linguagem que você goste, digamos Java ou C #. Esses livros teriam "OOP" ou "Beginning OO" no título. Certifique-se de navegar pelo livro e sinta que deseja acompanhá-lo antes de comprá-lo.

Quando você tiver coberto o básico, talvez queira passar para livros mais teóricos sobre Análise OO e Design OO, incluindo padrões de design.

    
por 08.01.2012 / 00:34
fonte
0

Para acertar isso de um ângulo de ataque diferente, há algo que o impeça de usar seu conhecimento de domínio em sua profissão principal para escrever software? Você não consegue imaginar um aplicativo que facilite seu trabalho atual? Não sei o que um treinador de desempenho esportivo faz, mas posso imaginar que manter registros da progressão das pessoas que você está treinando e mapeando esse progresso poderia ser útil para você e para as pessoas que você orienta.

Se você criar um aplicativo usando técnicas OO ou de outra forma, terá alguma experiência ao aplicar essas técnicas. Se você for parceiro de outro amigo com habilidades de desenvolvimento de software, começará a entender os problemas de engenharia de software (por exemplo, código de ramificação e mesclagem e problemas de colaboração de equipe no mundo real). Se você enviar o aplicativo (oferecendo gratuitamente ou por uma taxa aos seus colegas em seu trabalho atual), você terá o restante da experiência necessária para entender como dar suporte e manter um aplicativo. À medida que você mantiver o aplicativo, você entenderá as fraquezas do seu design inicial à medida que começar a acomodar solicitações de recursos e correções de bugs.

Naturalmente, isso pressupõe que você não tenha uma necessidade urgente de substituir seu trabalho atual, mas, quando terminar, terá os ingredientes necessários para uma pequena empresa ou experiência suficiente para convencer outra pessoa a empregar você.

    
por 08.01.2012 / 04:16
fonte
0

Como qualquer outro conceito, a OOP pode ser mal utilizada. Eu tenho visto muitos comentários que pretendem mapear os conceitos do mundo real, e IMHO esse caminho leva a estados mentais misteriosos dos quais os sujeitos não podem escapar, produzindo nada além de lixo.

Provavelmente, o seu gosto está correto, e a solução não orientada a objetos é melhor. Acho que tudo o que falta é confiança.

    
por 08.01.2012 / 17:30
fonte
0

OOP é inerentemente bobo. Por que você escreveria código "orientado a objeto"? As pessoas também constroem casas orientadas para concreto? Carros orientados a rodas?

OOP usa uma ferramenta útil e a eleva para uma religião. Um objeto pode ser muito útil como uma ferramenta para ajudar você a definir seu programa. Da mesma forma que uma roda é um componente bastante útil na construção de um carro. Não é apenas algo que tudo faz, ou deveria, girar em torno do termo "OOP".

Objetos são úteis porque nos permitem definir tipos de dados abstratos. Podemos definir uma classe que se comporta como o conceito que desejamos modelar, e que simplifica todo o código que manipula esses conceitos. Uma classe de string é útil porque se comporta como você esperaria que uma string de texto se comportasse. Ele define um número de operações que você espera estar presente ao lidar com strings e evita outras operações sem sentido que seriam possíveis se você estivesse trabalhando nos bytes brutos que usa internamente. Isso me permite pensar sobre strings, em vez de pensar em arrays e inteiros, que são usados internamente para definir a string.

O mesmo deve ser verdade para os objetos que você mesmo define. Eles devem fornecer abstrações e garantias e invariantes que permitem esquecer todos os detalhes da implementação. O ponto em uma classe é que ela deve garantir que nunca possa ser "quebrada" ou colocada em um estado inconsistente. Que você pode confiar nele para se comportar como o conceito que representa.

Se você tiver alguns desses objetos, poderá usá-los como blocos de construção para seu aplicativo.

Mas isso não significa que seu código precisa ser "orientado a objeto". Isso não significa que os objetos devam ser seu programa, ou que tudo esteja associado a um objeto.

OOP não é nada especial. É um paradigma de programação de muitos. Há programação orientada a objetos, há programação genérica, há programação funcional. Existem "nicho", como programação lógica, e "antiquado", como programação procedural. O ponto é que, em geral, a OOP não é "melhor". Ela tem uma poderosa máquina de marketing por trás, mas isso não a torna superior.

O melhor que você pode fazer é tentar aprender o máximo possível para tantos paradigmas diferentes quanto possível. Em seguida, use o que faz sentido na linguagem em que você está trabalhando. Algumas linguagens facilitam a OOP e tudo mais, o que geralmente significa que a OOP será uma opção mais atraente. Outros preferem FP, e alguns permitem praticamente qualquer paradigma .

Quanto aos empregadores, os bons contratam pessoas que são bons programadores. Os maus perseguirão as palavras-chave. (Você sabe OOP? XML? SABÃO? TDD? Ótimo, você é contratado!)

Portanto, não se preocupe muito em se tornar atraente para os empregadores. Concentre-se em tornar-se um programador melhor. Isso envolve manter uma mente aberta e desafiar a si mesmo. Se a OOP não "clicou" para você, não use isso como uma desculpa para voltar ao que você está familiarizado. Jogue-se em novos desafios. Talvez dê uma olhada no OOP de outro ângulo, em um idioma diferente. Talvez dê uma olhada na programação funcional. Tente aprender coisas novas e, mesmo que pareçam inferiores ao que você já conhece, dê a elas uma chance justa e aceite que sua impressão inicial pode estar errada - mas, no final, use seu próprio julgamento. Não há bala de prata e suas críticas podem ser perfeitamente válidas. Apenas não os use como desculpa para parar de aprender.

    
por 08.01.2012 / 18:52
fonte