Converti codice procedurale in object oriented

Question

Converti codice procedurale in object oriented

#1 da (7 voti)

3

Ho un'applicazione PHP (un servizio web). Consiste di file raggruppati in directory per tema come:

    /customer
        /search.php

con questo esempio di contenuto:

Auth::authenticate($options);
$db = new Db($options);
$db->query("select ... ");
echo json_encode($db->fetch_all();

Un modo semplice per convertire questo codice in codice orientato agli oggetti sarebbe quello di mappare un URL /object/method.php al metodo $ Object- > ($ post_parameters) usando un router di base. Il codice di esempio precedente diventerebbe (nel file /Customer.php):

class Customer
{
    function search($post_parameters)
    {
        Auth::authenticate($options);
        $db = new Db($options);
       $db->query("select ... ");
       echo json_encode($db->fetch_all();
   }
}

I vantaggi

È facile convertire il codice, non ci vorrà molto tempo.
Posso usare l'autoloading delle classi.

Svantaggi:

È solo formalmente orientato agli oggetti. Rimane ancora principalmente il codice procedurale.
Io chiamo ancora Auth :: authenticate () e creo un nuovo Db in ogni metodo (ma non sempre con gli stessi parametri).

Sono sulla buona strada? C'è un modo migliore per avvicinarsi a quel refactoring del codice? O c'è un ovvio passo successivo?

Pensi sia quello che ho descritto come caso di uso legittimo per codice procedurale? C'è una via di mezzo tra questo e un approccio orientato agli oggetti con una struttura completa come la struttura di Zend per esempio?

object-oriented refactoring procedural

posta Lorenz Meyer 18.11.2014 - 22:17

fonte

1 risposta

Leggi altre domande sui tag object-oriented refactoring procedural

Gli argomenti più efficaci a favore del miglioramento della qualità del codice, per un manager [chiuso] Come evitare lunghe catene di chiamate?

score 7 · Accepted Answer

Non c'è niente di male che non possa essere usato come un cattivo esempio, almeno. Per me, il tuo esempio non è nemmeno "formalmente orientato agli oggetti", è altrettanto procedurale dell'originale. L'unica cosa che hai notato è lo spazio dei nomi in cui la funzione di ricerca "vive".

Un oggetto del cliente dovrebbe rappresentare i dati e alcune logiche di business di un cliente (non c'è nemmeno un attributo nella tua classe e il metodo di ricerca non funziona su un oggetto cliente). Una funzione di "ricerca" per i clienti potrebbe restituire un oggetto cliente o una raccolta di oggetti cliente (l'eco di una stringa json non ha nulla a che fare con quello). Tale funzione probabilmente non è una funzione membro di una classe cliente (potrebbe essere inserita lì come funzione statica o altrove, ad esempio in CustomerFactory ). E una ricerca cliente ragionevole dovrebbe evitare l'accoppiamento con attributi e metodi globali (come $ options, Db o Auth :: authenticate).

Quindi, se il tuo obiettivo è quello di introdurre più "struttura orientata agli oggetti" nel tuo programma, potresti stare meglio facendo prima un po 'di design in anticipo. Ad esempio, inizia prima progettando una classe cliente e pensa a come deve apparire una funzione di ricerca per la pubblicazione di tali oggetti.