Обязанности объекта - список и пункт

Question

Мой вопрос больше похож на теоретический.

Скажем, у вас есть объект, представляющий список чего-либо (статьи, страницы, аккаунты и т. Д.)

class ObjCollection 

У вас есть класс, представляющий определенный элемент в коллекции:

class objItem

У меня проблемы с представлением об основных обязанностях каждого объекта.

Какой класс отвечает за создание нового objItem?

Какой класс отвечает за удаление objItem? Должен ли он удалить себя как метод?

---

Обновление 1: Techpriester: Можно ли использовать конструктор объекта как функцию для создания нового элемента? Я думаю об этом как:

class objItem {
    public function __construct($id = 0) {
        if ($id > 0) {
            // load item data...
        } else {
            // make new item...
        }
    }
}

Но что, если что-то пойдет не так в коде, и вместо передачи $ id> 0 он пропустит 0? В этом случае более ожидаемым поведением будет пустой объект, а не новый, или я ошибаюсь?

Answer 1

Способ мышления об этом:

objItem обычно имеют конструктор класса, поэтому этот класс может быть ответственным за создание объектов типа objItem.

Когда objItem вставляется в список / коллекцию, скажем objCollection, это может иметь objCollection ответственность за удаление его из коллекции.

Answer 2

У objItem обычно есть класс конструктор, так что этот класс отвечает за создание объектов введите objItem.

Конструктор не имеет ничего общего с ответственностью (обычно). Подумав так, каждый объект будет отвечать только за себя.

Ответственность - это концепция, не связанная напрямую с иерархией классов.

Если:

ObjCollection = Гнездо objItem = Яйцо. И есть третий объект Bird. Тогда Bird берет на себя ответственность за создание яиц (даже если в гнезде есть яйцо). Дело не в программировании, а в здравом смысле ... :)

Нет такой вещи, как "пустой объект". Объекты имеют «состояние». Вы можете создать объект, а затем он у вас есть, или вы можете не создавать его, и тогда нет никакого объекта.

Все, о чем вам нужно беспокоиться, это о том, что ваш конструктор будет работать нормально в обоих случаях, с созданием нового объекта и без него.

Обычно лучше внедрить объект как параметр конструктора (вместо $ id), чтобы не создавать его внутри другого объекта.

Answer 3

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

В этом случае, вероятно, лучше вообще отказаться от «коллекций», поскольку, если бы вы заставили каждый класс представлять только один объект, например, если вы хотите просмотреть 10 сообщений в блоге, вы бы вызвали 10 отдельных SELECT. запрашивает каждый, получая только отдельную запись в базе данных, потому что вы решили, что класс BlogPost инкапсулирует его метод поиска.

Альтернатива состоит в том, чтобы позволить классу представлять одну или несколько записей. Таким образом, вам нужно выполнить только один запрос SELECT, независимо от того, извлекаете ли вы 5000 записей или только одну. Практически каждый объектно-реляционный картограф делает это.

При выполнении объектно-ориентированного программирования лучше думать с точки зрения поведения или ответственности , чем того, является ли объект осязаемой «вещью». В этом проблема теоретического обсуждения ООП. Очень заманчиво использовать аналогии, такие как животные и фрукты, которые имеют мало отношения к программированию в реальном мире.

Answer 4

Поскольку объект не может удалить себя, то должно быть ответственностью коллекции.

Если вы позволяете коллекции создавать свои объекты, такие как $collection->makeNewItem(); (которая затем вызывает конструктор элементов), или напрямую используете $item = new Item();, то какой-то метод $collection->addItem($item); полностью зависит от вас и потребностей вашего приложения. *

Я бы рекомендовал использовать обычные экземпляры, если сами предметы также используются за пределами коллекции.