OOP - Padrões de Projeto

Fala GUJeiros,

Na opinião nada comturbada de vocês hehe

Diferenças de Orientação a Objetos e Padrões de Projetos?

Porque um e não o outro?

Custo/Beneficio?

E os frameworks? são ou não Padrões de Projeto?

Gostaria de deixar estas indagações, e gostaria de ver o formento deste tópico, ja que tem muitos especialistas aqui

Abraços...

This message was edited 2 times. Last update was at 25/02/2005 01:00:05

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?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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

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

marcioa1 wrote:( aprendi a programar perfurando cartões )

Alguém aqui no fórum deve ter algo a dizer a respeito disso. (Luca, apresente-se!)

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

Daniel Quirino Oliveira wrote:

marcioa1 wrote:( aprendi a programar perfurando cartões )

Alguém aqui no fórum deve ter algo a dizer a respeito disso. (Luca, apresente-se!)

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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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

Notícias, artigos e o maior fórum brasileiro sobre Java