Domanda

Problema

Supponiamo di avere un utente di classe. Si desidera essere in grado di restituire questo oggetto utente ad altri in modo da poterlo utilizzare per estrarre informazioni usando i getter. Tuttavia, non vuoi che le persone siano in grado di impostare prontamente lo stato interno perché le informazioni interne dovrebbero relazionarsi direttamente a una riga nel database. Ha senso avere mutatori protetti (setter) in modo che solo una classe estesa possa impostare le variabili? È una cattiva pratica, irrilevante, eccessiva o inutile?

Ho considerato di provare a limitare __construct a un uso (credo che questo sia a volte arbitrato come un modello singleton - anche se non sono sicuro di capire del tutto.)

Sono un programmatore dilettante, perdona ogni ignoranza. Grazie.

Esempio:

<?php

    class user
    {

    private username;

    protected function set_username($username)
    {
        $this->username = $username;
    }

    public function get_username()
    {
        return $this->username;
    }

?>
È stato utile?

Soluzione

Dipende. Se nulla in particolare non deve accadere quando lo stato è cambiato, puoi lasciare del tutto gli setter. Qualsiasi sottoclasse avrà accesso diretto alle proprietà che sono impostate o più allegre.

Se hai bisogno che accada qualcosa quando lo stato cambia (ad esempio avere un aggiornamento del database quando lo stato cambia), i setter renderà la tua vita molto più semplice, poiché la chiamata al codice di aggiornamento del database viene inserita nel setter. Ciò significa che se si passa sempre attraverso il setter, il DB aggiornerà sempre quando si cambia lo stato dell'oggetto.

Quindi in breve, dipende.

Altri suggerimenti

Se hai un costruttore che accetta un ID, ad esempio, perché vorresti avere setter. Non c'è regola che ti costringe a dare un set di oggetti solo perché ha getter. Se la tua usecase sta costruendo l'oggetto da qualche parte e successivamente usalo solo per estrarre dati da esso, non è affatto creare nessun setter.

L'estensione degli oggetti può manipolare le variabili della classe protetta stessa in modo che non richiedano anche alcuna forma di setter. Se non vuoi che il "mondo esterno" sia in grado di impostare qualcosa sulla classe, non permetterlo.

Il tuo codice è totalmente multa e IMHO incapsula perfettamente. TT supporta anche un accoppiamento sciolto.

Per un utilizzo più facile, è possibile aggiungere tutti i membri necessari (devono avere) come parametri del costruttore.

Per quanto riguarda il modello singleton, usalo con cura. Gli utenti in comune non sono singoli. Fare riferimento al refactoring ai modelli (Joshua Kerievsky).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top