File di utilità in php?

Question

Qual è il modo migliore per gestire le funzioni di "utilità" in un framework PHP OOP? Al momento, abbiamo solo un file con diverse funzioni necessarie in tutto il sistema. (Ad esempio, una funzione distribute() che accetta un valore e una matrice e restituisce una matrice con il valore distribuito nelle stesse proporzioni e le stesse chiavi dell'array di input.)

Mi sono sempre sentito "sporco" usando quello perché non è affatto orientato agli oggetti. È una pratica migliore spostare questi in varie classi come metodi statici, o è solo una soluzione semantica? O ci sarà solo un livello in un framework in cui alcune cose stanno per cadere fuori dalla struttura OOP?

Answer 1

Sono sempre stato più pragmatico su domande come queste.

Se si desidera eseguire l'OOP completo, è necessario inserirli in classi. Tuttavia, queste classi saranno solo classi contenitore, perché in realtà non rappresentano oggetti di alcun tipo.

Inoltre: l'utilizzo delle classi richiederebbe di avere un'istanza di tale classe, utilizzando il modello singleton o dichiarando ogni funzione statica. Il primo è più lento (ok, potrebbe non essere poi così tanto, ma in un framework di grandi dimensioni anche cose come questa diventano grandi - specialmente nei linguaggi interpretati come PHP), mentre il secondo e il terzo sono semplicemente inutili e semplicemente un wrapper OOP per un insieme di funzioni (in particolare il terzo approccio).

EDIT: Sentitevi liberi di mettermi in errore. Potrei essere. Non sono troppo esperto e l'ho sempre visto in quel modo, ma potrei sbagliarmi.

Answer 2

Penso sempre alle funzioni di utilità come estensioni delle funzioni php standard. Non sono orientati agli oggetti perché non ottieni alcun beneficio dal renderli OO.

Answer 3

Tendo a creare una classe Util() che contiene solo metodi statici, non ha attributi e non viene ereditata da. Essenzialmente, agisce come uno "spazio dei nomi" per un gruppo di funzioni di utilità. Consentirò a questa classe di crescere di dimensioni, ma occasionalmente dividerò i metodi nelle proprie classi se è chiaro che quei metodi sono progettati solo per lavorare con determinati tipi di dati o se è chiaro che un gruppo di metodi correlati dovrebbe essere raggruppato in una classe insieme, forse, ad alcuni attributi.

Penso che sia perfettamente corretto deviare dalle pratiche puramente OOP fintanto che il codice che devia è ben organizzato e non crea difetti architettonici nel sistema che rendono più difficile la comprensione e la manutenzione.