OOP - Padrões de Projeto

OOP é um tipo de culinária. Existe a culinária francesa, a italiana, a portuguesa, a japonesa, a brasileira, entre outras. Padrões de projeto são receitas. Esta é a diferença Um complementa o outro.

Já os frameworks costumam implementar alguns (vários) padrões de projetos para atingir um determinado fim. Got it?

Entenda framework como algo inacabado!!! Ou seja, ele só será útil quando em conjunto com sua aplicação por exemplo!!!

Um Abraço!

eae Daniel,

Bom, seguindo seu conceito, de “um complementa o outro”, poderiam eles existirem separados? cada um em seu contexto?

tata, o negocio é na cozinha…

é possivel existir uma culinária sem receitas?

é possivel existir receitas sem culinária?

Os framework precisam implementar padrões, pois como fornecem geralmente interfaces, são necessários fracos acoplamentos, e isso é quase uma regra básica no quesito padrões de projeto, creio que sem padrões nenhum framework terá grande sucesso.

abrços.

eae Thiago,

Thiago Senna:

Entenda framework como algo inacabado!!! Ou seja, ele só será útil quando em conjunto com sua aplicação por exemplo!!!

Um Abraço!

Cara não consideraria inacabado, eu diria que é até bem acabado hehee

e precisa ser assim pois ele encaixará na sua aplicação como mais um módulo qualquer. Um módulo desenvolvido por um qualquer para um determinado fim. Como não queremos reiventar a roda, usamos então esses parceiros.

abraços

skill_ufmt:

eae Daniel,

Bom, seguindo seu conceito, de “um complementa o outro”, poderiam eles existirem separados? cada um em seu contexto?

tata, o negocio é na cozinha…

é possivel existir uma culinária sem receitas?

é possivel existir receitas sem culinária?

Os framework precisam implementar padrões, pois como fornecem geralmente interfaces, são necessários fracos acoplamentos, e isso é quase uma regra básica no quesito padrões de projeto, creio que sem padrões nenhum framework terá grande sucesso.

abrços.

Não faz muito sentido falar de “receitas para culinária francesa” se não existir culinária francesa, né?

Mas, de qualquer forma, acho que eu entendi mais ou menos o que você quis dizer. OOP e Design Patterns são independentes, mas o segundo ajuda a tornar o uso do primeiro mais fácil. A idéia dos DP é fornecer um “caminho das pedras” para resolver uns probleminhas que insistem em aparecer no desenvolvimento de qualquer projeto OO. Por exemplo, você gostaria de tirar os códigos referentes ao mecanismo de acesso a dados da sua regra de negócios. Ok, use uns 2 ou 3 design patterns para isso e vá tomar uma cerveja com o pessoal do escritório no happy hour. Design patterns evitam que você fique reinventando a roda o tempo todo para resolver problemas que muitos já resolveram de maneira beeeeeeeeeem mais elegante.

Sugestão: leia este artigo aqui.

Olá,

Orientação a Objeto é uma metodologia de desenvolvimento que permite reutilizar código.

Padrões de Projeto é um conjunto de técnicas onde podemos reutilizar experiência.

Ao desenvolver sistemas OO, diversos problemas se repetem e, ao construir soluções, uns caras ( muito bons ) começaram a sacar que certos problemas são solucionados de uma mesma maneira. Assim, para um problema tal, um padrão tal pode ser aplicado de forma a facilitar sua solução.

Um ótimo livro é

Head First Design Patterns.

Vale cada centavo gasto nele.

Abraços,

Márcio

marcioa1:

Orientação a Objeto é uma metodologia de desenvolvimento que permite reutilizar código.

Esta é uma das premissa mais falsas da OOP. Com programação estruturada você também consegue reusar código. Ou o simples fato de vc fazer

#include <stdio.h>

em um código escrito em C não significa que você vai estar reusando código?

O grande princípio por trás da OOP não é o reuso do código. Reuso é uma mera consequência de algo maior: qualidade. A idéia da OOP lhe oferecer meios de se construir softwares com qualidade maior mais facilmente.

Nao percam, na proxima thread, Daniel e marcioa1 discutem “o que eh a arte?”, as 22:00, so aqui no GUJ!

Design patterns sao solucoes testadas e provadas para alguns problemas recorrentes no desenvolvimento de software (por exemplo, “como arrancar esse monte de linhas do banco de dados sem fazer muita sujeira?”). Alguns patterns so se aplicam a software desenvolvido usando orientacao a objetos, outros se encaixam em outros paradigmas, tambem. Mas, no geral, todos os patterns “funcionam” na OO, simplesmente pq eh o paradigma mais usado hoje, e eh o que foi mais pesquisado.

Daniel,

Tenho que confessar que me senti muito desconfortável quando disse que OO permite reuso. Outras “formas” de programar também permitem, é verdade.
E não é esta a “grande” vantagem de OO.

Não quis definir progamação OO, mas chamar a atenção de que com Padrões, a experiência de outros desenvolvedores ( testada e aprovada ) está disponível para quem quizer.

Esta “generosidade” é uma das coisas que mais me impressiona em Java. Até então, eu conhecia linguagens ( aprendi a programar perfurando cartões ) , mas ao estudar Java, vi mais do que uma linguagem. Vi uma comunidade.

Obrigado ao GUJ, que é para mim um grande apoio que me ajuda a me desenvolver profissionalmente. Espero sempre retribuir.

Abraços,

Márcio

:shock:
Alguém aqui no fórum deve ter algo a dizer a respeito disso. [size=9](Luca, apresente-se!)[/size]

to gostando de ver isso aqui bombear

Bom, Daniel, concordo que não existia receitas sem culinária, mas as culinárias podem sim existir perfeitamente sem receitas, ou não? eheh

Quanto a reuso de código, realmente isto não foi inovação de OO, simplesmente tantaram melhjorar isto, porém o sucesso não é tão grande assim como se prega, e é justamente por isso que entraram os padrões de projeto na parada, como viram que OO pura não atendia realmente os requisitos reais, e estava se tornando mais uma “Estruturarada da vida”, precisavam então refletir o estado real da vida, os caras então começaram a ajustar a OO, e assim BUMMM, temos padrões de projetos, que nada são além de melhores praticas, OO ou não de fazer algo, eu diria´ser a OO++ ou a OO versão 2 hehehe

Os padrões procuram empregar coisas simples porém que uma OO mal feita pode tornar complexa, o simples fato de sair dando NEW QaulaquerCoisa() dentro do seu codigo já o torna acoplado, e quanto mais NEWs, mais acoplamento, neste ponto entra as Interfaces que são MUITO utsadas nos padrões, que já deveriam começar junto a OO porém a maioria gosta dos NEWs primeiro

Herança é outra barca furada da OO, dependendo do contexto tu pode arrumar um baita problema usando muita Herança, você pode conseguir uma Exponenciação de classes muito loca 2 * 2 * 2 * 2 … n * n dependendo da profundidade disso.

E seria IOC(não conheço muito) a evolução de tais padrões? pelo pouco que vi, o importante é não dar o NEW heeh e usar muita interface, ou seja, padrões, ou seja mais ainda, MUITO conceito de padrões, estou certo? errado? essa é pra quem conhece IOC.

Abraços…

:shock:
Alguém aqui no fórum deve ter algo a dizer a respeito disso. [size=9](Luca, apresente-se!)[/size]

Sem querer ofender mas o cara deve ser bem velho, ops experiente eheh
Conheci um cara que programa desde quando programavam com pauzinhos ehehe, o cara é fera.

Cartões é uma programação bem antiga, uma das primeiras, as maquinas liam buracos feitos nos cartões, de dependendo da sequência, fazim aglo, um show hehehe

Olá!!

Em um dos tópicos lá em cima eu disse que deveríamos entender frameworks como algo inacabado! Talvez eu não tenha explicado bém minha opinião!

No caso do struts por exemplo, não há como você querer usá-lo sem que você tenha um sistema usando ele. Ou seja, o Struts só se fará útil apartir da hora que você integrá-lo com sua aplicação! Caso contrário, ele não tem utilidade.

É por isso que ele se chama framework… ou seja… um pedaço de trabalho… Ele é inacabado para que posso ser fácilmente acoplado ou integrado em alguma aplicação…

Um Abraço!

Daniel Quirino Oliveira:

OOP é um tipo de culinária. Existe a culinária francesa, a italiana, a portuguesa, a japonesa, a brasileira, entre outras. Padrões de projeto são receitas. Esta é a diferença Um complementa o outro.

Já os frameworks costumam implementar alguns (vários) padrões de projetos para atingir um determinado fim. Got it?

Pensando nesta linha, podiamos dizer que os frameworks são os temperos e condimentos pre prontos para as receitas. Junta-se varios desses condimentos e chegamos ao nosso prato preferido.

]['s

fabgp2001:

Daniel Quirino Oliveira:

OOP é um tipo de culinária. Existe a culinária francesa, a italiana, a portuguesa, a japonesa, a brasileira, entre outras. Padrões de projeto são receitas. Esta é a diferença Um complementa o outro.

Já os frameworks costumam implementar alguns (vários) padrões de projetos para atingir um determinado fim. Got it?

Pensando nesta linha, podiamos dizer que os frameworks são os temperos e condimentos pre prontos para as receitas. Junta-se varios desses condimentos e chegamos ao nosso prato preferido.

]['s

Claro desde que estes condimentos sejam feitos pelas proprias receitas

O problema era quando os cartoes caiam no chao e se misturavam todos! heheh

Eles tinham uma ordem pra serem executados e geralmente o computador que lia os cartões era um só na empresa, entao o cabloco tinha que sair da sua mesa com a pilha de cartões e ir até o computador. hehehe

Legal isso!

Essa analogia tah me deixando com uma Fome! :mrgreen:

outra,

Padrão de Projeto são verdades absolutas? tem que usar é pronto? se num usar ja fu… tudo a aplicação?

O problema era quando os cartoes caiam no chao e se misturavam todos! heheh

Eles tinham uma ordem pra serem executados e geralmente o computador que lia os cartões era um só na empresa, entao o cabloco tinha que sair da sua mesa com a pilha de cartões e ir até o computador. hehehe

Era isto mesmo. Os cartões não podiam cair, pois sairiam da ordem e era uma trabalheira. Entregávamos os cartões a um operador que os colocava numa leitora e nos devolvia em seguida. Se houvesse um erro de digitação (compilação ) , escrevíamos o cartão ( a linha ) novamente e submetíamos o programa novamente.

Velhice não é ofensa. É o tempo que coloca mofo nas paredes e cabelo branco nas pessoas. Algumas pessoas que se dizem “jovens por dentro” não estão sabendo lidar com a velhice, que é uma coisa que só pode ser evitada com a morte. Tenho 39 anos, me sinto bem e quero ficar bem velhinho ( e com muita saúde ) para curtir meus netos e, quem sabe, meus bisnetos. ( minha avó tem 100 anos ).

Saúde,

Márcio

Po cara tu é novo…
começou a programar com 7 meses?
ou foi um daqueles estágiarios que lavavam fita de impressora, buscavam o aspirador de bytes hehe (será que tinha fita de impressora naquele tempo )

Podia ter uma parte pra contar as histórias aqui no GUJ ehehe

Kiviano,

Você já viu um disquete de 8 polegadas ??

Márcio

marcioa1:

Kiviano,

Você já viu um disquete de 8 polegadas ??

Márcio

Eu já!!! É quase uma caixa de disco de vinil :mrgreen:

Pô, até eu, com meus 20 aninhos, já vi um disquete desses…

Mas até aí, meu irmão tem 33.

marcioa1:

Kiviano,

Você já viu um disquete de 8 polegadas ??

Márcio

Já sim, inclusive um hd tipo panela, que era 1GB, o trem pesava uns 10 kg, do tamanho de uma panela de pressão.
Na UFMT tem umas reliquias dessa pra ver

Padrão de Projeto são verdades absolutas? tem que usar é pronto? se num usar ja fu… tudo a aplicação?

skill_ufmt:

Padrão de Projeto são verdades absolutas? tem que usar é pronto? se num usar ja fu… tudo a aplicação?

São absolutas até alguém fazer uma análise crítica e propuser uma alternativa melhor.

Daniel Quirino Oliveira:

skill_ufmt:

Padrão de Projeto são verdades absolutas? tem que usar é pronto? se num usar ja fu… tudo a aplicação?

São absolutas até alguém fazer uma análise crítica e propuser uma alternativa melhor.

IOC? (não conheço a fundo)

tem algum relação entre IOC e Padrões?

IoC é um padrão.
E aí, Kivanio? Vamos começar a dar uma Googlada?

Daniel Quirino Oliveira:

IoC é um padrão.
E aí, Kivanio? Vamos começar a dar uma Googlada?

kkk, googlar é meu esporte preferido, e tenho googlado muito sobre IOC.

Mas a ideia inicial do post era trocar informações técnicas a respeito de padrões e OO, mas o que menos se falou aqui foi de padrões hehe

E velho e conhecido artigo deve ajudar.

http://martinfowler.com/articles/injection.html

ou em portugues

http://www.javafree.com.br/home/modules.php?name=Content&pa=showpage&pid=4

]['s

Daniel Quirino Oliveira:

IoC é um padrão.
E aí, Kivanio? Vamos começar a dar uma Googlada?

Cara, tenho estudado muito e escrito sobre padões (TCC da facul), ja vi e li a maioria dos livros de padrões, vo começar a ler o de refactoring do fowler.

E não vi nenhum padrão IOC, poderia me explicar melhor ou dar uma referência de que padrão ele é, artigo, livro? se é padrão onde ele ta “encaixado” em que contexto?

No artigo do Fowler, ele discute mais service locator e IOC, service e mensiona varias vezes que prefere service locator, e também diz depender do contexto para poder decidir sobre qual uso. Também menciona IOC como um padrão, porém não da também essa refenrência.

Se voce ficar muito fissurado nesse lance de OOP e patterns e nao partir pra quebradeira e realmente implementar sistemas que precisam deles, acho que vc nao vai pegar a sutileza da coisa, mas existe um equilibrio muito delicado entre as situacoes que requerem codigo especializado e aquelas em que socar meia duzia de patterns eh mais facil. No geral, vc quer se livrar de alguns problemas logo, e usa uns patterns pra ajudar - o que traz um novo conjunto de problemas, e vc vai resolvendo, e por ai vai… ate dar um ataque, vc ver que usou patterns demais e enfrescou demais o desenho da aplicacao.

Ai voce joga 5 quilos de codigo fora, faz de novo de forma mais simples e acaba com menos de 1/3 do que tinha antes, mantendo toda a funcionalidade. E o processo se repete… :mrgreen:

PS: “mensiona” foi foda hein?

Na minha opnião OO é um grande avanço dentro da programação pois o desenvolvedor para de pensar orientado ao computador e começa a pensar orientado ao problema em si e nos processos que o compõe de forma bem mais intuitiva. Quando programamos proceduralmente ou imperativamente dividimos nossos programas em blocos e fluxos de execução, e isso se parece muito com o modo que um computador funciona em baixo nível. Agora quando pensamos em objetos conseguimos abstrair idéias do mundo a nossa volta, assim mesmo como o vemos: cheio de objetos diferentes que possuem n relacionamentos diferentes entre si. Assim fica bem mais fácil construir aplicações escalaveis e de fácil manutenção, quando começamos a enchergar Objetos interagindo e não fluxos e sequências de bits com finalidades obscuras… É isso aew pessoal, minha opnião de uma das grandes vantagens de OOP. Valeu!

cv:

Se voce ficar muito fissurado nesse lance de OOP e patterns e nao partir pra quebradeira e realmente implementar sistemas que precisam deles, acho que vc nao vai pegar a sutileza da coisa, mas existe um equilibrio muito delicado entre as situacoes que requerem codigo especializado e aquelas em que socar meia duzia de patterns eh mais facil. No geral, vc quer se livrar de alguns problemas logo, e usa uns patterns pra ajudar - o que traz um novo conjunto de problemas, e vc vai resolvendo, e por ai vai… ate dar um ataque, vc ver que usou patterns demais e enfrescou demais o desenho da aplicacao.

Ai voce joga 5 quilos de codigo fora, faz de novo de forma mais simples e acaba com menos de 1/3 do que tinha antes, mantendo toda a funcionalidade. E o processo se repete… :mrgreen:

PS: “mensiona” foi foda hein? :P

opa, realmente a parada é implementar, eu diria, integrar, integrar padrões de maneira bem eficaz é realmente para pessoas experientes que também depois de muitas COs, aprenderam mais um pouco

Codigo de vai pro lixo, é reescrito, num é um prazer só dos patterns :), OO proporciona isso, e pq não dizer que a estruturada também proporcianava, cada qual a sua maneira é claro.
Reescrever, retirar, refazer, fazem parte do ciclo de vida do software…

Bom, vamos lá, o que OO revolucionou? qual efetivamente é seu ganho? Se for pensar com calma, realmente OO foi inovadora, mas não é perfeita, assim como na estruturada, OO tem seus vários problemas, e também não atendente de maneira completa a nossa realidade, dizer que OO é explendida, magnifica, é um exagero na minha opinião.

Se OO por si só fosse ótimo, não precisaria de patterns, IOCs e etc…
Os conceitos são magnificos, mas é preciso tomar cuidado ao usá-los…

Quem aqui já num viu OO Estruturada? hehehe

OBS: so fã de OO, antes que me batam

Bom, vamos lá, o que OO revolucionou? qual efetivamente é seu ganho? Se for pensar com calma, realmente OO foi inovadora, mas não é perfeita, assim como na estruturada, OO tem seus vários problemas, e também não atendente de maneira completa a nossa realidade, dizer que OO é explendida, magnifica, é um exagero na minha opinião.

Se OO por si só fosse ótimo, não precisaria de patterns, IOCs e etc…
Os conceitos são magnificos, mas é preciso tomar cuidado ao usá-los…

Quem aqui já num viu OO Estruturada? hehehe

OBS: so fã de OO, antes que me batam :)

O paradigma de Programação Orientada a Objetos revolucionou sim todo o conceito de programação, assim como o paradigma Imperativo e outros tantos revolucionaram um dia, cada um em um determinado âmbito do desenvolvimento de software. É uma questão natural de evolução! É lógico que não temos um paradigma perfeito, pois se tivessemos todos os outros poderiam ser ignorados e esquecidos. Cada um tem sua funcionalidade, afinal mesmo dentro da OO programamos um pouco de Procedural invariavelmente. Os patterns são certamente uma evolução e possivelmente irão contribuir para o surgimento de novos paradigmas! Mas já que a evolução do software segue uma linha bem mais vagarosa que a do hardware por exemplo, o ideal é ir integrando o que há de melhor de cada paradigma/padrão de projeto/componentes/tecnologias etc. É minha opnião! Valeu pessoal! []s

Pablo

Na minha visão, se estiver errado por favor me falem.
OOP é uma filosofia de programação que prega a reutilização de código e que busca abstrair e representar objetos do mundo real da melhor forma possível.
A idéia é fazer com que os objetos cooperem entre sí para fazer uma determinada tarefa.(objetos se comunicando com objetos)
Além disso cada objeto assume um papel dentro do sistema , ou seja cada objeto tem sua responsabilidade.(Dentro desse contexto podemos aplicar várias conceitos abstraidos do mundo real para melhorar OOP , como herança por exemplo,criação de objetos modelo, entre outros).

Design patternss são padrões encontrados a longo do tempo para resolver um série de problemas frequentemente encontrados em projetos, resumindo
é uma solução para um determinado problema que foi exaustivamente testada e aprovada.

A inovação da programação Orientada a Objetos esta justamente na maior capacidade de abstração do mundo real.

Por exemplo quanto trabalho vc teria na programação procedural para dizer que um gerente pode fazer tudo que um funcionário normal faz e mais um monte de coisa.

Quanto trabalho vc teria para criar diferentes tipos de autenticação de funcionários sabendo que todos os tipos são similares ou tem partes comuns.

A programação orientada a objetos trouxe vários benefícios dentre eles: facilidade de manutenção (quando programado direito , orientado a objetos de fato e não a gab ou string).
Reutilização de código , divisão de responsabilidades , além de ter simplificado a simulação de problemas reais do dia-a-dia).

Sem falar em muitas outras coisas: Como uso de memória, grande tolerância a mudanças.
(Vc pode obrigar que sejam seguidos alguns padrões pelo código, através de contratos entre classe ou interfaces).

Lógico a OOP tem seus problemas? tem , mas ainda assim é muito melhor do que a velha programação procedural.(onde tudo era meio que misturado)