2013-09-30 1 views
1

Вот что я продолжаю изо всех сил пытаться найти лучшее решение. У меня была эта проблема при работе с PHP и Java, поэтому это фундаментальное понимание проблемы ООП. Примеры приведены в PHP.Объекты ООП, вложенные объекты и DAO

Предположим, у меня есть несколько объектов здесь. Песня, Исполнитель, ArtistProfile, Пользователь.

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

Должен ли я вставлять один объект в качестве части другого или я должен создавать более конкретные объекты для разных способов использования.

Вариант 1: Вложенный

Class Song { 
    private $songId; 
    private $songName; 
    private $year; 
    private $Artist; //Artist object 
} 

Class Artist { 
    private $artistId; 
    private $name; 
    private $age; 
    private $subscriberArr; //Array of User objects which then have more nested objects such as a Role object, Profile object 
    private $profile; //Profile object which could also have more nested objects 
} 

Class User { 
    private $userId; 
    private $name; 
    private $age; 
    private $role; //Role object 
    private $profile; //UserProfile object 
} 

Вариант 2: Создание более объектов

Class Song { 
    private $songId; 
    private $songName; 
    private $year; 
    private $artistId; 
} 

Class Artist { 
    private $artistId; 
    private $age; 
    private $name; 
} 

Class User { 
    private $userId; 
    private $name; 
    private $age; 
    private $roleId; 
} 

Class SongWithArtist { 
    private $song; //Basic Song object 
    private $artist; //Basic Artist object 
} 

Class ArtistWithProfile { 
    private $artist; //Basic artist object 
    private $profile; //Profile object 
    private $subscriberArr; //UserDisplay object containing basic User object 
} 

Class UserWithProfile {} 

Вариант 1 означает, что тратить много времени/ресурсов захвата информации не может понадобиться для этой страницы, но проще управлять. Вариант 2 бесполезен и требует отслеживания того, какой объект является чем-то, но быстрее и намного меньше вызовов db. Какой вариант «правильный» и/или есть третий правильный вариант?

+0

Не могли бы вы просто создать метод getter для свойства, которое загружает его из БД, когда это необходимо? В качестве альтернативы/также вы можете передать, какие поля необходимы в качестве битового вектора для конструктора. –

+0

Возможно ли это, если я использую MVC? Разве мне не нужно все это загружать в контроллер? Кроме того, если бы я загружал Artist, как вы предлагаете, не все равно попытается загрузить все вложенные объекты внутри него (профиль, пользователи подписчиков, их профиль и т. Д.)? – user103555

+0

Какие рамки вы используете? Я не думаю, что действие по умолчанию любой модели заключается в загрузке всего в связанные классы, если вы не указали ее, например, в Yii, у вас есть метод 'relations()', где вы указываете связанные классы для загрузки - если вы не указывайте там, где вы можете загрузить. Нет, вам не нужно будет делать это в контроллере - вы можете сделать это в самом коде модели - искать '__get' в PHP, это волшебный метод, который позволяет вам указывать методы getter для частных/не существующих переменных. (будет продолжаться в следующем комментарии) –

ответ

0

Две вещи:

  1. Придерживайтесь вековым «является» против «есть» правило для выбора между наследованием по сравнению с составом.

  2. Не беспокойтесь об оптимизации запросов (особенно если речь идет о фундаментальных изменениях объекта проектирования), если вы не так, что ваши конкретные требования к производительности не выполняются и вы профилированные ваша заявку и определить что это ваши узкие места. «ООП» - это концептуальный способ организации и представления информации; проектируйте свои объекты, чтобы точно и точно представлять свои намерения и информацию. Не оптимизируйте преждевременно. В любом случае, достойная ORM (особенно с поддержкой ленивой загрузки, например, Hibernate с Java) и хорошо продуманной, правильно нормированной базой данных (которая часто, естественно, выходит из проектирования бизнес-объектов) в первую очередь хорошо справляется с большинством разумных подходов к проектированию ,