Giudizio su questa OOP

[SkyBlue]

Ciao a tutti, vi scrivo un script in OOP su un autenticzione login, non c'è scritto un papiro, ma vorrei solo sapere come vi sembra di sintassi, e di ordine....

<?php

class Login{
//Dichiaro queste variabili in public in quanto questa classe non sarà estesa a nessuna
public $username,$password,$errori,$login;

function __construct(){
/* 
   In questa funzione controllo se esiste il login (tasto premuto), trasformo errori in un array, che in futuro potrà riempirsi
   ed se vi è il login controllo i dati escludendo tutti i caratteri al di fuori della regular expresion 
*/
$this->login = ($_POST['login']) ? 1:0;
$this->errori = array();
$this->username = ($this->login) ? $this->controllo($_POST['username']) : 0;
$this->password = ($this->login) ? $this->controllo($_POST['password']) : 0;
}

function controllo($valida){
if(empty($valida)){
$this->errori[] = "Uno o più campi sono vuoti !";
}
return preg_replace("/[^a-zA-Z0-9]/","",$valida);
}

function ConnectDB(){
mysql_connect("localhost","root","") or die("Impossibile connettersi...");
mysql_select_db("login") or die("Impossibile connettersi al db");

$QueryVerify = mysql_query("SELECT Nome FROM utenti WHERE Nome LIKE '".$this->username."' AND Password LIKE '".$this->password."'"); 
// Non fate caso a livelli di sicurezza password ecc... in quanto è solo una prova..
$ResultQuery = mysql_num_rows($QueryVerify);
if(!$ResultQuery){
$this->errori[] = "Nessun account corrisponde ai dati da te inseriti." ;
}else{
header("Location: ./profile.php");
}

$this->Errors(); //Chiudo la funzione con una chiamata alla funzione errors
}

function Errors(){

if(!empty($this->errori)){
foreach(array_unique($this->errori) as $key => $value){
echo "Errore :".$value."
";
}
}
}

} //Fine classe

?>

[oronze]

Prendere una classe sola e "valutarne" la programmazione ad oggetti è difficile. La valutazione va fatta sull'insieme.... in ogni caso, la variaibiel $valida cosa contiene?
io vedrei così le classi...

class DB{
/*
  devi crearti una classe che faccia da interfaccia tra l'applicativo e la base di dati con opportuni metodi privati e pubblici e decidere se usarli statici o meno...nel mio esempio sono statici
*/
}

class Login{
  //è vero che al momento la classe non è estesa ma devi prevedere il riuso del codice quando
  //sviluppi con la logica OOP altrimenti non avrebbe senso
  private $username,$password,$errori,$login;
  
  public function __construct(){}

  private function checkInDB($user, $pass){
    if (!DB::connect("Nome_DB")) return DB::getError();
    $result = DB::execute("la tua query");
    .....
    return vero se c'è, falso se non c'è
  }

  private function valida(){}

  public function login(){
    if (!$this->valida())   return false;
    if($this->checkInDB($_POST['username'], $_POST['password'])
      header("Location: ./profile.php");
    else{
      $this->errori[] = "Ma che cacchio vuoi entrare se non puoi? ^_^"
      return false;
    }
  }

  public function getErrors(){}
} 

praticamente tu all'interno delle implementazioni non devi prevedere la stampa a video di nessuna informazione...devi fare in modo che ogni funzione restituisca un qualcosa. La stessa funzione getErrors, non deve stampare nulla, deve restituire una stringa di errori. è dal codice che invoca tali funzioni che devi prevedere la stampa del messagio di errore. Alcune funzioni critiche, come la connessione a una base di dati, devono prevedere dei sistemi di gestione delle eccezioni.

Detto ciò è probabile che io stia ancora dormendo, quindi se ho dimenticato qualcosa è "normale" ^_^. Il codice messo è una piccola dimostrazione di come lo svilupperei io e, ovviamente, per ragioni di sonno e tempo non è assolutamente completo

[Santino83_02]

senza il contesto difficile da definire.. se sei in una logica MVC, ad esempio, la classe è errata... poi a prescindere, tu dovresti avere una classe User con il metodo findByUSernamePAssword piuttosto che una classe esterna che interroga il database per cose inerenti all'user...

cmq senza contesto difficile dirti qualcosa

[SkyBlue]

Ah quindi se la riorganizzo così :
CLASSE DATI {} // CLASSE CHE CONTROLLA I DTI USER E PASS
CLASSE DB{} //CLASSE PER LA CONNESSIONE AL DATABASE
CLASSE LOGIN {} //CLASSE CHE SI OCCUPA DI RICHIEDERE AL DB IL LOGIN

Come starebbe ?

[SkyBlue]

scusate se vi riscrivo la struttura ma devo ancora imparare ad adattarmi al ragionamento con la oop

[Santino83_02]

Al limite

Login chiede ad un oggetto User/UserDAO se esiste un user con username e password passati

User/UserDAO attraverso classi DB apposite fa una query al db e ritorna un oggetto/array rappresentante l'user (o null se non trova nulla)

Login a seconda di quello che ritorna User/UserDAO fa o non fa la login

In tutto ciò non ho capito che cosa fosse $this->valida

[SkyBlue]

$valida è la variabile passata alla funzione controllo, senza la quale non si potrebbe effettuare un controllo su username e password...

[SkyBlue]

Senti, ma mi sapresti dire la mentalità da usare nella programmazione orientata ad oggetti ? in quanto da ciò che ho letto se non ho capito male, quando si programma con la OOP, tutte le funzioni grosse, tipo connessione al DB, Controlli, ecc...
vanno racchiuse in classi proprie che in futuro verranno se serve usate da sottoclassi con i dati che decido essere trasmissibili... giusto ?

[SkyBlue]

poi ho visto numerosi video con un sistema di login php in OOP e tutti differiscono tra di loro anche se lo scopo è identico,anche qui ho notato ciò, quidni deduco che non importa tanto quanto uno possa fare bene o male una script in php ci saranno sempre persone a cui va bene e male...

[oronze]

Lo scopo è identico ma l'architettura di un sistema non è sempre identica.
Con la programmazione ad oggetti, quelle che chiami funzioni grosse vanno racchiuse in classi proprie non perchè sono funzioni grosse ma perchè concettualmente appartengono a una sfera differente.....anche le funzioni da due righe vanno racchiuse in classi proprie. Poi dipende anche dal livello di astrazione che vuoi ottenere, dal grado di riuso del sw, dalle ipotetiche modifiche future....etc.
Ad esempio, ipotizziamo che vuoi realizzare un programma che faccia il caffè, quante classi individui (ovviamente tralasciando le implementazioni dei metodi ma inserendo i campi)?