Desvantagem de OO

Mobile
#1

Em um outro forum que participo ouvi dizer que quando se trata de aplicações para celulares não é bom usar todos recursos de orientação a objetos, quanto menos melhor…

Fiquei em dúvida sobre a veracidade desta afirmação. O que vocês acham?

Caso seja verdade, como devo pensar ao modelar e desenvolver um projeto de j2me? Quais recursos devo procurar não usar? etc…

#2

Use com dicernimento:

:arrow: Herança
:arrow: Interfaces
:arrow: Instanciação de objetos

Fazendo isto, sua aplicação será menor, mais rápida e irá consumir menos memória do que se ussasse isto e mais o resto que não citei.

O que importa é:

:arrow: velocidade da aplicação
Quem vai aceitar uma aplicação lenta ? Ainda mais num aparelho antigo, onde a implementação Java tende a sofrer mais para executar uma aplicação que foi feita e testada num aparelho novo.
É a mesma situação de vc desenvolver usando só o WTK e depois tendo um aparelho, rodar nele. Vc vai ver que as coisas mudam bastante e vc terá que fazer uma série de refinamentos para adequar o código que rodava maravilhosamente no WTK mas que no celular vira uma “carroça”…

:arrow: pouco consumo de memória
Ainda tem muito celular com heap pequeno por aí, portanto se não quiser ficar sem memória para instanciar objetos entre outras coisas, trate em pensar em reutilização de objetos…

:arrow: tamanho da aplicação
Ainda tem muito celular que chia se a midlet tiver mais que 40Kb/60Kb…portanto, quanto menos código, menos problema os usuários terão para fazer o download da aplicação. É lógico, tem aparelho que não tem este limite…

Não sou o primeiro nem serei o único a dar estas dicas, pois faz parte do “arroz com feijão” de quem programa em J2ME…

#3

Eu evito usar interfaces a todo custo, elas costumam ser bem mais lentas.

#4

pedpano,

   Uma coisa que é muito utilizada quando usamos OO é a separação de funcionalidades em classes, uso de composição, interfaces, etc. Você tem que ver que cada classe trás consigo um overhead, mesmo a classe mais básica, tipo:

class xpto{}
   Sobrecarrega a aplicação, num ambiente de recursos extremamente restrito, como é o caso de Micro aplicações, esses poucos bytes quando somados, caso você tenha muitas classes e interfaces, podem comprometer o desempenho do seu sistema. 
   Além desses exemplos existem outras formas de desperdicio, tanto de memoria quanto de uso de processamento, por exemplo: evite declarar e instanciar variáveis dentro de um laço:

for( ;; )
    Hobbit  frodo = new Hobbit();
    frodo =  getHobbit();
    System.out.println(frodo.toString());
   Ao invés, prefira:

     Hobbit frodo = new Hobbit();
     for( ;; )
         frodo =  getHobbit();
        System.out.println(frodo.toString());
    Entre outros.

[]'s Tone

#5

Interfaces são lentas??
tem um benchmark sobre isto para eu dar uma olhada?
eu utilizo interfaces direto e nunca percebi isto.

inclusive dentre um dos principais “principios” (ta, tudo bem, principais principios ficou forte) do Spring Framework é:
Desenvolver para interfaces e não para classes concretas.
interfaces facilitam a utilização de proxys, AOP, o desacoplamento

dão algum sentido a utilização de Dependency Injection.

<editado>
bahh, que feio, agora que percebi que eu to escrevendo no forum de Micro Edition :slight_smile:
sorry galera :slight_smile:
</editado>

#6

Olá pessoal
No profile MIDP 1.0, a coleta de lixo tem q ser realizada manualmente?

#7

Onde você leu isto ?

Fiquei interessado em saber quem blasfemou… :?

Olha, a coleta de lixo sempre é feita de forma automática pelo GC, não importa a plataforma (J2SE, J2ME, J2EE).

#8

Foi o q o texto d uma apostila q eu li me fez pensar…
Esta aqui, página 07

#9

Na página 7 não tem nada de Coleta de Lixo…

Na página 5, ele cita:

“Garbage collector existe, porém não executa método automático.”

Sinceramente, não entendi o que ele quis dizer com isto.

O fato é que o GC existe e roda independente da vontade do usuário/aplicação.

O que diferente o GC do J2ME do GC do J2SE, é que o primeiro, pelas próprias restrições do aparelho, não tem a mesma sofisticação que tem o GC para desktop.

#10

É, eu errei a página pq eu forneci a do Reader, não a da apostila mesmo. Mas foi esse trecho mesmo q me confudiu.
Valeu

#11

Urubatan, nas JVMs J2SE não existe diferença entre interfaces e classes abstratas do ponto de vista de performance. Também uso elas muito quando estou trabalhando nessa plataforma, assim como classes base abstratas.

Porem as VMs p/ J2ME são simplorias demais e a performance de interfaces costuma ser menor. Outro fator é que programo para ME com 0% de flexibilidade por não precisar.

#12

sorry :slight_smile:
eu editei o post depois quando vi que não tinha percebido que eu estava postando no forum de Micro Edition :slight_smile:
ja trabalhei um pouco com isto, conheço bem esta diferença :slight_smile:

#13