Jump to content
Sign in to follow this  
DougCoder

PHP Orientado Objeto e Procedural (migração, MVC, informações, ideia)

Recommended Posts

Bom dia a todos,

 

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

Share this post


Link to post
Share on other sites

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

 

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.

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:

mvc-shceme-feat.png

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.

 

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?

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.

 

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

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.

  • +1 1

Share this post


Link to post
Share on other sites

@Gabriel Heming

Excelentes explicações amigo, bem objetivo e detalhado!

 

 

 

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.

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Dserma, uma pequena correçã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.

 

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

Share this post


Link to post
Share on other sites

Dserma, uma pequena correçã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.

 

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

Share this post


Link to post
Share on other sites

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

 

Augusto, creio que me expressei mal quanto à "regra de negócio". Como você pode ver, após isso eu disse que o controller é o responsável por dizer o que, quando e como esse o que será realizado. Na minha lógica de explanação ao colega, chamei isso de "regra de negócio", pois, o controller é quem dita as regras de, novamente, o que, quando e como esse o que será realizado.

Share this post


Link to post
Share on other sites

Pessoal...

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Como vai.

 

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.

Share this post


Link to post
Share on other sites

 

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:

mvc-shceme-feat.png

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.

Gabriel....o que inicia a aplicação? um controller ou uma view? o autoload da aplicação é um controller ou model?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

 

Resumindo:

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Similar Content

    • By LukasTrin
      Estou montando um website e gostaria de saber como faço para o usuário que acabou de deslogar ficar na mesma pagina ?
       
      por exemplo, na programação atual, ele clica em " Sair " e vai automaticamente para a index, independente de onde esteja.
      eu gostaria q ele permanecesse na mesma pagina em que estava
       
      programação q faz o mesmo deslogar...
       
      //essa é a navbar.php <li><a href="?sair=sim">Sair</a></li> // Esse é o logado.php if(isset($_GET['sair']) == "sim"){     $objUser->sairUsuario(); } //e esse é o usuarios.class.php public function sairUsuario(){ session_destroy(); header ('location: index.php '); }  
    • By ment0r
      Bom dia amigos, tudo bem?
       
      Sou novo em POO e estou com algumas dificuldades.
      Tenho um método de uma classe que é bem simples, ele busca todos os campos da tabela USUARIO (Firebird 2.0) e retorna o array com elas. Só que a não consigo exibi-los com while.
       
      Sem o método eu faria:
      while($array = ibase_fetch_object($query)){ echo $array->ID; echo "<br>"; echo $array->ID; // E por aí vai... } public function selectAllUsers(){ $select = "select * from USUARIO"; $query = ibase_query($select); $array = ibase_fetch_object($query); return $array; } Só que com o array não consigo. Não sei como usar o while com esse array retornado.
       
      Por favor, se alguém puder me ajudar... serei grato.
      Um abraço a todos.
       
    • By Rodrigo5468
      Boa tarde a todos.
       
      Estou desenvolvendo um sistema de registro para fins de estudos, mas tenho algumas dúvidas e dificuldades até. Estou usando "programação orientada a objetos", e quero validar alguns campos do meu registro, se puderem me auxiliar, será de grande ajuda.
       
      Meu Diretório:
      Projeto1/ ├── backend/ │ ├── classes/ │ │ ├── Register.php ├── index.php Em Register.php tenho o seguinte código para fazer a validação, mas acredito que estou fazendo algo de errado.
      public function setUsername($username) { $sql = "SELECT * FROM $this->table WHERE username = :username"; $stmt = Database::prepare($sql); $stmt->execute(array('username' => $_POST["username"])); if(empty($_POST["username"])) { return "O campo usuário não pode ser vázio."; }elseif(ctype_space($_POST["username"])) { return "Não pode usar apenas espaços no campo de usuário."; }elseif(strlen($_POST["username"] < 3)) { return "É necessário no mínimo 3 (três) caracteres no usuário."; }elseif(strlen($_POST["username"] > 15)) { return "O máximo é de 15 (quinze) caracteres no usuário."; }elseif(preg_match("/^[a-zA-Z0-9]*$/", $_POST["username"] == 0)) { return "O nome de usuário só pode conter letras e números. (sem espaços e sem caracteres epeciais)"; }elseif($stmt->num_rows !== 0) { return "O nome de usuário já está cadastrado em nossos bancos de dados."; }else { $this->username = $username; } } E no index.php tenho o seguinte código, acredito que está certo, mas eu gostaria de mostrar as mensagens de erros que estão no Register.php, como que posso fazer isso?
      $register = new Registers(); if(isset($_POST["cadastrar"])) { $username = $_POST["username"]; $email = $_POST["email"]; $password = $_POST["password"]; $register->setUsername($username); $register->setEmail($email); $register->setPassword($password); if($register->insert()) { return "Usuário cadastrado com sucesso."; } }  
       
      Obrigado pela atenção!
    • By Falcon89
      Antes de minha dúvida, deixo algumas considerações:
      - Estou em nível de aprendizagem, então, talvez a idéia e o script possa parecer bem "amador"
      - A dúvida não corresponde nada a função ou biblioteca Date, o ano utilizado é ficticio, no caso começando no ano de valor 1;
      - A minha dúvida se relaciona a POO, a utilização do Python como ilustração é meramente ilustrativa.

       

      Vamos a dúvida:
      Então eu criei uma classe chamada tempo com atributo ano, e uma classe pessoa com apenas os atributos em questão, a data de nascimento e a idade. O que eu queria que acontecesse, se possivel, era que ao instanciar uma nova pessoa, ela pegasse o ano atual do objeto 'tempo' já instanciado, e jogasse como ano de nascimento, e já setasse a idade da pessoa, subtraindo o ano atual do objeto tempo pela data de nascimento, fica meio confuso para explicar vou tentar dar um exemplo:
      Supondo que criei o 'tempoObj', que tem o valor do 'tempoObj.ano=1', nesse periodo eu instancio um objeto 'pessoaObj', então eu queria que essa pessoa pegasse o valor do ano que no caso seria 1 e jogasse na "pessoaObj.data_nascimento"que agora teria o valor de 1 e ano atual que também seria o mesmo valor e já setando atravéz da subtração a 'pessoaObj.idade' como 0, em tempo de execução, chamando a funçao avancar_ano() umas 3 vezes, o valor do ano atual seria 'tempoObj.ano = 4', nesse caso a idade dessa pessoa teria que seria 3, porem ao passar "tempoObj.ano" como argumento para data de nascimento e ano atual, ele sempre irá passar o mesmo valor para ambos fazendo com que a idade sempre seja 0.
       Nesse caso existe alguma forma que o valor seja passado para o metodo data_nascimento, some ao instanciar a classe pessoa, e o que o valor recebido so ano do tempoObj seja correspondente ao ano que esta armazenado no tempoObj.ano no momento de execução.
      Já tentei varias formas e sempre chego na mesma, se ficou entendido a questão e se é que existe uma solução, alguém tem essa solução? Desde já agradeço, e peço desculpa se não fui tão claro ao apresentar o problema. 
    • By dayenne
      Galera então é o seguinte, tenho um trabalho da faculdade para fazer porém ainda não entendo quase nada de java, to meio perdida no trabalho.
      o trabalho propoe que eu faça uma agenda de contatos, onde eu possa armazenar contatos, excluir contatos, pesquisa-los, edita-los, tudo isso usando 
      arquivos txt, porém não consigo de jeito nenhum sair da estaca 0, queria que você me orientasse melhor para que eu consiga flluir melhor os codigos.
       
×

Important Information

Ao usar o fórum, você concorda com nossos Terms of Use.