Estava passando no Stack Overflow e me deparei com muitas dúvidas teóricas sobre compiladores, paradigmas, conceitos de orientação a objetos e outras determinadas coisas que me chamaram muita atenção ("O Java é realmente Orientado a Objetos? E JavaScript? Por quê? O que é, de fato, a orientação a objetos? O que é um paradigma?), desde então estou com uma dúvida: Você acha que esses conceitos tem uso prático no mercado de trabalho?
Se quiser dizer o motivo de sua resposta, será muito bem vindo!
Apesar da pregação da comunidade sobre Java OO, Java é multiparadigma, não tão bom quanto C#, mas é.
Pra mim não tem “sim” ou “não”, depende da necessidade, bom senso e decisão de cada equipe. Nem tudo que chamam de boas práticas é importante pra manter bem uma funcionalidade, pode atrapalhar mais do que ajudar.
Fazendo um paralelo: da mesma forma, entender um pouco de mecânica de motores te ajuda a ser um condutor melhor, mas é possível ser um bom condutor sabendo quase nada de mecânica.
Acho que o que você notou no StackOverflow é que muita gente, principalmente iniciantes, é ensinado a dar importância demais a siglas e essas coisas, em detrimento de uma boa análise e entendimento de alguns conceitos mais básicos, e entender e atender as necessidades do negócio.
Pegando o seu exemplo, ter uma boa base de OO (e outros conceitos) é importante ao se estruturar a aplicação, e saber quando usar e quando não usar OO é talvez o mais difícil.
Embora ainda não seja profissional da área pra dizer com propriedade, gostaria de acrescentar minha opinião.
Acredito ser importante e ajudar, pois conhecer estes conceitos pode te ajudar a pensar melhor sobre a solução de um problema e a escolher a melhor tecnologia para cada caso.
Eu nunca parei pra pensar sobre isso. Em sua opinião, quais seriam os casos de usar e não usar?
Em adição, você diz que é bom e ajuda. Eu só não entendi uma coisa: Se eu quisesse entrar nesse ramo de estudo mais teórico sobre programação, o que eu deveria começar estudando?
Mas, cuidado com comunidades onde alguns se colocam num pedestal de deuses da programação e conhecimentos absurdamente eu sei mais que todo mundo, desconfie, reflita, pegue a melhor parte, pesquise também em outros lugares, livros (principalmente), etc.
A nossa comunidade por exemplo o pessoal é muito bom, e aqui não se vê tantos conceitos, aqui tenta ao máximo resolver os problemas alheios e com isso aprender juntos.
Sua pergunta é interessante e bem válida, mas, reafirmando sempre tente buscar vários lugares de conceitos onde os mesmo batem em vários aspectos e não se divergem …
Não tenho uma resposta completa pra isso pois, como sempre, cada caso é um caso. Mas note que mesmo linguagens “OO” tem ganhado recursos “não-OO”, o que indica que esses recursos “não-OO” são úteis demais para serem deixados de lado, tornando essas linguagens multiparadigma, como disse o javaflex.
Basta olhar para recursos como lambdas do Java (que são extremamente comuns em linguagens mais funcionais, como Python e Lua), ou mesmo os callbacks que se usa constantemente em Javascript por exemplo (também extremamente comuns em linguagens funcionais e em C, que é comumente descrita como procedural).
Eu te diria pra cursar Ciência da Computação, mas é uma resposta muito longa e cara.
Primeiro você precisa se perguntar: por que você quer entrar nesse lado mais teórico da computação? O que espera obter com isso? Quais conceitos você tem em mente que quer entender? São só as diferenças e aplicações de paradigmas distintos ou algo mais?
Uma coisa que gosto de reforçar sempre que posso é um bom entendimento de estruturas de dados (pilhas, filas, tabelas hash, árvores, indo até autômatos e grafos, se possível).
Outra coisa que acho interessante é estudar linguagens funcionais. No meu caso, tenho preferência por Lua, pois acho-a menos inchada e complexa que Python (que já é uma linguagem multiparadigma a essa altura).
Java é multiparadigma é interessante ver isso, porque, a comunidade na sua maior parte diz que não, que é totalmente Orientada a Objeto … e foi concebida assim, é o que eu sempre digo em que projeção tem razão (só ratificando sou C# e também acho que Java não é só POO) mas, a comunidade no seu geral prega outra coisa … Interessante comentário, parabéns!
Estou cursando Análise e Desenvolvimento de Sistemas :o
Eu pensei em duas coisas: Primeiro, para realmente entender como funciona. Eu nunca havia parado pra pensar sobre isso, e bem, eu trabalho com programação. Achei que isso era algo que a galera, conforme o tempo passa, vai querer saber… O segundo motivo é que eu penso muito em fazer um mestrado, e me perguntei se isso seria uma linha de pesquisa. Estou cheio de dúvidas sobre o mestrado, mas acho que isso eu vou postar em outro tópico!
Em suma, muita coisa do que se prega, não se aplica!
A comunidade sempre comenta prezando a utilização de OO no desenvolvimento, mas na prática nem sempre ocorre, fica aquela velha situação do faça o que eu digo mas não faça o que eu faço.
Concordo totalmente com as respostas dos amigos acima.
Meu problema é nunca conseguir “achar um norte para começar” sozinho. Quer dizer, eu li o post do SO sobre Paradigmas e fiquei curioso e comecei a querer entender mais, mas agora eu não sei por onde começar… hehe
Mas concordo, não quero tomar uma resposta como absoluta e sim ouvir a todos e tirar minha opinião a partir daí.
Acho que meu objetivo é mais acadêmico, começar a pesquisar para definir uma linha de pesquisa para um futuro mestrado por exemplo. Se depender da equipe atual onde estou, apenas programar já é suficiente e eu sinceramente não quero ficar só nisso…
Acho que é bem possível conciliar a teoria e a pratica da programação, certo?
Eu acho que pouquíssimas pessoas realmente sabem o que é OO.
A orientação a objetos surgiu para impor disciplina na transferência indireta de controle entre partes de um programa estruturado. Ela substituiu os ponteiros para funções por polimorfismo, reforçando as regras a respeito de como essas funções podem ser usadas. Com essas regras, é mais fácil entender e controlar o programa. É isso. É só isso. A linguagem é um detalhe.
Paradigmas de programação impõem restrições sobre os programas. O paradigma estruturado impõe restrições a respeito de trasnferência direta de controle (go to), e o funcional impõe restrições sobre atribuições (separando o conceito de identidade do conceito de valor).
O paradigma é apenas um detalhe. Muito mais importante é saber construir um código coeso e coerente. Essa skill de design é uma das mais difíceis de se desenvolver, porque não existe um método objetivo para se seguir. É muito mais uma arte do que uma ciência. Leitura nos dá a capacidade de olhar para um código e dizer se ele é bom ou ruim, mas não nos ensina como construir um design bom.
Mas estao certos, no mercado o mais importante é atender o Negócio da forma mais eficiente e simples de manter. No meio academico dá sim pra conciliar bem teoria com um pouco de prática, mas de qualquer forma você precisa estar nesse ambiente pro norte vir naturalmente.
Acho importante estudar os conceitos, mesmo para uso prático.
É válido ouvir seu time para o problema específico que está resolvendo, mas depender apenas deles limita sua soluçao apenas ao que seu time pode fazer. E se todo mundo sempre seguir esse método, nunca haveria evoluçao, apenas copiariam soluçoes anteriores, possivelmente ignorando melhores maneiras de se resolver o mesmo problema.
Dado um conceito específico (um paradigma, uma boa prática, uma ferramenta, uma técnica, etc), as pessoas costumam atuar em diferente estágios:
Nao conhecem o conceito: resolvem o problema de outra maneira por ignorar a prática.
Usam por ser boa prática: utilizam o conceito por acreditar ser boa prática, as vezes de forma errada ou incompleta, porque aprenderam por cima, de ouvir dizer. Podem desconhecer os reais benefícios ou limitaçoes.
Conhecem por ler a respeito, sem experiência: leram a respeito do conceito mas sem utilizar na prática. Geralmente querem usar toda hora (para ganhar experiência), mas nao conhecem as limitaçoes
Conhecem bem com experiência: muitas vezes chamado de “já passou raiva” com aquilo, a pessoa conhece o conceito, onde ajuda e onde atrapalha.
Conhece bem com a experiência dos outros: como o caso anterior mas você tenta usar a experiência de outros que já tiveram problemas, para conhecer as limitaçoes do conceito.
Acho que você deveria sempre tentar estar em uma das duas últimas opçoes antes de tentar algo na prática, mas o mais comum no mercado, que vejo, é o pessoal nas outras opçoes.
Esse é o estágio ideal, mas também o mais difícil de se atingir.
Pra ter experência, você tem que usar em um projeto e muita gente acaba forçando a barra em um projeto que as vezes nem precisa daquilo, só pra adquirir essa experiência.
É o velho problema do ovo e da galinha.
Esse é o melhor caminho, pode ser que nem te encorajem em ficar nesse assunto, mas algo com mais peso pra atualidade, relacionado a segurança da informação, IA, etc.