Desvantagens da orientação a objetos?

Estou fazendo um trabalho para a faculdade sobre orientação a objetos - vantagens e desvantagens.

Alguém poderia me citar algumas desvantagens da orientação a objetos?

Desde já, grato.

http://www.geocities.com/tablizer/oopbad.htm

[quote=Thundercat]Estou fazendo um trabalho para a faculdade sobre orientação a objetos - vantagens e desvantagens.

Alguém poderia me citar algumas desvantagens da orientação a objetos?

Desde já, grato.[/quote]É mais dificil de aprender no começo, principalmente quando se vem de uma programação procedural.

Se você quiser aproveitar o que a Orientação a Objeto pode lhe proporcionar, ficará mais trabalhoso.

E como qualquer coisa, somente com o tempo você vai conseguir abstrair melhor as coisas (não vejo isso como uma desvantagem, foi apenas um comentário).

Obrigado por responder mas você não conhece um material em português?

kina,

com base em que “OO eh mais dificil de aprender”?

Quando voce muda de paradgma é uma cosia diferente de aprender do zero, e eu nucna vi dados sobre aprendizado OO em pessoas sem experiencia anterior.

[quote=pcalcado]kina,

com base em que “OO eh mais dificil de aprender”?

Quando voce muda de paradgma é uma cosia diferente de aprender do zero, e eu nucna vi dados sobre aprendizado OO em pessoas sem experiencia anterior.[/quote]

Isso é um dilema, o Deitel afirma que isso funciona, a primeira experiência da galera na UFPB aqui foi um desastre…

Mas tem muita gente que diz que aprender a programar direto com OO funciona melhor do que passar primeiro pela procedural.

[quote=Maurício Linhares][quote=pcalcado]kina,

com base em que “OO eh mais dificil de aprender”?

Quando voce muda de paradgma é uma cosia diferente de aprender do zero, e eu nucna vi dados sobre aprendizado OO em pessoas sem experiencia anterior.[/quote]

Isso é um dilema, o Deitel afirma que isso funciona, a primeira experiência da galera na UFPB aqui foi um desastre…

Mas tem muita gente que diz que aprender a programar direto com OO funciona melhor do que passar primeiro pela procedural.[/quote]

Eu não dúvido… mas acho que o cara no mínimo tem que aprender algoritmo, não é? :mrgreen:

Alguns artigos…
http://www.mundooo.com.br/php/modules.php?name=News&new_topic=8

Uma das maiores desvantagens que vejo em OO é o aumento do gasto de memória (heap). No caso de programação para dispositivos limitados (J2ME - por exemplo), isso é crítico. Existem práticas para programar nestes dispositivos que falam pra você encapsular o mínimo possível; ou seja, menos OO e mais procedural.

[]'s

Olá

Uma boa referência de Java e OO em português você pode fazer download em http://www.caelum.com.br/curso_joo.jsp

Se alguém me der 15 minutos, explico OO mesmo para alunos de cursos ligados à área mas que nunca programaram uma linha sequer. Já fiz mais de uma vez.

Aliás, na vida real somos como objetos. Temos propriedades e capacidade de fazer coisas.

A principal vantagem de OO é permitir construir abstrações que só com programação estruturada ficam muito difíceis de representar, passar da abstração para um sistema real e principalmente administrar o resultado.

Desvantagens? Não vejo nenhuma, todas as citadas podem ser consideradas também como vantagens. Quem como eu já passou por outras eras de desenvolvimento está a espera de novas abstrações e não consegue entender como algo tido como obsoleto pode ser melhor do que o atual.

Problemas? Sim, alguns. Mas os bons autores tem fornecido razoáveis soluções.

[]s
Luca

Opa, já to baixando pra dar uma olhada, tava precisando mesmo de um bom material pra dar umas aulinhas a uns iniciantes por aqui :mrgreen:

[quote=pcalcado]kina,

com base em que “OO eh mais dificil de aprender”?

Quando voce muda de paradgma é uma cosia diferente de aprender do zero, e eu nucna vi dados sobre aprendizado OO em pessoas sem experiencia anterior.[/quote]Tive o prazer de conhecer um programador VB que fazia o seguinte código em java.

public void salvaPessoa(String nome, int idade, String sexo, Date dataNascimento, PessoaBean pessoa)

Por isso eu disse que a transação de uma pessoa que programa em uma linguagem procedural é dificil.
Explicar o conceito de extender uma classe para alguém que trabalha com “variaveis globais”.

class Pai{
  public String cor="azul";
  public mostraCor(){
    System.out.println(cor);
  }
}

class Filho extends Pai{
  public String cor="verde";
  public mostraCor(){
    System.out.println(cor);
  }
}
class Main{
  public static void main(String args[]){
    Filho f1 = new Filho();
    Filho f2 = new Filho();
    f1.cor = "marrom";
    System.out.println(f2.mostraCor); // Qual a mensagem?
    // Muitos respondem marrom, pois está herdando do Pai, ou seja
   // Tem um conhecimento de "variavel global"
  }
}

Quanto a alguém que está começando, eu percebi que muitas pessoas tem dificuldade em enteder o que é um public static void main(String args[])
quando não se sabe nem fazer uma validação do tipo “é maior de idade?”.
Lógico que você não irá entrar em detalhes, mas é mais fácil de visualisar isso com outras linguagem (por exemplo clipper) quando a transação normalmente é de fluxograma -> programação.

[quote]Tive o prazer de conhecer um programador VB que fazia o seguinte código em java.
[/quote]

kina,

tem aqui em VB do meu lado q me “pertuba”… fala q é baba é baba e nunca começa…

sem conceito não tem condição, nem de começar…

:evil:

Alguns problema são desgraçadamente dificeis de resolver com OOP. E com linguagens funcionais é brincadeira de criança.

Qualquer problema que envolva backtracing ou branch-and-bound é besta de implementar com uma linguagem funcional, com OOP pode ir do chato ao muito dificil.

Quem já usou Standard ML, Haskell, LISP ou Scheme sabe como algumas construções de pattern mattching são triviais de serem feitas enquanto a versão imperativa ficaria horrivel.

[color=blue]Acho que aí em cima faltou um conceito básico de OO, encapsulamento. Usar get’s e set’s ao invés de variáveis públicas é uma boa prática, base pra OO e ainda conta pontos pra SCJP ;)[/color]

[color=blue]Pouco “psicológica” essa análise pro meu gosto…
Acho que o pessoal vai mais pelo jeito que sabe mesmo.[/color]

[color=#444444]Na minha opnião OO é um dos paradigmas mais fáceis de se entender e mais difícil de ver alguém utilizando. Conheço gente que diz que se teu código for maior atravessar um “PAGE-DOWN” no teu editor, ele já ta grande e você não ta mais “encapsulando”!!! Daí vc fragmenta seu código demais, e ele difícil de acompanhar (sequência)… mistura com UML, encaixa padrão CMM e por aí vai…

A maior confusão que já vi foi quando um professor meu foi explicar pra minha turma UML e OO ao mesmo tempo. Resultado: ninguém aprendeu, todo mundo se confundiu, os poucos que gostavam de comp. passaram a não gostar mais, etc. Não que o cara fosse ruim, ou não soubesse a matéria, pelo contrário, tem até um livro (mto bom): http://www.umlnapratica.com.br/. Mas, pra mim, foi um jeito de se aprender como NÃO se ensina OO!!

[]'s[/color]

Olá

Louds, os casos que você citou são muito específicos. Mesmo com linguagens como C, Cobol, Assembler e Fortran estes problemas seriam difíceis de resolver. Foi exatamente por esta dificuldade é que surgiu Functional programming (In contrast to procedural / imperative programming, functional programming emphasizes the evaluation of functional expressions, rather than execution of commands. The expressions in these languages are formed by using functions to combine basic values.)

[]s
Luca

Sim eu sei, fiz na pressa, pois estava em meu espediente, apenas foi um exemplo das dificuldades que alguém que sai de uma Programação Procedural, por exemplo VB.
Na realidade o exemplo que eu queria fazer está ai embaixo.

Não consegui entender direito o que você quis dizer com isso, mas eu estou falando isso porque eu vi na minha faculdade e digamos que se não foi 100% das respostas foram 90%, porque 10% do pessoal não respondeu, e os que trabalham com Linguagem Procedural responderam “marrom” (conceito de variavel global)^^

[quote=albinati]
[color=#444444]Na minha opnião OO é um dos paradigmas mais fáceis de se entender e mais difícil de ver alguém utilizando.
[/color][/quote]
OO Conceito é facil de explicar, mas muitos tem dificuldades em colocar na prática, ou então juntar vários conceitos (ví na prática esses problemas).
Até agora o meu professor evitou falar o que seria “static” pois iria “complicar” para a sala :?

Exemplo:

public class Pai {
	private String cor="Azul";
// getters and setters
}
public class Filho extends Pai {
	public String getCor() {
		return super.getCor();
	}
	public void setCor(String cor) {
		super.setCor(cor);
	}
}

class Main {
	public static void main(String[] args) {
		Filho f1 = new Filho(), f2 = new Filho();
		f1.setCor("Marrom");
		System.out.println(f2.getCor());
	}
}

Com certeza eu vejo muito mais vantagens que desvantagens em OOP, mas como o mesma havia pedido apenas desvantagens, tentei mostrar o que eu achava “problemático”.

Claro kina, me desculpe o excesso de perfeccionismo. Quis apenas focar também sobre a importância do conceito do encapsulamento, além da abrangência de classes e objetos. Perfeita sua colocação e código demonstrado.

Quis dizer que, não consigo visualizar que o problema das pessoas seja o modelo procedural ou OO de programação; mas o que “aprenderam”… Em resumo, é uma mudança de paradigma. Como se falassem, de repente, que a maneira de segurar o garfo ao comer, é com a mão toda fechada e que você tivesse que se adaptar de uma hora pra outra. Quantas vezes erraríamos?

[quote=kina]

Concordo plenamente. Já peguei “N” códigos pra trabalhar, que tava passando 200 parâmetros no construtor, sem reuso de código, etc. Polimorfismo e herança nem pensar…
Daí quando você vai conversar com a pessoa, ela te explica bonitinho tudo isso!

Claro, OO é um conceito fortíssimo, padrão de mercado e, ao meu ver, excelente para o ciclo de desenvolvimento atual.
Concordo com as desvantagens, principalmente no quesito aprendizagem. Apenas em resumo, afirmo que as pessoas aprendem bem os “macetes” e se esquecem dos “conceitos”…