Crea l'oggetto solo per chiamare una funzione in PHP. È brutto come penso? Come ridisegnare?

Question

Crea l'oggetto solo per chiamare una funzione in PHP. È brutto come penso? Come ridisegnare?

#1 da (1 voti)

0

Recentemente sono stato assunto in un'azienda e mi è stato chiesto di aiutare a scrivere un'API rimasta incompiuta. Non ho ancora molta esperienza, quindi non sono mai troppo sicuro di quali siano le buone pratiche di codifica.

Questa API verrà utilizzata in seguito per creare un'interfaccia Web che mostri informazioni sull'applicazione sviluppata dalla società. Sia l'applicazione che l'API sono scritte in PHP.

L'API è fondamentalmente un singolo file con una grande lista di funzioni (circa 300). Ogni funzione chiama un'altra funzione nell'applicazione. Per ogni funzione viene applicato lo stesso modello:

Crea l'oggetto contenente la funzione che desidera chiamare.
Chiama la funzione da questo nuovo oggetto e memorizza il suo risultato.
Restituisce il risultato.

L'oggetto stesso non viene mai restituito o referenziato. Sembra davvero strano dover creare un oggetto e distruggerlo ogni volta che vuoi fare qualcosa. Rende il design object oriented completamente inutile.

Ho quindi esaminato il codice dell'applicazione. Per riassumere, l'architettura è fatta in questo modo:

C'è un "database" di grande classe che si collega al database e fa un sacco di altre cose.
Ci sono molte altre classi (circa 40) che sono figli del Database. Fondamentalmente elaborano i dati e creano query SQL per comunicare con il database. Ciascuna di queste classi è correlata a un argomento, ad esempio esiste la classe "Punteggio" che fornisce le funzioni per ottenere o aggiornare il punteggio da alcuni o da tutti gli utenti. Ma nessuna di queste classi ha attributi (eccetto quelli del Database), sono solo usati per comunicare con il database.

Ora capisco la logica dietro questa strana progettazione dell'API. Dal momento che queste classi sono utilizzate solo come strumenti di comunicazione, è sufficiente creare l'oggetto per chiamare una funzione e funzionerà.

Quindi le mie domande sono:

Quanto è grave creare un oggetto solo per chiamare una funzione?
Se non funziona correttamente, dovrei riprogettare solo l'API o l'applicazione e l'API? E come?

design php

posta Kalaeman 02.11.2017 - 17:50

fonte

1 risposta

Leggi altre domande sui tag design php

richiede file in nodejs - singoli file o gruppi? Come posso eseguire la produzione come le distribuzioni utilizzando un server artefatto che impone il controllo delle versioni semantiche con artefatti che non hanno ancora ricevuto una versione?

score 1 · Accepted Answer

Non esagerare nell'heap e dovresti stare bene. Se hai obbedito al principio che i costruttori non dovrebbero fare il vero lavoro allora la creazione dell'oggetto è come costoso come aggiunta puntatore.

Anche se non lo fosse, preoccuparsi di ciò è probabilmente un'ottimizzazione prematura. Se si deve speculare, si supponga che il codice sia veloce ma difficile da leggere per gli umani fino a prova contraria. In oltre 20 anni le uniche buone ottimizzazioni delle prestazioni che ho fatto senza dati rigidi sono state il tipo che la grande notazione O ti insegna. Questo non è uno di quelli.

Questo non vuol dire che non ci siano problemi qui. Quello che stai guardando sono oggetti usati come funzioni. Questo non è tragico, ma non è un progetto utile. Se stai guardando il codice come

$result = new Employee()->getIDBySSN($ssn);

quindi potrebbe anche essere utile

$result = Employee::getIDBySSN($ssn);

Perché sei altrettanto legato a un'implementazione di getIDBySSN() . Forse non ti importa di questo. Se non lo fai, allora va tutto bene. Se stai pensando che il metodo statico sembra migliore, forse perché è più familiare, beh, allora va bene. Non penso sia meglio. Quello che penso sia meglio è questo:

$result = $employee->getIDBySNN($ssn);

Perché? Perché ora non so esattamente quale implementazione sto usando. Ciò significa che altre implementazioni possono essere sostituite qui. Significa anche che devi fare più lavoro perché ora qualcos'altro (preferibilmente un'altra classe) deve capire quale implementazione usare qui e consegnarla a te.

Questo è chiamato separare la costruzione dal comportamento. È molto potente Conserverà la capacità di usare il polimorfismo. Ma non è economico. Spetta a te se ne vale la pena prendersi cura. La migliore regola empirica per se questo è OK che ho trovato è quanto sia stabile la cosa concreta che ti leghi a te stesso. Non mi sono mai pentito di aver usato String o collezioni di raccolte di base in questo modo. Tuttavia, altre cose, soprattutto dalla mia base di codice, mi hanno fatto desiderare di avere una macchina del tempo in modo da poter tornare indietro e urlare a me stesso.

Oltre a questo, no, creo oggetti temporanei senza nome (il termine di fantasia per questo) tutto il tempo. È solo una parte del costo di fare affari.