Инстанцирования нового объекта или повторно использовать один и те же один для хранения данных

Question

я следующий класс PHP называется Customer с функцией созданием(), которая хранит данные клиента в базу данных:

class Customer 
{ 
    public $createdby; 
    public $cname; 

    public function create() 
    { 
    ... 
    } 
} 

Поскольку мне нужно хранить больше клиенты в цикле, где изменяется только имя (переменная $ cname) (для простоты $ created_ variable одинаково для всех созданных клиентов в этом цикле), возникает вопрос о том, что является (и почему) лучшей практикой;

Способ) повторное использование и тот же объект Customer, где один изменяет только переменные, которые изменяются:

$Customer=new Customer(); 
$Customer->createdby='somebody'; 
foreach($cnames as $cname) 
{ 
    $Customer->cname=$cname; 
    $Customer->create(); 
} 

Метод B) instatiating нового объекта Customer и установка всех переменные для каждого конкретного создания, как:

foreach($cnames as $cname) 
{ 
    $Customer=new Customer(); 
    $Customer->createdby='somebody'; 
    $Customer->cname=$cname; 
    $Customer->create(); 
} 

Если бы я хотел был создать массив объектов Customer, то, конечно, мне пришлось бы использовать второй метод. Но дело не в этом. Я не вижу недостатка в первом принципе с повторным использованием существующего объекта для хранения большего количества клиентов в базе данных, но, возможно, я ошибаюсь. Поэтому я спрашиваю на всякий случай, что лучше и почему!

Answer 1

Кажется, что оба метода равны, но я предпочел бы второй. Это потребует от меня каких-то потенциальных проблем, связанных с любыми внутренними деталями метода create() (например, он может генерировать некоторый уникальный хеш в некотором beforeCreate() методе, если объект Customer его не содержит).

Answer 2

Статические Создатели экземпляров

Прежде - если метод предназначен для метода создания экземпляра, логически должен мне static (потому что нет никакого контекста объекта перед тем конкретизации). Случай методов создания экземпляров является одним из правовых случаев использования статических методов. Таким образом, ваш обычный метод create() ошибочен, так как он работает в контексте объекта. Вы можете вместо этого использовать магический метод класса __construct(), конечно, если вы уверены, что логика создания экземпляра всегда будет одинаковой.

Использование заводском

Другой способ заключается в использовании какого класса фабрики, чтобы создать экземпляр объекта с заданными данными - следовательно, реализовать Factory рисунок. В вашем случае это может быть, как:

class CustomerFactory 
{ 
    public function createByNames($name, $createdBy) 
    { 
     $customer = new Customer(); 
     $customer->setName($name); 
     $customer->setCreatedBy($createdBy); 
     return $customer; 
    } 
} 

Выгода здесь - что исходный класс может избавиться от экземпляра логики и завод будет нести ответственность за создание действительного субъекта с точки зрения бизнес-правил & целостности. Вы можете, например, добавить некоторые проверки на ваш конкретизации и пройти определенный валидатор как dependency:

class CustomerFactory 
{ 
    public function createByRawData(CustomerValidator $validator, array $customerData) 
    { 
     if(!$validator->check($customerData)) 
     { 
      //or use some namespace, which I omit here to simplify case: 
      throw new CustomerInstantiationException('Creation error '.$validator->getErrorMessage()); 
     } 
     $customer = new Customer(); 
     $customer->setData($customerData); 
     return $customer; 
    } 
} 

Как вы можете видеть, этот подход, если гораздо более гибким и масштабируемым - и не потребует модификации Customer класса - поскольку логика теперь принадлежит фабрике.

Коллекция конкретизации

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

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

Когда вы повторно используете один и тот же объект, вы, очевидно, имеете только одну сущность, которая меняет свое состояние. Если это правильное отражение вашей логики (то есть: у вас действительно есть только один клиент), вы можете использовать ее. Но если ваши клиенты логически разные сущности, то это неправильный подход, так как вы не сможете работать с ними после того, как вы перезапишите тот же объект.

Объекты ваши бизнес-объекты рефлексия, их поведение, бизнес-логика отражение