Gestire dipendenze opzionali di classe

Question

Gestire dipendenze opzionali di classe

#1 da (1 voti)

4

Mi chiedo come stai gestendo le proprietà di una classe opzionale. Diciamo che ho un prodotto che può nascere non deve avere una proprietà color . È davvero il modo migliore per farlo? Dovrei usare il modello di oggetto nullo? Dovrei usare il modello di strategia forse? Dovrei forse usare un motivo decoratore qui così avrò Product e ProductWithColor ? Cosa succede se verrà aggiunta un'altra proprietà e diventerà facoltativa?

<?php

class Product
{
    private $id;
    private $title;

    /**
     * @var string|null
     */
    private $color;

    function __construct($id, $title, array $color = null)
    {
        $this->id              = $id;
        $this->title           = $title;
        $this->color           = $color;
    }
}

object-oriented design design-patterns

posta acid 15.08.2014 - 09:19

fonte

1 risposta

Leggi altre domande sui tag object-oriented design design-patterns

Design Pattern per analizzare array di oggetti Installazione client server API

score 1 · Answer 1

What if another property will be added and become optional?

Ho fatto esattamente questo quando ho dovuto iniettare alcune nuove funzionalità in quel metodo. Questo non infrange il codice esistente; devi amarlo! Nel mio caso ignoro la nuova cosa se il parametro è nullo.

I generally prefer to use a more meaningfully named value/enum. For example, "Unassigned/Unknown/NotSet".

Non sono assolutamente d'accordo con questo (citazione da un commento). Fare questo con una stringa è una grande seccatura - errori di battitura, intelaiatura, mancanza di controllo del tipo (io faccio C #). Tuttavia se questo era un enum allora assolutamente, avere un valore enum "non definito" (in C # avrei questo corrisponde a zero perché questo è il default per enumerazioni).

Should I use null object pattern?

Non esattamente. Abbiamo a che fare con una singola proprietà, ma l'idea è la stessa. Rendi i parametri del metodo facoltativo / predefinito comportarsi in modo corretto. Ad esempio, ho impostato i miei parametri di stringa facoltativi su string.Empty (C #) in modo che i membri su di esso non vengano visualizzati.

Should I use strategy pattern maybe? Should I maybe ...

No. La strategia è per il comportamento polimorfico - cioè funzioni / metodi con gli stessi parametri (firma) su tipi diversi.

I parametri facoltativi sono una tecnica per la creazione di overload di metodi concisi.

I'll have Product and ProductWithColor

Bene, se il tuo progetto lo richiede, ma sospetto di no. Perché stai lasciando che un singolo parametro opzionale per una singola funzione guidi il tuo design? null ha "richiesta gestione speciale", certo, ma lo stesso vale per qualsiasi proprietà con qualsiasi valore che abbia un significato speciale. Qui è solo un meccanismo per consentire al codice client di ignorare il colore per la chiamata. Com'è una classe completamente diversa?