Melhoria em insert orientado a objetos

[João Paulo Hildebrand 0]

Pessoal, bom dia!

Estou aprendendo orientação a objetos agora. Então, gostaria de mostrar a vocês o código que fiz e pedir opiniões de melhorias no código. Sei que ele está sem criptografia de senhas e outras boas práticas de segurança, mas meu foco aqui é apenas Orientação a Objetos.

Poderiam me dar essa força e opiniar? Obrigado!!!

index.php (Pequeno formulário de cadastro)

 

<form action="funcoes/controle.php" method="post">

<input type="hidden" name="tipo" value="cadastro">

<input type="text" name="nome" placeholder="Nome" required>

<input type="text" name="sobrenome" placeholder="Sobrenome" required>

<input type="email" name="email" placeholder="E-mail" required>

<input type="password" name="senha" placeholder="Senha" required>

<input type="submit" name="enviar" value="Enviar">

</form>

 

 

funcoes/controle.php (Responsável por dar a tratativa correta as informações vindas do form)

 

require_once("../classes/crud.class.php");

$crud = new crud;

$crud->conectar();

$tipo = $_POST['tipo'];

switch($tipo){

case "cadastro";

$nome = $_POST['nome'];

$sobrenome = $_POST['sobrenome'];

$email = $_POST['email'];

$senha = $_POST['senha'];

$insert = "INSERT INTO usuarios(nome, sobrenome, email, senha) VALUES('$nome', '$sobrenome', '$email', '$senha')";

$crud->inserir($insert);

break;

};

 

 

crud.class.php (Onde há a classe CRUD, com conexão e insert)

 

class crud{

var $servidor = "localhost";

var $usuario = "root";

var $senha = "";

var $banco = "php_oo";

var $conexao = NULL;

var $query = NULL;

function conectar(){

$this->conexao = mysqli_connect($this->servidor, $this->usuario, $this->senha, $this->banco);

return $this->conexao;

}

function inserir($query){

$this->query = $this->conexao->query($query);

return $this->query;

}

}

 

 

 

 

Está bem simples e pequeno, mas como disse, estou aprendendo ainda :)

Aguardo e muito obrigado!

[Diogo Camargo 18]

Se a classe está dentro de uma pasta chamada "classes" porque nomear o arquivo como *.class.php?

[João Paulo Hildebrand 0]

Sinceramente? Não sei kkkkkk' Mas todos os vídeos que assisti para aprender a galera faz isso, então achei que fosse uma boa prática...

 

Mas obrigado pelo toque :)

[Diogo Camargo 18]

Achei que fosse uma boa prática...

 

Não é sobre boa ou má prática, é questão de lógica.

 

"class.php" foi muito usado na época do PHP 4 e ainda existe até hoje

[João Paulo Hildebrand 0]

Mas se tratando do código em si, estou no caminho certo? O que você melhoraria nesse simples código?

[Vinicius Rangel 208]

A confusão com a história do nome é a seguinte.

 

Geralmente quem aplica o OO aplica o MVC logo não existe estrutura com pasta CLASS.

 

Então para diferir um arquivo estruturado de um objeto é colocado o nome .class no final assim como já vi .interface.

 

Não entendi a função do $_POST['tipo'] na sua aplicação.

 

Seu objeto CRUD é totalmente depende do MYSQLI.

 

De uma lida sobre SOLID:

http://code.tutsplus.com/pt/tutorials/solid-part-1-the-single-responsibility-principle--net-36074

 

Caso você for criar uma validação sobre o cadastro de usuário você colocaria nessa tela e tudo bem.

 

Caso outra tela tenha opção de cadastrar usuário, o código de validação se repetiria.

Você precisa de um objeto que converse com a sua estrutura de usuários e que tenha um validador que possa se conectar a esse objeto de usuários.

 

Ai se aplicaria um uso da interface a depender da regra de negócio.

 

Acho que por enquanto é isso.

 

Lembrando que estou focado no OO para esse post.

[Diogo Camargo 18]

Então para diferir um arquivo estruturado de um objeto é colocado o nome .class no final assim como já vi .interface.

 

Agora isso é má prática, misturar arquivos em uma mesma pasta. Foi assim que surgiu essa idéia de escrever .class.php.

 

Interfaces ou classes abstratas devem informar o que são no nome e não como uma extensão.

 

DataInterface

AbstractData

[João Paulo Hildebrand 0]

Vinicius,

 

Legal cara, obrigado pela resposta!

 

Poderia me dar um exemplo de como não deixar meu código tão dependente do MYSQLI? Não entendi muito bem isso..

 

 

Mas muitíssimo obrigado pela resposta!

[Vinicius Rangel 208]

Aqui no fórum tinha um tópico muito legal explicando sobre.

 

O polimorfismo vem a calhar nesse caso.

 

Um exemplo bom seria algo mais ou menos assim

class crud {var $servidor = "localhost";
public $query  = NULL;


function inserir($query){
$this->query = $this->conexao->query($query);
return $this->query;
}

}

public function crud_mysqli extends crud {
​
private $usuario = "root";
private $senha = "";
private $banco = "php_oo";
private $conexao  = NULL;

function conectar(){
$this->conexao = mysqli_connect($this->servidor, $this->usuario, $this->senha, $this->banco);
return $this->conexao;
}
}

Agora você passa a chamar o objeto crud_mysqli.
Se um dia você precisar usar ORACLE basta criar o seu objeto crud_oracle criar o método conectar e usar o código que conecta com o oracle e pronto.

Você pode alterar seu programa sem afetar a estrutura principial.

Hoje se você alterar seu crud e der algum problema seu sistema inteiro sofre com a alteração.

repare também que alterei VAR para private, outra coisa importante é visibilidade.

Acho que é isso cara..

[Diogo Camargo 18]

Aqui no fórum tinha um tópico muito legal explicando sobre.

 

http://forum.imasters.com.br/topic/401441-organizar-cdigo/#entry1572696

[Diogo Alves da Silva 2]

Olá João, tudo bem?

Achei bastante organizado a forma como você desenvolveu sua classe de CRUD. Assim como os colegas acima notaram, acho apenas que você não precisa mais nomear os arquivos indicando sua funcionalidade, adeus notação Húngara! rsrs

Uma outra dica que eu daria é utilizar o PDO para criar os CRUDs... Estas funções já não são usadas para conexões com banco de dados....

Abraços.

[Vinicius Rangel 208]

 

http://forum.imasters.com.br/topic/401441-organizar-cdigo/#entry1572696

Diogo, bom tópico mas não era disso que estava falando.

 

Antes tinha uma base de conhecimento escrita pela gênio João que abordava Polimorfismo, herança.

 

Também existia o blog do usuário no qual eu e alguns outros usuários criamos uma base de conhecimento também com experiências de projetos no qual também foi removido.

 

Abraços.