clientsfirst_name | last_name | ageSELECT *
FROM clients
ORDER BY age DESC
LIMIT 3class Observer(ABC):
@abstractmethod
def update(self, subject: Subject) -> None:
"""
Получить обновление от субъекта.
"""
passmigration_versions руками
Если статус не является одним из них - выбрасываем исключение. Так же было бы удобно в самом статусе создавать объект через методы фабрики: Status::active(), Status::publish().
$data = [
'вес' => '',
'дата' => '',
'телефон' => '',
'город' => '',
'товар' => '',
'суммазаказа' => '',
'остаток' => '',
'статусзаказа' => '',
'ок' => '',
'предоплата' => '',
'доставка' => '24',
'поставщик' => '',
'статусоплаты' => '',
'номерзаказа' => '6666',
'оплата' => '',
'ценазакупки' => '',
'прибыль' => '',
'артикул' => '',
'коментарии' => '',
'коментарийклиента' => '',
'датазаказатовара' => '',
'статусдоставки' => '',
'магазин' => '',
];
$filterKeys = ['доставка', 'номерзаказа'];
$result = array_filter($filterKeys, function($key) use ($data) {
return isset($data[$key]);
});
var_dump($result);function myFunc(...$args) {
// вернем все аргументы, что пришли в функцию
return $args;
}
$arr = [1, 'Maks', new \DateTime(), null];
var_dump(myFunc(...$arr));require_once 'classes.php';Перейти на Композер и неймспейсы
class smartPhoneProductОставить Product, а тип товара вынести в свойство товара
type или в categoryproduct_id, name, value и таких быть может много у одного товара. Или иной способ работы, главное чтобы при добавлении сотен характеристик вам не пришлось бы сотнями файлов классы придумывать и всегда был один Product, ну или были др причины создавать детей, например простой товар и цифровой... getProduct()После исправления предыдущего шага данная штука product->getProduct() устранится, а сериализация должна быть в другом слое, товар не должен знать ничего про то, как отображать его, тк отображений может быть много (в каталоге, в письме, в отчетах, в корзине)
echo "\nСкидка: " .$discountOnProduct. "P";echo — вывод, бизнес-объект не должен ничего знать про вывод, ответ сервера и прочее, должен быть просто
return $this->description()
Я вроде читаю https://symfony.com/doc/4.4/validation/custom_cons... но чё то понять не могу.
/**
* @Annotation
*/
class ContainsAlphanumeric extends Constraint
{
public function validate($value, Constraint $constraint) {}
}
размер, а если не передадим, то его значение будет 55 (ну так хотим). Причем это будет относиться не к кполю, которое валидируем, а именно к констрейнту, То есть то, что он отдаст валидатору. Ну например возраст или некий пинг,да что угодно, в общем ориентируясь на который валидатор применит некую логику. /**
* @Annotation
*/
final class AnyConstraint
{
/**
* @Required
* @var int
*/
public $size = 55;
/**
* Вот тут мы укажем некий валидатор, тот класс, который и будет валидировать наше значение
* Дял удобства он будет называться также + слово Validator, в нашем случае AnyConstraintValidator
*/
public function validatedBy()
{
return \get_class($this).'Validator';
}
}class AnyConstraintValidator extends ConstraintValidator
{
public function validate($value, Constraint $constraint): void
{
// Тут логика, при которой или все пройдет до return - все отлично
// Или вообще исключение вывалится (если пришло чего-то не то)
// Или (для чего и используется валидатор) создастся violation
// например число в объекте больше того, которое мы указали в size (по дефолту если не указали: 55)
if($value > $constraint->size) {
$this->context->buildViolation('Тут пинг пришел вообще большой — такой нельзя, брат')
->setParameter('{{ string }}', $value)
->addViolation();
}
}
}class AnyEntity
{
/**
* Если значение больше 55 — то не пройдет валидацию
* @AnyConstraint(120)
*/
protected $name;
}@Target({"PROPERTY", "METHOD", "ANNOTATION"})
class User
{
/**
* Кого пригласил
* @var ArrayCollection
* @ORM\OneToMany(targetEntity="User", mappedBy="invitedBy")
*/
private $invitedMembers;
/**
* Кем был приглашен
* @var User
* @ORM\ManyToOne(targetEntity="User", inversedBy="invitedMembers")
*/
private $invitedBy;
public function __construct() {
$this->invitedMembers = new \Doctrine\Common\Collections\ArrayCollection();
}
}Symfony includes the following normalizers:
...
PropertyNormalizer to normalize PHP object using PHP reflection.
получили по API ответ от некоего сервиса, содержащий поля и их значения некоего объекта "Документ", и после на основании некоего конфига мы создаем новый инстанс класса Document, с заполненными свойствами нужными нам значениями. Свойства приватные
Создавать через конструктор не вариант по своим причинам.
Как сделать так, чтобы, получив обновлённое приложение, конкуренты не смогли узнать его новые функции?