СП
Не нарушать LSP
так ничего и не нарущается же
Size: a a a
2020 September 17
СП
SelfEmployed
он станет ещё одним типом контрагента
СП
на одном уровне с ооо, ип и фл
СП
Не нарушать LSP
class Contractor { ... }
class Fizik extends Contractor { ... }
class Org extends Contractor { ... }
Мы можем заменить все использования Contractor на Fizik или Org и всё будет работать.
Ты же об этом?
class Fizik extends Contractor { ... }
class Org extends Contractor { ... }
Мы можем заменить все использования Contractor на Fizik или Org и всё будет работать.
Ты же об этом?
NO
он станет ещё одним типом контрагента
У него свои собственные будут поля.
СП
У него свои собственные будут поля.
в дополнение к полям контрагента
NO
в дополнение к полям контрагента
То есть ты добавишь все поля в контрагента?
СП
То есть ты добавишь все поля в контрагента?
Как вариант. Но я рассматриваю предложенный тобой вариант разбиения на таблицы (для хранения), но не пойму как реализовывать в самих сущностях, которые наследуются от контрагента.
NO
Всё что требуется можно вытянуть через таблицу связей
СП
Твой подход подразумевает один класс Contractor? Или Contractor + отнаследованные от него ип, физик и тд?
NO
Представь как бы сделал человек, если бы вёл всё на бумаге. Допустим некий бухгалтер.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
СП
Представь как бы сделал человек, если бы вёл всё на бумаге. Допустим некий бухгалтер.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
Вот ты любишь не отвечать на вопрос :)
СП
Представь как бы сделал человек, если бы вёл всё на бумаге. Допустим некий бухгалтер.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
Для каждого контрагента заводится папка с данными. В каждой папке (для простоты берём) хранится два листочка.
Первый листок, данные по контрагенту. Форма единая для всех контрагентов.
Второй листок, подробные анкетные данные, всё что требуется для конкретного типа. Для физлиц одна форма, для организаций вторая форма, для ИП третья.
Примерно такую структуру можно создать в БД и в коде.
Как в коде быть в приведённом примере
NO
Твой подход подразумевает один класс Contractor? Или Contractor + отнаследованные от него ип, физик и тд?
Без наследования. Наследование — это жёсткая связь, её следует избегать, если можно обойтись без неё. Здесь больше подходит композиция, кмк
СП
Без наследования. Наследование — это жёсткая связь, её следует избегать, если можно обойтись без неё. Здесь больше подходит композиция, кмк
контрагент будет иметь ссылку на ИП / ООО / ФЛ / Самозанятых, которые будут реализовывать некий интерфейс и по нему отдавать что там ему надо?
NO
в коде
$fizik->getContragentInfo()->getInn()
$fizik->getContragentInfo()->getSummary()
$fizik->getContragentInfo()->getInn()
$fizik->getContragentInfo()->getSummary()
СП
в коде
$fizik->getContragentInfo()->getInn()
$fizik->getContragentInfo()->getSummary()
$fizik->getContragentInfo()->getInn()
$fizik->getContragentInfo()->getSummary()
$contraget->getInfo() надо, а у типов у каждого своя реализация
NO
Это без разницы. Ты можешь реализовать оба варианта доступа к данным.
СП
"контрагент будет иметь ссылку на ИП / ООО / ФЛ / Самозанятых, которые будут реализовывать некий интерфейс и по нему отдавать что там ему надо"
Вот это вроде вписывается в то, о чем ты говоришь, да?
Вот это вроде вписывается в то, о чем ты говоришь, да?
NO
Одновременно ) Если понадобится