Não me lembro de nada postado a respeito desse link, então aqui vai, é bem interessante.
Por que OOP?
Já foi discutido sim, mas enfim, o cara tem pontos bons mais também fala besteira, como todos 
Ele tem muitos “eu acho” “eu nunca vi” e fica por isso mesmo.
Programação estruturada é legal, mas a pessoa que quer programar OO, acha que programa OO e faz aquela linda mistura com DTOs saltitantes entre EJBs faz tudo menos isso 
Porgrame em objetos ou programe em procdimentos, desde que você:
- Programe com qualidade
- Conheça a técnica que usa
Não importa.
[quote]Já foi discutido sim, mas enfim, o cara tem pontos bons mais também fala besteira, como todos
Ele tem muitos “eu acho” “eu nunca vi” e fica por isso mesmo.
Programação estruturada é legal, mas a pessoa que quer programar OO, acha que programa OO e faz aquela linda mistura com DTOs saltitantes entre EJBs faz tudo menos isso [/quote]
Alguém entendeu alguma coisa???
Ae pessoal,
A gente já teve uma extensa discussão sobre esse assunto e outras cositas em um tópico aqui no JUG. Confiram em http://www.guj.com.br/posts/list/20753.java Vale a pena! 
[]s
Att. Pablo
[quote=YellowBike]
Alguém entendeu alguma coisa???[/quote]
Pera…
Todos os que acabam expondo sua opnião têm pontos sérios mas falam besteira
Os textos dele são baesados demais em “achismo” opiniões e nada muito concreto.
[quote]
Programação estruturada é legal, mas a pessoa que quer programar OO, acha que programa OO e faz aquela linda mistura com DTOs saltitantes entre EJBs faz tudo menos isso [/quote]
Se você quer programar de forma procedural, programe, se quer de forma OO, programe, não misture as coisas.
[quote=pcalcado]
Se você quer rpogramar de forma procedural, programe, se quer de forma OO, programe, não msiture as coisas.[/quote]
É isso ae
Ou PE ou POO, e saiba o que esta fazendo em cada uma delas.
Hum… ‘não misture as coisas’ quer dizer ‘não use as duas juntas’, ou ‘não use uma pensando que é a outra’?
Por exemplo, os padrões Transaction Script, do Fowler, e Application Service, do Core, são basicamente procedurais, isto é, o serviço acaba representando uma procedure, não corresponde a uma ‘entidade de negócio’ como seria o ideal numa abordagem OO purista. Porém, estes padrões são bem úteis para isolar casos de uso do sistema (assim como DTOs são úteis em outras situações).
E por favor, não foquem apenas em destruir esse exemplo especificamente :). Só quero dizer que muitas vezes - principalmente em sistemas de informação que são basicamente CRUD - uma abordagem parcialmente procedural é melhor que uma totalmente OO (mesmo porque, pouca gente recebe o preparo necessário pra lidar com OO direito :twisted: ), aproveitando muitas das vantagens da OO, como polimorfismo, herança e o uso extensivo de frameworks.
Tetsuo
[quote=ronaldtm] aproveitando muitas das vantagens da OO, como polimorfismo, herança e o uso extensivo de frameworks.
Tetsuo[/quote]
Herança :shock: me cheira gambiarra :lol:
Wow, você consegue programar Java sem usar herança? Como é que você faz isso?
duh
Misturar as cosias numa mesma plataforma/linguagem.
Uma coisa é um Domain Model, outra coisa são objetos. Um transaction Script é um Command fortemente acoplado, você pode ter comandos como objetos se for seu objetivo, apesar deste padrão ser utilizado comod esculpa para designs ruins o tempo todo.
Só não crie uma função/método/procedimento que manipule um bean cheio de gets e sets e ache que está utilizando objetos, uma coisa não tem nada a ver com a outra
Quando você mistura funções intrusivas (que manipulam estruturas de dados independentes deliberadamente) com encapsulament, geralmente acaba-se com quase nenhum (ou nenhum) objeto de verdade. Não estou sequer falando de objetos de negócio, estou falando de comportamento e propriedades. Você geralmente tem um monte de classes com membros públicos (como um bean típico, uma classe com membros públicos fingindo que são privados) pulando entre procedimentos.
Droga 
Já que é para fazer parcialmente procedural, por que não procedural de vez? As vantagens de uma abordagemd e objetos só são realmente vantagens se você usar objetos de verdade. Faça em C.
Agora, por que fazer CRUD sem objetos seria mais fácil? A minha opinião sobre isso é que as ferramentas que permitem fazer um sistema rapidamente (RAD e essas coisas) produzem código procedural, mas uma pessoa que efetivamente programe OO com ferramentas semelhantes (ou uma que não programe em nada mas tenha uma ferramenta boa que faça tudo com modelo de objetos - coisa que eu não conheço) pdoeria fazer o tal CRUD da mesma maneira.
Qual seria o seu motivo?
Wow, você consegue programar Java sem usar herança? Como é que você faz isso?
duh[/quote]
hehehe, delegação? composição? encapsulamentos?
Talvez viver sem ela não no mundo java não de, mas quem sabe um dia.
Se não pode viver sem ela, deixe-a pequenininhazinha…
[quote=skill_ufmt]
hehehe, delegação? composição? encapsulamentos?
Talvez viver sem ela não no mundo java não de, mas quem sabe um dia.
Se não pode viver sem ela, deixe-a pequenininhazinha… ;)[/quote]
Por que você ia querer isso?
Sem herança? C, pascal…
[quote=pcalcado][quote=skill_ufmt]
hehehe, delegação? composição? encapsulamentos?
Talvez viver sem ela não no mundo java não de, mas quem sabe um dia.
Se não pode viver sem ela, deixe-a pequenininhazinha… ;)[/quote]
Por que você ia querer isso?
Sem herança? C, pascal…[/quote]
Quanto maior o nível de herança que eu tenha, maior será o meu problema mais tarde, ou não?
Teria um mega acoplamento…
A um nível é até “aceitável”, mais que isso é problema…
[quote=skill_ufmt]
Quanto maior o nível de herança que eu tenha, maior será o meu problema mais tarde, ou não?
Teria um mega acoplamento…
A um nível é até “aceitável”, mais que isso é problema…[/quote]
É aceitável até o nível que você precisar para modelar seu domínio.
Além do fato de que acoplamento zero é uma impossibilidade (você teria classes -ou procedimentos fora de um contexto de objetos - que são tão auto-suficientes que não servem para nada), toda ferramenta precisa ser usada com sabedoria.
Ou você acha que não é possível ter me-acoplamentos com associações?
É ruim, mas será que:
É menos acoplado? Depende.
No final das contas, você vai ter o mesmo número de dependências, sendo que numa associação você pode ter dependências bilaterais, numa herança são sempre unilaterias.
Ok, não associamos então?
Claro que não! Usamos as ferramentas certas para a ocasião certa
[quote=pcalcado]
Claro que não! Usamos as ferramentas certas para a ocasião certa ;)[/quote]
É OO, doce mistério
Exatamente, ‘não use uma pensando que é a outra’
RAD? Não precisava me insultar! 
-
Eu não vou fazer o projeto sozinho.
-
Eu não vou, nem quero, ficar na manutenção do sistema, anos depois.
-
Eu não estou falando de CRUD sem objetos, mas de uma abordagem não tão purista.
Mesmo porque, bancos relacionais são o padrão de persistência, e não dá pra programar ‘puramente OO’ (pelo menos não no sentido de OO que os proponentes de tecnologias como o Prevayler dão) quando se faz o sistema sobre um, você acaba tendo o triplo de trabalho tentando encapsular tudo perfeitamente (se é que isso é possível).
O Domain Model é a abordagem mais OO, de fato, mas mais vale a pena quando há relacionamentos e regras de negócio complexos. Quando é ‘crude CRUD’, não acho que valha a pena o trabalho.
Tetsuo
Isso!
[quote=ronaldtm]… e não dá pra programar ‘puramente OO’ …
Tetsuo[/quote]
NÃO? vige maria santa, agora ferrou legal, se num da para programar OO, então vamos parar com ela
vamos voltar aos procedimentos, ou quem sabe a boa época das válvulas :lol:
Isso! :D[/quote]
Concordo, mas então vamos usar JBuilder, JDev, quem sabe o Delphi, arrastar botõeszinhos e andar rápido com as coisas :lol:
[quote=skill_ufmt][quote=ronaldtm]… e não dá pra programar ‘puramente OO’ …
Tetsuo[/quote]
NÃO? vige maria santa, agora ferrou legal, se num da para programar OO, então vamos parar com ela
vamos voltar aos procedimentos, ou quem sabe a boa época das válvulas :lol:
[/quote]
Você por acaso leu o que eu escrevi? -sigh–