Почему в массивах конфигурации допустимы параметры в PHP и Javascript?

Question

В большинстве других объектно-ориентированных языков. было бы кощунственно, чтобы каждая функция получала один ассоциативный массив объектов, а не перечисляла каждый в сигнатуре метода. Почему, однако, это приемлемо и обычно используется в большинстве популярных сред для обоих этих языков?

Есть ли какое-то оправдание помимо желания иметь краткие сигнатуры методов?

В этом я вижу преимущество - API может оставаться неизменным при добавлении новых необязательных параметров. Но Javascript и PHP уже допускают необязательные параметры в сигнатурах своих методов. Во всяком случае, похоже, что Java или другой язык OO выиграют от этого больше ... и все же я редко вижу там этот паттерн.

Что дает?

Answer 1

По моему мнению, многие из этих функций растут по количеству аргументов, которые они принимают, более 10 не редкость Даже если вы делаете необязательные параметры, вам все равно придется отправлять их по порядку.

Рассмотрим функцию, подобную:

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

Скажем, вы хотите использовать только аргументы 3 и 11. Вот ваш код:

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

Не лучше ли:

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

Answer 2

Для этого есть несколько причин.

Во-первых, не все списки аргументов имеют естественный порядок. Если есть вариант использования для предоставления только 1-го и 6-го аргумента, теперь вы должны заполнить четыре заполнителя по умолчанию. Джейдж хорошо это иллюстрирует.

Во-вторых, очень трудно запомнить порядок, в котором должны встречаться аргументы. Если вы возьмете в качестве аргументов ряд чисел, вряд ли будет известно, какое число означает что. Возьмите imagecopyresampled($dest, $src, 0, 10, 0, 20, 100, 50, 30, 80) в качестве примера. В этом случае массив конфигурации действует как именованные аргументы Python.

Answer 3

Основная причина в том, что эти конкретные языки просто не поддерживают наличие нескольких соглашений о вызовах для одного и того же имени функции. И.Е. Вы не можете сделать следующее:

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

Таким образом, вы должны найти другой способ создания более простых способов передачи ваших переменных, в PHP мы получаем someFunc(array('some'=>$some, 'another'=>$another)), потому что это единственный удобный способ. В JavaScript мы используем объекты, что не так плохо: someFunc({some: something, another: anotherthing})

Answer 4

Одна из наиболее важных причин, почему вы не видите этого в других языках OO, заключается в том, что вы, вероятно, имеете в виду скомпилированные языки, такие как C ++ или Java.

Компилятор отвечает за то, чтобы определить, во время компиляции, а не во время выполнения, какой метод вы хотите вызвать, и это обычно делается на основе сигнатуры, поэтому в основном это должно быть сделано таким образом. Так же и в этих языках осуществляется перегрузка метода.

Answer 5

Ruby также следует этой методологии и даже разработал более сжатый синтаксис, предназначенный специально для использования хэшей в качестве инициализаторов, начиная с Ruby 1.9:

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

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

Проблема, которая решается, заключается в том, что в этих языках нельзя перегружать функции в зависимости от типа аргумента. Это приводит к сложным классам с одним конструктором, который может иметь огромный и громоздкий список аргументов. Использование хеш-подобных объектов для предоставления параметров допускает своего рода псевдоперегрузку по имени параметра, а не по типу.

Моя единственная реальная проблема с этой практикой - становится трудно документировать ваши аргументы: PHPDoc для массивов аргументов переменной длины

Answer 6

Прежде всего такая техника очень проста для кодировщиков.

Им не нужно запоминать порядок всех параметров всех функций в вашем приложении. Код становится более читабельным и надежным.

Любые будущие разработки, улучшения или рефакторинг не будут такими сложными. Код становится более понятным.

Но есть некоторые подводные камни. Например, не каждая среда разработки даст вам простой код, дополненный такими функциями и их параметрами.

Answer 7

По моему мнению, есть 2 причины, по которым это произошло:

1. Массивы очень легко создавать и манипулировать даже со смешанными типами.
2. Программисты PHP / JS часто имеют не академическое образование и менее подвержены влиянию таких языков, как Java и C ++.