Пишу некий класс, в классе есть метод, который принимает допустим 15 параметров. Стала задача, как бы красиво оформить передачу вот этих параметров. Параметры все приходят извне. Если все параметры передавать как отдельные переменные, то вызов метода будет ужасным типа $someObj(param1, param2, param3, param4, param5, param6, param7 ....  ), мне кажется это не сильно приятно. Рассматриваю другой вариант - передача параметров через массив или с использованием функций get_func_args(). Тогда возникает проблема, что тот, кто хочет передать параметры должен знать, как работает метод и что он может принимать. Это я думаю не является верным решением при разработке и использовании класса. Увы, число параметров сократить нельзя. Работы ведется с кредитными карточками, а том в запросе могут участвовать до 20 параметров. Можете что-нибудь посоветовать?

Не внимательно прочитал  

Это сообщение отредактировал(а) pizzz - 22.4.2009, 00:01

Если массив, то передавать в виде ключ => значение. Тогда тот, кто вызывает данный метод должен знать все ключи, которые можно передать в метод. Мне кажется это не верно, хотя могу и ошибаться.

Тогда как вариант разбить метод.

Если количество параметров у метода действительно никак уже не уменьшить, то вряд ли можно что-то красивее ассоциативного массива придумать. Просто в файле класса в комментариях укажите структуру массива. Причём комментарии лучше указывать в формате PhpDocumentor'а. Тогда описание структуры массива увидят и те, кто залезет в исходники, чтобы посмотреть, какие методы предоставляет класс, и те, кто пользуется какими-либо IDE, которые парсят файлы и выделяют объектную структуру. Наиболее популярные IDE как раз понимают комментарии в формате phpDoc.
p.s. а по свойствам класса точно часть параметров не удастся раскидать и задавать их при инициализаци объекта, например?

Нет, разбить на несколько методов не получиться, так как есть метод addTrunsaction() и они принимается пачку данных, которые уходят на сервер и все тут   

в "более декстопных" языках в таком случае параметры группируются в объекты. вместо 15 параметров - 2-3 объекта(параметры группируются по смыслу).
в РНР же действительно удобно использовать ассоциативные массивы. И ничего в этом страшного нет. 

Вызывающий функцию при любой организации работы с параметрами обязан знать, какой параметр что обозначает.

Понятно. Спасибо всем

 Если 15(а не неограниченное количество) - то это ошибка проектирования.
Используй 2-3 параметра на метод.