[php5]Classi annidate

[fatmatt]

Salve a tuttti

Ho una situazione del genere:

 class miaclasse
 {
public function metodo()
    {
         //CODICE
    }
 }

 class b
 {
    public $attributo;
    public function __construct()
    {
      $this->attributo = new miaclasse();
    }
     public funnction faiQualcosa()
    {
      $this->attributo->metodo() 
   }
 } 

perchè quando provo ad utilizzare il metodo "metodo" , l'interprete si lamenta del fatto che richiamo ->metodo() da un non-object? voglio dire.... ho valorizzato "attributo" nel costruttore della classe !


grazie in anticipo per l'aiuto

[filippo.toso]

A me funziona perfettamente:

<?php 

class miaclasse {
    public function metodo() {
        echo(__METHOD__);
    }
}

class b {

    public $attributo;
    public function __construct() {
        $this->attributo = new miaclasse();
    }

    public function faiQualcosa() {
      $this->attributo->metodo();
   }
}

$obj = new b();
$obj->faiQualcosa();

?>

[fatmatt]

credo di essermi espresso male.... il mio problema è il seguente:

riscrivo l'esempio come nel mio caso

<?php

class pager extends controller
{
    function __construct()
    {
        parent::__construct();
        $this->view = new template();
        
        
    }
    
    function main()
    {
        //$this->view = new template();
        
        $this->view->assignTag("contenuti",$valore); //valore è a titolo di esempio
        $this->view->display();
    }
?>

come dicevo l'errore è

Fatal error: Call to a member function assignTag() on a non-object in pager.class.php on line 25

Se decommento la prima istruzione del metodo main va tutto liscio... ma questo mi è del tutto inutile ...se volessi manipolare la view nel costruttore così verrebbe resettata

[filippo.toso]

Come chiami il metodo main()?

Se inserisci un die(__METHOD__) nel metodo __construct(), viene visualizzato?

[fatmatt]

il metodo main viene richiamato automaticamente ogni volta che il cotnroller si accorge della non esistenza della variabile GET che chiama il metodo... diciamo che è un metodo di default che si attiva nel caso in cui non venga richiesta una azione specifica al controller.

con il test che mi hai proposto ottengo una cosa strana (per la mia ignoranza xD)

se inserisco il die prima della chiamata parent::__construct() il die viene visualizzato, altrimenti no... forse skippa tutto il codice dopo la call al costruttore del padre... faccio un test...

[LeaderGL]

mi sa che se scrivi qualche pezzetto anche della classe "controller" ci si fa un'idea migliore.

[fatmatt]

grazie, ho risolto...

Il codice del controller esteso, va scritto prima della chiamata parent::__construct()... poichè il codice ad essa successivo viene ignorato....

Questo avviene perchè nel costruttore della classe controller, c'è una chiamata ad un metodo del controller stesso che si accerta dell'esistenza del metodo main() . così se estendo il controlller senza definire un metodo di default, il sistema tira una exception.. se invece il metodo esiste, richiama il metodo main... l'esecuzione del restoi del codice successivo a questo punto viene ritardata troppo e non ha + senso
ecco come avviene il tutto

1)Costruttore della classe che estende controller
2)chiamata al costruttore del controller
3)Chiamata del main (che deve essere automatica)

ringrazzio filippo che mi ha dato lo spunto necessario alla risoluzione del problema: ho notato che il die(__METHOD__) veniva ignorato se posto dopo parent::__controller

[LeaderGL]

Originariamente inviato da fatmatt
Questo avviene perchè nel costruttore della classe controller, c'è una chiamata ad un metodo del controller stesso che si accerta dell'esistenza del metodo main() . così se estendo il controlller senza definire un metodo di default, il sistema tira una exception..

questo è concettualmente molto sbagliato...
nella programmazione ad oggetti per fare in modo che una generalizzazione di un classe (una sottoclasse, ovvero una classe che estende un'altra classe) implementi obbligatoriamente determinati metodi si utilizzano le interfacce o le classi (metodi) astratte

[fatmatt]

interfacce e metodi astratti implicano che l'implementazione di tali metodi avvenga nelle classi che estendono/implementano tali classi giusto?

in questo modo, non posso richiamare automaticamente il metodo di default, anzi ogni classe "figlia" , avrebbe dovuto contenere nel proprio costruttore una cosa del tipo $this->main che prioprio non mi piace.

In secondo luogo, il mio controller deve caricare delle classi che si occupano di recuperare i dati ecc... questo non è possibile con clasi astratte, poichè queste non contengono alcuna definizione dei metodi.

Prima di passare a questa implementazione , sono passato attraverso i (giustissimi) dettami dell'OOP ovvero tramite una classe astratta che obbligava il programmatore client ad implementare il metodo main... ma mi ritrovavo con una gerarchia delle classi abbastanza complessa per un progetto di piccole dimensioni.

Io sono un convintissimo sostenitore dell'OOP ma mi sono dovuto confrontare con un progetto troppo piccolo.. se avessi seguito alla lettera i sacri testi della programmazine ad oggetti mi sarei ritrovato una infrastruttura che avrebbe pesato il 60% del progetto stesso.. non nascondo di voler espandere il mio lavoro, per cui ho conservato la vecchia implementazione

Spero di non aver detto eresie... in caso vi prego di farmele notare (magari non prendetemi a bastonate )

[LeaderGL]

perchè era tanto peccato fare qualcosa in stile:

interface IController
{
   public function main();
}

abstract class Controller implements IController
{
   public function __construct()
   {
      // ...
   }
} 

e di conseguenza quando estendi Controller sei obbligato a fare:

class Pager extends Controller
{
   public function main()
   {
      // ...
   }
} 

dovevi solo rendere "abstract" la classe controller e creare l'intercaccia con la funzione main().