Voglio sapere perché usiamo le classi in php. Ho visto in tutto l'open source che usano le classi per eseguire query. Significa che usano le classi per ottenere risultati, inserire query, ecc. Penso che questo sia usato per coerenza e velocità, ma siccome le mie conoscenze se eseguiamo query usando mysql_query(), piuttosto che creare un collegamento oggetto $db->query, si eseguirà velocemente come confronta con il secondo perché in oggetto goto la funzione e poi la esegue lì e dopo restituisce il risultato ma in caso di mysql_query() eseguirà la query nello stesso posto. Quindi penso che lo mysql_query() verrà eseguito velocemente. Quindi, perché utilizziamo classi e oggetti per eseguire query, quali sono i vantaggi dell'utilizzo delle classi?Perché utilizzare le classi in php?
risposta
Incapsulamento: una classe è un pacchetto utile contenente il codice ei dati rilevanti insieme, isolati da tutto il resto. Ciò rende più facile spostarlo senza cercare le variabili esatte, senza conflitti con codice/dati esistenti.
Naturalmente le classi hanno altri usi ma in ambienti di scripting come PHP, penso che il più grande vantaggio sia quello.
EDIT: Sono stato obiettato con argomento "l'ereditarietà è più potente di incapsulamento". Penso che ciò non si applichi agli script e agli scenari web e proverò a spiegare perché:
Primo, la durata di una pagina web è una coppia richiesta/risposta e idealmente meno di un secondo. Lo stato è generalmente conservato in entità esterne (sessione, cookie, db ecc.). Dal momento che la durata della pagina è molto breve, gli stati possibili in un codice di una pagina web sono inferiori, ad esempio, a un fat client. Sono quasi sempre piccole esplosioni di codice che corrono e finiscono il lavoro continuamente. Probabilmente una pagina web è paragonabile a un'applicazione console in termini di semplicità e numero di parametri di progettazione. Sebbene il numero di parametri di input possa essere un gigabyte in una forma, la relazione tra gli elementi dell'interfaccia utente e i parametri di input sono limitati alla risoluzione dello schermo, la capacità complessiva di un utente a ciò che lui/lei può riempire in una sola volta. Pertanto nella maggior parte dei casi abbiamo un numero limitato di parametri di input, ovvero un numero minore di stati. Ovviamente nel mondo combinatorio e "mutevole" ciò non è vero, ma nel caso delle "tipiche applicazioni web", anche lo stato interno è piccolo, rendendo quindi plausibile la mia affermazione.
L'input e l'output in un'applicazione Web sono principalmente gli stessi: Input è parametri di query o dati di modulo e l'output è un documento HTML. Pertanto, nella sua breve durata, il codice di input processing e output production è similmente modellato e progettato per una pagina web. Sono consapevole del fatto che ho omesso una grande parte della "logica aziendale" nell'immagine e ci arriverò. Tuttavia, assicuriamoci di non aver bisogno di nifty features di OOP come "polymorphism" e "inheritance" in queste parti del nostro codice. Esistono modelli molto noti, a lungo studiati, pratici e non OOP. Sarebbe quantomeno stupido inventare nuovi modi di analizzare i parametri della query usando "polimorfismo", "modello di visitatore" ecc.
L'accesso ai dati viene eseguito anche da librerie esistenti e lussi come "ereditarietà" o "polimorfismo" non hanno usare lì. Puoi ancora usare le classi, ma sarebbe semplicemente un incapsulamento. Non è possibile ereditare/riutilizzare il codice MySQL per scrivere codice T-SQL o PL/SQL. Hai bisogno di una sostituzione completa. Oh forse il tuo SELECT * FROM table potrebbe essere "ereditato" e pensare alle possibilità, wow.
Ora che cosa abbiamo lasciato? Sì, la logica del business. Abbiamo già accennato al fatto che la logica di business è anche un breve processo di elaborazione delle informazioni. Non esiste uno stato aziendale persistente nel codice PHP stesso. Sappiamo che quasi tutte le operazioni aziendali devono richiedere meno di un secondo a causa dei requisiti del Web. Pertanto, gli stati che puoi superare, di nuovo, sono molto meno di un'applicazione completa. Si dispone di operazioni aziendali atomiche e isolate in corso per la maggior parte dei casi in una tipica applicazione Web.
Ora torniamo al design. Sappiamo che la nostra pagina è costituita da queste parti:
- ingresso
- logica di business
- accesso ai dati
- uscita
Abbiamo già ottenuto in ingresso, dati, uscita fuori della portata del polimorfismo e dell'eredità. Qui è la nostra immagine finale:
elaborazione ingresso- logica di business
accesso ai dati
produzione di uscita
Althoug h la logica di business potrebbe essere la parte più grande della nostra app, deve ancora essere nella nostra seconda finestra in un'applicazione web quindi deve essere small, alias short life.
Sì, un supercomputer può fare molto in un secondo, ma stiamo ancora parlando in termini di maggioranza, scenari comuni. Cosa è comune? CRUD è comune. Ecco perché il pattern di Ruby on Rails e Active Record è un tale successo e ha guadagnato una tale popolarità perché ha aumentato la produttività su una cosa: CRUD.
La complessità di un progetto è proporzionale al numero di elementi di dati e operazioni coinvolte. E poiché riteniamo che la maggior parte delle operazioni siano CRUD, abbiamo un numero fisso di operazioni e un piccolo numero di parametri di input, abbiamo un piccolo spazio di problemi.
Ci possono essere delle eccezioni, ma per la maggior parte dei casi un progetto per un piccolo spazio problematico non può essere complesso e buono allo stesso tempo. È molto improbabile che tu possa utilizzare l'ereditarietà nel design di una pagina web a meno che non ci sia una grande quantità di punti dati e troppe ridondanze in corso. Ripeto, per la maggior parte dei casi, è crudo CRUD.
In secondo luogo, (sì, c'era una prima all'inizio nel caso in cui si è dimenticato), le prestazioni web app è importante (se non critico) -Ricordarsi "Un secondo" - e in un ambiente di scripting è due volte più importante.
Il paradigma object-oriented si basa su un meccanismo di basso livello molto importante per essere utile e performante allo stesso tempo: puntatore indiretto. La capacità di una CPU di leggere puntatori e saltare all'indirizzo indirizzato con quasi nessuna differenza che saltare direttamente all'indirizzo. In questo modo possiamo avere una tabella dei metodi virtuale utilizzata per le ricerche per la chiamata della funzione corretta e in questo modo il compilatore può chiamare il metodo "some()" dell'oggetto senza conoscere il suo tipo esatto perché è proprio quello che c'è nel puntatore lì, ma si comporta ancora come un cavallo Pazzo.
Questo sogno finisce nel mondo dello scripting. Non hai una CPU in esecuzione in modo nativo istruzioni.Hai i bytecode prodotti dal compilatore PHP e questo è interpretato dall'interprete di PHP. A differenza di una CPU, l'interprete PHP ha a che fare con concetti di livello superiore come astrazioni, classi, tipi indipendentemente dal fatto che si tratti di un bytecode. Il semplice puntatore indiretto per una CPU è un complesso insieme di operazioni per PHP. Analisi dell'operazione, comprensione dell'operazione, esecuzione di alcuni controlli di integrità e infine esecuzione di un altro set di bytecode.
Pertanto, l'overhead dell'ereditarietà in un mondo di scripting è di ordini di grandezza più lenti rispetto a un ambiente nativo.
Ovviamente è accettabile, a condizione che i guadagni siano più che perdite. E pensando che la perdita di prestazioni può essere recuperata in altri modi, come l'aggiornamento, il clustering, non sembra un problema. Questo è certamente vero ed ecco la mia dichiarazione finale:
Per la maggior parte degli scenari nello sviluppo di applicazioni Web, è possibile ottenere un progetto ugualmente manutenibile, ugualmente riutilizzabile e possibilmente più performante senza richiedere ereditarietà/polimorfismo, quindi l'incapsulamento è il più comune e il più grande vantaggio in PHP, non ereditarietà.
Questo diventa un aspetto sempre più piccolo delle cose per progetti più grandi e ben progettati. La modularità è grande, ma l'ereditarietà e il riutilizzo sono molto più potenti di questo solo. Mi piace la risposta @ Prisoner molto meglio. – zanlok
@zanlok, È vero in senso generale, ma non penso che si adatti molto bene allo scripting e alla maggior parte degli scenari web. Proverò a spiegarlo nella mia risposta. –
@zanlok, modificato. –
Ci sono molti motivi per utilizzare le classi o OOP (Object Orientated Programming).
- il riutilizzo del codice
- Inheritance
- Più facile manutenibilità
- incapsulamento
Ci sono molte altre ragioni, si deve solo guardare in alto i vantaggi/svantaggi di usare OOP.
Tempo preso il mio
$db->query()
mysql_query()
è quasi lo stesso.
Non usiamo le classi per eseguire il codice più velocemente ma per organizzarle.
Man mano che il progetto diventa sempre più grande, avrai difficoltà a gestire il tuo codice.
Se si obietta, è possibile creare un'istanza di tale oggetto e utilizzarli di nuovo, e inoltre il codice ha meno possibilità di essere incasinato con gli altri.
La modalità di codifica orientata agli oggetti è la procedura più semplice e migliore per gestire il codice in modo elegante e quindi produrre risultati migliori.
Come detto da @frbry, usiamo le classi per l'astrazione. L'astrazione è necessaria per gestire e ridurre la complessità. Quando sei in grado di "astrarre" operazioni e dati, puoi concentrarti su altre cose e non pensare all'implementazione delle cose "isolate e astratte" quando fai altre cose.
Aiuta anche a cambiare il sistema in futuro con impatti minori su altre parti del codice, e di nuovo riduce la complessità di un sistema.
C'è una buona lezione del MIT del 1986 che riguarda generalmente la programmazione LISP, tuttavia descrive anche molto bene, perché è necessario astrarre le cose nelle procedure (o nelle black box che chiamano) - il punto che fanno è che lo sviluppo del software si basa sulla riduzione della complessità.
Ecco il link: http://www.youtube.com/watch?v=2Op3QLzMgSY
quando usiamo mysql_query() è necessario collegare prima al DB con mysql_connect() e mysql_select_db().
Ogni volta che si effettua un mysql_connect() costo.
Quindi verrà effettuata una volta mysql_connect() e verrà salvato il $link. E usa questo link per ogni mysql_query("...", $link)
In oggetto è lo stesso, ma è più elegante che tu possa creare un'istanza della classe (quindi creare una connessione al DB) e utilizzare l'oggetto abbia un collegamento.
Se si modifica la password del DB, la si cambierà una sola volta, solo nella classe.
Se si modifica MySQL per PostgreSQL, si riscriverà il codice una sola volta, solo nella classe. Non influenzerà il resto della tua app.
Non si tratta solo di prestazioni. Personalmente, uso le classi per l'astrazione. – frbry