PHP domanda controllo metodi doppi, programmare a classi

Ciao a tutti,
Se qualcuno di voi aveva visto l'esempio MVC che avevo postato un pò di tempo fa, ha notato che la logica era molto semplice ad ogni azione passata da Ajax corrisponde un metodo nella classe ajaxModel, bene io ho allargato questa dinamicità ed in poche parole ad ogni azione=PIPPO il parse cerca in tutta la cartella model TUTTE LE CLASSI e cerca IL METODO PIPPO, dinamicamente istanzia la classe che ha il metodo PIPPO ed invoca il metodo.Ovviamente funziona anche se B etends A e C extends B perchè recupera i metodi da C che include tutti i metodi di A e di B, tutto funziona perfettamente, ogni file con l'autoload deve avere la prima classe = nomeFile.php(questa è una regola con l'autoload), ok ci siamo.
Qualì'è il problema?
Io ho fatto diverse funzioni metodo che mi debuggano tutte le classi nella CARTELLA model, quindi mi dice, quante e quali classi ci sono, se una classe ha figli, quali sono i padri della classi, quali sono i metodi delle classi padri etc...etc...
Il problema è che se io programmatore inserisco due metodi con lo stesso nome dentro due classi diverse o anche dentro una classe parente, il software funziona ma entra nel primo metodo che trova, io vorrei avvertire GUARDA CHE IL METODO E' DOPPIO.
Innanzi tutto avvertire se i metodi hanno lo stesso nome ma in classi che non sono parenti, ovviamente questa è una chicca perchè chi sviluppa dovrebbe stare attento a non scrivere due funzioni con lo stesso nome, lo stesso vale per i metodi, ma io vorrei scorrere tutti i metodi ed i metodi delle classi padri, ciclare i metodi doppi esempio se B extends A e C extends A ovviamente i metodi di B e C hanno dei metodi comuni che sono quelli di A ma non sono doppi perchè sono comuni alla classe padre sia di B che di C.
Secondo voi si può fare una cosa del genere o diventa troppo dispendiosa?
Ad oggi al programmatore non rimane altro che scrivere una classe scrivere un metodo e se vuole entrare con ajax in quel metodo basta chiamare index.php?azione=metodo lui dinamicamente prende la classe che ha il metodo valorizzato istanzia la classe e invoca il metodo, è comodo ed anche il debug è puntuale perchè ad ogni azione corrisponde uno ed un solo metodo.
Ovviamente non voglio usare i namespace perchè OGNI METODO DEVE ESSERE UNIVOCO, per ragioni di velocità di debug ed analisi del codice.
Secondo voi c'è una possibilità per controllare che i metodi non siano doppioni ed ovviamente doppioni sono solo quelli che non sono comuni alle classi figlie con lo stesso padre....Io ho quasi fatto nel senso ho tutti i dati ma devo analizzare i diversi casi cioè se B extends A e C extends B e D extends C e E extends B per esempio oppure B extends A e C extends A...etc...qualcuno di voi sa come poter fare con poche righe di codice?

[mzanella]

Premesso che potrei essere io ad aver frainteso la spiegazione -e a mia discolpa devo dire che in alcuni punti non è molto chiara-, mi sembra che un sistema siffatto aggiunga delle complicazioni gratuite e non necessarie, oltre a rompere le idee alla base delle architetture MVC; in termini concreti, intendo dire che il nomi di metodi e classi, in un sistema MVC, sono dettagli implementativi, mai e poi mai dovrebbero essere acceduti direttamente. L'accesso va piuttosto mediato da un'interfaccia.

Così facendo stai imponendo molti vincoli inutili, ad esempio l'uso della programmazione orientata ad oggetti anche laddove un codice procedurale sarebbe più elegante od efficiente, oppure il vincolo che classi appartenenti a gerarchie distinte debbano avere metodi con nomi diversi (vietando, di fatto, l'uso di interfacce nel senso OOP del termine e creando accoppiamento tra tutte le classi).

Ribadisco, è possibile che io abbia frainteso la spiegazione. Ad ogni modo, se il problema è "determinare la presenza di metodi con lo stesso nome all'interno di un insieme di classi", il primo passo è definire come trattare metodi "sovrascritti" nelle sottoclassi (overridden, n.d.t.):

class A {
    public function foo() {
        echo "A::foo()";
    }
}

class B extends A {
    public function foo() {
        echo "B::foo() overrides A:foo()";
    }
} 

In questo caso, desideri considerare il nome foo come duplicato?

La seconda questione riguarda i nomi di metodi che non fanno parte dell'interfaccia di una classe (in altri termini, metodi privati e protetti): essi devono essere conteggiati?

Sciolti questi dubbi, andrebbe chiarito in quale momento desideri effettuare questo controllo (on-demand? Alla creazione di una nuova classe?). Supponendo che sia on-demand, uno schema di algoritmo potrebbe basarsi su una visita di un grafo (in particolare della foresta indotta dalle gerarchie di classi):

1. per ogni gerarchia di classi, crea un albero in cui ciascun nodo è una classe e ciascun arco modella la relazione di ereditarietà
2. per ogni gerarchia di classi crea un insieme used_names di nomi di metodi presenti in quella gerarchia (inizialmente vuoto)
3. per ogni albero esegui una visita in profondità partendo dal nodo radice come segue:
   
   1. aggiungi ad used_names i nomi di metodo nella classe corrente, se non sono già presenti
   2. estendi la visita ad i nodi figli (ricorsivamente)
   3. alla fine used_names contiene tutti i nomi di metodo usati nella gerarchia
4. confronta gli insiemi used_names alla ricerca di duplicati

Per ottenere informazioni sui metodi di una classe puoi usare i meccanismi di riflessione che preferisci. Se per quest'analisi usi PHP, un'idea è get_class_methods...

Ciao Mzanella,
No, permettimi di dire che non hai capito, la struttura MVC è una struttura che fondamentalmente divide gli ambiti di lavoro, cioè cosa può fare l'utente e cosa fa il server, con cosa si interfaccia l'utente e con cosa si interfaccia il server, ma la base dell'MVC in maniera molto in soldoni, è una chiamata sempre ad index.php con una valorizzazione di una variabile.
Questo fa l'MVC la variabile viene passata al controller che testuali parole CONTROLLA, la variabile e se è tutto corretto invoca il model che si interfaccia con il server, il model analizza sviluppa e poi risponde alla view, o in alcuni casi al controller e il controller alla view.
Non sono io a dirlo ma programmatori da anni...Comunque la struttura del model view controller è proprio questa.
Quello che ho fatto io, l'ho fatto prendendo in esempio chi ne sa più di me ed aveva già fatto una struttura a classi per l'MVC io ho solamente implementato in base alle mie esigenze.
L'esempio che tu hai messo non è una forma di programmazione elegante, perchè in php > 5 sono stati introdotti apposta i namespace, proprio per ovviare al problema di classi con lo stesso nome o di metodi con lo stesso nome, quindi quello che hai scritto non è elegante a livello di programmazione, non serve, ogni classe ha un suo metodo che difficilmente è uguale al metodo di un'altra classe, a livello di programmazione, se classe mammifero ha un metodo = al metodo della classe figlia cane o della classe figlia gatto non ha senso includere il metodo nelle classi figlie ma si mette solo nella classe padre.
Nella programmazione ad oggetti TUTTI I METODI DEVONO ESSERE DISTINTI, altrimenti si fa un minestrone, il namespace cosa fa?impone un path, ma perchè si usa il namespace perchè essendo PHP un linguaggio open source può essere che l'utente installa classi di altri utenti e queste classi possono avere nomi uguali, ma dato che io non devo installare nessun classe in open source ma sono io che faccio il progetto ed il progetto è PRIVATO E NON SARA' MAI OPEN SOURCE non ha senso che uso i namespace.
Il mio problema è il seguente

class A{

public function provaA(){

    print 'ciao sono prova della classe A';
}
}

class B{

public function provaA(){

    print 'ciao sono prova della classe B';
}
} 

Io non voglio che questo accada per diversi svariati motivo uno di questi è la velocità di debug, quindi ho inserisco dei namespace ma ribadisco NON LO VOGLIO FARE perchè così permetto la valorizzazione di metodi con nome uguale in classi diverse e non parentate.
Poi c'è l'altro caso, perchè il caso in cui le classi non hanno parenti grandi problemi non ce ne sono ma quando le classi hanno parenti e cioè:

class A{

public function provaA(){

    print 'ciao sono prova della classe A';
}
}


class B extends A{

public function provaB(){

    print 'ciao sono prova della classe B';
}
}


class C extends A{

public function provaC(){

    print 'ciao sono prova della classe C';
}
} 

Io ho creato il codice che mi dice chi è figlio di A e recupero tutti i metodi del padre A(ed anche dei figli volendo), ma ovviamente il metodo provaA non è un doppione ma è un metodo comune alla classe padre...Il problema ancora più intrinseco è questo e sinceramente non so come risolverlo...cioè

class A{

public function provaA(){

    print 'ciao sono prova della classe A';
}
}


class B extends A{

public function provaB(){

    print 'ciao sono prova della classe B';
}
}

class C extends B{

public function provaC(){

    print 'ciao sono prova della classe C';
}
}


class D extends B{

public function provaD(){

    print 'ciao sono prova della classe D';
}
} 

Qui non ci sono metodi doppioni ma se io per fare il controllo prendo i metodi dei padri e dei figli ovviamente il parse trova dei metodi doppioni perchè C ha come metodi provaA provaB provaC e D ha come metodi provaD provaB e provaA capisci che sembrano doppioni?Ma non lo sono....quindi ovviamente io non voglio che in class D non ci sia il metodo provaA per esempio, ma voglio permettere solo metodi con nomi diversi....ma devo controllare il caso in cui sono parenti.
Perchè imporre che i metodi abbiano un nome univoco non è difficile ma devi tenere in considerazione il caso in cui ci siano figli di classi...Hai capito adesso?
Cioè io non voglio che capiti questo caso:

class A{

public function provaA(){

    print 'ciao sono prova della classe A';
}
}


class B extends A{

public function provaB(){

    print 'ciao sono prova della classe B';
}
}

class C extends B{

public function provaC(){

    print 'ciao sono prova della classe C';
}
}


class D extends B{

public function provaA(){

    print 'ciao sono prova della classe D';
}

public function provaB(){

    print 'ciao sono prova della classe D';
}
} 

ps:get_class method lo conosco bene, mzanella, ho già tutto io ho sia quali sono i metodi sia quante classi ci sono quali sono i padri e quali sono i figli ho tutto...recupero i metodi dei figli e dei padri ma poi appunto troverà dei metodi doppi ma non sono doppi in verità perchè sono metodi ereditati...Invece l'ultimo caso è DOPPIO ed è quello che devo impedire...Ed anche il primo caso cioè metodi con nome uguale in classi che non sono parenti...ribadisco è una chicca perchè tu non puoi sviluppare in un file due funzioni con lo stesso nome(i metodi non sono altro che funzioni sia chiaro che o ad oggetti o procedurale si fanno le stesse cose non è che ci sono cose che non riesci a fare con il procedurale ed invece con gli oggetti si)....

pps:Ovviamente il controllo è il controller che lo fa e se il metodo quindi è valido chiama il model

[mzanella]

Probabilmente avevo frainteso alcuni punti, ti rinnovo dunque le mie scuse.
Lo schema di algoritmo che avevo proposto nel messaggio precedente dovrebbe comunque essere un buon punto di partenza per le tue necessità. Dopo aver riletto i tuoi messaggi, credo che l'unico punto da modificare sia la visita dell'albero della gerarchia. Dovresti tenere traccia dei nomi di metodi incontrati nelle superclassi e, dalle sottoclassi, leggere solo i metodi non ereditati. Se uno di questi ultimi è già presente nell'insieme dei nomi di metodi già incontrati nelle superclassi hai (un overriding e dunque) un "doppione".

Ci sono però alcune tue affermazioni che temo di dover mettere in discussione:

MVC è una struttura che fondamentalmente divide gli ambiti di lavoro, cioè cosa può fare l'utente e cosa fa il server, con cosa si interfaccia l'utente e con cosa si interfaccia il server

Corretto, la mia obiezione riguarda l'interazione tra il controller ed il model: il primo interagisce con il secondo inviandogli dei comandi. Poiché MVC enfatizza il concetto di separazione di ruoli (o suddivisione degli ambiti di lavoro), è bene che struttura e contenuto dei comandi prescinda dall'implementazione specifica; segue che una modifica nel model non deve ripercuotersi nel controller, né viceversa. Ciò equivale a definire un'interfaccia, o protocollo.
Nel tuo esempio, al contrario, modificare il nome di un metodo nel model implica che tutti i controller che utilizzano quel metodo vadano revisionati di conseguenza (in un certo senso è un problema simile al noto Base Class Fragility nella programmazione ad oggetti).
(Fonte: Model-view-controller)

in php > 5 sono stati introdotti apposta i namespace, proprio per ovviare al problema di classi con lo stesso nome o di metodi con lo stesso nome

I namespace hanno "effetto" su classi, interfacce, funzioni, e costanti, non sui metodi, come riportato nella documentazione ufficiale. Ciò è ragionevole, in quanto un metodo è già incapsulato all'interno di una classe.

se classe mammifero ha un metodo = al metodo della classe figlia cane o della classe figlia gatto non ha senso includere il metodo nelle classi figlie ma si mette solo nella classe padre

Naturalmente, non ha senso ricopiare in una classe figlia un metodo presente in una sua superclasse. Infatti io ho parlato di overriding, ovvero la ridefinizione di un metodo in una sottoclasse al fine di modificarne il comportamento. E no, non è una cattiva pratica, al contrario, è lo strumento con cui si realizza il dynamic binding, uno dei principi cardine della programmazione orientata ad oggetti. Per dare un'idea della diffusione di questo meccanismo, si pensi che il linguaggio C++ offre la possibilità di definire delle virtual member function proprio per questo scopo... o ancora meglio, al fatto che in Java ed in PHP tutti i metodi sono virtuali, in modo da permettere l'overriding !

Nella programmazione ad oggetti TUTTI I METODI DEVONO ESSERE DISTINTI

Nient'affatto, al contrario, diversi Design Pattern (come il Proxy ed il Composite, per citarne due) si basano proprio sull'idea di avere classi diverse con (alcuni) metodi omonimi. Più in generale, le interfacce richiedono che le classi concrete ne implementino i metodi (segue che le classi concrete avranno necessariamente metodi omonimi).

tu non puoi sviluppare in un file due funzioni con lo stesso nome(i metodi non sono altro che funzioni [...]

L'idea è corretta, ma occorre non abusarne. È vero che, in fondo, un metodo è una funzione, e come le funzioni non possono esserci doppioni... nello stesso scope. Nel momento in cui due metodi con lo stesso nome risiedono in classi diverse, non ci sono problemi (vedi le osservazioni precedenti), salvo il fatto che se le classi in questione fanno parte della stessa discendenza si parla di overriding, ed il metodo nella superclasse viene "oscurato" da quello nella sottoclasse. per permettere il late binding.

Ahh tu dici di non prendere in considerazione i metodi ereditati si però se usi la get_class_method ti da anche i metodi ereditati, te li da tutti...uhmm devo provare a risolvere in qualche modo io ad oggi ho creato una struttura così..una specie di debug che mi dice..class debugStrutturaClassi...vedi chiamata A e chiamata A1 li conta ripetuti perchè sono comuni sia a B che C che sono figli di A ma non sono parenti....

Metodi totali di tutte le classi esclusi i metodi dei padri che hanno figli :

array (size=11)
  'Classe : ajaxModel' => 
    array (size=2)
      0 => string 'chiamata' (length=8)
      1 => string 'chiamata2' (length=9)
  'Classe : Classe Padre A' => string 'Nessun metodo conteggiato per classe padre' (length=42)
  'Classe : B' => 
    array (size=3)
      0 => string 'chiamataB' (length=9)
      1 => string 'chiamataA' (length=9)
      2 => string 'chiamataA1' (length=10)
  'Classe : C' => 
    array (size=3)
      0 => string 'chiamataC' (length=9)
      1 => string 'chiamataA' (length=9)
      2 => string 'chiamataA1' (length=10)
  'Classe : D' => 
    array (size=1)
      0 => string 'chiamataD' (length=9)
  'Classe : E' => 
    array (size=1)
      0 => string 'chiamataE' (length=9)
  'Classe : F' => 
    array (size=1)
      0 => string 'chiamataF' (length=9)
  'Classe : G' => 
    array (size=1)
      0 => string 'chiamataG' (length=9)
  'Classe : essere' => 
    array (size=1)
      0 => string 'mammifero' (length=9)
  'Classe : essere1' => 
    array (size=1)
      0 => string 'chiamataB1' (length=10)
  'Classe : modello' => 
    array (size=1)
      0 => string 'controllaAzione' (length=15)

Numero di metodi che si ripetono : 2
I metodi che si ripetono sono :

Array
(
    [0] => chiamataA
    [1] => chiamataA1
)

Nome Metodi e quante volte di ripetono() :

Array
(
    [chiamataA] => 1
    [chiamataA1] => 1
)

ajaxModel ha come padri : nessuno
A ha come padri : nessuno
B ha come padri : A
C ha come padri : A
D ha come padri : nessuno
E ha come padri : nessuno
F ha come padri : nessuno
G ha come padri : nessuno
essere ha come padri : nessuno
essere1 ha come padri : nessuno
modello ha come padri : nessuno
I metodi delle classi padri sono in stdClass ReflectionClass:

array (size=2)
  0 => 
    array (size=2)
      0 => &
        object(ReflectionMethod)[5]
          public 'name' => string 'chiamataA' (length=9)
          public 'class' => string 'A' (length=1)
      1 => &
        object(ReflectionMethod)[8]
          public 'name' => string 'chiamataA1' (length=10)
          public 'class' => string 'A' (length=1)
  1 => 
    array (size=2)
      0 => &
        object(ReflectionMethod)[7]
          public 'name' => string 'chiamataA' (length=9)
          public 'class' => string 'A' (length=1)
      1 => &
        object(ReflectionMethod)[6]
          public 'name' => string 'chiamataA1' (length=10)
          public 'class' => string 'A' (length=1)


ciaoA 

Adesso dovrò ancora studiarci un pò....Comunque rispondendo al tuo commento sul controller...no no il controller per come è sviluppata l'applicazione una modifica nel model non si ripercuote affatto sul controller, allora la base è semplice non ho mica creato un controller per ogni metodo, fossi matto, no no deve essere il più semplice e veloce possibile...il controller si intefaccia prima con una struttura base del model poi se è tutto ok invia il comando al server altrimenti si blocca subito.
Ma tutti i metodi che si interfacciano con il server non sono soggetti al controller...L'unica regola dato che uso l'autoload è che la prima classe ed il primo file abbiano nomi uguali perchè includo tutto dinamicamente nel model, non ho bisogno di includere dei file...quindi il file inserimento.php avrà la prima classe inserimento nel file inserimento.php, il file variazione.php avrà la prima classe variazione nel file variazione.php e tutti i metodi, poi se c'è necessità di altre classi basta scriverle sempre nello stesso file ma sotto....Ma questo è perfetto perchè io voglio tutto sott'occhio quindi devo sapere che nel file inserimento.php ci sarà la classe inserimento con tutti i metodi per l'inserimento lo stesso per la variazione lo stesso per i recapiti, e per qualsiasi altro argomento...ma prima di dirottare, il controller in unione al model(questa è il punto di interfaccia come intendi tu), analizzano i comandi passati e poi inviano o rispondono subito...no in casa questo comando non è valido e non ti fa entrare.
Le interfacce mzanella, ehh va behh quello è normale che hanno metodi comuni ma sono sempre dell'interfaccia però..va behh quello certo.Ma anche nell'intefacce non è permesso fare l'override...La logica deve rimanere pulita e veloce nel debug e ordinata nella struttura.
Però io vorrei solamente che se uno fa una chiamata e ci mette azione=pippo e pippo è un metodo che lo avverta guarda che pippo è usato due volte in classi diverse e questo non va bene.Poi fa il debug della struttura classi e può vedere dove è usato e quale classi lo usano...

[mzanella]

Per ottenere solo i metodi non ereditati ci sono le Reflection API, in particolare getMethods().

Ad esempio:

class A {
  public function foo() {
    echo "A::foo()";
   }
}

class B extends A {
  public function bar() {
    echo "B::bar()";
  }
}

$class = new ReflectionClass('B');
var_dump($class->getMethods()); 

Che produce:

array(2) {
  [0]=>
  &object(ReflectionMethod)#2 (2) {
    ["name"]=>
    string(3) "bar"
    ["class"]=>
    string(1) "B"
  }
  [1]=>
  &object(ReflectionMethod)#3 (2) {
    ["name"]=>
    string(3) "foo"
    ["class"]=>
    string(1) "A"
  }
} 

In particolare, per ogni metodo, viene fornita anche la classe nella quale è stato implementato. Se la classe di implementazione è diversa da quella corrente, il metodo è ereditato.

Ehh mi hai dato una buona idea usare la reflectionClass per recuperare i metodi di tutte le classi e poi metto tutto in un array e controllo che non si ripetono...Si se pò fa domani lo sviluppo io già uso la reflectionClass se vedi il var dump che ho messo prima alla fine quella è un std reflection class la funzione è questa:

    /*
     * Ritorna il print dei metodi di tutte le classi padri
     * è un object ReflectionClass
     * Passargli l'array di tutte le classi padri.
     */
    public static function getMetodiClassiPadri(array $arrayClassePadri){
    
           //Ricava tutti i metodi delle classi padri
           $metodiClassiPadri=array();
           foreach($arrayClassePadri as $classe){
               if (is_array($classe)){
                   foreach ($classe as $metodi){
                        $class = new ReflectionClass($metodi);
                        $methods = $class->getMethods();
                        array_push($metodiClassiPadri,$methods);  
                   } 
               }
     
           }
           
           print '<b>I metodi delle classi padri sono in stdClass ReflectionClass:'.'</b><br>';
           var_dump($metodiClassiPadri);    
        
    } 

Il problema è che sei fai getName() ti ritorna solo il nome del metodo e non il nome della class sembra che non riesco ad accedere alla A cioè in questo var_dump

array (size=2)
  0 => 
    array (size=2)
      0 => &
        object(ReflectionMethod)[5]
          public 'name' => string 'chiamataA' (length=9)
          public 'class' => string 'A' (length=1)
      1 => &
        object(ReflectionMethod)[8]
          public 'name' => string 'chiamataA1' (length=10)
          public 'class' => string 'A' (length=1)
  1 => 
    array (size=2)
      0 => &
        object(ReflectionMethod)[7]
          public 'name' => string 'chiamataA' (length=9)
          public 'class' => string 'A' (length=1)
      1 => &
        object(ReflectionMethod)[6]
          public 'name' => string 'chiamataA1' (length=10)
          public 'class' => string 'A' (length=1) 

Accedo ai metodi chiamataA1 etc...ma non alla class...comunque in qualche modo risolverò la logica però si può essere quella che hai detto te, cioè prendo tutti i metodi senza contare i metodi ereditati e poi metto in un array e poi conto se ci sono doppioni... la chiamata azione=nomeMetodo prima ovviamente di chiamare i metodi nel model il controller controllerà che i metodi siano univoci e se sono univoci chiama e dirotta il parse dentro il metodo se per caso sono doppi ed è uguale ad azione allora risponde guarda che stai chiamando un metodo presente due volte...Si devo solo isolare quella stdClass.....Se pò fa ;)
Grazie ciao buona serata

Però così non posso usare le interfacce...Behh va behh facciamo un passo alla volta intanto risolviamo questo poi al massimo controlliamo che se sono doppi se appartengono all'interfaccia allora ok altrimenti blocco...Si dai ci sta... ;)

Ok perfetto ci siamo questo è il ciclo giusto la funzione è simile a quella di prima ma quella di prima recupera i metodi delle classi padri questa invece recupera tutti i metodi escludi i metodi ereditati, passandogli l'array con il nome di tutte le classi...Perfetto, domani continuo, grazie zanella, buon input...Ciau

    /**
     * Ritorna il nome di tutti i metodi e non include i metodi ereditati, passargli l'array con tutte le classi
     * complete chiamando la getNomeClassi
     */
    public static function getMetodiTotali(array $arrayClassiComplete){
                
         var_dump($arrayClassiComplete);
    
         foreach($arrayClassiComplete as $classe){           
           $class = new ReflectionClass($classe);
    
           foreach($class->getMethods() as $metodi) {
              if($metodi->getDeclaringClass()->getName() === $classe) {
                   print $metodi->getName().'<br>';
              }
          }
         }
    } 

Funziona, se chiami un metodo con lo stesso nome in un'altra classe lo scrive, quindi invece di fare il print metto tutto in un array e poi conto che non ci siano doppioni...PERFETOOOOO...Olè...cioè mi sono fatto tutto un debug bastava che facevo sta funzioncina.ahahahaha beh meglio così anche perchè adesso conosco vita morte e miracoli delle classi incluse nella cartella model, quanti figli quanti padri quanti e quali metodi quali metodi delle classi padri quante volte si ripetono...Ahahahah quante volte vanno in bagno anche... :) Ciao

Voglio fare una precisazione a quello che dici sull'overiding, a parte che non sempre si può fare nelle interfacce non puoi fare l'overriding.

http://php.net/manual/it/language.oop5.interfaces.php

Ma capisci che un'analista di software che guarda il tuo software e vede che hai fatto un overriding non è per niente elegante?
C# non supporta l'overriding e mi trova pienamente d'accordo, premetto che non sono esperto di overriding proprio perchè lo evito come il sale nel caffè però se tu devi riscrivere perchè overriding vuol dire questo, che è molto lontano dal polimorfismo, un metodo e fare l'override, MA CANCELLA QUELLO VECCHIO NO?Lo teniamo lì a fare la muffa, giusto per complicarci l'esistenza di analisi e debug... :)
Ognuno diciamo che ha i suoi modi e le sue scuole di programmazione ma io sono per poche righe di codice che fanno tutto, io sono per il keep it simple ma gestibile, usabile e PRATICO sia nel debug che nella gestibilità, questo è proprio che non vogliono capire i Javisti perchè JAVA a mia opinione non è proprio per niente malleabile, un codice deve essere malleabile versatile, per me questo deve fare un buon linguaggio...e sinceramente il PHP soddisfa le mie eseigenze, poi dipende da quello che uno deve fare, ma se devo gestire un codice che può cambiare ogni giorno e si deve interfacciare con un DB behh il PHP per me rimane il NUMBER ONE ma ovviamente TENUTO ORDINATO.
Però l'overriding non è una buona norma, guarda ti assicuro che dopo un pò di tempo se vedi metodi che sono stati override TU LI CANCELLI FIDATI.
Quello che sto facendo adesso è semplicemnte una struttura che avrà tre cartelle model, view controller nella view ci sono i template e i php che caricano i template, nel controller, c'è un file nel controller, ci sono le classi di controllo e di debug o di permessi, nel model che è il cuore dell'applicativo TUTTI I FILE SONO DIVISI PER ARGOMENTI, inserimento, variazione, recapiti, documenti, etc...ogni file è creato per un determinato argomento con la sua relativa classe e metodi...Capisci che così se mi trovo un problema nei recapiti io basta che vedo dove è direzionata la chiamata e so già dove andare nel model so in quale punto intervenire, il PHP, almeno il mio lavoro, è usato per gestione dei dati web/DB ogni giorno possono esserci dei problemi, delle specifiche diverse, delle change request e quello di cui c'è bisogno è ORDINE.Purtroppo io l'ho sempre detto il PHP essendo versatile ha anche il suo difetto che tutti possono programmare anche in maniera disordinata,tanto funziona :) , ma immaginati a lavorare su un progetto con 100 file .php di 10 mila righe a file e mettici pure l'override ciao...diventa un casino...alla fine lo gestisci ma si deve programmare in maniera ordinata.Che poi è proprio questo che fa un programmatore un buon programmatore.

[mzanella]

Bene, alla fine lo scopo è stato raggiunto!

Anche questa volta ci sono alcune precisazioni da fare:

Voglio fare una precisazione a quello che dici sull'overiding, a parte che non sempre si può fare nelle interfacce non puoi fare l'overriding.
http://php.net/manual/it/language.oop5.interfaces.php

Nella documentazione non ho trovato esempi di impossibilità di overriding di metodi, anzi sembra riportare l'esatto opposto... e a conprova di ciò, il seguente proof of concept funziona senza problemi:

interface I1 {
    public function foo();
}

interface I2 {
    public function foo();
}

class A implements I1 {
    public function foo() {
        echo "A::foo()";
    }
}

class B extends A implements I2{
    public function foo() {
        echo "B::foo() overrides A::foo()";
    }
} 

C# non supporta l'overriding e mi trova pienamente d'accordo [...] overriding vuol dire questo, che è molto lontano dal polimorfismo

Tutti i linguaggi orientati ad oggetti lo supportano, incluso C# (vedi override (C# reference) e Method overriding in C#). L'overriding è lo strumento principale di una forma di polimorfismo, ovvero il polimorfismo dinamico (vedi late binding e Dynamic dispatch); in misura minore partecipa implicitamente anche al polimorfismo di sottotipo.

MA CANCELLA QUELLO VECCHIO NO?Lo teniamo lì a fare la muffa, giusto per complicarci l'esistenza di analisi e debug... :)
[...]
Però l'overriding non è una buona norma, guarda ti assicuro che dopo un pò di tempo se vedi metodi che sono stati override TU LI CANCELLI FIDATI.

"Quello vecchio" potrebbe essere ereditato da un'altra classe, in questo caso è bene mantenerlo (oppure potrebbe essere la super classe stessa ad averne bisogno). Semplicemente, la sottoclasse che esegue l'override desidera specializzare od alterare un comportamento.
In un certo senso PHP "incentiva" l'overriding rendendo di default tutti i metodi virtuali. Se vuoi, al contrario, impedire che un metodo venga overridden devi compiere una fatica addizionale (cioè ricorrere alla parola chiave final).
Altre fonti: Knowing When to Use Override and New Keywords (C# Programming Guide) e What is the use of overriding in OOP.

non sono esperto di overriding proprio perchè lo evito come il sale nel caffè

Senza dubbio ci sono contesti in cui l'overriding non è la scelta migliore. Ce ne sono molti altri in cui esso rappresenta uno strumento molto valido. Quest'affermazione in realtà vale per qualunque strumento, dall'ereditarietà alla ricorsione!
Se nel tuo progetto, come mi sembra di capire, le gerarchie delle classi sono poco profonde probabilmente dell'overriding non te ne fai nulla. Non per questo bisogna togliergli i suoi meriti .


Fatte queste precisazioni, che ritenevo doverose per evitare l'insorgere di fraintendimenti, preferisco non insistere oltre: il problema originario è stato risolto, e non è questo il luogo per tenere un corso di linguaggi di programmazione .
Presa una qualunque funzionalità di una qualunque tecnologia (o linguaggio), ci saranno sempre almeno una persona che la esalterà come elegante, efficiente, funzionale, buona pratica, design pattern... ed almeno una che la marcherà come non elegante, poco efficiente, cattiva pratica, anti-pattern...
Se ci dovessero essere altri dubbi a riguardo, meglio aprire una discussione separata.

Ma infatti si dialoga, mica si litiga :)
In php non puoi fare comunque l'overriding di costanti nelle interfacce, ed in C# puoi fare l'override solo di metodi virtuali, il resto non è ammesso, ma sorvolando su queste cose, secondo me siamo sempre lì nel senso a cosa serve il PHP e a cosa serve un altro tipo di linguaggio, nel senso, parliamoci chiaro zanella, io devo combattere tutti i giorni con un progetto che non è a classi, è tutto procedurale con 200 file e 50 milioni di righe che sinceramente sono disordinate, e cambia ogni tre per due perchè è un software web/DB di gestione dati, quindi capisci che quello che serve a me è ordine e velocità di poter debuggare sapere dove entra il parse capire immediatamente quale funzione javascript chiama chi e cosa etc...Io credo(posso anche sbagliarmi sia chiaro) che se devo fare un software web/DB con pagine dinamiche che può cambiare funzionalità o implementazioni, ogni giorno in base alle esigenze uso il PHP perchè è un linguaggio versatile e mi permette di poter modificare in maniera abbastanza veloce e dinamica, se invece devo fare un .exe o un .jar allora uso C# o Java e qui ci possiamo mettere tutte le override che vuoi, è un software però che viene construito e mai più toccato, e se devi fare delle modifiche chiamo lo sviluppatore, si prende una settimana e te le fa, ma con il PHP e il lavoro web non funziona così, perchè il software è in continuo mutamento e dinamico, è un software web, quindi secondo me, per una buona gestione e velocità di debug eviterei di fare degli override se non strettamente necessario, come eviterei di usare namespace o programmazione a scatola cinese se NON STRETTAMENTE NECESSARIO, perchè questo?
Perchè quando hai una funzionalità che non funziona ed hai bloccato il lavoro quotidiano dei dipendenti, non puoi dirgli ehh fra 5 giorni è pronto, no al massimo hai 4 ore, non di più...Quindi è logico che io cerco di sviluppare ed adattarmi il software a questa esigenza.
Ciao un salutone, buona giornata.