Как представить обязательные бизнес-поля на модельной структуре?

Question

Если мы используем подсказку типа, мы можем разместить объект в обязательном порядке:

public function myMethodThatDoFineStuff(MyObject $myobject) {

}

Что делать, если мы хотели бы разместить не объект all , а только someиз его атрибутов , быть обязательным?Давайте предположим, что наша модель предметной области будет лучше, если она будет лучше представлять определенный домен. Если это может иметь больше смысла для нашей бизнес-модели (для нашего домена)?Как мы должны это сделать?

Мы должны всегда поместить ВСЕ объект , несмотря ни на что?

ПРИМЕР для разъяснения предлагает:

Давайте представим, что для перечисления книг определенного автора у нас есть такой метод:

public function listBookOfAuthor(Author $author) {

}

Теперь давайте представим, чтоОбъект автора имеет 200 свойств или около того, НО, чтобы обработать список книг, нам нужны только их first и фамилия .

Если мы получимВСЕ $ авторский объект в любом случае?

Answer 1

Я бы проверил требуемые свойства следующим образом:

public function listBookOfAuthor(Author $author) {

    if (empty($author->firstName)) {
        throw new listBookOfAuthorException('firstName must be defined');
    }

}

Если вы обнаружите, что делаете это много, вы можете написать какой-нибудь родительский класс, который включает в себя метод проверки свойств.

Answer 2

В зависимости от вашей схемы, метод listBooksOfAuthor() (который выглядит как метод для сервисного объекта, такого как BookService) может быть достаточным только с $authorId, а не с полным Author объектом.

Но мне кажется, я понимаю суть вопроса.Возможно, объект Author дорогой для полного заполнения - скажем, с помощью метода, подобного AuthorService::getAuthorById().

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

Вы также можете создать набор методов - возможно, на AuthorService объект или AuthorSummaryService объект - который производит AuthorSummary объекты.Затем в тех случаях, когда требуется только AuthorSummaryInterface функциональность, вы можете создать эти ограниченные функциональные возможности, более дешевые для создания объектов.

Просто некоторые идеи.

Answer 3

Что делать, если мы хотим разместить не весь объект, а только некоторые его атрибуты, как обязательные?

Технически вы можете создать интерфейс только с этими некоторыми атрибутамифункция ожидает.В отдельности это может выглядеть как издержки, но с интерфейсами стоит немного поиграться, подробнее в руководстве о том, как они работают в PHP.

Просто потому, что это может сделать большесмысл нашей бизнес-модели?

Я ничего не знаю о вашей бизнес-модели, поэтому не могу сказать, имеет ли она смысл или нет.Но я подумал, что вы задаете вопрос о программировании, а не деловой.

Мы должны всегда размещать объект ALL, несмотря ни на что?

Тогда вы потеряете типнамекает, но вы сможете пройти любой объект.Зависит от того, насколько строго вы хотите написать свой код.Если вы используете интерфейсы, вы достаточно гибки при рефакторинге кода (изменении реализаций конкретных объектов), а также с объектом stclass.Однако с объектом stdclass функция должна сначала проверить, что она получает, перед обработкой на входе функций.