Это в порядке для передачи параметров Методу фабрики?
Я думаю, что было бы более эффективно делать это и в SQL, но вы можете сделать функцию для проверки дубликата, что-то вроде этого:
function isDuplicated( $title, $db ){
$dp = $db->query("SELECT * FROM arts WHERE title = $title");
if ( $dp->num_rows > 1)
return true;
return false;
}
$st = $db->query("select id, title from arts order by title asc");
$st->execute();
$x = 0;
while($row = $st->fetch()){
$title = $row['title'];
if( isDuplicated( $title, $db ) ){
$x++;
$title .= ' ' . $x;
$stb = $db->query("update arts set title = '" . $title . "' where id = " . $row['id']);
$stb->execute();
}
}
7 ответов
Я видел довольно много примеров, которые используют фиксированный набор аргументов, как в Вашем примере имени, и использовали их сам также, и я не вижу ничто плохого с ним.
Однако существует серьезное основание, что много учебных руководств или маленьких статей стараются не показывать фабрики, которые передают параметры созданным объектам: практически невозможно передать произвольное число аргументов (даже для нормального предела как 6 аргументов). Каждый параметр, который Вы передаете, должен быть принят как const T& и T& если Вы хотите сделать это универсальный.
Для более сложных примеров, однако, Вам нужен экспоненциально растущий набор перегрузок (для каждого параметра, константы и nonconst версии), и идеальная передача не возможна вообще (так, чтобы временные файлы были переданы как временные файлы, например). Для следующего Стандарта C++, что проблема решена:
class ApplicationBuilder {
template<typename... T>
House *build( T&&... t ) {
return new House( std::forward<T>(t)...,
new Kitchen(new Sink(),
new Dishwasher(),
new Refrigerator())
);
}
};
Тем путем можно звонить
builder.build("Hello", 13);
И это возвратится
new House("Hello", 13, new Kitchen(new Sink(...
Прочитайте статью, которую я связал выше.
Я не вижу, почему было бы неправильно добавить этот параметр к Вашей фабрике. Но знайте, что Вы не должны заканчивать тем, что добавили много параметров, которые не могли бы быть полезны для всех объектов, созданных фабрикой. Если Вы делаете, Вы потеряете довольно много преимуществ фабрики!
Не только, приемлемо, но и распространено передать параметры методу фабрики. Проверьте некоторые примеры. Обычно параметр является типом, говоря фабрику, что сделать, но нет никакой причины, Вы не можете добавить другую информацию, необходимо создать объект. Я думаю, что Вы делаете, прекрасен.
Идея фабрики состоит в том, что она приводит Вам пример класса/интерфейса, таким образом, нет ничего неправильно с передающими параметрами. Если бы было, то это было бы плохо для передачи параметров новому () также.
Я соглашаюсь с Benoit. Думайте о фабрике для создания чего-то как sql соединения, хотя, в случае как это было бы необходимо передать информацию о соединении с фабрикой. Фабрика будет использовать ту информацию для использования корректного протокола сервера и так далее.
Несомненно, почему нет..!?
Хорошая вещь о передающих параметрах состоит в том, что это позволяет Вам скрывать реализацию конкретного объекта. Например, в коде Вы отправили Вас, передают параметры конструктору. Однако можно изменить реализацию так, чтобы они были переданы с помощью метода Initiailze. Передающими параметрами к методу фабрики Вы скрываете природу построения и инициализации объекта от вызывающей стороны.
Смотрите на Loki:: Фабрика, существует реализация очень как он прибывающий для Повышения также, как бы то ни было. Некоторый пример кода я регулярно использую в различных разновидностях:
определение типа Loki:: SingletonHolder <Loki:: Фабрика <Компонент, станд.:: строка, Loki:: Список типов <константа DataCollection&, Loki:: Список типов <Игра*, Loki:: NullType>>>> ComponentFactory;
Это могло бы казаться немного странным на первый взгляд, однако позволить мне объяснить этого зверя и насколько мощный это действительно. В основном мы создаем одиночный элемент, который содержит фабрику, большинство параметров для одиночного элемента, Компонент является нашим продуктом, станд.:: строка является нашим идентификационным типом создания, после того, как это следует списку типов параметрических усилителей, который требуется для создания Компонентов (это может быть определено с помощью макроса также для менее подробного синтаксиса). После этой строки можно просто сделать:
ComponentFactory:: Экземпляр ().CreateObject ("someStringAssociatedWithConcreteType", anDataCollection, aGamePointer);
Чтобы создать объекты, зарегистрировать тот просто используют ComponentFactory:: Экземпляр ().Register ();. существует замечательная глава по деталям в книге современный Дизайн C++.