OO PHP static keyword, dovrei usarlo?

3

Sto scrivendo script per fb e ho 3 oggetti che userò in tutte le classi. Mi chiedo se ci sia qualche vantaggio nell'usare la parola chiave static eccetto che non devo creare un'istanza ogni volta che ho bisogno di usare un metodo / oggetto? Da che parte dovrei andare, con statico o senza?

So che questo è basilare, ma sono nuovo di OOP e voglio imparare a usarlo in modo appropriato.

    
posta Arline Rosales 11.12.2012 - 09:53
fonte

3 risposte

5

La tua domanda è un po 'vaga quindi farò del mio meglio.

C'è una buona domanda da porsi quando provi a scegliere tra la creazione di un metodo statico o un metodo di istanza.

Do you need to persistent state between method calls?

I metodi statici non sono diversi dalle funzioni procedurali tradizionali. Gli dai un input e dovrebbe produrre costantemente un output basato sull'input completamente privo di effetti collaterali.

In sostanza, è possibile utilizzare una dichiarazione di funzione tradizionale nella sua posizione senza alcuna differenza. L'unico vantaggio è che i metodi statici sono collegati a uno spazio dei nomi in cui le funzioni tradizionali sono definite nello spazio dei nomi globale.

Non hanno molta importanza in PHP perché il linguaggio mescola sia gli stili procedurali che quelli OOP, ma in linguaggi che sono puramente OOP (ex C # / Java) non c'è modo di definire le funzioni in modo da utilizzare i metodi statici al loro posto.

I metodi statici sono perfettamente accettabili da utilizzare quando si definiscono metodi di supporto che agiscono in modo stateless. Se hai bisogno di persistenza dei dati tra le chiamate e / o ti trovi a fare affidamento su variabili globali, non ; usa invece oggetti / istanze.

Aggiornamento:

Tom B ha fatto un ottimo punto sui test unitari. I metodi statici (come le funzioni procedurali) sono intrinsecamente disaccoppiati dalle classi a cui sono collegati. Quindi, se un metodo statico fallisce, può anche causare il fallimento di qualsiasi altro metodo di istanza in cui è chiamato. È un classico esempio di effetto collaterale.

Questo spiega perché ho incontrato così tante persone che pappagallo "i metodi statici sono cattivi, mmmkay" nella comunità TDD. Hanno un punto completamente valido.

Ci sono modi in cui questo potrebbe essere migliorato. Nella lingua, generando un'eccezione implicita quando i metodi statici falliscono. Tecnicamente, non sarebbe più un disastro che fare conversioni di tipo. Supponiamo che spezzerà qualcosa se fallisce. Ovviamente, ciò presuppone un maggior livello di comprensione da implementare.

In ogni caso, si tratta della semplice domanda.

Do you limit the language you use, or limit the ability to test your code's consistency?

Il mio pregiudizio personale è verso l'espressività, il pregiudizio della scuola TDD di pensiero è verso la coerenza. YMMV.

Attendo molti anni di guerre religiose su questo argomento.

    
risposta data 11.12.2012 - 23:47
fonte
4

In breve: No. I metodi statici sono generalmente considerati cattive pratiche. Introducono molti potenziali problemi. Si tratta di un modo per scandire il codice procedurale in OOP.

  1. Introducono dipendenze nascoste. Il codice che chiama arbitrariamente foo :: bar () ha una dipendenza da foo e non può essere eseguito senza che foo sia definito. In questo caso, l'oggetto che usa foo :: bar () verrà costruito correttamente ma non sarà utilizzabile se foo non è definito. Si romperà solo nel punto in cui viene chiamato foo :: bar (). Se un'istanza $ pippo è stata passata nel costruttore dell'oggetto, l'oggetto non potrebbe nemmeno costruirlo senza le sue dipendenze. Questo crea un codice molto più robusto.

  2. Le statistiche sono globali. Lo stato globale è molto cattivo, tutto può cambiare il codice e il suo stato è sconosciuto. Sacrifichi la potenza e il controllo ottenuti dall'incapsulamento OOP usando metodi statici.

  3. È impossibile sostituire le funzioni per una versione diversa. Nell'esempio foo :: bar (), si sacrifica tutto il potere che il polimorfismo consente in OOP usando metodi statici.

  4. Rende impossibile il test dell'unità. Per il test delle unità, è necessario essere in grado di sostituire le dipendenze per i mock. L'uso di metodi statici rende questo molto più difficile.

  5. Sei sicuro di voler solo una singola istanza? Immagina di avere una classe che ha creato una connessione FTP e ha consentito una semplice API per la creazione di file. Basta chiamare FTP :: upload ($ file); sarebbe abbastanza pulito, vero? Il problema è che, una volta modificati i requisiti, "il file può essere caricato anche sul server di backup". allora hai un problema: non c'è modo di connettersi a due server diversi contemporaneamente.

I metodi statici dovrebbero essere evitati come ovvio. Da una prospettiva OOP, non c'è motivo per cui dovrebbero mai essere scelti su un oggetto con un metodo.

    
risposta data 11.12.2012 - 17:46
fonte
0

Sono un po 'confuso dalla tua domanda. Hai tre oggetti: istanziali e passali per riferimento. Hai bisogno di tre istanze, usa tre istanze, supponendo che non siano modificate, non è necessario che siano clonate, ecc. In alternativa, controlla il pattern del singleton.

Parola chiave statica: link . È esattamente lo stesso in PHP come in JAva snd altrove: ne hai bisogno specifico per la classe, quindi è statico. Perché ha a che fare con la manutenzione, le prestazioni e altri fattori.

Nuovo in OOP: richiede tempo, non ti preoccupare.

    
risposta data 11.12.2012 - 16:15
fonte

Leggi altre domande sui tag