Почему современные PHP библиотеки и фреймворки избегают передачу нескольких параметров в метод через ассоциативный массив?

Question

[Вячеслав]

Почему так:

<?php 
$mail = new Mail();
$mail->setTo('[e-mail]');
$mail->setFrom('[e-mail]');
$mail->setSubject('Тема письма')
$mail->setBody('Текст письма');
$mail->send();

Почему не так?

$mail = new Mail([
    'to' => '[e-mail]',
    'from' => '[e-mail]',
    'subject' => 'Тема письма',
    'body' => 'Текст письма'
]);

$mail->send();

Второй пример мне кажется и лаконичнее и красивее и читабельнее. Но чем он может быть хуже в плане поддержки и расширяемости кода? Почему первый способ установки параметров объекта встречается чаще?

Answer 1

[trevoga_su]

www.phpinfo.su/articles/theory/peredacha_parametro...

Comments

[Алексей Скобкин]

Там, кстати, довольно спорное, на мой взгляд, утверждение:

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

Я бы в таком случае сделал конструктор, в который нужно передавать все зависимости этого класса. Чтобы он был либо рабочий, либо его не было. Сеттеры и геттеры не накладывают на разработчика обязательств по удовлетворению всех необходимых зависимостей. Это, само собой, не значит, что их вообще не нужно делать.

[trevoga_su]

Алексей Скобкин: не всегда в конструктор уместно пихать 100500 значений свойств
хотя в целом Вы правы, да

[werevolff]

Надо попросить ребят из phpinfo специально для Вячеслава написать статьи "Почему юнит-тестирование в PHP не имеет web-gui" и "Почему не надо начинать писать свою CMS, если вы ещё недостаточно знаете PHP"

[Алексей Скобкин]

Алексей Скобкин: В принципе, да. На практике есть исключения. Хотя в таких ситуациях нужно посмотреть, а не God Object ли у нас получился, когда в конструктор нужно 100500 зависимостей засунуть.

Answer 2

[Алексей Скобкин]

Прозрачность.
Потому, что так сложнее контролировать то, что приходит (тайпхинтинг), документировать (phpDoc), кроме того нужно ещё дополнительно проверять массив на наличие нужных ключей.
Это не говоря уже о том, что это портит end-user experience, когда вы работаете, скажем, в какой-нибудь IDE, где вам будет очень понятно и удобно показываться, какой аргумент для чего нужен и какого он типа.
Плюс, вы немного странное сравнение делаете. Если уж сравнивать инициализацию через конструктор, то с инициализацией через конструктор с отдельными аргументами.

Comments

[Вячеслав]

Спасибо, полезный комментарий!
+ Тайпхинтинг (проверка типа параметров )
+ Документация и подсказки IDE

Уточните, плиз, что такое end-user experience? Имеется в виду всплыващая подсказка в IDE по аргументам метода?

[Алексей Скобкин]

Вячеслав: Да, в том числе и всплывающая подсказка. Пользователями классов и интерфейсов являются разработчики. Если бы речь шла о сайте - End-User'ом был бы пользователь сайта.

Answer 3

[Евгений]

Автокомплита нет с массивом

Comments

[Вячеслав]

В JavaScript тоже нет автокомплита, но там такой способ для передачи опций часто применяется (например в плагинах jQuery). Это минус JS?

[Андрей]

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

[Алексей Скобкин]

Вячеслав: Во-первых, там не массивы, а объекты. Во-вторых, тут, скорее, особенность JS, где нет того же тайпхинтинга, да и вообще немного другая парадигма языка. Ну и, кстати, объекты в JS вполне себе документируются в JSDoc и автокомплит работает.

[trevoga_su]

Вячеслав: не надо путать промышленный код и плагины на JS, которые
- пишутся как готовое решение, сплошной копипаст настроек со страницы разработчиков и забыли..
- сам JS не настолько идеален как ЯП

[Вячеслав]

Спасибо!

[Dark Hole]

Вячеслав: их удобно сливать с умолчанием

Answer 4

[xmoonlight]

Можно писать включая пакетную передачу как отдельно, так и в get/set ("перегружено"): чтобы и массив можно было передать в конструктор или функцию send(), и set/get'ры работали. Это наиболее оптимально.

$data=array([
    'to' => '[e-mail]',
    'from' => '[e-mail]',
    'subject' => 'Тема письма',
    'body' => 'Текст письма'
]);

Тогда:

$mail = new Mail($data);
$mail->send();

или

$mail = new Mail();
$mail->send($data);

и потом:
$mail->to("новый@адрес.отправителя"); //setter
или текущий:
$current = $mail->to(); //getter
Когда используем массив, то методы setter/getter можно сформировать динамически, а можно проверить "ключи" на присутствие одноимённых методов в классе и лишнее - исключить/обработать с ошибкой.