Como pensar em Orientação a Objetos

[Juliano amadeu 3]

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.

[William Bruno 1501]

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

[Luis Paullo 47]

YAGNI ?? significa oq??

DRY eu tinha visto =P

[Juliano amadeu 3]

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.

[Henrique Barcelos 290]

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

[William Bruno 1501]

YAGNI ?? significa oq??

DRY eu tinha visto =P

leitura:

http://wbruno.com.br/2011/08/18/boas-praticas-de-programacao-filosofias-de-desenvolvimento/

[Luis Paullo 47]

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

[Juliano amadeu 3]

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.

[João Batista Neto 448]

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

 

 

[Juliano amadeu 3]

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.

[João Batista Neto 448]

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.

;)

[João Batista Neto 448]

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.

[Kakashi_Hatake 267]

compre o livro Clean Code, do Uncle Bob, e tenha-o como livro de cabeceira.

;)

 

 

:lol:

[Gabriel Heming 766]

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

[João Batista Neto 448]

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

[Gabriel Heming 766]

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

[João Batista Neto 448]

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.

[Gabriel Heming 766]

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

[Juliano amadeu 3]

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.

[Juliano amadeu 3]

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