Pontos fortes e fracos da programação orientada a objetos

Assuntos Gerais Notícias
#1

Boa noite, estou desenvolvendo um artigo científico sobre programação orientada a objetos e estou debatendo os pontos fortes e fracos do paradigma…

porém até agora não encontrei pontos fracos com excessão da demora no desenvolvimento do sistema (ao invés de desenvolver um arquivo só, as vezes desenvolvemos mais) que ao meu ver não seria bem uma desvantagem pois o mesmo seria uma vantagem futura pois o projeto seria mais organizado, mais legível e bem mais fácil de se dar manutenção…

bom, abaixo estão os benefícios que consegui descrever… peço que me corrijam caso estejam errados…
[b]

Benefícios

Fragmentação
O conceito fragmenta o sistema em módulos, como exemplo na vida real pode ter o funcionário contador que exerce funções específicas de sua área, o contador não é responsável por administrar a empresa, para isso já existe um outro funcionário específico, por tanto na POO funciona da mesma forma, cada módulo é responsável por manipular informações sobre um determinado assunto.

Reutilização
Podemos reutilizar códigos já desenvolvidos que exerçam uma determinada função, na vida real podemos comparar a uma televisão na qual ela pode ser utilizada para a exibição de diversos canais, já na programação temos o exemplo da validação de um CPF na qual é importante em todos os cadastros para verificar a consistência dos dados fornecidos no cadastro, assim, caso haja muitos cadastros em um sistema como fornecedor, clientes, funcionários entre outros, bastaria que fosse desenvolvido uma vez a função de validação e a mesma poderia ser reutilizada em todos os cadastros.

Agilidade
Com a reutilização de código não precisamos ter o mesmo código diversas vezes, apenas reutilizamos, assim torna mais fácil a detecção de erros, uma vez que quando ao reutilizarmos o código e seja necessário fazer uma alteração em um cálculo qualquer desse código, não precisamos alterar o código várias vezes, fazendo com que possamos ir diretamente na fonte do erro, ganhando assim bastante tempo ao procurá-lo.

Organização
Os arquivos são organizados em pacotes ou simplesmente diretórios que facilitam a alocação correta dos arquivos de um determinado assunto.

Segurança
Os arquivos podem ter seus acessos limitados através de uma funcionalidade denominada modificadores de acessos que dá o devido acesso a um determinado arquivo.

As características citadas acima só nos mostram que a POO nos resulta em um aumento significativo da produtividade, tornando o código-fonte mais legível, flexível e sendo assim bastante fácil a manutenção do mesmo até por programadores que não participaram do desenvolvimento.
[/b]

#2

Os pontos fracos da Programação Orientada a Objetos são:
a) não é boa para resolver problemas simples;
b) não é a melhor forma para gerar interfaces gráficas;
c) não é produtiva para projetos de curto baseline;
d) cega de visão de outras relações ambiental e por isso descarta qualquer coisa que não seja objeto como por exemplo necessidades estruturais, procedimentais e MER (*);
e) sugere que junção de ações e atributos é uma heresia e por isso leva muitos profissionais a complicarem o projeto com excessos de fragmentação do projeto (atomicidade burocrática).

(*) Existem ORMS e padrões de projetos para “suavizar” isso hoje.

Obs.: Não sou contra a POO, só exponho os pontos fracos para apoiar melhor na escolha da POO dentre outros métodos de programação.

wiliamps

#3

nenhuma das características que você descreveu, com exceção da que chamou de segurança (que a meu juízo deveria se chamar encapsulamento) é exclusiva de OO.

#4

veja se esse artigo do maior de todos lhe ajuda:

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html

#5

[quote=wiliamps]Os pontos fracos da Programação Orientada a Objetos são:
a) não é boa para resolver problemas simples;
b) não é a melhor forma para gerar interfaces gráficas;
c) não é produtiva para projetos de curto baseline;
d) cega de visão de outras relações ambiental e por isso descarta qualquer coisa que não seja objeto como por exemplo necessidades estruturais, procedimentais e MER (*);
e) sugere que junção de ações e atributos é uma heresia e por isso leva muitos profissionais a complicarem o projeto com excessos de fragmentação do projeto (atomicidade burocrática).

(*) Existem ORMS e padrões de projetos para “suavizar” isso hoje.

Obs.: Não sou contra a POO, só exponho os pontos fracos para apoiar melhor na escolha da POO dentre outros métodos de programação.

wiliamps

[/quote]

Cara, com todo o respeito à sua opinião, poderia detalhar melhor os pontos que você elencou? Acho a discussão relevante e gostaria de compreender melhor o que você quis dizer, já que olhando suas palavras, eu discordo totalmente desses “pontos negativos”. Em especial esse aqui

Não vejo sentido nessa afirmação, respeitosamente.

#6

[quote=alias][quote=wiliamps]
e) sugere que junção de ações e atributos é uma heresia e por isso leva muitos profissionais a complicarem o projeto com excessos de fragmentação do projeto (atomicidade burocrática).
[/quote]

Não vejo sentido nessa afirmação, respeitosamente.

[/quote]
Eu ia questionar justamente essa afirmação. Não vejo sentido também. Poderia elaborar?

#7

o william deu uma verdadeira lição do que OO tem de fraco e que usamos BPM e arquitetura corporativa pra dizimar.
Os projetos OO não tem visão global, são sempre pra solucionar problemas pontuais e nao de ambito corporativo.

d) cega de visão de outras relações ambiental e por isso descarta qualquer coisa que não seja objeto como por exemplo necessidades estruturais, procedimentais e MER (*);
Em se tratando de processos cada sistema OO é apenas uma caixa, leia sobre BPM e verá que OO nao se encaixa dentro desse paradigma.

Tá tudo certo o que ele disse assino embaixo, mas o OO continua sendo interessante pois precisamos dele pra resolver problemas pequenos que juntos viram um grande problema.

#8

Aonde isso está certo?

#9

Se voce tem um processo dinamico e evolutível onde envolvem departamentos distintos em que os fluxos mudam constantemente definitivamente OO não resolverá seu problema jamais.

#10

Não fuja do tópico, cara. O que o ponto que eu citei, que você disse que assina embaixo tem de verdade?

#11

Não fuja do tópico, cara. O que o ponto que eu citei, que você disse que assina embaixo tem de verdade?[/quote]
o que ele falou é um problema recorrente, quem já andou em mais de 10 projetos sabe disso aí muito bem. excesso de fragmentação em N camadas leva a desordem… isso ai é mais problema de arquiteto fanatico que de OO em si.

#12

É exatamente esse o ponto.

Não é correto dizer que algo é errado em OO, por causa dos projetos que você participou. A orientação a objetos diz uma coisa, mas nada diz que você não pode criar um projeto que vá contra tudo isso.

Nesse ponto eu não concordo com ele, até que me provem o contrário a OO diz que objetos devem ter atributos e comportamentos. Não que os mesmos devem ser divididos, como no famigerado modelo anêmico.

#13

É exatamente esse o ponto.

Não é correto dizer que algo é errado em OO, por causa dos projetos que você participou. A orientação a objetos diz uma coisa, mas nada diz que você não pode criar um projeto que vá contra tudo isso.

Nesse ponto eu não concordo com ele, até que me provem o contrário a OO diz que objetos devem ter atributos e comportamentos. Não que os mesmos devem ser divididos, como no famigerado modelo anêmico.[/quote]
Há uma grande diferença entre o que a OO contém em seus conceitos e a forma como isso é (ou não) utilizada.
Até por que, quando falamos em OO, não estamos falando da forma como este ou aquele projeto a empregaram, mas, de um conjunto específico que norteia um paradigma todo.
Ou seja, o problema não é do martelo, se o carpinteiro não sabe manuseá-lo, mas, do próprio carpinteiro.

#14

[quote=drsmachado]Há uma grande diferença entre o que a OO contém em seus conceitos e a forma como isso é (ou não) utilizada.
Até por que, quando falamos em OO, não estamos falando da forma como este ou aquele projeto a empregaram, mas, de um conjunto específico que norteia um paradigma todo.
Ou seja, o problema não é do martelo, se o carpinteiro não sabe manuseá-lo, mas, do próprio carpinteiro.[/quote]
Um dia ainda consigo expressar o que eu quero falar claramente desse jeito hehehe

Foi isso aí que eu quis dizer

#15

Concordo.

Concordo (embora que em C#, por exemplo, o processo fica bem fácil. Mérito da linguagem, não do paradigma).

Discordo. Ruby é uma linguagem orientada a objetos em que projetos são feitos muito rapidamente.

Discordo radicalmente. A maior parte das linguagens orientadas a objetos oferecem amplo suporte a serviços (sejam eles de que tipo forem), e isso se encaixa bem em OO. WS-*, por exemplo, tem uma relação bem forte com OO.

Discordo radicalmente também. Veja DDD.

Em suma, acredito que as opiniões levantadas aqui levaram em consideração apenas uma linguagem OO (Java, provavelmente), e apenas um modo de trabalho com esta. A OO tem vários problemas em relação a diversos pontos, mas apenas dois dos expostos acima.

[]'s

#16