È questo l'approccio corretto per una struttura di progettazione OOP in PHP?

Naviga le tue risposte
5

Sto convertendo un sito basato su procedurale in un progetto OOP per consentire un codice più facilmente gestibile in futuro e finora ho creato la seguente struttura: 

/classes
/templates
index.php

Con queste classi: 

ConnectDB
Games
System
User
User   -Moderator
User   -Administrator

Nel file index.php ho un codice che rileva se sono presenti valori di $_GET per determinare su quale contenuto della pagina deve essere compilato (è presto, quindi c'è solo un esempio e nessun valore predefinito): 

function __autoload($className) {
    require "classes/".strtolower($className).".class.php";
}

$db = new Connect;
$db->connect();

$user = new User();

if(isset($_GET['gameId']))
{       
    System::buildGame($gameId);
}

Quindi esegue la funzione BuildGame nella classe di sistema che assomiglia a quanto segue e quindi usa entra nella Game Class per restituire valori, come $game->getTitle() nel file template template/play.php : 

function buildGame($gameId){

    $game = new Game($gameId);
    $game->setRatio(900, 600);

    require 'templates/play.php';
}

Ho anche .htaccess in modo che l'effettivo URL della pagina di gioco funzioni invece di passare i parametri a index.php

Ci sono degli errori importanti su come sto configurando questo o ho l'idea generale di OOP corretta?

    
posta Dan 03.01.2012 - 15:04
fonte

4 risposte

11

Per quanto riguarda l'OOP, non c'è mai un modo giusto o sbagliato . Ci sono sempre più strade che portano a Roma.

Tuttavia, ci sono alcuni avvertimenti da evitare. La tua classe System ha l'aspetto di un oggetto God , che è un cosiddetto "anti-pattern". Meglio evitare quelli. Inoltre, sospetto che tu stia utilizzando $db e $user come variabili globali, quelle non sono incoraggiate in OOP. È meglio passare l'handle DB alle classi che ne hanno bisogno, sia in fase di costruzione che, ad esempio, con un metodo setDatabase() (questo è chiamato Iniezione delle dipendenze e facilita la supervisione, la manutenzione e il debug delle tue lezioni.

Infine, un autoloader potrebbe rendere un po 'più facile il tuo lavoro di programmatore . Questo prenderà il compito di fare le chiamate require dalle tue mani e ti costringerà anche a strutturare il tuo codice in modo logico:)

    
risposta data 03.01.2012 - 15:16
fonte
2

Potresti dare un'occhiata a un MVC ... stai già dividendo i tuoi template e le tue classi per i componenti View e Model / Controller), ma cerca di dividere le tue classi in modelli e controller

    
risposta data 03.01.2012 - 15:18
fonte
2

Potresti utilizzare un autoloader per caricare tutte le tue classi per te.

Potresti vedere come ho provato a farlo in my (m) vc .

    
risposta data 03.01.2012 - 15:15
fonte
1

Quindi probabilmente è troppo vecchio per me per aiutare l'OP in qualsiasi modo, e non sono un esperto. Tuttavia, mi piacerebbe supportare @Rijk & la loro risposta accettata con un po 'più di struttura e amp; alcuni libri di riferimento (obsoleti come i libri stanno iniziando a essere questi sono, a mio parere, quelli buoni).

Quindi l'OOP moderno è per lo più incentrato sull'acronimo SOLID .
Responsabilità unica, principio Open-closed, sostituzione di Liskov, segregazione di interfaccia e amp; Inversione delle dipendenze (quasi una citazione esatta dal link).

Sono definiti meglio nell'articolo collegato di quanto potrei renderli giustizia, ma qui ci sono i concetti generali a cui la maggior parte di questi elementi si adattano (ma, per quanto ne so, meno termini dal punto di vista tecnico):

  • Fai una cosa e amp; fallo bene
  • Tentativo di mantenere gli oggetti di programmazione più piccoli e amp; più semplice piuttosto che più grande e amp; complesso (puoi ancora costruire sistemi complessi con parti meno complesse e rende molto più facile comprendere ogni parte del sistema complesso ... ed evitare e correggere bug)
  • Costruisci le tue classi in modo che seguano quanto sopra E così puoi aggiungere funzionalità a loro SENZA cambiare il codice che compone la classe (quando cambi codice funzionante stai sempre mettendo a rischio la creazione di bug)
  • Progetta concetti e idee prima di progettare il tuo codice
  • Quando un concetto è implementato in codice, crea un'interfaccia per esso e tutto ciò che si adatta a quel concetto dovrebbe supportare la stessa interfaccia e amp; quell'interfaccia al concetto NON dovrebbe cambiare
  • In base a quanto sopra, crea più interfacce e amp; più concetti dietro di loro se le interfacce che hai creato non sono sufficienti (piuttosto che rendere l'interfaccia che hai definito più complessa)
  • Evita anche catene di ereditarietà complesse e utilizza invece la composizione di oggetti


Probabilmente ho perso un certo numero di punti importanti e / o non sono riuscito a trasmettere le idee corrette in ciò che ho detto così, ai libri di riferimento. Questi libri mi sono stati raccomandati da più programmatori con più esperienza, esperienza, e amp; conoscenza di me. Quindi con quella raccomandazione:

Il secondo è un eccellente libro su come scrivere buoni software e amp; tirare fuori progetti software e amp; piano & design & ... solo un sacco di altre cose preziose.
Il primo è più accessibile in generale ed è una risorsa davvero grande per l'apprendimento, beh ... probabilmente tutti i principi trattati nell'acronimo SOLID.
Il concetto generale sembra essere meglio descritto come:
scrivere relativamente software privo di errori attraverso la scrittura di parti di codice più piccole che hanno dimostrato di funzionare, che non devono essere modificate quando si aggiungono ulteriori funzionalità.

Spero che sia utile a qualcuno.

    
risposta data 03.12.2015 - 10:18
fonte

Leggi altre domande sui tag

Scrittura di funzioni ricorsive Come posso evitare gli errori usando di nuovo lo stesso nome di variabile?