Qual è il livello pratico di astrazione in un'applicazione web? [chiuso]

Question

Qual è il livello pratico di astrazione in un'applicazione web? [chiuso]

#1 da (4 voti)

1

(Originariamente richiesto su StackOverflow - link )

Mi considero ancora un nuovo arrivato alla programmazione OO, specialmente in PHP, quindi perdonami se ho perso qualche principio fondamentale!

Supponiamo di avere un'applicazione intranet con un oggetto staff con proprietà e metodi univoci per essere membro del personale:

class staff {
    ...
    private $job_title;
    private $start_date;
    etc...
}

Nella ricerca di mantenere le parti manutenibili del mio codice in un unico posto, rendere il mio modello di dati più intelligente e rendere il mio codice meno strettamente accoppiato, è ragionevole astrarre ogni proprietà dell'oggetto ad un altro livello?

Ad esempio, mi aspetto che ogni proprietà abbia un value , ma per complicare le cose, sono interessato anche a cosa label e description usare quando ci si riferisce ad esso in applicazioni leggibili. Più interessante è quale type sia, così come la capacità dell'oggetto di validarsi, se anche le sue proprietà membro possono validarsi. Sembra quindi che le proprietà della maggior parte degli oggetti abbiano molto in comune. Pertanto, la proprietà $start_date potrebbe effettivamente essere un oggetto in sé:

abstract class property {
    public $value = NULL;
    protected $label; // A simple label which can be used on user forms, reports, etc.
    protected $description; // Some detail to describe what this property is used for
    protected $type; // Helps choose the right HTML form control and validate user input
    protected $regex; // Regular expression to prompt user entry and validate return value
    protected $unique = FALSE; // If TRUE, check for duplicates in the persistence layer
    protected $default_value; // Prompt the user when entering new values
    protected $HTML_form_element; // Which form element suits this field best?
    etc....
}

class start_date extends property {
    ...
    public function __construct(){
        ...
        $this->label = 'Start date'; // Might be an i18n entry
        $this->description = 'Enter the date on which the contract starts for this staff member'; // Might be an i18n entry
        $this->type = 'VARCHAR(512)'; // Better to use persistence layer's requirements?
        $this->regex = '/^([0-9]{1,2})[/.-]([0-9]{1,2})[/.-]([0-9]{2,4})$/'; // UK date
        $this->default_value = date('Y-m-d'); // Depends on the business policy of the company
        $this->HTML_form_element= 'datepicker'; // Chooses the correct HTML element when building forms automatically
        ...
    }
    etc...
}

class staff {
    ...
    public function __construct(){
        ...
        $start_date = new start_date();
        ...
    }
    etc...
}

Nelle precedenti applicazioni, queste cose correlate sono vissute in luoghi diversi; variabili globali casuali, codice commentato, oggetti decoratore, un file di configurazione, incorporato in HTML, una tabella di database, un pezzo di carta. Ha senso riunire tutte le proprietà di un oggetto in un unico posto, ma è questo il modo giusto?

object-oriented validation design-patterns php web-applications

posta Bendos 15.02.2013 - 15:05

fonte

1 risposta

Leggi altre domande sui tag object-oriented validation design-patterns php web-applications

Informazioni sulle classi e i loro stati validi Multitasking in C #

score 4 · Answer 1

I dati che stai descrivendo sono dati meta . Molte lingue hanno modi puliti per archiviare queste informazioni, come annotazioni . Il team di PHP come annotazioni native respinte più e più volte, ma Symfony2 e Doctrine2 hanno un'implementazione locale usando doc-block Commenti. Questo è lontano dalla soluzione ideale , ma è il miglior lavoro che abbiamo in questo momento. Questo è lo stesso modo in cui le annotazioni sono state create in Java prima le annotazioni native sono state implementate da Sun in Java 5.

Non sono sicuro che la soluzione Symfony / Doctrine sia disponibile come componente indipendente o meno. Penso che Symfony si affidi alla libreria comune alla dottrina per analizzare le annotazioni.

In ogni caso, controlla Formidazione del modulo di Symfony2

// Acme/TaskBundle/Entity/Task.php
use Symfony\Component\Validator\Constraints as Assert;

class Task
{
    /**
     * @Assert\NotBlank()
     */
    public $task;

    /**
     * @Assert\NotBlank()
     * @Assert\Type("\DateTime")
     */
    protected $dueDate;
}

Le informazioni che stai cercando di descrivere con una relazione ha-un sopra sono descritte in modo chiaro qui senza confondere il codice. Internamente, questi commenti vengono analizzati e memorizzati nella cache in puro PHP, in modo che possano essere consultati in fase di esecuzione.