Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Oi galera,
Meu problema é o seguinte: Não tenho formação acadêmica em programação, mas já fiz muitos trabalhos na área. Comecei com o bom e velho ASP que acabei substituindo recentemente pelo PHP. Como passei muito tempo programando apenas com vbScript, acabei criando vícios absurdos de programação procedural, orientada a eventos. Já li, reli e pesquisei sobre a Orientação a Objetos, fiz um curso online de PHP orientado a objetos e ajudou um pouco, mas tenho muita dificuldade em desenvolver um código que utilize de forma eficiente os recursos da Orientação a Objetos. Pretendo fazer um curso de Design Patterns para ver se ajuda alguma coisa, mas não tenho certeza se este é o caminho.
Só para você terem uma ideia, minhas classes PHP não passam de um amontoado de instruções CRUD isoladas.
Estou desenvolvendo um sistema de perguntas e resposta onde tenho certeza de que poderia aplicar conceitos OOP para facilitar minha vida, mas não consigo.
Qual é melhor caminho para aprender OOP eficiente? O que você recomendam?
Obrigado.
YAGNI ?? significa oq??
DRY eu tinha visto =P
Valeu Igor,
é isso mesmo. eu não sinto que esteja fazendo nada realmente OO. Apenas um bando de classes.
Vou pesquisar mais.
Olhar um código fonte bem escrito pode ajudar? O que eu sinto é que não me ajuda muito olhar pedaços de código isolados que explicam apenas um conceito.
Obrigado.
YAGNI = You Aren't Going Need It
DRY = Don't Repeat Yourself
KISS = Keep It Simple, Stupid
E vários outros...
O problema mesmo é identificar quando isso ocorre.
Não existem atalhos para o aprendizado de programação, você só aprende fazendo e errando (muito).
>
YAGNI ?? significa oq??
DRY eu tinha visto =P
leitura:
http://wbruno.com.br/2011/08/18/boas-praticas-de-programacao-filosofias-de-desenvolvimento/
vlw _
Realmente indentificar esses problemas, que é o X da questão
>
Valeu Igor,
é isso mesmo. eu não sinto que esteja fazendo nada realmente OO. Apenas um bando de classes.
Vou pesquisar mais.
Olhar um código fonte bem escrito pode ajudar? O que eu sinto é que não me ajuda muito olhar pedaços de código isolados que explicam apenas um conceito.
Obrigado.
nao, olhar um codigo bem escrito nao pode ajudar, pq? pq muitas vezes os melhores programdores usando os padroes de projeto, q sao completamente diferente da oo, mas ambos se completam, oo eh uma coisa e design patterns (padroes de projeto) eh outra, e aconselho so a pegar padroes de projeto depois de estudar oo, mas pra comecar
o objetivo da oo eh sempre transmutar o mundo real no codigo, por exemplo, andamos em veiculos, existem varios veiculos, cada um faz algo diferente, e tem caracterisicas semelhantes, com este exemplo você ve a heranca
e um dos principios da OO: cada objeto tem seus metodos, suas propriedades e portante sua responsabilidade, seu objetivo.
ae você ve q cada veiculo depende de combustivel pra andar, mas nao tem dentro dele, entao você agrega combustivel q pode ser de varios tipos, entao ae você tem outro objeto e varias herancas, e outro principio
agregacao, junto com agregacao tem outros 2: composicao e associacao...
eh so um exemplo pratico, peq e banal, mas q eu meu ver exemplifica muito a tranmutacao do mundo real em programacao...
se achar necessario posso indicar bibliografias...
>
nao, olhar um codigo bem escrito nao pode ajudar, pq? pq muitas vezes os melhores programdores usando os padroes de projeto, q sao completamente diferente da oo, mas ambos se completam, oo eh uma coisa e design patterns (padroes de projeto) eh outra, e aconselho so a pegar padroes de projeto depois de estudar oo, mas pra comecar
o objetivo da oo eh sempre transmutar o mundo real no codigo, por exemplo, andamos em veiculos, existem varios veiculos, cada um faz algo diferente, e tem caracterisicas semelhantes, com este exemplo você ve a heranca
e um dos principios da OO: cada objeto tem seus metodos, suas propriedades e portante sua responsabilidade, seu objetivo.
ae você ve q cada veiculo depende de combustivel pra andar, mas nao tem dentro dele, entao você agrega combustivel q pode ser de varios tipos, entao ae você tem outro objeto e varias herancas, e outro principio
agregacao, junto com agregacao tem outros 2: composicao e associacao...
eh so um exemplo pratico, peq e banal, mas q eu meu ver exemplifica muito a tranmutacao do mundo real em programacao...
se achar necessario posso indicar bibliografias...
Eu sinceramente achei que os padrões de projeto fossem quase um complemento indispensável para um bom codigo Orientado a Objeto... Valeu pela dica e se você puder apontar umas duas referências para eu pesquisar, vou ficar grato.
Obrigado e um abraço.
...os padroes de projeto, q sao completamente diferente da oo,oo eh uma coisa e design patterns (padroes de projeto) eh outra
Como assim? Não compreendi essas afirmações.
agregacao, junto com agregacao tem outros 2: composicao e associacao...
Na verdade, agregação e composição são tipos de associação, que são formas de relacionamento entre os objetos.
João, fantástica sua resposta! Pensar em mysql! É exatamente isso que eu faço. É muito complicado ainda imaginar as ações do software sem que estejam totalmente vinculadas ao banco de dados e sem criar código voltado para a comunicação com o DB. Qual é mágica neste ponto?
enquanto deveria pensar em mecanismo de armazenamento
Mas o que difere um mecanismo de armazenamento de um banco de dados?
O restante do post foi uma ótima aula. Muito obrigado.
>
OO eh um paradigma de programacao, design patterns eh uma forma de resolver determinados problemas...
Okay, está correto! [+1]
Minha pergunta foi mais retórica, apenas uma forma de alertar para se tomar cuidado com a forma que se escreve. Uma frase mal formulada pode causar problemas de compreensão e, nesse caso, poderia levar o autor da dúvida para um caminho errado.
O primeiro passo para se pensar "orientado a objetos" é ser capaz de abstrair um problema. Conhecer conceitos como encapsulamento, polimorfismo, herança, composição, agregação, são importantes também, mas de nada adiantarão se você não for capaz de pensar abstrato. É muito comum, para quem está iniciando, pensar em MySQL, enquanto deveria pensar em mecanismo de armazenamento, ul/li enquanto deveria pensar em lista de coisas.
O segundo passo, após ser capaz de abstrair, é saber delegar responsabilidades e ser capaz de escrever código desacoplado e reutilizável, e os princípios de design como S.O.L.I.D. e padrões de design como os descrito por GoF deverão ser estudados a fundo nesse momento.
Não tente estudar padrões de design enquanto você estiver pensando em MySQL em vez de mecanismo de armazenamento, você acabará fazendo absorção errada de conceitos e, invariavelmente, será incapaz de distinguir casos em que usamos Strategy em vez de State ou Abstract Factory em vez de Factory Method.
Normalmente eu faria um big post aqui, adoro o tema dessa discussão, mas estou no tab agora e fica um tanto complicado escrever muito por aqui. Quando estiver conseguindo enxergar as coisas na sua forma mais abstrata, pesquise por Robert "Uncle Bob" Martin e, quando tiver compreendido os princípios de design, pesquise sobre GoF. Assim que estiver dominando todos os princípios e padrões de design, compre o livro Clean Code, do Uncle Bob, e tenha-o como livro de cabeceira.
;)
>
Pensar em mysql! É exatamente isso que eu faço. É muito complicado ainda imaginar as ações do software sem que estejam totalmente vinculadas ao banco de dados e sem criar código voltado para a comunicação com o DB. Qual é mágica neste ponto?
Veja, MySQL é apenas 1 SGBD, existem vários, alguns relacionais outros não relacionais, você precisa pensar simples: Seu usuário utiliza sua aplicação e salva uma informação.
Perceba que o usuário salva uma informação, ele não salva uma informação no MySQL ou SQL Server ou Oracle, ele salva a informação, o lugar ou a forma que a informação será salva é irrelevante para o usuário, ele quer salvar a informação para poder recuperá-la depois.
Quando sua aplicação for capaz de salvar uma informação em vez de salvar uma informação no MySQL, então ela será capaz de variar o SGBD sem que absolutamente nada na aplicação precise ser modificado, bastará que você mude a instância do SGBD e sua aplicação funcionará com o novo, seja relacional ou não.
compre o livro Clean Code, do Uncle Bob, e tenha-o como livro de cabeceira.;)
/applications/core/interface/imageproxy/imageproxy.php?img=http://img593.imageshack.us/img593/1801/badcodegoodcode.jpg&key=05f8204ce646e29295dae181b2966a2f839fce75d32ba8f8466ea127febb25bc" alt="badcodegoodcode.jpg" />
:lol:
Quais livros recomendam para estudo de Princípios de Design?
Estive procurando em algumas livrarias, mas não é fácil de encontrar, ainda mais sem saber nomes '-'
>
Quais livros recomendam para estudo de Princípios de Design?
Estive procurando em algumas livrarias, mas não é fácil de encontrar, ainda mais sem saber nomes '-'
:seta: http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258
:seta: http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
Na verdade, essa lista completa aqui é excelente :seta: http://www.amazon.co.uk/Robert-C.-Martin/e/B000APG87E/ref=ntt_athr_dp_pel_1/280-8933008-2924036
>
Quando estiver conseguindo enxergar as coisas na sua forma mais abstrata, pesquise por Robert "Uncle Bob" Martin e, quando tiver compreendido os princípios de design, pesquise sobre GoF. Assim que estiver dominando todos os princípios e padrões de design, compre o livro Clean Code, do Uncle Bob, e tenha-o como livro de cabeceira.
O livro Clean Code, necessariamente, deve ser somente estudado após os outros conceitos?
Faço essa pergunta pois também encontrei esse livro, e em promoção ( tempos difíceis :yay: )
>
Faço essa pergunta pois também encontrei esse livro, e em promoção
Gabriel, se encontrou esse livro em promoção, então adquira-o, é o tipo de livro que se deve ter.
É complicado de encontrar livros bons, especialmente em php, só encontro os famosos (vide Use a Cabeça e Pablo Dal'Oglio). Nada contra, mas já ouvi muito o que falar sobre eles. Até mesmo estou lendo o livro do Pablo Dal'Oglio, e encontro alguns problemas de conceitos, como leio bastante, vejo que mais de um autor diz uma coisa, e ele as vezes diz outra.
O único exemplar de Matt Zandstra que eu encontrei, estava rasgado.
De outras linguagens de programação, autores como Martin Fowler e Erich Gamma, as livrarias nem sabem quem são esses "meliantes".
Realmente este é assunto que rende bastante. Como eu tenho um sério problema apenas com teoria, logo mais vou colocar um problema prático para ver como vocês o abordariam e como isso difere da minha abordagem, ok?
Obrigado a todos pelas respostas.
Abs.
Bom, vamos ver qual seria a abordagem de vocês nesta ocasião.
Eu estou desenvolvendo um sistema de pesquisa. Este sistema tem perguntas e respostas (doh). Em um determinado momento, o pesquisador terá que digitar as respostas que coletou.
Como eu montaria classes para lidar com este sistema de perguntas e respostas?
Eu imaginei o seguinte. Uma classe Questionario que lidaria com as informações genéricas como "o questionário já foi iniciado?" "Quantas perguntas tem?" "qual é a próxima pergunta?"
class Questionario{public function setIdPesquisa(){}public function temPergunta(){}public function proximaPergunta(){}class Pergunta{public function setIdPesquisa(){}public function getPergunta(){}class Respostas{public function setIdPergunta(){}public function getTodasRespostas(){}}
Este não é exatamente o caso real. É apenas um exemplo, ok?
Aí algumas coisas começas a embaralhar um pouco. Os métodos da classe questionário se referem às perguntas, mas tambem fazem parte do controle do questionário como um todo. Onde estes métodos deveriam ficar? Como é que eu defino qual é a responsabilidade de cada classe? pelos conceitos de OOP este seria um caso de composição (Questionário TEM uma pergunta) mas não seria possível utilizar a herança, uma vez que eu poderia reescrever o método proximaPergunta() para proximoRegistro() e utilizá-lo também na classe Resposta?
>
Bom, vamos ver qual seria a abordagem de vocês nesta ocasião.
Eu estou desenvolvendo um sistema de pesquisa. Este sistema tem perguntas e respostas (doh). Em um determinado momento, o pesquisador terá que digitar as respostas que coletou.
Como eu montaria classes para lidar com este sistema de perguntas e respostas?
Eu imaginei o seguinte. Uma classe Questionario que lidaria com as informações genéricas como "o questionário já foi iniciado?" "Quantas perguntas tem?" "qual é a próxima pergunta?"
class Questionario{public function setIdPesquisa(){}public function temPergunta(){}public function proximaPergunta(){}class Pergunta{public function setIdPesquisa(){}public function getPergunta(){}class Respostas{public function setIdPergunta(){}public function getTodasRespostas(){}}
Este não é exatamente o caso real. É apenas um exemplo, ok?
Aí algumas coisas começas a embaralhar um pouco. Os métodos da classe questionário se referem às perguntas, mas tambem fazem parte do controle do questionário como um todo. Onde estes métodos deveriam ficar? Como é que eu defino qual é a responsabilidade de cada classe? pelos conceitos de OOP este seria um caso de composição (Questionário TEM uma pergunta) mas não seria possível utilizar a herança, uma vez que eu poderia reescrever o método proximaPergunta() para proximoRegistro() e utilizá-lo também na classe Resposta?
lembre q eu falei sobre cada objeto ter suas responsabilidade? eu nao vi isso ai...uma classe "seria" uma estrutura fixa de um objeto....entao você tera uma classe q representa uma pergunta e outra q representa a alternativa, uma pergunta pode ter uma ou varias alternativas, ae você usa a uml, nesse caso você vai usar a agregacao pra representar em qual pergunta pertence tal alternativa, e vamos supor q você queira montar um questionario? ae você tera um problema chamado ninho de gato: kkkkkk....mas serio, você usara um padrao de projeto: o composite...
você usara um padrao de projeto: o composite...
Não, esse NÃO é um caso de uso de composite!
Não, esse NÃO é um caso de uso de composite!
um objeto pergunta nao poderia agregar alternativas?...
um objeto pergunta nao poderia agregar alternativas?...
Agregação é uma coisa. Composite existe toda uma motivação e aplicabilidade, que não se enquadra nesse caso de uso.
Ps: sorry pelas respostas muito curtas, estou no tab e é péssimo escrever por aqui.
>
Agregação é uma coisa. Composite existe toda uma motivação e aplicabilidade, que não se enquadra nesse caso de uso.
Ps: sorry pelas respostas muito curtas, estou no tab e é péssimo escrever por aqui.
ok...
ok...
No post abaixo eu falo sobre motivação e aplicabilidade de Composite:
/applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/wink.gif&key=0566fd943552bcff9cb1b879403ca34b5ff8f67befaac7fe4648006e9f764689" alt="wink.gif">
>
No post abaixo eu falo sobre motivação e aplicabilidade de Composite:
http://forum.imaster...ost__p__1812242
/applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/wink.gif&key=0566fd943552bcff9cb1b879403ca34b5ff8f67befaac7fe4648006e9f764689" alt="wink.gif">
sim, foi o q eu disse, uma pergunta agrega alternativas, mas uma alternativa nao pode ser a questao seguinte, num questionario? ae se torna um composite, com no exemplo da biblioteca, um livro pertence a a tal estante, tal estante tem tantos livros, e uma biblioteca tem tantas estantes....a nao ser q o composite so aceite objetos do mesmo tipo...
Igor, leia:
Composite é um padrão de projeto de software utilizado para representar um objeto que é constituído pela composição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado para representar listas recorrentes - ou recursivas - de elementos. Além disso, esta forma de representar elementos compostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetos atômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.
Perguntas e respostas não tem nada a ver um com outro no quesito hierarquia, não são unidos por herança, e sim por agregação (ou composição, se preferir), ou seja, uma pergunta não é constituída de várias respostas, uma pergunta é constituída de um frase interrogativa. PONTO.
Que métodos em comum teriam pergunta e resposta?
Você está sofrendo de "paternite", ou seja, está enxergando padrões onde eles não existem, tome cuidado com isso. Todos os que entendem um pouco do assunto também já devem ter passado por essa situação, mas tente tomar cuidado ao dar sugestões a outros membros e indicar-lhes o caminho errado.
>
com no exemplo da biblioteca, um livro pertence a a tal estante, tal estante tem tantos livros, e uma biblioteca tem tantas estantes....a nao ser q o composite so aceite objetos do mesmo tipo...
Você lê uma estante?
Você armazena estantes em um livro?
Você pode tratar uma estante como um livro, ou um livro como uma estante?
Se a resposta para qualquer uma das perguntas acima for positiva, significa que você pode ignorar as diferenças entre esses objetos e, assim, dizer que uma estante É UM livro e que um livro É UMa estante e, dessa forma, utilizar uma composição recursiva como Composite.
Se a resposta for negativa e você achar que uma estante TEM livros, então trata-se de uma associação 1.., assim como uma empresa está associada com 1.. funcionários, uma estante possui livros que não dependem da estante para existir, bem como a estante não depende do livro para existir.
E existe um padrão específico para esse exemplo da estante ou dos funciona´rios ou é apenas uma Coleção simples?
Entenda os conceitos. Eles fazem falta.
E antes de aprender OO, esteja certo de ter "boas práticas" de programação como teus guias, coisas como "DRY", "YAGNI"..
Recomendo tentar. Recomendo fazer, e depois olhar para oque fez, e verificar se algo lhe incomoda.
bom, você disse q veio do asp, entao eu recomendo q aprenda a linguagem, o php oferece muito dinamismo q outras linguagens nao oferecem, e isso eh bom, pois facilita muita coisa...sobre oo, aprenda oo, entenda q fazer classe nao eh oo, usar classe nao eh oo, oo eh uma filosofia, um modo, um paradigma de progrmacao...e por tanto tem os seus conceitos, seus proprios conceitos....como o amigo acima disse, entenda os conceitos....você nao consegue andar de bicicleta sem antes aprender q tem q se equilibrar pra andar nela...primeiro a teoria, depois a pratica, e claro a pratica o leva a perfeicao...