СП
У контрагента есть свои поля
Size: a a a
2020 September 17
СП
он не может быть интерфейсом
СП
interface Contragent { public function getInfo():string }
class Fizik implements Contragent { public function getInfo():string { return $this->fio; } }
class OOO implements Contragent { public function getInfo():string { return $this->okpo . ' ' . $this->ogrn; } }
class Fizik implements Contragent { public function getInfo():string { return $this->fio; } }
class OOO implements Contragent { public function getInfo():string { return $this->okpo . ' ' . $this->ogrn; } }
это же противоречит твоему предложению
СП
Физики/ООО/ИП расширят понятие "Контрагент" и имеют в дополнение к полям контрагента свои поля и реализуют некоторые методы контрагента по своему.
JD
так что мешает общие данные вынести в абстрактный класс, а реализации унаследовать от него
abstract class BaseUser {
public function getAttributesFromDb() {
return [
'inn' => '23234',
'fio' => '...'
];
}
public function getInfo() {
$attributes = $this->getAttributesFromDb();
return ['inn' => $attributes['inn']];
}
}
final class Fizik extends BaseUser {
public function getInfo() {
$attributes = $this->getAttributesFromDb();
$parentAttributes = parent::getInfo();
$parentAttributes['fio'] = $attribute['fio'];
return $parentAttributes;
}
}
abstract class BaseUser {
public function getAttributesFromDb() {
return [
'inn' => '23234',
'fio' => '...'
];
}
public function getInfo() {
$attributes = $this->getAttributesFromDb();
return ['inn' => $attributes['inn']];
}
}
final class Fizik extends BaseUser {
public function getInfo() {
$attributes = $this->getAttributesFromDb();
$parentAttributes = parent::getInfo();
$parentAttributes['fio'] = $attribute['fio'];
return $parentAttributes;
}
}
СП
так что мешает общие данные вынести в абстрактный класс, а реализации унаследовать от него
abstract class BaseUser {
public function getAttributesFromDb() {
return [
'inn' => '23234',
'fio' => '...'
];
}
public function getInfo() {
$attributes = $this->getAttributesFromDb();
return ['inn' => $attributes['inn']];
}
}
final class Fizik extends BaseUser {
public function getInfo() {
$attributes = $this->getAttributesFromDb();
$parentAttributes = parent::getInfo();
$parentAttributes['fio'] = $attribute['fio'];
return $parentAttributes;
}
}
abstract class BaseUser {
public function getAttributesFromDb() {
return [
'inn' => '23234',
'fio' => '...'
];
}
public function getInfo() {
$attributes = $this->getAttributesFromDb();
return ['inn' => $attributes['inn']];
}
}
final class Fizik extends BaseUser {
public function getInfo() {
$attributes = $this->getAttributesFromDb();
$parentAttributes = parent::getInfo();
$parentAttributes['fio'] = $attribute['fio'];
return $parentAttributes;
}
}
Да, это один из вариантов. Но @nex_otaku предлагал другой подход и я пытаюсь понять как в его подходе это сделать
NO
Физики/ООО/ИП расширят понятие "Контрагент" и имеют в дополнение к полям контрагента свои поля и реализуют некоторые методы контрагента по своему.
Я ночь не спал, вряд ли внятно распишу сейчас... Давай в другой раз )
AB
Как вариант - json-поле
NO
В общем эту структуру я уже много лет обдумываю, в продакшене ещё так не разделял.
По похожей схеме у меня в прототипе одного пета работает, но там у меня просто дублируются данные при создании, для простоты.
Сложных случаев ещё не обкатывал.
По похожей схеме у меня в прототипе одного пета работает, но там у меня просто дублируются данные при создании, для простоты.
Сложных случаев ещё не обкатывал.
NO
Я вижу проблему в наследовании и в жёсткой связке таблиц. Это как раз очень часто приводит к вереницам ифов, режимов и костылей.
В
В некоторых случаях очень удобно.
Например, есть в системе контрагенты, которые могут быть организацией, ИП или физлицом, для каждого из них есть уникальные поля. Но в системе все работают с контрагентами. Делаем базовую сущность
Например, есть в системе контрагенты, которые могут быть организацией, ИП или физлицом, для каждого из них есть уникальные поля. Но в системе все работают с контрагентами. Делаем базовую сущность
Contractor, от неё наследуемся и для каждого типа контрагента делаем свой класс.Я в своем проекте (yii2-based) нечто подобное делаю. Но все сущности, с которыми работает проект, у меня реализовываются в виде DTO, которые получаются из репозитория. И только репозиторий работает с AR.
В
Возможно, потом буду переезжать на yii3, и для этого хватит заменить репозиторий)
СП
Разве это не тот случай где наследование - органично и логично?
СП
ФЛ / ИП / ООО - являются на 100% контрагентами + имееют доп. методы и свойства
В
ИМХО, этот тот случай, где оно портит жизнь
СП
ИМХО, этот тот случай, где оно портит жизнь
дублировать функционал и свойства для каждого типа контрагента?
В
Не нарушать LSP
NO
Разве это не тот случай где наследование - органично и логично?
Появится ещё одна "общая" сущность, к которой будет относиться ИП и физики, но не организации. Что будешь делать?
СП
Появится ещё одна "общая" сущность, к которой будет относиться ИП и физики, но не организации. Что будешь делать?
например
NO
например
SelfEmployed