С CsvReader:
class CsvReader {
public static function createFromString($csvString){
/.../
return new static($something)
}
}
Я планирую работать с csvString из разных источников: для чтения файла, из тела http-ответа и т. Д. Поэтому я ищу шаблон проектирования для простого создания этих объектов csvReaders. На данный момент я закончил что-то вроде этого:
use SplFileInfo as UploadedFile;
use CsvReader as Reader;
use GuzzleHttp\Client as HttpClient;
class CsvFactory {
public function createFromUploadedFile(UploadedFile $uploadedFile){
return Reader::createFromString($uploadedFile->toString());
}
public function createFromHttpEndpoint(HttpClient $client, $url, $options = array()){
$response = $client->request('GET', $url, $options);
if($response->getStatusCode() != 200){
throw new Exception('Http Code Not Ok', $response->getStatusCode());
}
return Reader::createFromString($response->getBody());
}
}
Я чувствую, что это может быть достигнуто лучшим способом. Но как?
Вопрос, который вам нужно задать себе, — какую основу вы хотите сделать? Шаблоны проектирования — это полезные инструменты, которые помогают вам понять и / или объяснить решения для организации кода определенным образом. Однако вы никоим образом не обязаны использовать какой-либо конкретный шаблон дизайна.
То, как вы его создали, работает нормально, если вы хотите сохранить код, содержащийся в этом конкретном классе. Однако альтернативой было бы создать toCsv
метод в пределах CSVable
интерфейс. Затем вы можете прикрепить это к классам и заставить их определить, как они должны возвращаться при запросе на вывод в формате CSV. Тогда класс CSV мог бы обеспечить, чтобы он только давал объекты, которые реализуют ваш CSVable
интерфейс.
Есть много способов сделать это, но вы должны сделать шаг назад и найти шаблон, который соответствует тому, что вы делаете; Не найти шаблон для применения, прежде чем вы знаете, какие преимущества и недостатки вы хотите. Может даже не быть шаблона, который точно соответствует вашему варианту использования.
Других решений пока нет …