Personalmente non mi piace avere troppi argomenti opzionali se riesco a farla franca. Posso trovarlo piuttosto difficile da leggere e quando finisci per passare cose come
getOption($option1, "",0,"")
dove la dichiarazione del metodo è in realtà qualcosa di simile (ovviamente i nomi dei parametri reali dovrebbero essere meglio nominati)
getOption($myoption, $textStr, $numberOf, %description = "", $name = "", $typeOf = 0)
È difficile sapere dalla lettura di ciò che sono esattamente i valori e anche cosa stai impostando o escludendo. Ogni volta che voglio chiamare questo metodo devo fare molta attenzione a impostare i parametri corretti nel posto giusto.
Una possibile alternativa è quella di utilizzare qualcosa come il pattern Builder in cui si costruiscono i criteri che si desidera aggiungere in modo esplicito. Per quei parametri che sono richiesti fai parte del costruttore. Per quelli opzionali hai un metodo da aggiungere.
Qualcosa come:
class StudentEnrollmentCriteriaBuilder {
function __construct($id) {
// id is always required for this criteria
}
function getCriteria() {
// return the built up criteria
}
function addNameFilter($name) {
// add the name to the filter
return $this;
}
function addSexFilter($sex) {
// add sex type as a filter
return $this;
}
// etc
}
Suppongo che potresti usarlo come
$criteria = new StudentEnrollmentCriteriaBuilder ($id);
$query = $criteria.addNameFilter('bob').addSexFilter('M').getCriteria();
// fare cose
Ogni metodo sarebbe responsabile dell'aggiunta del filtro se valido. Quindi suppongo che nel caso del nome, se fosse un nome vuoto, non lo si aggiungerebbe come filtro, ecc., In quanto non era richiesto, o si lanciava un'eccezione ecc. Ecc.
Se ci si avvicina, dove ci sono molte proprietà preferisco l'opzione oggetto. Se alcuni sono richiesti almeno renderli parte del costruttore. Se hai almeno reso facoltativo il metodo basato potresti aggiungere un controllo di validità sui dati a quel punto, oppure lasciare all'utente l'oggetto da fare.
Solo i miei 1 1/2 cent.