Statico e non statico: teoria quantistica programmatore

0

Lascia che ti illustri usando il linguaggio PHP. La discussione qui è, come dovrei fare esattamente per risolvere questo problema in modo chiaro e non ambiguo.

Immagina di avere una classe chiamata Path . Questa classe è responsabile della definizione di un oggetto che fa riferimento a un percorso di un file, ad esempio. Questa classe mi aiuta con alcune attività, ad esempio:

$pathInstance = new Path("path/to/file.bin");
$pathInstance->exists();             // Return if file exists.
$pathInstance->get_dirname();        // Return the dirname of file.
$pathInstance->get_basename();       // Return the basename of file.
$pathInstance->is_file();            // So on...

Tuttavia, c'è un problema in questa metodologia quando ho bisogno, allo stesso tempo, di utilizzare un metodo statico che consente di eseguire un'attività senza creare un'istanza. Ad esempio:

Quando chiamo is_file() controlleremo se il percorso interno se $this è riferito a un file. Ma voglio farlo anche in modo statico, ad esempio Path::is_file("path/to/file.bin") .

In PHP, questo non è raccomandato ed è necessario per eseguire una soluzione di base. E personalmente penso che non sia il concetto giusto da applicare.

Immagina di averlo:

class Path {
    /** @var string */
    private $path;

    /** @param string $path */
    function __construct($path) {
        $this->path = $path;
    }

    /**
     * Normalize the path.
     * @param  boolean $force_normalize Force even if path doesn't exists.
     * @return string|false
     */
    public function normalize($force_normalize = null) {
        if($force_normalize === true) { /* ... */ }
        return realpath($this->path);
    }
}

Così uso come:

$pathInstance = new Path("/abc/../def");
echo $pathInstance->normalize(); // output "/def"

Ma mi piacerebbe lavorare TRO staticamente, ad esempio:

echo Path::normalize("/abc/../def"); // output "/def"
    
posta David Rodrigues 10.10.2014 - 00:39
fonte

1 risposta

2

Per me, questa è una questione di design della classe.

Se stiamo progettando per linguaggi di implementazione di destinazione come C ++, Java e simili (se permetterete che siano raggruppati insieme), le domande sono

  • quali casi d'uso vuoi supportare?

  • come dovrebbero essere strutturate le loro interfacce?

  • in che modo questi due master possono essere supportati e bilanciati al meglio?

Hai dato un requisito per la prima domanda: vuoi metodi statici (di classe) e metodi dinamici (di istanza). Per un determinato metodo, per ora consente di chiamare questi due metodi classMethod e instanceMethod . Daremo loro nomi migliori più tardi.

Per la seconda domanda, le interfacce con i due metodi devono essere diverse. Al momento hanno nomi diversi, ma vorremmo che fossero uguali se facessero lo stesso lavoro. Quali sono le opzioni?

  • Potremmo inserirli in classi diverse, ma ciò renderebbe il nostro progetto più complesso.

  • Potremmo assegnare loro lo stesso nome e quindi avrebbero bisogno di diversi elenchi di parametri.

Il secondo è l'ideale per questo problema. Possiamo chiamare i nostri metodi myMethod() per la versione del metodo di istanza e myMethod(path) per la versione della classe.

Riguardo all'implementazione, potremmo fare in modo che il nostro metodo di istanza chiami il metodo di classe, passando il suo percorso. Oppure fai in modo che il metodo di classe costruisca un'istanza e quindi invochi il metodo di istanza. Dal momento che vedo alternative di implementazione ragionevoli, il mio lavoro di progettazione di classe di alto livello è terminato.

Quindi, in qualità di implementatore, le mie preoccupazioni saranno

  • quale approccio è più naturale nella mia lingua di arrivo?

  • voglio che la mia implementazione corrisponda ad altre implementazioni in altre lingue?

  • ci saranno evidenti performance perdite nella scelta di un'implementazione rispetto a un'altra? (Dico qui delle perdite, perché mentre desidero evitare l'ottimizzazione prematura, voglio anche evitare implementazioni "deliberatamente inefficienti").

Infine, data l'intuizione che un'implementazione non avrà un grande vantaggio sull'altra, implementerei myMethod () per chiamare myMethod (percorso).

Spero che ti aiuti.

    
risposta data 10.10.2014 - 02:34
fonte

Leggi altre domande sui tag