Utilizzare metodi e proprietà di altre classi

[oly1982]

Originariamente inviato da whisher
ma non leggi quello che la gente scrive

Non ho certezze quando si parla di OOP

Originariamente inviato da oly1982
Sto iniziando a programmare ad oggetti

[oly1982]

Aspè... ma quando dici

"passi la classe Mysql.class.php nel costruttore della classe news"

qual "passi" è inteso come "imposti come parametro del costruttore"?

[Grino]

Originariamente inviato da oly1982
Ti ringrazio per la risposta solo che io cercavo una sorta di regola da applicare in senso iù generale...

Faccio un altro esempio:
poniamo che io mi costruisca un ulteriore classe per la validazione di dati:

class validate
      {
      public function is_email($string)
         {
         return preg_match(...);
         }
      public function is_url($string)
         {
         return preg_match(...);
         }
      public is_alfanumeric($string)
         {
         return preg_match(...);
         }   
      // etc etc
      } 

Ora io voglio eseguire un INSERT nel db di una nuova news...
Mi occorreranno all'interno della classe news:
- la connessione a mysql e le relative funzioni presenti nella classe
- le funzione per validare i dati in ingresso

Come è "corretto" fare; io... facendo smenettamenti vari sono in grado di farla funzionare...
ciò che invece mi preme capire è:
quel è il corretto modo di operare?

Secondo me, e di sicuro sbaglierò, non pensi agli oggetti. Il campo è l'oggetto, la validazione è un metodo che il campo esegue per verificare il proprio contenuto.

class cCampo{
    const kasURL=0;
    const kasMail=1;
    const kasTesto=2;    

    private $contenuto;
    private $tipo;

    public function  __construct($tipo=self::kasTesto) {
        $this->tipo=$tipo;
    }

    public function ContenutoGet(){
        return $this->contenuto;
    }

    public function ContenutoSet($contenuto){
        $this->contenuto=$contenuto;
        if(!$this->Valida())
            throw new Exception("Contenuto campo non corretto");                
    }
    
    public function TipoSet($tipo=self::kasTesto){
        $this->tipo=$tipo;
    }

    public function TipoGet(){
        return $this->tipo;
    }

    protected function Valida(){
        switch ($this->tipo) {
        case self::kasURL:
            return ...
            break;
        ...
        default:
        throw new Exception("Tipo validazione non gestita");
            break;
        }
    }
}

Nella tua classe news avrai un certo numero di oggetti di classe cCampo. come puoi vedere dal codice la validazione è spontanea nel momento in cui assegni un valore al campo. Il tipo di dato definito dal campo lo specifichi nel costruttore. Nel caso in cui passi un contenuto non coerente con il tipo la classe solleva una eccezzione.

In generale tutte le variabili in una classe dovrebbero essere private, eccezionalmente possono essere protected, quando ad ad esempio i discendenti hanno necessita di accedere in modo diretto alla variabile (se possibile da evitare), da evitare le variabili public. La classe dovrebbe esporre solo dei metodi e nascondere i propri dati (incapsulamento) sui quali occorre agire tramite i metodi che la classe offre. Esistono poi i metodi di accesso, tipicamente Get e Set che conentono di impostare dei valori in varibili della classe ma mai dare acceso diretto alla variabile.

Ad esempio, se nel costruttore vuoi consentire di settare il contenuto del campo, dovresti richiamare all'interno del costruttore stesso il metodo ContenutoSet e non accedere direttamente alla variabile anche se disponibile. in questo modo ottieni due risultati:
1) hai già implementato il controllo sul contenuto perchè integrato nella set
2) se aggiorni il metodo set, perchè memorizzi in modo differente i dati ti trovi già tutto il codice aggiornato
questo perchè hai fatto lavorare metodi e oggetti e non le variabili.

Perchè la funzione valida è protected? Perchè un giorno potresti voler estendere la tua classe e defnire nuove funzionalità di controllo per nuovi tipi. dovresti semplicemente ridefinire la funzione di validazione e se il tipo non è gestito nella nuova funzione richiamare il parent::valida

Questo per dire due cosine, ma c'è molto di più.

[Grino]

Ti faccio ancora un esempio e poi mi fermo. Diciamo che un bel giorno decidi di gestire dei campi data ma non vuoi manomettere la classe cCampo ancora si guasta ciò che funziona. Decidi allora di estendere (ereditarietà) la classe cCampo e di creare la classe cCampoData

class cCampoDate extends cCampo{
    const kasData=100;
    
    public function  __construct() {
        parent::__construct(self::kasData);
    }
    
    public function  ContenutoSet($contenuto) {
        $oData=new DateTime($contenuto);
        parent::ContenutoSet($oData);
    }
    
    public function  ContenutoGet() {
        $oData=parent::ContenutoGet();
        return $oData->format("d-m-Y");
    }
    
    protected function Valida(){
        return true;
    }
}

Il costruttore è semplificato perchè gioca subito sul nuovo tipo essendo una classe specializzata. Ridefinisci contenuto set in modo da memorizzare un oggetto DateTime piuttosto che una stringa. Quando si cerca di accedere alla data con contenutoget ti torna indietro una data in formato umano. Quando il Parent::ContenutoSet invoca il valida che ha al suo interno nella superclasse, viene in realtà invocato il valida della classe cCampoData e non quello di cCampo (polimorfismo). La funzione valida ti ritorna direttamente true, perchè se a contenutoset viene viene passato un valore non appropriato il costruttore DateTime genera una eccezione.

Con questi due esempi hai avuto esempio di incapsulamento, polimorfismo ed ereditarietà.

[oly1982]

Originariamente inviato da Grino
Secondo me, e di sicuro sbaglierò, non pensi agli oggetti.

non sbagli... tieni presente che ho iniziato 5 giorni fa!

Solo avendo acquisito una discreta abilità nella produzione di codice procedurale pensavo fosse stato meno indolore il passaggio alla programmazione ad oggetti... ed invece...

[las]

Originariamente inviato da whisher
in soldoni scartando extends (perchè come soluzione è poco elastica)

cosa intendi? io estendo sempre la classe di connessione sulle altre a che problemi/limitazioni posso andare incontro?

[oly1982]

Grino mi hai dato importanti input per iniziare a capirci qualcosa. Credo di aver trovato anche un buon tutorial per beginner:

http://www.killerphp.com/tutorials/o...lerphp.com.pdf

ora cerchèerò di produrre qualcosa e lo posterò qui così da vedere se sono sulla strada giusta... quindi a presto...

[Santino83_02]

Originariamente inviato da las
cosa intendi? io estendo sempre la classe di connessione sulle altre a che problemi/limitazioni posso andare incontro?

niente niente ha detto una cosa vera ma riportandola in maniera inesatta.. estendi pure la classe di connessione don't worry

[oly1982]

Originariamente inviato da Santino83_02
niente niente ha detto una cosa vera ma riportandola in maniera inesatta.. estendi pure la classe di connessione don't worry

e potresti dirci la cosa vera riportandola in maniera esatta?

[Santino83_02]

Originariamente inviato da oly1982
e potresti dirci la cosa vera riportandola in maniera esatta?

che "estendere" una classe porta come limitazione che il sottotipo (ovvero chi estende) non potrà estendere direttamente piu nient'altro. L'inesattezza è definire "limitazione" questa caratteristica quando in realtà è usatissima e serve per risolvere problemi ben specifici