if($obj->getField === *smth*) {...} - у вас нарушена инкапсуляция, у вас повышается связность(coupling), и эта логика, этот if, должен находиться внутри класса с даннымиА как пользователь например сам себя зарегистрирует?
$user = User::createWithNameAndPass($name, $passHash);Вот вы можете сами себя принять на работу в стороннюю организацию?
$organizationBranch->hire($user);$hrDepartment->hire($user);Касается всего: зачем, к примеру называть метод "changeUserName" если можно просто "setName" или "setNickname" ну или "setUsername".
В платежных агрегаторах разве нет уже своего антифрода?
Чтобы зарегистрироваться в моем сервисе, необходимо обязательно привязать телефон через смс на реальный, не виртуальный номер, либо установить 2FA. Будут ли они этим заморачиваться, чтобы проверять работоспособность карт?
Если пользователь по какой-то причине больше не имеет возможности использовать свой счет с которого было пополнение, то он может пополнить с другого и в таком случае выводить он сможет тоже только на него
<?php
class VendorValidator {
public function validateJson(string $json): bool
{
return (bool)random_int(0,1);
}
}
class MyValidator {
/**
* @var VendorValidator
*/
private $validator;
public function __construct(VendorValidator $validator)
{
$this->validator = $validator;
}
public function validate(string $json): bool
{
$result = $this->validator->validateJson();
if($result === false) throw new \Exception('InvalidJson');
return $result;
}
}ООП - это, конечно, не серебряная пуля. Но это неплохие вилы для разгребания того навоза, который получается без их использования в том же пыхе, например.
как тогда без знания что у Юзера есть какие то данные выводить их?
но простите, как тогда учиться ООП если учебный проект у тебя простой и там всё отлично живёт на процедурке?
читал где-то что настоящее ООП это когда объекты, образно говоря, "обмениваются сообщениями".
Так вот - в чем вы обычно проектируете? На бумажке (как я :)), в каких-то специальных программах которые создают UML-диаграммы или просто " в уме"?
а как решить такую проблему - одного огромного ресурса (например у меня будет 50 моделей для связи с 50 таблицами в бд), но нужно обязательно понимать что логики в них вообще не будет. заносить их в соотвтетсвующие модули - точно нельзя.
Тут дело семантики и того что "достать переменную из объекта" и "установить переменную в объекте" это старая добрая процедурщина а не "ООП"