Pagina 5 di 7 primaprima ... 3 4 5 6 7 ultimoultimo
Visualizzazione dei risultati da 41 a 50 su 66
  1. #41
    Originariamente inviato da LeaderGL
    Sono daccordo, però è anche vero che una buona programmazione ad oggetti prevede l'uso di vari pattern e l'applicazione della giusta strategia per risolvere i vari problemi; questo significa che bisognerebbe fare un minimo di fase di analisi del problema, però senza conoscere niente della programmazione ad oggetti è difficile fare un ragionamento di questo tipo.

    Credo possa essere più utile in questa fase prendere dimestichezza con gli elementi fondamentali della programmazione ad oggetti: le classi, i vari modificatori, un po di separazione (concetti di coesione ed accoppiamento), qualche minimo pattern.

    Una volta che si prende dimestichezza allora si potrà ragionare con più consapevolezza su nuove tecniche e su quale sia la strada giusta.

    Almeno secondo me
    si ok d'accordo, allora è inutile continuare a parlare: gli si da il link del corso di fondamenti di informatica di qualsiasi facoltà di ing. informatica/informatica e gli si dice "parti da qui e poi ritorna quando sai quello di cui vuoi parlare"... oppure si sceglie il pattern piu semplice possibile (a mio avviso, il dao) e glielo si spiega. però, andare a spiegare nel dettaglio implementativo un pattern ad una persona che di classi e oggetti non conosce neanche la differenza, è una cosa mooooolto lunga se non impossibile. Non si può partire da scalare l'everest se non si è mai andati in montagna. Ormai questo 3D è OT da troppe pagine secondo me, tutto qua
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  2. #42
    io sto seguendo l'approccio suggeritomi da grino... ma ancora non ho finito... sono work in progressi perchè mi sto studiando tutto man mano che lo incontro...

    Vi faccio vedere a che punto sono... nn rimuovo i commento così capite anche il modo in cui sto lavorando:

    DAOFactory
    Codice PHP:
    <?php
    /*
    Questa classe mi servirà:
    1) per selezionare fra i vari disponibili la base dati da cui attingere
    2) "vincola" tramite la definizione di metodi astratti le classi che saranno sua estensioni
        +----------------------+
        |  TEORIA -> ABSTRACT  |
        +----------------------+
        Una classe deve essere astratta quando contiene al suo interno metodi astratti.
        Essa non può essere istanziata.
        
        I metodi astratti sono un'imposizione sull'implementazione successiva della classe e sono senza corpo.
        Cioè le classi "figlie" (extends) dovranno contenere necessariamente i metodi che nella classe "padre"
        (in questo caso la sottoscritta) sono stati dichiarati come astratti ripettando il nome e i parametri.
        
        Le classi astratte pertanto svolgono un ruolo di "progettazione", "coordinamento", "uniformazione" soprattutto
        nel caso in cui una classe dovrà avere numerosi extends.
        Una classe astratta, pertanto, "prevede" necessariamente delle sottoclassi e tali sottoclassi dovranno 
        necessariamente definire i metodi dichiarati come astratti.
        
    */
    abstract class DAOFactory
        
    {
        
    /*lista dei db disponibili*/
        
    const MYSQL 1;
        
    //const ORACLE = 2;
        //const SYBASE = 3;

        /*
        definiamo i metodi previsti dalle classi figlie
        ovvero tutte le classi che potrò creare in futuro
        che necessiteranno di un db come fonte per i loro dati
        */
        
    public abstract function getArticoloDAO();
        
    //public abstract function getCommentiDAO();
        //public abstract function getUtentiDAO();
        
        /*
        Le classi sopra elencate avranno bisogno di un db... quale?
        prego scelga pure...
        */
        
    public static function getDAOFactory($scelta_db)
            {
            switch (
    $scelta_db)
                {
                case 
    self::MYSQL:
                    return new 
    MysqlDAOFactory();
                
    /*case self::ORACLE:
                    return new OracleDAOFactory();
                case self::SYBASE:
                    return new SybaseDAOFactory();*/
                
    default:
                    return 
    null;
                }
            }
        }
    ?>
    MysqlDAOFactory
    Codice PHP:
    <?php
    /*
    La classe astratta DAOFactory ha prescelto (... tra i tantissimi disponibli...) MYSQL 
    e ha "imposto" (in virtù dei metodi astratti) ai suoi extends di implementare un metodo 
    per ogni classe che richiede il sorgente dati.

    Se Mysql viene interpellato per poter avviare qualsivoglia operazione bisognerà connettersi. 
    Quando nella pagina web faremo:

    $MySQLFactory = DAOFactory::getDAOFactory(DAOFactory::MYSQL);
    $artDAO = $MySQLFactory->getArticoloDAO();

    Nella prima riga:
    - scegliamo il db con il metodo statico getDAOFactory della classe DAOFactory
    - scegliamo MYSQL tramite proprietà statica ovvero istanzio MysqlDAOFactory

    Nel second rigo:
    - istanzio la classe ArticoloMysqlDAO attraverso il metodo getArticoloDAO

    */

    class MysqlDAOFactory extends DAOFactory
        
    {
        private static 
    $host 'localhost';
        private static 
    $user 'root';
        private static 
    $pass '';
        private static 
    $db   'my_test';
        private static 
    $conn null;

        
    /*metodo per creare una connessione a MySQL*/
        
    public static function createConnection()
            {
            
    /*
            non eseguiremo la connessione tutte le volte che faremo una query (ovviamente...)
            quindi se è NULL, cioè il valore di default, eseguaimo la connessione che sarà 
            contenuta da self::$conn (è static!! non fare $this->conn che da errore)
            */
            
    if (is_null(self::$conn))
                {
                if (!(
    self::$conn = @mysql_connect(self::$hostself::$userself::$pass)))
                    {
                    throw new 
    Exception(mysql_error());
                    }
                if (!@
    mysql_select_db(self::$db))
                    {
                    throw new 
    Exception(mysql_error());
                    }
                }
            return 
    self::$conn;
            }

        
    /*
        Istanziamo la classe che contiene le query a mysql 
        riguardanti gli articoli
        */
        
    public function getArticoloDAO() 
            {
            return new 
    ArticoloMysqlDAO();
            }
        }
    ?>
    interfaccia_Articolo_DAO.php
    Codice PHP:
    <?php
    /*
    Interaccia della classe ArticoloDAO.
    Il nostro applicativo potrà essere sviluppato con diversi db (se se...).
    Per ciascun db vi saranno diverse sintassi e funzioni native per ricavare i dati.
    Tuttavia definendo nell'interfaccia il nome che dovranno avere i metodi presenti 
    nelle successive implementazioni si determina che il nome dei metodi per ogni tipo 
    di db sarà sempre lo stesso.
    Quindi swichando in sede di istanza tramite getDAOFactory tutto rimane integro e funzionante.

        +-----------------------+
        |  TEORIA -> INTERFACE  |
        +-----------------------+
        Contiene una serie di metodi con i relativi parametri, ma senza corpo.
        L'interfaccia impone l'implementazione di tutti i metodi in essa definiti 
        tramite una successive classi 'implements'.
        
        A differenza delle classi/metodi astratti nelle interfacce nessun metodo ha un corpo. 
        Quindi le interfacce possono (in un certo senso) assomigliare a classi astratte ma con
        al loro interno tutti metodi astratti.
        
        Infatti, tutti i metodi definiti nelle interfacce implicano che si tratta di metodi astratti
        e che, pertanto, occorre necessariamente che nella successive classi 'implements' tali metodi
        vengano implementati.
        
        La differenza fra le due è molto sottile: mentre l'interfaccia è un progetto per classi che 
        saranno tutte su uno stesso livello gerarchico, fra le classi astratte e le extends che ne derivano
        vi è un rapporto di tipo gerarchico.
    */
    interface ArticoloDAO
        
    {
        public function 
    insertArticolo($oArticolo);
        public function 
    deleteArticolo($oArticolo); 
        public function 
    findArticolo($oArticolo);
        public function 
    updateArticolo($oArticolo); 
        public function 
    selectArticoloRS($oArticolo);
        public function 
    getNextArticoloTO($RowSet);
        public function 
    selectArticoloTO($oArticolo);
        }
    ?>
    Articolo.php
    Codice PHP:
    <?php 
    class Articoli 
        
    /*le proprietà coincidono coincidono con i campi del db*/ 
        
    protected $id_art
        protected 
    $titolo_art
        protected 
    $testo_art
        protected 
    $data_inserimento

        
    /*serie di metori set e get per impostare/ottenere il valore di tali proprietà*/ 
        
    public function getId_art()  
            { 
            return 
    $this->id_art
            } 

      
        public function 
    setId_art($id_artIn)  
            { 
            
    $this->id_art $id_artIn
            } 

        public function 
    getTitolo_art()  
            { 
            return 
    $this->titolo_art
            } 
       
        public function 
    setTitolo_art($titolo_artIn)  
            { 
            
    $this->titolo_art $titolo_artIn
            } 

        public function 
    getTesto_art() 
            { 
            return 
    $this->testo_art
            } 
      
        public function 
    setTesto_art($testo_artIn
            { 
            
    $this->testo_art $testo_artIn
            } 

        public function 
    getData_inserimento() 
            { 
            return 
    $this->data_inserimento
            } 

        public function 
    setData_inserimento($data_inserimentoIn)  
            { 
            
    $this->data_inserimento $data_inserimentoIn
            } 
        } 
    ?>

  3. #43
    il pattern DAO l'avevo suggerito iooooooooooo


    e cmq getData_inserimento non se pò vede... getDataInserimento molto meglio
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  4. #44
    ... si si si... ...

    RETTIFICO:
    sto seguendo il consiglio di SANTINO e l'esempio di GRINO... ok?

  5. #45
    uhm...ok, seguiamo la vostra strada però il codice che vedo non mi fa sperare bene.

    alcuni appunti/correzioni:
    [list=1][*]una classe che implementa il pattern factory non credo debba conoscere cose come:
    /*
    definiamo i metodi previsti dalle classi figlie
    ovvero tutte le classi che potrò creare in futuro
    che necessiteranno di un db come fonte per i loro dati
    */
    public abstract function getArticoloDAO();
    la tua classe "DAOFactory" deve solo fornirti l'istanza del giusto gestore della persistenza dei dati.
    Quindi ti serve solo il metodo statico: getDAOFactory($scelta_db)
    [*]la classe MysqlDAOFactory non vedo perchè dovrebbe essere una estensione della classe factory, ereditando quindi da essa il pattern. La classe MysqlDAOFactory (che rinominerei in MysqlDAO) deve fornire l'implementazione dei metodi di accesso al db, meglio se per fare questo implementi una apposita inferfaccia che la obblighi ad esibire determinati metodi; questo per fare in modo che tutte la classi che gestiranno la persistenza (mysql, oracle, etc) sia obbligate a fornire almeno gli stessi metodi di base (questo volendo può essere fatto anche estendendo una classe astratta)
    [*]sempre la classe MysqlDAOFactory non ha alcun motivo per possedere dei metodi che la legano agli articoli...altrimenti non è più MysqlDao_qualcosa:
    /*
    Istanziamo la classe che contiene le query a mysql
    riguardanti gli articoli
    */
    public function getArticoloDAO()
    {
    return new ArticoloMysqlDAO();
    }
    }
    questa classe ti deve solo servire per le operazioni sul db. Per la strada che hai scelto qualora tu decidessi che oltre agli articoli ti servono: blog, downloads, review, news, altro vorrebbe dire che in mysqldao devi metterci tutta questa roba; devi fare in modo che quando crei una classe questa sia a se stante dal resto del progetto...deve dipendere quanto meno possibile. sopratutto se è la classe che accede al db.
    [*]l'interfaccia ArticoliDAO va bene, anche se bisogna vedere come hai in mente di utilizzarla[*]nella classe "Articoli" ho qualche perplessità sulle funzioni che settano l'ID; il campo ID dovrebbe essere un campo univoco associato bene o male al database sottostante...perchè dovresti variarne arbitrariamente il contenuto? quando poi vai a salvare sul db queste modifiche sei sicuro che funzionerà in ogni situazione? [/list=1]
    Administrator of NAMDesign.Net

  6. #46
    Leader rileggiti il pattern dao prima

    nel breve, hai una Entity nel db... da quella fai un Model, poi farai un'interfaccia ModelDAO con i metodi per usare il dao, poi farai le implementazioni dell'interfaccia, e per ottenere le implementazioni, farai una factory DAOFactory con metodi che ritornano i vari dao. nel concreto, la daofactory ritornerà le interfacce dao implementate.

    quindi se hai mysql/postgres/mssql/hibernate/filemaker/sqllite/etc, ti basta cambiare nella daofactory(o nel file properties dell'applicativo) quale implementazione usare e il gioco è fatto...figaggine
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  7. #47
    Originariamente inviato da Santino83_02
    Leader rileggiti il pattern dao prima

    nel breve, hai una Entity nel db... da quella fai un Model, poi farai un'interfaccia ModelDAO con i metodi per usare il dao, poi farai le implementazioni dell'interfaccia, e per ottenere le implementazioni, farai una factory DAOFactory con metodi che ritornano i vari dao. nel concreto, la daofactory ritornerà le interfacce dao implementate.

    quindi se hai mysql/postgres/mssql/hibernate/filemaker/sqllite/etc, ti basta cambiare nella daofactory(o nel file properties dell'applicativo) quale implementazione usare e il gioco è fatto...figaggine
    Quindi sto seguendo la strada giusta?... please...

  8. #48
    si boh mi pare ad un'occhiata veloce mi pare di aver visto tutte le classi che servono o almeno quasi tutte... se stai seguendo il link che ti avevo mandato sul pattern dao, stai facendo bene
    IP-PBX management: http://www.easypbx.it

    Old account: 2126 messages
    Oldest account: 3559 messages

  9. #49
    Originariamente inviato da Santino83_02
    Leader rileggiti il pattern dao prima

    nel breve, hai una Entity nel db... da quella fai un Model, poi farai un'interfaccia ModelDAO con i metodi per usare il dao, poi farai le implementazioni dell'interfaccia, e per ottenere le implementazioni, farai una factory DAOFactory con metodi che ritornano i vari dao. nel concreto, la daofactory ritornerà le interfacce dao implementate.

    quindi se hai mysql/postgres/mssql/hibernate/filemaker/sqllite/etc, ti basta cambiare nella daofactory(o nel file properties dell'applicativo) quale implementazione usare e il gioco è fatto...figaggine
    La confusione la state facendo quando avete messo nel mezzo anche il patter factory.
    Di base il "Pattern DAO" prevede la creazione di 3 file:
    - una classe che rappresenta l'oggetto da gestire (Articolo)
    - una interfaccia che definisce le operazioni effettuabili sull'oggetto (ArticoloDAO)
    - una classe che implementa l'interfaccia di sopra e fornisce metodi specifici per effettuare quelle operazioni su un determinato database (MySQL_ArticoloDAO)

    il vostro problema è che mettendoci di mezzo il "Pattern Factory" per gestire "più tipi di database" avete fatto un po di confusione ed avete mischiato un po i due pattern.

    Cose come questa:
    Codice PHP:
    abstract class DAOFactory
    {
        const 
    MYSQL 1;
        const 
    ORACLE 2;
        const 
    SYBASE 3;

        public abstract function 
    getArticoloDAO();
        public abstract function 
    getCommentiDAO();
        public abstract function 
    getUtentiDAO();
        
        public static function 
    getDAOFactory($scelta_db)
        {
            switch (
    $scelta_db)
            {
                case 
    self::MYSQL:
                    return new 
    MysqlDAOFactory();
                
    /*case self::ORACLE:
                    return new OracleDAOFactory();
                case self::SYBASE:
                    return new SybaseDAOFactory();*/
                
    default:
                    return 
    null;
             }
         }

    non hanno alcun senso.

    Ti stai mettendo nella condizione che:
    1) qualora volessi riutilizzare il tuo codice non puoi farlo
    2) ogni volta che aggiungi un "componente" (o "modulo", tipo gli articoli) ti devi andare a modificare la tua "DAOFactory" e le varie [Mysql|Oracle|Sybase]DAOFactory.....molto male.

    ...spero di essermi chiarito...almeno un po
    Administrator of NAMDesign.Net

  10. #50
    ok... se manco i guru sanno la best pactices diventa veramente difficile...

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 © 2026 vBulletin Solutions, Inc. All rights reserved.