Help OOP Inizio

[michelepi]

Qualche anima buona che mi dice se come approccio va bene?
Classe padre db mi serve per connessione
La estendo per il login come segue

<?php
require_once("class_db.php") ;
class login extends db_con{


  function login($campouser,$campopw,$campodb,$campodb1,$campodb2,$sesutente,$valsesutente,$nomevarses,$valorevarses,$nometabella){
//tralascio qui le variabili che nelle mie prove ci sono logicamente
            /*richiamo metodo costruttore class_db che avvia connessione*/
           parent::db_con() ;

          
           /*lancio metodo che conta righe nel db per il login*/
           $this->get_login() ;



           }

[maje]

Io implementerei una classe che gestisce la connessione al DB, proprio come hai fatto. Invece però di estenderla per implementare il login sarebbe meglio che nella classe login tu creassi una istanza della classe DB che ti restituisca ad esempio la connessione al DB da usare per effettuare il login.

Intendo una cosa di questo tipo:

<?php class Database() {
    
//costruttore
public Database () {}

private $userDB = "blabla";
private $passDB = "blabla";
private $nomeDB = "blabla";

//altri metodi di gestione
...
} ?>

<?php class Login() {
    
$dbObject = new Database();
$connessione = $dbObject.getConnection();
} ?>

E' solo per darti l'idea, quindi non ti soffermare sui nomi delle classi o degli oggetti (anche perchè li ho sparati a caso )

Sull'oggetto $dbObject potresti eseguire tutte le query del caso, scrivendo metodi che implementano ad esempio delle SELECT specifiche o delle INSERT.

[michelepi]

Ok grazie, mi serve per capire se sto muovendomi bene o rinunciare all'OOP

Io ho ragionato così perchè inserendo nel costruttore della classe DB la connessione e nel costruttore della classe login richiamo il metodo della connessione risparmio un paio di righe.


Logicamente la classe va inclusa?

<?php class Login() {

$dbObject = new Database();
$connessione = $dbObject.getConnection();

$connessione = $dbObject.getConnection(); SI PUò METTERE ANCHE IL PUNTO??
} ?>

[maje]

scusa, il punto è una reminiscenza java!

Sì per usarla dovresti includerla, in un modo o nell'altro. A meno che non utilizzi dei sistemi più sofisticati di autoloading, come succede ad esempio in Zend Framework.

Diciamo che per fare le cose fatte proprio proprio bene dovresti utilizzare dei design pattern per l'ottimizzazione e per implementare una architettura più manutenibile (come ad esempio il Factory o il Singleton).

[Santino83_02]

Login generalmente non è un modello, è un'azione, pertanto piu che usare una classe che estende un database o comunque una fonte dati, userei una classe che estende un controllore. Per maggiori info: http://it.wikipedia.org/wiki/Model-View-Controller

[michelepi]

Seeeeeeee io vi dico che sono all'inizio, praticamente pianeta terra, e voi mi catapultate sulla luna così.

Scherzo, il problema è che tutti i concetti espressi da voi sono troppo avanti per me.

E' interessante però il discorso sulla manutenzione del sito, sembrerebbe che + si vada avanti con la OOP e + sia gestibile l'applicazione.

[Santino83_02]

Originariamente inviato da michelepi E' interessante però il discorso sulla manutenzione del sito, sembrerebbe che + si vada avanti con la OOP e + sia gestibile l'applicazione.

togli il sembrerebbe.... nella OOP due cose sono fondamentali (per la manutenzione): che l'OOP sia fatta come si deve, e che ci sia tanta documentazione nel codice... senza questi due accorgimenti, tra oop e scripting classico c'è ben poca differenza....

comunque programmare ad oggetti prescinde il linguaggio utilizzato, quindi se veramente vuoi imparare ti suggerisco di prenderti uno o piu libri (possibilmente di livello universitario, non cose tipo "OOP 4 Dummies") e studiare la teoria. Senza teoria, non si va mai da nessuna parte. Poi la pratica la fai parallelamente al libro col php o con quello che ti pare

Tornando a noi, se non strutturi tutto il sito a oggetti (magari usando MVC appunto) è inutile fare login come oggetto... anche perchè concettualmente sbagliato a mio avviso... però puoi cominciare a usare il db e le tabelle del db in maniera migliore:

nella versione piu semplice, dovresti fare una classe DbConnection che sia capace di compiere le operazioni piu comuni sul database. Per comuni non intendo particolari al tuo programma (vedi quel get_login() che hai usato te che è errato perchè non è un'operazione standard del database ma una tua particolarità rispetto all'azione "login"), ma azioni comuni che tu puoi compiere nel database: le CRUD (Create [add], Read [select], Update, Delete), varie info tipo getLastInsertID, apertura/chiusura connessione, gestione delle transazioni, numero di righe che la query ha interessato etc...

Poi hai un database con tante tabelle dentro... ogni tabella all'incirca rappresenta un modello del dominio: ad esempio in un gestionale di calcio ci può essere la tabella Squadre, la tabella Giocatori, la tabella Allenatori... ognuna rappresenta nell'applicazione un'entità (spesso concreta nella realtà) che funge da rappresentazione dei dati di interesse all'applicazione e hanno dei metodi utili all'applicazione. Nel tuo caso, avrai immagino nel database una tabella Utenti...quello sarà il tuo model

quindi potresti fare una classe Utente che estende DbConnection. in questo modo dovresti arrivare ad ottenere che una funzione del tipo Utente::findAll() ti riporti un elenco (array?) di oggetti(?) Utente ognuno rappresentante una riga della tabella Utenti, oppure che Utente::delete($id) cancelli l'utente con l'id passato, o che Utente::findByUsername($username) ritorni l'utente associato a quell'username, etc etc etc

a quel punto nella tua app la procedura di login diventerebbe:

if(isset($_POST)){ //è stato fatto il submit del form di login

$username = $_POST['uname'];
$password = $_POST['passwd'];

//.... some checks
//....

$user = Utente::findByUsername($username);

if(!$user) //utente inesistente

if($user->getPassword() != $password) //wrong password

//tutto ok
//DO LOGIN


} 

o qualcosa del genere, dipende da come uno realizza le cose....

Realizzare da 0 cmq è complicato, soprattutto se manca l'esperienza... una cosa buona e giusta, a parte studiare, è usare intanto framework di terze parti e imparare ad usarli, cercando di capire quali sono le problematiche che il framework risolve (o amplifica a seconda dei framework) e come si lavora in un contesto ad oggetti, poi magari se si ha voglia uno prova a farsene uno homemade.