Orientatção a objetos x Estrutural

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.

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

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

YellowBike:

Alguém entendeu alguma coisa???

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.

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

Se você quer programar de forma procedural, programe, se quer de forma OO, programe, não misture as coisas.

pcalcado:

Se você quer rpogramar de forma procedural, programe, se quer de forma OO, programe, não msiture as coisas.

É 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

ronaldtm:

aproveitando muitas das vantagens da OO, como polimorfismo, herança e o uso extensivo de frameworks.

Tetsuo

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

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…

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… ;)

Por que você ia querer isso?

Sem herança? C, pascal…

pcalcado:

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… ;)

Por que você ia querer isso?

Sem herança? C, pascal…

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…

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…

É 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

pcalcado:

Claro que não! Usamos as ferramentas certas para a ocasião certa ;)

É OO, doce mistério

Exatamente, ‘não use uma pensando que é a outra’

RAD? Não precisava me insultar!

1. Eu não vou fazer o projeto sozinho.

2. Eu não vou, nem quero, ficar na manutenção do sistema, anos depois.

3. 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!

ronaldtm:

… e não dá pra programar ‘puramente OO’ …
Tetsuo

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

Concordo, mas então vamos usar JBuilder, JDev, quem sabe o Delphi, arrastar botõeszinhos e andar rápido com as coisas :lol:

skill_ufmt:

ronaldtm:

… e não dá pra programar ‘puramente OO’ …
Tetsuo

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:

Você por acaso leu o que eu escrevi? -sigh–

ronaldtm:

Você por acaso leu o que eu escrevi? -sigh–

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á:

Hibernate in Action

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

skill_ufmt:

Ou usamos OO ou procedural, ou inventamos um novo paradigma OOR - Orientação a Objetos Relacionais :lol:

Tipo isso?

Qeuria ter um filho assim como o Shoes hehehe

pcalcado:

… Yourdon

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

O grande ponto é: escolhi a tecnologia errada. java e servlets para fazer algo tão simples é um overkill. Pense nisso ;)

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?

skill_ufmt:

E o JRapi… shoes? paro? desanimo? ;)

[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]

pcalcado:

skill_ufmt:

E o JRapi… shoes? paro? desanimo? ;)

[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]

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?

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.

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.

pcalcado:

ronaldtm:

2. Eu não vou, nem quero, ficar na manutenção do sistema, anos depois.

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.

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.

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 :)

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

ronaldtm:

Dizer que ‘só uso OO’ ou ‘só uso procedures’ é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo

é 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?

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?

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

skill_ufmt:

ronaldtm:

Dizer que ‘só uso OO’ ou ‘só uso procedures’ é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo

é 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

Calma, calma, eu tava brincando!