Как сделать фабрику с параметрами?

Question

[BuzzBz]

Доброе утро.

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

<?php 
	class DataExporter {
		public function Create( $type ) {
			$class = $type . 'Exporter';
			return new $class;
		}
	}

	class AbstractExporter {
		public function setData( $data ) { ... }
		public function getResult( ) { ... }
	}

	class CSVExporter extends AbstractExporter { ... }
	class XLSXExporter extends AbstractExporter { ... }

<?php 
	$data = db::query( 'select * from table' );
	$format = $request->get[ 'format' ];

	$exporter = DataExporter::Create( $format );
	$exporter->setData( $data );
	echo $exporter->getResult( );

Проблема начинается когда хочется передать дополнительные параметры в каждый экспортер. Например, для xlsx - это стиль или ширина столбцов.

<?php 
	class XLSXExporter extends AbstractExporter {
		public function setColumnWidth( $column, $width ) { ... }
		public function setColumnStyle( $column, $style ) { ... }
	}

Прописывать в каждом контроллере что-то вроде кода ниже очевидно неправильно.

<?php 
	$exporter = DataExporter::Create( $format );
	$exporter->setData( $data );

	if( $format == 'XLSX' ) {
		$exporter->setColumnWidth( 0, 100 );
		$exporter->setColumnWidth( 1, 30 );
		$exporter->setColumnWidth( 2, 60 );
	}

	echo $exporter->getResult( );

Собственно, вопрос: как по-красивому в фабрике (или, может, тут нужна не фабрика?) передать параметры от контроллера каждому создаваемому классу ?

Comments

[Adamos]

Фабрика уместна только тогда, когда вызывающий ее код не знает и знать не желает, какой именно из наследников класса был сформирован - и работает с ним, как с базовым классом. У вас же даже конструкторы у классов разные, и именно вызывающий код разбирается с различиями - при чем тут фабрика?
Не факт, что ваши DataExporter вообще должны быть наследниками одного класса. Если из общих методов, вызываемых снаружи, у них только одна функция экспорта, наследование теряет смысл.

Answer 1

[dmitriy]

думаю не много не так реализовали, вот если:

$driver = new XLSXExporter();
$exporter = new DataExporter($driver);

echo $exporter->getResult();

class DataExporter{
protected $driver;
function __construct(DriverExporterInterface $driver){
$this->driver = $driver;
}
function getResult(){
return $this->driver->process();
}
}
interface DriverExporterInterface{
public function process();
}

получается:

if( $format == 'XLSX' ) {
    $driver = new XLSXExporter();
    $driver->setColumnWidth( 0, 100 );
    $driver->setColumnWidth( 1, 30 );
    $driver->setColumnWidth( 2, 60 );
  }
else{
$driver = new EmptyExporter();
}

$exporter = new DataExporter($driver);
$exporter->setData( $data );

echo $exporter->getResult();

Comments

[BuzzBz]

Мне это очень нравится - красиво и лаконично. Спасибо больше!

(Выше в ветке советуют DI, но я с ним абсолютно не знаком, а этот метод отлично решает мои потребности).

Answer 2

[Максим Федоров]

Для решение этой задачи стоит использовать не фабрику а DI-контейнер

Comments

[Sanovskiy]

А в DI-контейнер стоит запихнуть ещё один DI-контейнер.

[Вася]

Объясните мне неразумному, чем хуже будет добавить параметр $options методу create ?

[Максим Федоров]

Sanovskiy, ну при кривых руках можно и не такое сделать ....

[Максим Федоров]

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

[D3lphi]

haramba, желаю успехов в использовании и поддержке такого кода.

Sanovskiy, ну тогда уж проще вообще использовать глобальный инстанс контейнера. Разница не велика (разве что, в случае с инъекцией можно подменить контейнер), тот же service locator. Что одно что второе - очень хреновая практика.

[BuzzBz]

Насколько я понял из первой ссылки, это — просто глобальный реестр уже инициированных и сконфигурированных объектов?

То есть, в моём случае мне надо будет где-то при иницииации создавать все экспортеры, давать им конфиг и класть в контейнер, а при вызове контейнер сам передаст нужные настройки?

Мне это не очень подходит: настройки при экспорте меняются не только для каждого типа файла, но и для каждого типа данных. То есть, грубо: в xlsx-экспорте списка юзеров заголовки будут болдом и шириной 120 пикселей, а при xlsx-экспорте списка комментариев — италиком и 200 пикселей. Как это разрулить в случае с DI?

Или я совсем неправильно понял принцип?

Answer 3

[KTF]

ИМХО, на вашу задачу отлично ложится паттерн Стратегия. Ответ, отмеченный как решение, как раз показывает примерную реализацию.