Форум PHP

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

>>Некоторые ...
тАк их наверное еще никто не называл:)
согласен про композицию, к тому же, если этот класс нагрузить функцией переименования - имхо нарушается принцип единственной ответственности
я бы создал массив фильтров в классе (по аналогии с валидаторами)

С $_FILES ошибся. Тогда можно сделать и вовсе без параметра.
cheops.. Некоторые кстате утверждают, что лучше вместо многократных наследований использовать композицию.. Хотя каждый сам для себя определяет соотношение использования одного и другого

-

>Реализовать тогда один интерфейсный статический метод с 1 параметром - $_FILES.
Смысле передавать $_FILES? Почему? Почитайте выше сообщения Trianon'а

В таком случаи я бы советовал ввести, например, дополнительные параметры, которые бы указывали - делать все автоматически (вы передаете только индекс массива $_FILES, а на выходе сразу получаете имена загруженных файлов), либо нет, когда вы вручную задаете имя и т.д.
Правда во втором слуаи встает вопрос - а нафига класс то нужен?

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

Если говорить про один public-метод, то мне кажется, что в таком случае лучше и вовсе не создавать объект.
Реализовать тогда один интерфейсный статический метод с 1 параметром - $_FILES.
конструктор сделать приватным.
Для данного класса это можно сделать и таким образом

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

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

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