Quando dovremmo usare la classe e quando non dovremmo

Question

Le classi sono utili e tutte, ma quando scrivo una classe, la penso sempre come un heavy rock sulla mia sceneggiatura. Mi sento come se le classi dovessero essere usate raramente. Ma allo stesso tempo siamo tutti presi in considerazione dal paradigma OOP.

Se uno script non ha mai funzioni libere? Dovrei usare mille classi solo per rendere la sceneggiatura più pulita? E per quanto riguarda le esibizioni? class::method() richiede molto più tempo di un semplice function()? Qual è il vero significato di OOP? Sono un po 'confuso.

Da quando ho scoperto OOP, non riesco a vedere le funzioni casuali. Sono ossessionato. Non riesco a vedere le funzioni che non hanno una classe genitore. Io piuttosto creare una classe con solo un metodo, quindi vedere quella funzione tutto da solo. È giusto? Ci sono esempi di CMS puro OOP là fuori?

Answer 1

La cosa più importante per un programmatore in PHP, a mio parere, oltre alla sua esperienza è il suo toolkit. Cioè, codice che lui/lei ha scritto dentro e fuori, avanti e indietro da tempo immemorabile.

Per me, in questo caso, il vantaggio di OOP in chiaro. Avere una classe che conosci preformerà sempre quello che vuoi attraverso semplici metodi è molto più facile per te e per i membri del team, quindi è solo chiamando una moltitudine di funzioni statiche. Mentre si potrebbe argomentare che una libreria di funzioni satiche include lo stesso scopo, a mio avviso le lezioni sono molto più facili da leggere e capire. Per esempio, nella mia classe di sessione personalizzato un programmatore può guardare il mio codice e vedere,

$my_session = new session(); 
$my_session->start(); 

if (($session_errno = $my_session->error()) !== FALSE) 
{ 
    //DO SOMETHING BECAUSE OF A SESSION ERROR 
} 

e facilmente capire che le sessioni in questa applicazione sono gestite tramite la nostra classe di sessione personalizzato, e deve restituire un certo tipo di successo/insuccesso senza aver mai esaminato la biblioteca/la classe.Nel frattempo, una chiamata di questo tipo,

session_start(); 

if (session_error()) 
{ 
    //DO SOMETHING BECAUSE OF A SESSION ERROR 
} 

non lo rende chiaro che session_start() non è un gestore di sessione di PHP di default, ma che chiamerà le funzioni definite in session_set_save_handler() che è stata inclusa in qualche mega lista di include globale che potrebbe non essere facilmente individuabile in una grande applicazione. Non è altrettanto chiaro che session_error() sia una funzione che restituisce un errore impostato dal gestore di sessione personalizzato, rispetto a una funzione che può cercare attivamente i problemi di sessione su una sessione già generata ed è completamente indipendente dalla sessione predefinita di PHP.

Questo non è un ottimo esempio, ma penso che sia un buon esempio. Non sono entrato nei dettagli sulla bontà che protegge i dati dall'applicazione per intero, l'ereditarietà e tutto ciò che rende OOP utile.

Ma rapidamente, immagina una classe che accede al database MYSQL di un'applicazione. Viene dedicato molto tempo alla progettazione della classe per utilizzare istruzioni preparate, errori di registro e fornire la logica appropriata al programmatore secondo necessità. Un team può preoccuparsi meno dei problemi di accesso al database semplicemente chiamando le funzioni pubbliche di "accesso ai dati" della classe senza preoccuparsi di errori fatali, cattiva logica o SQL pericoloso (iniezioni e così via).

Questo può essere fatto con funzioni statiche come suggerite, MA ogni funzione in quella libreria statica è esposta all'applicazione nel suo complesso, mentre solo le funzioni pubbliche e 'SAFE' sono esposte all'applicazione che utilizza un database oggetto di accesso. Il programmatore non può chiamare accidentalmente una funzione pericolosa che, se non correttamente inizializzata da altre funzioni, potrebbe causare problemi importanti, né il programmatore potrebbe sopprimere deliberatamente errori o altri dati protetti dalla classe come potrebbero con un gran numero di funzioni statiche e variabili globali.

Mentre una buona applicazione può essere progettata senza oggetti, un buon programmatore dovrebbe godere dell'utilizzabilità, dell'estensibilità e delle protezioni che gli oggetti offrono quando appropriato.

Partirò con la mia metafora finale. Gli oggetti sono come macchine e strumenti specializzati all'interno di una fabbrica. Mentre la fabbrica stessa ha un numero di questi strumenti unici sulla sua catena di montaggio, dai semplici freni di piegatura alle macchine CNC e robot automatizzati, sono solo una piccola parte del team che esiste per aiutare i più numerosi lavoratori e manager, i nostri statici funzioni, fare il lavoro di costruire una macchina, un camion o una bicicletta migliore.

Answer 2

Penso che tu abbia qualche brutta visione della programmazione OOP perché non lo fai mai. Quake 3 è redatti utilizzando puro C senza classe e OOP, allora questa è una prova che si può fare buone cose senza usare OOP.

Ma se vuoi puoi usarlo. L'ereditarietà nelle classi ha una piccola funzionalità nella pratica logica di programmazione aziendale, molto meglio nella programmazione di quadri.

Se si decide di programmazione con OOP poi scrivere piccoli oggetti con piccole funzioni che fare le cose piccole, non grandi classi non leggibili con lunghi non funzioni non intuitive, quindi si rimanere pulita nel codice.

Answer 3

Date un'occhiata a questo:

Le classi sono poco più di un contenitore per le variabili e le funzioni interessano quelle variabili, ma può essere molto utile per la costruzione di piccoli componenti - quasi programmi miniture. La differenza è che non è necessario disporre di da shellare e possono essere inseriti nella maggior parte degli script con facilità - Basta richiedere o includere l'istruzione nella parte superiore. Una classe descrive un 'oggetto'. Un oggetto è una raccolta di oggetti più piccoli, solo come in una classe.

Reference

Answer 4

Se pensate dei vostri oggetti come rocce pesanti, che potrebbe essere una buona cosa. Dato che php non è molto per natura (tranne alcune estensioni predefinite), le funzioni procedurali sono sufficienti, circa 6000, non è vero?

Ti incoraggio a continuare con OOP. Tuttavia centinaia di classi sembrano esagerate. Per i principianti, metti tutto ciò che ti serve in un oggetto e dividi le sottoclassi quando opportuno.

Answer 5

Non c'è una risposta semplice a questo.

Mentre in generale è necessario attenersi a un approccio funzionale o OO, una delle cose carine di PHP rispetto a, ad esempio Java, è che consente le funzioni come entità di prima classe.

La cosa più importante da ricordare è che si scrivono programmi in un linguaggio e uno stile che li rende leggibili dagli esseri umani! Il fatto che il computer possa analizzarli è praticamente una coincidenza.

Certamente l'overhead di chiamare un metodo statico rispetto a una funzione non dovrebbe essere una considerazione - e tu sei sicuramente colpevole di ottimizzazione prematura. Se sei preoccupato di questo, perché non lo misuri per te? Scoprirai che mentre è più lento, la differenza è molto piccola - e non dovrebbe ignorare gli obiettivi primari quando scrivi il codice (cioè dovrebbe funzionare, dovrebbe essere il più chiaro possibile come funziona, non dovrebbe avere alcun lato -Effetti).

Answer 6

Non utilizzare OOP per raggruppare insieme un insieme di funzioni apparentemente correlate.

Utilizzare OOP per avere rappresentazioni logiche di "cose" di stato e di stato che possono essere manipolate, avere attributi o essere utilizzate in vari modi.

Non utilizzare OOP solo perché qualcuno qui dice che dovresti.

Utilizzare OOP perché si vede il vantaggio in data encapsulation.

Non utilizzare OOP se pensi che possa rendere felice il tuo capo.

Utilizzare OOP perché si ottiene che un Tacoma è un Toyota è un passeggero. Veicolo è un veicolo.

Non utilizzare OOP finché non si è almeno guardato oltre i modelli di progettazione della Gang of Four - i vantaggi diventano più chiari.

Utilizzare OOP perché si desidera fornire alle persone che svilupperanno questa classe interfacce facili da utilizzare.