Visualizzazione dei risultati da 1 a 6 su 6
  1. #1

    Dubbi gestione delle classi in php

    Buonasera a tutti, sono entrato nel mondo dell'OOP da poco, e sto sviluppando il mio primo progetto con questo nuovo approccio.
    A tal proposito purtroppo, sono abbastanza incerto su come impostare questa situazione che vi vado a descrivere:

    Ho una classe User con relativi metodi:
    create();
    login();
    update();
    delete();
    etc..

    Poniamo di avere anche una classe Game ( inteso come partita ), con relative classi:
    create();
    update();
    delete();
    etc..

    Vorrei creare un metodo che permetta all'utente di "iscriversi" alla partita.
    La mia domanda è: questo metodo lo devo ( a livello logico )..
    A) inserire nella classe User ( perchè è l'utente che "entra" nel game ), per esempio come enterGame()
    B) inserire nella classe Game ( perchè è il game che "fa entrare" l'utente ), per esempio come insertPlayer();

    E' qualche giorno che ci sbatto la testa contro, onestamente ho valutato anche la situazione attributi, ma ho convenuto che nel caso A avrei tutti gli attributi dell'utente già loggato, e mi basterebbe passare alla function l'id del game per effettuare la query di inserimento.
    Allo stesso modo nel caso B avrei l'id del game, e mi basterebbe comunque passare un array dei dati che mi interessa andare a piazzare nella query.
    In sostanza, guardando il lato variabili, non ne vengo molto fuori

    Concettualmente, il ragionamento che faccio da niubbo è che è l'utente che compie l'azione di iscriversi, e sarei quindi orientato a preferire il metodo A. Così facendo capisco bene però che in un sistema dove il protagonista è l'utente, se facessi tutto con questo ragionamento, mi basterebbe la classe User, e quindi il concetto di OOP andrebbe un pò a farsi benedire..

    Un altro dubbio amletico che mi pongo riguarda una questione ancora più generica, anche qui trovando difficile porvi la questione "a parole" ve la sottopongo con un esempio pratico.
    Voglio creare un metodo per l'invio di messaggi privati tra utenti: quale approccio è più "corretto"?
    A) creo una classe messaggioPrivato con metodo create() e passo al costruttore l'id dell'utente che lo deve inviare. Creerò anche il metodo send() a cui passerò l'id del destinatario, il messaggio, token di sicurezza etc etc.
    B) creo un metodo nella classe User, tipo sendPvt() a cui passo l'id del destinatario, token e messaggio ( non l'id del mittente, perchè essendo l'user loggato lo recupero tramite attributo ).

    Grazie molte a chi vorrà aiutarmi a districare i miei dubbi, sottoponete pure questioni e approcci diversi, sono aperto ad ogni consiglio anche perchè l'OOP, ad occhio, mi sembra un mondo dove le interpretazioni sono comunque legittime Grazie!

  2. #2
    Risposta breve:
    Farei una classe terza con metodo "addUserToGame" a cui passi l'user e il game e fa tutte le operazioni del caso

    Risposta lunga:
    User e Game immagino abbiamo una relazione molti a molti tra di loro, quindi sia User che Game dovrebbero avere una proprietà a testa che identifichi tale relazioni. In particolare, User avrà una collezione di oggeti Game salvati in $games (un utente potrà essere iscritto a molti Game) e un Game avrà una collezione di oggetti User salvati in $users (Un game ha molti utenti iscritti). Quindi user avrà i metodi setGames/getGames/addGame/removeGame e Game avrà i metodi setUsers/getUsers/addUser/removeUser per gestire tale associazione (che poi i metodi add*/remove* in una delle due classi potrebbero anche non esserci). Persistendo l'oggetto User o l'oggetto Game (e qui devi scegliere te quale lato usare come master), grazie a getGames/getUsers salverai la relazione. Visto a Controller:

    Codice PHP:
    class UserController{

    ...

    function 
    iscriviUtenteAGame($user_id,$game_id)
    {
         
    $user = ...; //ripesco l'utente dal db
         
    $game = ...; //ripesco il game dal db
       
         
    $user->addGame($game);
         
    $user->save();

    }
    ...

    in un GameController:

    Codice PHP:

    class GameController{

    ...

    function 
    iscriviUtenteAGame($user_id,$game_id)
    {
         
    $user = ...; //ripesco l'utente dal db
         
    $game = ...; //ripesco il game dal db
       
         
    $game->addUser($user);
         
    $game->save();

    }
    ...

    Poi tutto il discorso dipende dal tuo model e da come lo usi
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  3. #3
    Premesso che dovresti leggere: http://en.wikipedia.org/wiki/SOLID_%...nted_design%29 e approfondire

    Per risponderti ci vorrebbero ore di tempo..

    Vorrei creare un metodo che permetta all'utente di "iscriversi" alla partita.
    dovresti avere una classe che prende l'utente e il gioco ed effettua l'iscrizione..

    Codice PHP:
    class Subscriber {

     public function 
    __construct$game$user ) {
     }

     public function 
    subscribe() {
     }

    Non aver paura di creare classi....!!!

    Voglio creare un metodo per l'invio di messaggi privati tra utenti: quale approccio è più "corretto"?
    troppo generico
    Questa volta, più che un voto.. è favoreggiamento.

  4. #4
    Grazie ad entrambi per le risposte
    Vedo che entrambi proponete una soluzione 3° classe, ma concettualmente parlando quello che proponete non è più un interfaccia o una classe astratta?
    Mi rendo conto di essere sicuramente molto più legato a quello che ho studiato rispetto a voi che avete ovviamente più esperienza.. la butto lì: stiamo parlando di interfaccia/classe astratta ma per praticità bypassiamo la dichiarazione come tale e la creiamo invece come class?

    Da quello che dite mi rendo conto di essere stato troppo, decisamente troppo conservativo sulla creazione delle classi. Ho chiaramente estremizzato la semplicità della faccenda, ho altri funzioni che l'utente deve fare e non riguardano solo Games ma anche per esempio Groups o Auctions.. ma con questo nuovo modo di approcciare al problema, creando un controller che "colleghi" le due o più classi interessate penso di poterne venire a capo più facilmente.

    Studierò iper volentieri il SOLID, da una lettura della pagina wiki mi sembra un approccio che può aiutare molto a schiarirsi le idee.
    Diciamo che per farla breve ho sviluppato delle macro classi ( tra l'altro enormi anche a livello di righe di codice ) senza sviluppare classi "ponte" che collegassero le macro..

    Usando dei controller non rischio però di trovarmi con la macro classe che nella pratica non fa quasi nulla?
    Mi spiego:

    Creo class PM, e definisco gli attributi necessari per esempio $sender, $recipier, $text etc...
    Creo poi una class PMController, definendo i metodi send(); update(); delete(); read(); etc..

    Che metodi potrei mai inserire all'interno della classe PM se è il controller che me li gestisce?

    Al_katraz984 invece se non capisco male tu proponi una soluzione più "action" rispetto al controller, del tipo creare le classi:
    class SendPM,
    class UpdatePM,
    etc etc etc

    Ho capito male? O forse anche Santino intendeva la stessa cosa ma il nome della classe mi ha portato fuori strada facendomi pensare a un controller generico anzichè ad uno "dedicato" allo scopo dell'iscrizione dell'utente alla partita?

  5. #5
    Ho capito male? O forse anche Santino intendeva la stessa cosa ma il nome della classe mi ha portato fuori strada facendomi pensare a un controller generico anzichè ad uno "dedicato" allo scopo dell'iscrizione dell'utente alla partita?
    credo che santino intendesse la stessa cosa è che non mi ha letto nella mente, o io non ho letto nella sua e abbiamo scritto 2 nomi diversi

    Quote Originariamente inviata da lordsabbath Visualizza il messaggio
    Grazie ad entrambi per le risposte
    Vedo che entrambi proponete una soluzione 3° classe, ma concettualmente parlando quello che proponete non è più un interfaccia o una classe astratta?
    proviamo a mescolare le due soluzioni:
    Codice PHP:
    interface Registrable {
     public function 
    registerUser $user );
    }

    class 
    GameSubscriber {

     public function 
    __constructUser $user ) {
      
    $this->user $user;
     }

     public function 
    iscriviUtenteAGameRegistrable $game ) {
       return 
    $game->register$user );
     }

    Si può applicare un interfaccia se vuoi, la classe astratta non centra niente però

    Studierò iper volentieri il SOLID, da una lettura della pagina wiki mi sembra un approccio che può aiutare molto a schiarirsi le idee.
    Diciamo che per farla breve ho sviluppato delle macro classi ( tra l'altro enormi anche a livello di righe di codice ) senza sviluppare classi "ponte" che collegassero le macro..
    classi piccole e che soddisfano 1 sola operazione, non sempre è il miglior approccio ma puoi trovare un giusto compromesso


    Usando dei controller non rischio però di trovarmi con la macro classe che nella pratica non fa quasi nulla?
    Mi spiego:

    Creo class PM, e definisco gli attributi necessari per esempio $sender, $recipier, $text etc...
    Creo poi una class PMController, definendo i metodi send(); update(); delete(); read(); etc..

    Che metodi potrei mai inserire all'interno della classe PM se è il controller che me li gestisce?

    Al_katraz984 invece se non capisco male tu proponi una soluzione più "action" rispetto al controller, del tipo creare le classi:
    class SendPM,
    class UpdatePM,
    etc etc etc
    ecco non esagerare troppo devi definire le classi che servono con i metodi che servono a seconda dello scopo che ha la tua applicazione. Piu sei SOLID piu sei avvantaggiato ma questo non significa che bisogna fare 1 classe per qualunque cosa
    Questa volta, più che un voto.. è favoreggiamento.

  6. #6
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,316
    Quote Originariamente inviata da Al_katraz984 Visualizza il messaggio
    ot/ quali sono i nomi degli standard utilizzati per progettare oop "correttamente"?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.