2010-04-20 10 views
10

Nella maggior parte delle altre lingue orientate agli oggetti. sarebbe sacrilego che ciascuna funzione riceva un singolo array associativo di oggetti anziché enumerarne ciascuno nella firma del metodo. Perché, però, è accettabile e comunemente usato nei framework più diffusi per entrambi questi linguaggi?Perché gli array di configurazione sono parametri accettabili in PHP e Javascript?

C'è qualche giustificazione al di là del desiderio di avere firme di metodo concise?

Vedo un vantaggio in questo: l'API potrebbe rimanere invariata come nuova, i parametri facoltativi sono stati aggiunti. Ma Javascript e PHP consentono già parametri facoltativi nelle loro firme di metodo. Semmai, sembra che Java o un altro linguaggio OO trarrebbero beneficio da questo di più ... eppure raramente vedo questo schema lì.

Cosa dà?

risposta

2

Il motivo principale è che quelle particolari lingue semplicemente non supportano più convenzioni di chiamata per lo stesso nome di funzione. OSSIA non è possibile effettuare le seguenti operazioni:

public function someFunc(SomeClass $some); 
public function someFunc(AnotherClass $another); 
public function someFunc(SomeClass $some, AnotherClass $another); 

quindi è necessario trovare un altro modo per creare modi più semplici per passare le variabili in giro, in PHP si finisce con someFunc(array('some'=>$some, 'another'=>$another)), perché è l'unico modo conveniente. In JavaScript finiamo per usare gli oggetti, che non sono così male: someFunc({some: something, another: anotherthing})

10

A mio parere, molte di queste funzioni stanno salendo nel numero di argomenti che accettano, oltre 10 non è raro. Anche se fai parametri opzionali, devi ancora inviarli in ordine.

consideri una funzione come:

function myFunc(a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13){ 
    //... 
} 

dire che si desidera utilizzare argomenti 3 e 11 solo. Ecco il codice:

myFunc(null, null, null, 'hello', null, null, null, null, null, null, null, 'world'); 

Non ti piuttosto solo:

myFunc({ 
    a3 : 'hello', 
    a11 : 'world' 
}); 

?

1

Prima di tutto tale tecnica è molto semplice per i programmatori.

Non è necessario ricordare l'ordine di tutti i parametri di tutte le funzioni nell'applicazione. Il codice diventa più leggibile e più robusto.

Qualsiasi futuro sviluppo, miglioramento o refactoring non sarà così difficile da fornire. Il codice diventa più mantenibile.

Ma ci sono alcune insidie. Ad esempio, non tutti gli IDE ti forniranno un semplice codice che completa con tali funzioni e i loro parametri.

4

Ci sono un paio di motivi per questo.

Il primo è che non tutti gli elenchi di argomenti hanno un ordine naturale. Se c'è un caso d'uso per fornire solo il 1 ° e il 6 ° argomento, ora devi inserire quattro segnaposto di default. Jage lo illustra bene.

Il secondo è che è molto difficile ricordare l'ordine in cui devono avvenire gli argomenti. Se si prendono una serie di numeri come argomenti, è improbabile sapere quale numero indica cosa. Prendi il numero imagecopyresampled($dest, $src, 0, 10, 0, 20, 100, 50, 30, 80) come esempio. In questo caso, l'array di configurazione agisce come gli argomenti con nome di Python.

0

A mio parere ci 2 motivi per cui questo si è evoluto:

  1. Array sono molto facili da creare e manipolare, anche con tipi misti.
  2. I programmatori PHP/JS hanno spesso un background non accademico e sono meno indottrinati da linguaggi come Java e C++.
2

rubino segue questa metodologia pure, e ha anche messo a punto una sintassi più succinta destinato specificamente per l'utilizzo hash come inizializzatori, come di rubino 1,9:

# old syntax 
myFunc(:user => 'john', :password => 'password'); 

# new syntax 
myFunc(user: 'john', password: 'password'); 

Il problema viene affrontato è che, all'interno di questi lingue, non è possibile sovraccaricare le funzioni in base al tipo di argomento. Ciò si traduce in classi complesse con un singolo costruttore che può avere un elenco di argomenti enorme e poco maneggevole. L'uso di oggetti tipo hash per fornire i parametri consente una sorta di pseudo-sovraccarico in base al nome del parametro piuttosto che al tipo.

Il mio unico vero problema con questa pratica è diventa difficile per documentare le sue argomentazioni: PHPDoc for variable-length arrays of arguments

2

uno dei motivi più importanti per cui non si vede questo in altri linguaggi OO è che si sta probabilmente riferendo linguaggi compilati come C++ o Java.

Il compilatore è responsabile di determinare, al momento della compilazione non durante l'esecuzione, quale metodo si desidera chiamare e questo è normalmente eseguito in base alla firma, quindi in pratica deve essere fatto in questo modo. Questo è anche il modo in cui il sovraccarico del metodo viene eseguito in queste lingue.

Problemi correlati