PHP Orientado Objeto e Procedural (migração, MVC, informações, ideia) - PHP - Fórum iMasters
By DougCoder, April 13, 2016 in PHP
Tenho um projeto atualmente zero orientado a objeto. Estava dando uma lida e pesquisada pela net, muita gente diz que o PHP é muito "misto", praticamente todos projetos irá encontrar linguagem procedural a grosso modo como também linguagem orientada a objeto (juntas), principalmente se for algo pequeno que não utilize frameworks como zend, cake, etc.
Também ciente que orientação a objeto é um paradigma para nosso código se tornar "algo real", já li até mesmo que não é necessário o código ser baseado em classes para ser orientado a objeto(nunca vi POO sem classes), achei estranho e comecei a duvidar do que estava lendo, onde também dizia que Orientação a Objeto é mais a parte de organização do nosso código e algumas medidas que são padrões para manter essa organização.
OK, até ai tudo é teoria.
DÚVIDAS QUE NÃO ME DEIXAM DORMIR:
• MVC: É possível eu seguir a estrutura MVC em php para um código não orientado a objeto? É possível ter o MVC em algo mais procedural ou misto?
• MIGRAÇÃO: Caso eu seja obrigado a refazer meu projeto orientado a objeto, o que eu preciso saber que irei encarar pela frente? É algo que leva tempo, mas existe alguma forma de tornar essa migração facilitada?
• PDO / MySQLi: PDO é um método montado em cima do paradigma orientado a objeto, sendo assim posso dizer que PDO é orientado a objeto? Minhas manipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.
OBS: Boatos de que BOA PARTE da documentação do PHP é estrutural, isto é por si verdade ou não, tudo que existe em PHP estruturado/procedural também existe em PHP orientado a objeto?
Eu consigo argumentar para uma banca examinadora de TFC que meu projeto não foi desenvolvido orientado a objeto por algum bom motivo (igual este da documentação se for verdade)?
Eu realizei testes de software (funcional/unitário com badboy e análise estática com rips) incrivelmente consegui zerar as falhas de sql injection, session e banco e quase zerar os erros de cross-scripting. Não consegui resolver file manipulation e alguns cross-scripting que quando apliquei a correção com htmlentities deu alguns bug na página.
Enfim, com os testes de software consigo "provar", ou melhor, argumentar que minha gambiarra é funcional !!! Porém agora estou preso no MVC/Orientação a Objeto.
O que vocês podem me ajudar nesse conceito galera? Estou fudido e tenho que desenvolver orientado a objeto ou existe uma saída? rsrs
É importante entender que, no final das contas, a teoria é diferente da prática.
Tenho um projeto atualmente zero orientado a objeto. Estava dando uma lida e pesquisada pela net, muita gente diz que o PHP é muito "misto", praticamente todos projetos irá encontrar linguagem procedural a grosso modo como também linguagem orientada a objeto (juntas) [...]
O PHP, no geral, permite ambos os paradigmas. Foi inicialmente uma linguagem de scripts que evoluiu para uma linguagem dinâmica orientada à objetos.
[...] principalmente se for algo pequeno que não utilize frameworks como zend, cake, etc.
Não necessariamente. O framework é uma ferramenta de trabalho para facilitar o desenvolvimento, utilizá-la corretamente é outra história. Assim como trabalhos pequenos (estou falando de qualquer trabalho em qualquer profissão), existem pessoas que quase não utilizam ferramentas, e fazem um trabalho exemplar, e outras que utilizam um grande conjunto de ferramentas (como um framework) e deixam a desejar.
O conceito de orientação à objetos sem classes existe apenas quando o assunto for somente reutilização de código (que é apenas uma parte da POO).
A reutilização, no seu âmbito mais simplista, ocorre através das funções. Agora, a POO, como já falaste, é um paradigma com objetivo de deixar o seu código, e a forma de programar/pensar, o mais próximo possível do mundo real.
Em questões de organização, você poderá ter o mesmo nível de organização tanto procedural quanto POO, não é um paradigma que irá definir, previamente, qual será mais organizado.
MVC: É possível eu seguir a estrutura MVC em php para um código não orientado a objeto? É possível ter o MVC em algo mais procedural ou misto?nipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.
Seguindo a risca o que diz o MVC, e considerando a teoria, é possível. O MVC define uma estruturação em três camadas, com o foco principal na view. Como as camadas são estruturadas, fica conforme o custo x benefício.
Se for pensar em questões históricas, o MVC teve sua composição através das classes do Smaltalk. Mas, apenas utilizar classes, não significa ser POO.
Veja bem, conforme a imagem abaixo:
As linhas contínuas definem uma comunicação direta, enquanto as linhas pontilhadas/traçadas definem uma ligação indireta. Em POO, é fácil pensar como trabalhar e criar essas conexões. Já proceduralmente falando, é um pouco complexo manter a separação. No final das contas, o custo de desenvolvimento para realizar essa interação, de forma procedural, é tão elevado que não vale o benefício.
MIGRAÇÃO: Caso eu seja obrigado a refazer meu projeto orientado a objeto, o que eu preciso saber que irei encarar pela frente? É algo que leva tempo, mas existe alguma forma de tornar essa migração facilitada?
É a quebra de paradigma. Quando começa a se estudar POO, é muito difícil "pensar" em POO. É do nosso consciente pesar em programação top-to-down, execução linha-à-linha. Na orientação à objetos, apesar de seguir uma linearidade, o pensamento não é mais o mesmo.
Acho que a maior "epifania" que ocorre é com os princípios S.O.L.I.D., pois, são essências para qualquer desenvolvedor POO.
PDO / MySQLi: PDO é um método montado em cima do paradigma orientado a objeto, sendo assim posso dizer que PDO é orientado a objeto? Minhas manipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.
As SQLs continuarão sendo SQLs e são estruturadas (Structured Query Language), o fato de usar PDO/MySQLi não mudará a essência da linguagem. A manipulação, em PHP, é POO, mas pode ocorrer em um script procedural
MySQLi permite ser totalmente procedural.
A documentação era toda procedural, pois era assim que a linguagem era. Mas a linguagem foi evoluindo e, certas funções, foram agrupadas em bibliotecas. Agora, num passado recente, algumas bibliotecas foram criadas sem a existência de um código procedural preexistente. Mas é muito raro encontrar algo, no PHP, em POO que não possa ser feito de forma procedural.
Qual o motivo dessa argumentação? Estou querendo entender o seu ponto para explicar que todo o sistema deve ser procedural.
Outro ponto a ressaltar, é o benefício entre programadores POO e procedural, que é nenhum. Mas não ter benefício, não significa que as coisas serão feitas de forma similares.
Excelentes explicações amigo, bem objetivo e detalhado!
É o seguinte, eu sou acadêmico de Engenharia de Software e eles cobram o máximo para que o projeto/sistema seja algo bem organizado e principalmente bem definido, isto significa que, o que eu escrever na documentação, tem que fazer 100% sentido com a minha aplicação.
Eu fiz um esquema de busca que pesquisava 1 campo por vez, em um select, porém o meu banco era tabelas N:N isto torna uma "inconsistência", pois se meu banco é N:N, minha aplicação deveria permitir a busca de 1 ou mais dados relacionados a este campo. Exemplo: Pesquisa de 1 arquivo. Eu devo levar em conta que minha documentação permite que o usuário pesquise no filtro de busca o nome do arquivo, 1, 2 ou mais editoras, 1, 2 ou mais autores, disciplinas, enfim... Este é um "diferencial" do projeto, onde a maioria não possui este recurso, permite apenas a busca de 1 informação por vez.
O que vem ao caso:
Eu tenho que estar preparado para caso seja questionado coisas do gênero:
- "Onde está a orientação a objeto em seu sistema?". "Porque optou pela forma procedural?"
- "Onde está o padrão MVC citado no DERS?".
A Qualidade de Software e garantia da qualidade em software muitas vezes cobram tipagens das quais geralmente se encontra... Ou melhor dizendo, são mais popularizadas com utilização da orientação a objeto.
Porém, se eu conseguir levantar argumentos, teorias e citações das quais defendem a utilização do PHP procedural, eu terei uma base relevante para justificar o porque da utilização procedural e em meu ponto de vista e realidade, eu achei mais documentações e mais facilidade em desenvolvê-lo assim do que orientado a objeto. Mas a palavra "facilidade" não é uma justificativa para tal decisão.
La no semestre passado, antes mesmo de projetar qualquer coisa via código, na própria documentação, escrevi que o projeto teria MVC. E assim será, porém fiquei confuso se o MVC é bem visto com código procedural e também como ele deveria ser dividido? Pois o que vi sobre MVC foi praticamente apenas relacionado com Java e seus beans, DAO, get/setters, db package, etc.
Como ficaria o MVC no PHP Procedural? Você teria algum exemplo mais "prático", para eu ter noção de como funciona na prática.
MVC é um tipo de organização estrutural de sistemas, também chamado de "programação em 3 camadas". Ele provém de Model, View e Controller.
O que isso significa? Significa que um sistema em estrutura MVC possui uma separação de suas partes.
Na prática é o seguinte: Antes do padrão MVC, se colocava tudo junto, em uma mesma página php, por exemplo, o HTML, o PHP, o CSS, o JavaScript e etc.
Com o padrão MVC temos a separação das coisas, sendo assim, teremos: Uma página HTML, que é a View, uma página PHP sendo o Controller, e uma página PHP sendo o Model. Fora isso, também, hoje, é padrão termos o CSS e o JS em arquivos externos, apenas sendo referenciados na View.
O View, é a visualização, ou seja, o que é exibido ao usuário. Ele é basicamente HTML, CSS e JS. Pode ser escrito em HTML mesmo, ou em PHP, tanto faz, desde que seja um arquivo que só tenha essa função.
O Controller é o responsável por toda a regra de negócio. É ele que vai dizer o que deve ser feito, como deve ser feito e quando vai ser feito.
O Model é o modelo da coisa. É ele quem determina quais atributos o objeto terá, e também faz a interação com o Banco de Dados. E SÓ ele interage com o BD.
EU, PARTICULARMENTE, utilizo um padrão MVCD, digamos assim, pois programo utilizando uma quarta camada. Eu separo o Model, utilizando o mesmo APENAS para o objeto, com seus atributos e funções específicas dele, como uma formatação de exibição e coisas do tipo. A camada de abstração de dados, eu faço na "camada D", chamando-a de Data Object. Assim, ao MEU ver, fica ainda mais separado e organizado, tendo cada coisa em seu lugar.
Orientação a Objeto é um tipo de programação, que também pode ser utilizado sem o padrão MVC. Sendo assim, são duas coisas distintas.
É possível fazer um sistema no padrão MVC, sem OO? Sim, é possível. É viável? Não, não é. É fácil? Também não.
E por que não é viável?
Imagine um sistema de Pedidos, por exemplo. Você terá um cadastro de clientes, um de produtos e outro dos pedidos em si. Se você não tratar cada "cadastro" como um objeto separado, na parte de pedidos, você terá que repetir quase todo o código dos clientes e dos produtos, para poder criar o pedido, tornando assim o desenvolvimento muito mais trabalhoso.
Imagine que neste mesmo sistema, você tenha que exibir o pedido em umas 3 partes e de 3 formas diferentes. Você terá que programar em cada exibição a consulta dos dados, o tratamento e a exibição dos mesmos. Ou seja, se você tiver que alterar, adicionar ou remover algum atributo do pedido, terá que fazer isso pelo menos 3 vezes, pois, não sendo um objeto, você fez com que em cada página ele fosse algo independente. MESMO sendo no padrão MVC.
Posto isso, a MINHA opinião é que, hoje, sendo MVC ou não, a boa prática e o bom senso nos "obrigam" a fazer tudo em OO, sendo MVC ou não.
Eu, pessoalmente, não consigo nem mais olhar para códigos fontes que não estejam no padrão MVC, sério, me causa arrepios quando vejo HTML no meio de PHP, e coisas do tipo.
Da mesma maneira, não consigo fazer mais nada hoje que não seja em OO, devido à facilidade, rapidez, consistência, qualidade e agilidade no suporte e alterações deste tipo de programação.
Augusto Moreira 0
Interesses:Gosto de transmitir conhecimento apenas por prazer; programar para web e mobile; curtir a família e estudar :)
Dserma, uma pequena correção:
A camada responsável pela tua regra de negócio é a model. O controller, como o próprio nome sugere, é o cérebro do sistema, ou seja, lidam com as requisições web, dados de formulário etc..
Não tem jeito, não vou poder correr do MVC / Orientação a Objetos.
Agradeço a todos pelas explicações bem detalhadas, muito obrigado. Retornei aqui para tirar uma última dúvida sobre o assunto...
Terei que "migrar" meu projeto que está pronto em PHP estruturado para PHP orientado a objetos. É preciso utilizar algum framework tipo cakePHP / codeIgniter? Para algum benefício relacionado a MVC ou alguma outra coisa?
Posso meter a cara no código puro mesmo? O que me recomendam?
Estou bem chateado... Tenho nem 1 mês para tentar passar meu projeto para orientado a objeto com mvc... Missão meio impossível, mas vamos lá, é fazer ou fazer...
OBS: A não ser que eu consiga JUSTIFICAR o porque não utilizei MVC no projeto. Alguém de vocês tem argumentos para esta justificativa? hehe
Pesquisando na internet, nada "concreto", quando falo justificar, digo... Baseado em documentação, artigo, algo publicado, o que não vale... Um blog/fórum, site que não tenha sido publicado cientificamente.
Framerwork é uma ferramenta, normalmente em MVC. Não necessariamente necessita de um, mas facilita muito. Para entender melhor, deve pensar em trabalhos reais.
É mais fácil realizar uma conta complexa com uma calculadora ou sem?
Para esse cálculo, é melhor uma calculadora comum ou científica?
Ter uma HP 12c (calculadora financeira) me trará algum benefício perante as demais?
Quanto a justificativa, é prós e contras. Todas as arquiteturas tem seus prós e contras. Não é porque ela é muito utilizada que seja a melhor. Talvez ela apenas seja a melhor "pensada" no momento para alguma determinada ação. As vezes, a justificava é apenas porque é a mais rápida a ser implementada e/ou é a única que o desenvolvedor sabe utilizar. Mas com certeza o MVC, atualmente, é mais utilizado pois a grande maioria de frameworks que o utiliza.
Suas justificativas, no meio acadêmico, devem vir de bibliografia. Você não conseguirá justificar, através de livros, que criou um sistema MVC de forma procedural. Isso porque, na literatura, é tudo orientado à objetos. Principalmente quando os "mestres em arquitetura" (das antigas e que não programavam nada nas linguagens atuais) exemplificavam MVC com OO.
Agora, quanto a justificar o fato de não utilizar uma arquitetura, é fácil, pois a arquitetura é utilizada para resolver um problema (e acaba criando outros). Dessa forma, é bom entender a necessidade do seu sistema, quais os pontos que quer abordar nele e, então, escolher a arquitetura que melhor de adequa a ele.
No meu TCC de pós, houve colegas que justificaram, a arquietura/linguagem escolhida, como questões de aprendizagem e dizer que é possível fazer daquela forma. Você pode enumerar os pontos cruciais de uma arquitetura e expor que é possível realizar de outra forma. Mas isso depende da linha do seu curso, se é sobre questões práticas e implementação ou sobre linhas de pesquisa. Lembrando que, na linha de pesquisa, pesa muito o conhecimento que isso ira agregar para as futuras gerações de programadores.
Sobre arquiteturas atuais, com as questões web, eu acredito que a RESTful esteja entrando como a bola da vez. Pois divide as responsabilidades e diminui o tráfego de dados entre cliente x servidor.
Seria o ciclo de reinvenção da computação, aonde no início tínhamos os mainframes processando e os terminais burros somente para acesso. Depois, removeu-se os mainframes e o processamento dividiu-se entre os PCs.
Agora, tínhamos o cloud (como se fossem mainframes) para centralizar toda a informação e o browser (como se fossem terminais burros) para acesso. E , com o avanço do javascript, estamos novamente dividindo o processamento e diminuindo o I/O entre servidor x terminal.
Se for para agilizar algo, pode usar algum framework, no entanto, você vai precisar escrever e estudar as coisas.
Conheço alguns ai que se diz desenvolvedor, mas quando você olha o trabalho do cara, nota-se que é alguém muito bom em coisas prontas e não em programação.
Se você dirigir sua mente para a programação, em breve vai dominar facilmente qualquer framework ou novas linguagens, não adianta tentar correr sem aprender andar primeiro.
Ontem eu estava dando uma olhada na linguagem swift da Apple, estudei um pouco do manual disponibilizado gratuitamente pela própria empresa, fiquei cerca de uma hora e neste momento aqui agora, posso abrir meu notepad++ e escrever alguma coisa utilizando esta linguagem e isso só é possível porque antes estudei programação do zero by hand.
Trabalho nesta área faz uns sete anos, imagine se fossem sete anos de WordPress ou CakePHP, neste momento eu seria praticamente um copiador e não conseguiria criar nada quanto mais, por exemplo aprender outras linguagens.
Gabriel....o que inicia a aplicação? um controller ou uma view? o autoload da aplicação é um controller ou model?
Literalmente falando, é o controlle. Mais precisamente o Front Controller, o qual não é um Controller dentro do padrão MVC.
Aplicações mais antigas realizavam o request diretamente para o controller (o C do MVC), nesse caso, o controller era responsável por carregar o que fosse necessário para o seu uso (algo que está de acordo com a necessidade).
Não entendi as setas pontilhadas Gabriel...não seria um require?
Não, são associações indiretas. Mais precisamente é o conhecimento que cada componente tem de outro.
Não é de responsabilidade do MVC definir como você deve implementar a sua aplicação (require/include é um exemplo).
Acho que a melhor explicação que você pode encontrar está nestes posts:
http://forum.imasters.com.br/topic/458278-como-pensar-em-orientacao-a-objetos/?p=1816034
http://forum.imasters.com.br/topic/425372-padrao-active-record/?p=1685860
é importante saber que o foco do MVC é a View, tudo no MVC (ao menos em teoria) foi concebido para facilitar a implementação da View.
As setas/linhas contínuas, são associações diretas.
O Controller acessa ambos Model e View, tem conhecimento sobre como buscar dados na model e como devem ser enviados para a view.
A View acessa a Model. Apesar de não acessar o objeto Model, ela acessa os dados que, por sua vez, são de total responsabilidade da Model. Além disso, tem total conhecimento sobre como são os dados/objetos (responsabilidade da model), como devem ser acessados para serem renderizados e, em alguns momentos, tem total conhecimento que uma solicitação/interação, com algum componente, resultará em um acesso com a Model.
Já as setas/linhas pontilhadas, são associações indiretas.
Basicamente, a View não tem conhecimento que o impacto de uma de suas ações pode se conectar com um Controller. A View sabe que, ao clicar naquele botão do formulário e, ao realizar o submit, irá implicar em uma nova requisição. Entretanto, não tem conhecimento que essa requisição será respondida por um Controller. Apenas sabe que há uma nova requisição.
Já a Model, não tem conhecimento algum sobre a View (assim como View não conhece o Controller). Mas, em determinadas situações, uma alteração na Model deve ser propagada para as demais camadas (isso inclui a View) sem o conhecimento da Model.
Como por exemplo, um dado é alterado no SGBD e essa alteração deve ser propagada para as demais camadas. A Model não sabe que existe uma camada além dela, mas existe algum componente, responsável por esse conhecimento, seja um Observer, Mediator ou qualquer componente. E, diferente de alguns componentes acessados pela View, a Model não tem o conhecimento sobre as reações de sua ação.