[quote=ronaldtm]
Você por acaso leu o que eu escrevi? -sigh–[/quote]
Sim, só to sendo radical um pouquinho 
Ou usamos OO ou procedural, ou inventamos um novo paradigma OOR - Orientação a Objetos Relacionais :lol:
Quer dizer que as habilidades das pessoas variam?
Bom, programar proceduralmente também requer habilidade e conhecimento, existem diversos livros sobre boas práticas, Yourdon, Page-Jones e tantos outros sobre Análise Essencial e Projeto Estruturado dão uma idéia que mesmo os sistemas procedurais feitos hoje (e ontem) não estão nas boas práticas, e se você considerar que as pessoas programam com ele há mais tempo, é preocupante.
Se a pessoa sabe programar estruturada e quer passar para OO, uma abordagem assim (mista) pode ser funcional, mas eu não usaria em projetos muito sérios (contrate novas pessoas ou treine os antigos antes de começar, pelo menos tenha um coach disponível!).
Se a pessoa sabe programar OO dificilmente vai ter problemas num modelo de objetos puro, mas em tecnologias como Java vai acabar limitado (e xingando muito), logo uma abordagem com pequenos toques procedurais se faz necessário pelas limitações impodtas. Note, entretanto, que programar de maneira OO não implica programar numa linguagem oo, e vice-versa. “Eu posso programar FORTRAN em qualquer linguagem”.
Se a pessoa sabe estruturada e não quer usar OO… a menos que não haja escolha deixe o cara em paz e atualize o ambiente que ele usa.
Isso tem a ver com o item 1? Bom, se você faz um sistema ruim em OO, procedural ou BASIC ele vai ser ruim de manter até por você…não sei exatamente o que você quis dizer aqui.
O que é purismo?
Usar as ferramentas do paradigma como elas foram concebidas? Boas práticas? Técnicas avançadas?
Se seu sistema é simples, ele não precisa mais que o bê-a-bá da OO.
Se ele for complexo, a regra muda.
Se ele for muito simples, faça em shell script com GTK, fica bem legal 
Ok, pelo que entendi do seu conceito de OO pura, não dá pra programar OO nem sequer em Java. Vamos esquecer a OO pura então e vamos nos concetrar em ter um modelo de objetos com herança, polimorfismo, dynamic binding e essas coisas mais “comuns”.
Sim, eu posso programar com tudo isso mesmo usando um SGBD. Basta eu fazer um mapeamento condizente e bem feito. Ok, certas coisas vão ser belas gambiarras, mas passar entre paradigmas sempre implica em gambiarras (alguém mencionou JNI?), e esse é um dos meus pontos quanto misturar paradigmas em um único sistema (note que não falo de subsistemas se comunicando).
Aliás, tem uma apresentação bem legal sobre isso está no site do JavaPolis (precisa de registro), aliás tem MUITA coisa legal lá:
O Domain Model é a essência de um sistema. Se você vai mais que ler o conteúdo de um campo de texto para colocar num INSERT, vale muito a pena um bem construído.
Mas, eu concordo com você. Semana retrasada os outros coordenadores do RioJUG me pediram para fazer a parte de inscrição do RioJavaSummit 2005 (olha o jabá!) e eu comecei com um modelo muito bom, mas… era sexta e eu ia viajar no fim de semana. Como ninguém podia continuar para mim, peguei na segunda, já atrasado.
Bem, o que era um belo modelo de objetos virou um servlet-faz-tudo. Por que? Falta de tempo para uma coisa simples. Construir um modelo de objetos seria legal mas… cacete, era só um formulário de inscrição para um evento que não ser mais usado depois de uma semana!
O grande ponto é: escolhi a tecnologia errada. java e servlets para fazer algo tão simples é um overkill. Pense nisso 
[quote=skill_ufmt]
Ou usamos OO ou procedural, ou inventamos um novo paradigma OOR - Orientação a Objetos Relacionais :lol: [/quote]
Tipo isso?
Qeuria ter um filho assim como o Shoes hehehe
[quote=pcalcado]… Yourdon
[/quote]
Não cara, yourdon não, meu deus, tenho traumas desse cara heee tenho um prof. que é viciado nesse cara, e trabalha usando uma versão do livro dele de 20 anos atrás quando PE era o que existia, ja imagina a caca na aula dele né? ehhe
Não, droga, tive um leve descontentamento com essa sua frase 
[quote]
O grande ponto é: escolhi a tecnologia errada. java e servlets para fazer algo tão simples é um overkill. Pense nisso ;)[/quote]
Acho esse o grande ponto, saber escolher o que é mais certo, independente de modismos ou comentários de alguém que você viu por ae, e trabalhar nessa escolha de maneira que naquele momento seja a coisa mais certa possível a se fazer.
E o JRapi… shoes? paro? desanimo?
[quote=skill_ufmt]
E o JRapi… shoes? paro? desanimo? ;)[/quote]
[off-topic :Conversa de Comadre debruçada na janela]
Falta de tempo… mas o Thiago (a.k.a. “!!!”) está mais por dentro, acho.
Quase me despacham pro Chile de novo essa semana
Aliás, eu estou trabalhando agora :evil: :evil: :evil:
[/off-topic]
[quote=pcalcado][quote=skill_ufmt]
E o JRapi… shoes? paro? desanimo? ;)[/quote]
[off-topic :Conversa de Comadre debruçada na janela]
Falta de tempo… mas o Thiago (a.k.a. “!!!”) está mais por dentro, acho.
Quase me despacham pro Chile de novo essa semana
Aliás, eu estou trabalhando agora :evil: :evil: :evil:
[/off-topic][/quote]
kkk, ta certo, trabalhar sabadão é foda
Chile? legal, pelo menos viaja hehe
E eu, que tinha prometido pra mim mesmo que não ia mais entrar nessas discussões sem fim… -sigh–
Não?
[quote=pcalcado]Bom, programar proceduralmente também requer habilidade e conhecimento, existem diversos livros sobre boas práticas, Yourdon, Page-Jones e tantos outros sobre Análise Essencial e Projeto Estruturado dão uma idéia que mesmo os sistemas procedurais feitos hoje (e ontem) não estão nas boas práticas, e se você considerar que as pessoas programam com ele há mais tempo, é preocupante.
Se a pessoa sabe programar estruturada e quer passar para OO, uma abordagem assim (mista) pode ser funcional, mas eu não usaria em projetos muito sérios (contrate novas pessoas ou treine os antigos antes de começar, pelo menos tenha um coach disponível!).
Se a pessoa sabe programar OO dificilmente vai ter problemas num modelo de objetos puro, mas em tecnologias como Java vai acabar limitado (e xingando muito), logo uma abordagem com pequenos toques procedurais se faz necessário pelas limitações impodtas. Note, entretanto, que programar de maneira OO não implica programar numa linguagem oo, e vice-versa. “Eu posso programar FORTRAN em qualquer linguagem”.
Se a pessoa sabe estruturada e não quer usar OO… a menos que não haja escolha deixe o cara em paz e atualize o ambiente que ele usa.[/quote]
Exato. O problema é que muito pouca gente sabe programar OO. Muitos sabem Java, muitos sabem usar Struts (argh), mas poucos conseguiriam construir um Struts ou um WebWork (hum… não é um exemplo legal, já existem frameworks MVC demais por aí, dá pra copiar na boa… whatever).
É aquela coisa, o cara fala: ‘- Essa classe chama essa, essa classe chama essa. Aqui, eu usei o páterni Obisérver com Injeção de Dependente.’
Tá, você é bom, e modéstia a parte, eu sou bom :). Mas e a média do mercado?
Exemplo real: no meu trabalho, minha equipe está fazendo um sistema (obs.: não é web) para um banco. Eu criei um framework que integra várias tecnologias, se comunica com vários outros sistemas, faz o controle de fluxo, lifecycle, recursos, encapsula os detalhes da tecnologia (de infra-estrutura) utilizada, etc. Lá até tem uns caras bons (por sorte, peguei um com bom potencial pra treinar), mas a maioria não é exatamente de ‘programadores hardcore’. Eles entendem de negócio, conseguem fazer loops e ifs em java, mas vai perguntar pra eles a diferença entre composição e herança! Pode até ser que algum responda, mas vai ser uma resposta decorada do livro. Isso não é exatamente condenável, nem todo mumdo pode ou quer passar as madrugadas estudando pra aprimorar essa habilidade especificamente.
Por isso, fizemos com que as ‘transações de negócio’ ficassem o mais simples possível. Basta estender uma classe (eu fiz uma interface também, tá, não ouse compará-lo ao Struts! :P), implementar um método e registrar a classe em um XML. Já estão lá os métodos auxiliares, as referências para os recursos necessários, etc. A programação, neste nível, é procedural. Por trás, tem todo o projeto OO, com as interfaces bem definidas, hooks pra pontos de extensão, classes-base pra facilitar a implementação. Foi um misto de objeto-procedural que aproveitou o melhor dos dois mundos, ao invés de se limitar a um deles.
[quote=pcalcado][quote=ronaldtm]
2. Eu não vou, nem quero, ficar na manutenção do sistema, anos depois.
[/quote]
Isso tem a ver com o item 1? Bom, se você faz um sistema ruim em OO, procedural ou BASIC ele vai ser ruim de manter até por você…não sei exatamente o que você quis dizer aqui.[/quote]
Eu só estava continuando a idéia do ítem 1. Não quis dizer que é mais fácil manter um programa procedural (aliás, deve ser bem mais difícil se o nível de complexidade for alto).
OO foi criada para facilitar o gerenciamento da complexidade (na verdade, para dar ferramentas pra isso). Nas partes mais complexas do sistema, bastante OO cai muito bem. Nas partes do sistema que vão ser mantidas por programadores ‘não tão programadores’, a abordagem procedural é mais apropriada, porque é mais simples se mantida isolada e é mais fácil pra eles entenderem.
[quote=pcalcado]O que é purismo?
Usar as ferramentas do paradigma como elas foram concebidas? Boas práticas? Técnicas avançadas?
Se seu sistema é simples, ele não precisa mais que o bê-a-bá da OO.
Se ele for complexo, a regra muda.
Se ele for muito simples, faça em shell script com GTK, fica bem legal :)[/quote]
Purismo é achar que ter um ‘get’ no código é um sacrilégio e o cara tem que ser queimado na fogueira! 
Brincadeira (duh). O purismo que eu falo é achar inaceitável o fato de termos que fazer pequenas gambiarras não-OO, como você mesmo falou, e alguns outros casos, como esse do exemplo (partes do sistema feitas para serem procedurais).
Certo, mas não é OO ‘puro’, você concorda, certo? E é isso que eu acho isso perfeitamente aceitável, por isso não concordei com o ‘se vai programar OO, programe só OO, se vai programar procedural, programe só procedural’.
Eu estava me referindo ao padrão Domain Model (no Fowler, Business Object, no Core). É nesse sentido que você está falando?
Tá me chamando de programador ASP? Precisava me insultar assim?
O que eu estou tentando defender é exatamente ‘the right tool for the job’. Dizer que ‘só uso OO’ ou ‘só uso procedures’ é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo
Sim, eu estava perguntando se você estava querendo dizer isso
Com isso acho que precisamos de um filtro aqui…
Uhhmmm… acho que você está falando de uma coisa bem diferente.
Uma JVM feita em C permite que eu programe orientado a objetos. Eu ainda posso fazer uma linguagem de script para a JVM (como o groovy) que seja totalmente procedural. Posso utilizar a estrutura OO do Delphi para fazer um projeto procedural.
Resumo: O ambiente não faz o programa. Não é porque seu sistema é baseado numa tecnologia OO que você vai programar OO, eu falei isso no último post (ainda fiz a clássica citação do FORTRAN).
Você simplesmente preparou o ambiente para programação procedural. Eu posso programar com objetos neste ambiente que você criou, assim como posso programar em objetos com C, mas o ambiente não é proício.
Se a pessoa pensa: “Ei, vou usar a tecnologia XYZ mas vou fazer um projeto estruturado”, não importa se é Smalltalk, Eifell, Java ou ruby, todas elas (até odne sei) comportam um modelo estruturado facilmente, com estruturas de dados formadas através de classes burras (get/set ou membros públicos), variáveis globais (singletons e estáticos) e funções (funções-membro estáticas).
Se ela pensa assim e assim desenha seu software, vai ser ruim, porque ela poderia ter usado uma tecnologia mais própria, mas eu te garanto que vai ser bem melhor do que sse ela projetar um software teoricamente OO com idéias estruturadas, como 99% dos projetos que envolven DTO, JavaBeans, EJBs e Struts que eu conheço (incluindo quase todos os apresentados neste fórum).
Acho que “programadores não tão programatores” novatos poderiam se adaptar a um ou a outro (oo ou procedural), mas como a maioria esmagadora têm background estruturado, concordo com você. Se eles só querem o sistema pronto, dane-se o projeto, pdoeriam fazer tufdo de forma estruturada e serem mais felizes em vez de fingirem que usam objetos (e isso não encessariamente implica em não usar uma plataforma OO, como java, apesar de eu não gostar da idéia).
Na verdade, minha idéia é que as pessoas com esse eprfil vão cada vez mais se transformar em consultores de ferramenta, se especializando verticalmente. Mas isso é outro tópico
:evil:
Sacrilégio é uma palavra forte, designs ruins são aceitáveis, mas você não concorda que devem ser evitados? Não ach que se você vê uma má pratica utilizada descaradamente por tudo quanto é lugar você poderia falar algo contra isso?
A menos em ambientes muito específicos, que estão fora dos sistemas desenvolvidos em massa hoje, é impossível achar um absurdo fazer gambiarras como mapeamento O-R ou DTOs, mas isso não faz delas menos gambiarras, apenas as fazem gambiarras necessárias. Quando elas não forem mais necessárias, adeus
Programar procedural não é não usar objetos. VB 6 é um ambiente procedural baseado em objetos.
Mais ou menos, estou falando de Domain Model num conceito mais amplo, “o domínio da aplicação na forma de abstrações”.
Pelo contrário, estou dizendo que se eu tivesse escolhido ASP/PHP/CGI neste caso, eu teria sido mais feliz
A conclusão que tiro é que podemos estar falando da mesma coisa em escopo diferente.
O que eu não consigo conceber é um design OO e procedural ao mesmo tempo, porque eu nunca vi isso acabar bem.
O exemplo que você citou foi um framewokr oo para aplicações procedurais, quando o cara usa seu framework, ele sabe disso. Quando eu uso uma interface gráfico cujo toolkit é em C, eu sei que o C++ vai ter que ter alguns adaptadores, a diferença é que não é porque meu ambiente é OO que eu devo misturar.
Ou como fazer uma interface em algo (orientado a… orientado à porcaria nenhuma ) como HTML (eu diria orientado a bug ), eu tenho que abstrair o HTML e o HTTP em si.
Voltando ao CRUD, meu ponto sobre aplicações simples foi descrito no outro post.
É, eu estava pensando nisso também, o problema é o ‘mismatch’ da língua, a opinião não é tão diferente assim (é um pouco, mas cada um deve ter a sua mesmo :))
Bom, vou deixar você trabalhar agora :lol: (afe, ninguém merece…)
Tetsuo
[quote=ronaldtm] Dizer que ‘só uso OO’ ou ‘só uso procedures’ é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo[/quote]
é Skill não esculaxa também ehehe
Minha possição extremista EXCLUSIVAMENTE neste tópico parte do princípio de que para que criariam OO se é para usarmos OO-Relacional? ntão deixava como estava, concorda?
Agora se criaram é por que alguma coisa no outro modo não estava dando certo.
Enfim se criaram OO vamos usar OO ou ficar no PE, e não OOR, entende?
Tá é extremista sim, mas fazer o que antes não tivessem criado ehehe
Eu acho que o rpoblema é que deesde a criação sempre usaram OOR, pois ninguem sabia OO e ai começaram a mesclar com idéia PE achando ser OO, e virou a bagunça até os dias de hj
Eu não concordo num ponto apenas que foi dito aqui que os novatos entendem melhor OOR.
Claro alguma vez alguém paraou para ensinar OO de verdade?
Os caras ja entram usando get set, extendo isso aqui, ali, usando algo pronto(tá o mercado exige dinâmica) e bla blas.
Se alguém para, pensa e resolve começar as coisas do princípio certo,
usando OO, acho que os caras, ou caras crus de programação, poderiam aprender perfeitamente OO, ou não?
Bom, to querendo seriamente fazer essa experiência por aqui com uma equipe que to pensando em montar, tendo sucesso ou não, posto as coisas aqui depois do ocorrido.
Abraços.
Calma, meninos
Exato, e o que recomendo nesse caso é a lsita de livros que passei aqui (quinta página, não sei linkar pra ela ).
Teoricamente sim. Na verdade, segundo alguns textos, é mais fácil, porque objetos modelam melhor o mundo real (apesar do que disse o buda lá do início do tópico )
Skill, uma idéia que estou tendo para o RioJUG é exatamente fazer oficinas deste tipo, preferencialmente desenvolvendo um software livre enquanto isso. Que tal essa pro Caju também?
[quote=pcalcado]
Skill, uma idéia que estou tendo para o RioJUG é exatamente fazer oficinas deste tipo, preferencialmente desenvolvendo um software livre enquanto isso. Que tal essa pro Caju também?[/quote]
Da lista que você passou já li tres deles :lol: o resto aidna são minhas vontadades de ir elndo(grana só da pra um por mês), mas vou ler sim.
Então cara, sem dúvida é uma boa idéia montar algo para fazer nesse estilo, vamos ver se a idéia amadurece aqui.
Ou possamo testar a idéia no Jrap… que tal?
Abraços
[quote=skill_ufmt][quote=ronaldtm] Dizer que ‘só uso OO’ ou ‘só uso procedures’ é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo[/quote]
é Skill não esculaxa também ehehe
Minha possição extremista EXCLUSIVAMENTE neste tópico parte do princípio de que para que criariam OO se é para usarmos OO-Relacional? ntão deixava como estava, concorda?
Agora se criaram é por que alguma coisa no outro modo não estava dando certo.
Enfim se criaram OO vamos usar OO ou ficar no PE, e não OOR, entende?
Tá é extremista sim, mas fazer o que antes não tivessem criado ehehe[/quote]
Calma, calma, eu tava brincando!