Muitas vezes ouvi dizer que os objetos não foram entregues em termos de reutilização de código. Você concorda? Se você acredita que não, por que não?
Muitas vezes ouvi dizer que os objetos não foram entregues em termos de reutilização de código. Você concorda? Se você acredita que não, por que não?
Respostas:
Não, não necessariamente.
Os objetos oferecem melhor semântica, organização do código / funcionalidade e, possivelmente, facilidade de uso.
Bibliotecas bem projetadas cumprem a promessa de reutilização de código, não objetos em si.
Sinceramente, não tenho certeza se "reutilização de código" é realmente o que alguém está buscando (ou pelo menos, deve estar procurando). Minha filosofia é "componentes de software", o que significa melhor manutenção através de boas interfaces e evitando acoplamentos desnecessários. A "reutilização de código" é uma das coisas que, às vezes, é excluída - o código duplicado desnecessariamente é um sinal de que você organizou as coisas da maneira errada e, é claro, é uma tarefa difícil de manter.
Para responder à pergunta um pouco mais diretamente, há uma coleção de boas ferramentas para evitar repetições: herança, características, delegação, funções de ordem superior, etc. Destas, as pessoas tendem a confundir herança com OO como um todo - e eles também tendem a abusar um pouco, se você me perguntar. Talvez seja daí que parte da vibração "OO é péssima": encontrar herança presa onde não tem o direito natural de estar :)
Não, "objetos" não tornaram a reutilização de código mais fácil ou mais comum. As mesmas preocupações que impedem que o código seja reutilizado em um programa modular (projetar, testar e documentar uma API de uso geral requerem um esforço inicial muito maior do que escrever uma rotina pontual, e o ponto principal de todas as negociações pode ser o mestre de nenhum - a lógica destinada a ser reutilizada pode não ser bem otimizada para os usos a que se destina) se aplica aos programas OO, com a preocupação adicional de que um modelo de objeto mal projetado pode dificultar a reutilização de outros recursos reutilizáveis código.
OO é uma abstração útil para muitos problemas, mas tenha cuidado com o hype dos anos 80-90: não magicamente resolve os problemas fundamentais do nosso comércio, assim como não faz waffles para você enquanto dorme.
Não espero que TODOS os objetos sejam reutilizados, mas temos muitos objetos que reutilizamos em muitos projetos diferentes. Também temos objetos que são reutilizados em um projeto. Geralmente, consumimos os mesmos objetos de negócios (ou objetos de transferência de dados) e objetos de lógica de negócios de um aplicativo de desktop Click-Once, de aplicativo da Web e de telefone para o mesmo projeto.
Onde você já ouviu falar que o OO não é reutilizado? E qual foi o raciocínio? Talvez o design de seus objetos os tenha forçado a entrar nessa situação ...
Alguns programadores irão copiar e colar em qualquer idioma e estilo.
Realmente bons programadores podem evitar a maioria das cópias e colas em praticamente qualquer idioma.
Acho que os padrões de OO tendem a incentivar a reutilização. Eu vi o código Java que foi escrito em um estilo não OO (onde os dados foram separados do código devido ao ORM de baixa qualidade) e a reutilização foi realmente miserável - mas no OO os mesmos programadores fizeram um trabalho melhor no design ( e reutilizar).
Também nos casos em que usamos padrões não-oo ou oo anti-padrões, como setters / getters, instruções switch, classes internas anônimas, funções enormes e similares que eu já vi reutilização de código diminuir e clichê aumentar ... significativamente.
ps. Eu sei que as pessoas terão problemas com o parágrafo anterior, então vou explicar um pouco.
Setters e getters causam problemas de OO porque permitem que você opere nos membros de um objeto (um objeto deve manipular seus próprios membros) Isso distribui o código que opera em sua classe por outras classes, exigindo que você copie a funcionalidade em torno do setter / getter . Isso também se aplica às propriedades - apenas porque as propriedades são mais fáceis não as tornam "boas" em todas as situações.
O código nas classes internas anônimas não pode ser reutilizado e as pessoas esquecem que muitas coisas (como ouvintes) podem e devem ser classes de pleno direito - isso se aplica também a fechamentos! Se você usou uma classe interna anônima para implementar algo como um ouvinte, é muito mais provável que você copie e cole sua implementação do que extrair o código em um método ou em sua própria classe e chamá-lo. Os fechamentos também podem melhorar a reutilização - depende apenas de como você os usa.
Em muitos casos, os recursos disponíveis para você moldam como você estrutura seu código. OO é ainda mais poderoso quando se trata de ajudá-lo a visualizar todo o seu código e como ele interage, mas isso é outra questão.
Os objetos não têm mais capacidade de fornecer reutilização de código do que um trepador de escada ou outro equipamento de fitness pode oferecer perda de peso. Os desenvolvedores precisam estar motivados para usar as ferramentas corretamente.
Uma vez que as equipes de software valorizam mais a reutilização do código testado do que mantendo todos os detalhes em mente, você verá muito mais objetos e métodos refinados e, portanto, mais reutilização de código.
OOP oferece mais maneiras de reutilizar o código
Não há bala de prata
sobre o que você colocou nele e o que você esperava em troca!
Sim. Uma boa programação orientada a objetos promove a separação de preocupações, baixo acoplamento, alta coesão e ocultação de informações. Essas coisas são essenciais para o código reutilizável.
Eu diria que o principal benefício do OOP é modularidade e modificabilidade, em vez de reutilizar, mas essa é outra questão.
Sim, a capacidade de estender (herdar) de uma super classe claramente contribui para a reutilização de código. Não sei como alguém poderia argumentar o contrário. Você pode simplesmente estender uma classe e substituir um método, enquanto usa o restante da superclasse, se isso não ajudar na reutilização de código, não sei o que é
Se é que eles cumpriram sua promessa de reutilização de código até agora? Sim, se os programas escritos com OOP em mente aplicarem padrões de design com sabedoria. Caso contrário, principalmente não. Mas, observando a popularidade de programas não triviais de larga escala que os sistemas Adobe, Google e similares escrevem com C ++, Java ou outras linguagens OOP, eu diria que a OOP ainda tem um longo caminho a percorrer antes de terminar. Esse tempo será muito mais adequado para fazer essa pergunta e poderá ajudar a fornecer trabalho de base para um novo paradigma.