2010-11-11 3 views
0

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

Я думаю о том, как предоставить интерфейс встроенному объекту комментария. Я мог бы сделать его публичным участником и напрямую запросить программиста ($case -> comment -> addComment()) или сделать его приватным и поместить методы в класс Case для предоставления доступа к комментариям через объект Comment (p ublic function addComment() { return ($this -> comment -> addComment()); }).

Думая об этом, последний стиль будет означать, что объект Case становится зависимым от объекта Comment. Тем не менее, в первом случае программист может делать такие вещи, как сделать свойство comments комментариев к объекту объекта Case, не относящихся к делу, или даже элементам, которые не являются объектами комментариев!

Из двух подходов, которые считаются лучшими?

ответ

1

Я не совсем понимаю, что вы имеете в виду, но ...

Я думаю, что нужно что-то вроде этого:

class Case { 
    private $comment; 

    public function getComment() { 
     // Add some checks if necessary 
     ... 
     return $this->comment; 
    } 

    public function addComment(Comment $comment) { 
     // Add some checks if necessary 
     ...   
     $this->comment = $comment; 
    } 
} 

Вы также можете выбрать, чтобы сделать ваш защищенный $ комментарий Собственость , Это особенно полезно, если вы хотите расширить объект.

Всегда широко применяйте инкапсуляцию, это одно из самых больших преимуществ ООП. Всегда разумно сделать свойство класса защищенным или закрытым. Без этого вы не можете принудительно проверять его при настройке свойств. Имейте в виду, что если вы создаете общедоступную собственность, каждый класс может получить доступ и изменить его без каких-либо проверок. Подумайте о возможных последствиях этого!

$ комментарий не примитивный тип, его ссылка на экземпляр комментария CLAS

Успехов!

@Gordon: Не имеет значения. Даже если это экземпляр комментарий и вы обнародует его, вы можете сделать так, что-то вроде:

// $Case is a Case object, doh ;)... 
$Case->comment = "Just a string value"; 

И вдруг ваш комментарий примитивный тип, пока вы ожидаете экземпляр класса Комментарий ... Это может привести к нескольким ошибкам. Если вы сделаете его защищенным или приватным, строка кода просто невозможна вне класса. Тогда вы будете вынуждены использовать сеттер для него нравится:

public function setComment(Comment $comment) { 
    ... 
} 

Ваша функция ожидает комментарий и выдаст ошибку, если что-то другое дано. Это обеспечит согласованность вашего объекта.

@Gordon: Это не метод класса комментариев, который вы строите в своем классе Case. Описанные выше методы необходимы только для вашего класса Case.Единственное, что они делают, это получение объекта Comment, принадлежащего классу Case, и Установка Объект Comment, относящийся к классу Case. После того как вы успешно извлекли объект Comment с помощью getter, вы можете запустить все общедоступные методы, определенные в вашем классе Comment. Поэтому он ничего не делает с объектом Comment.

Ваш комментарий по-прежнему полностью независим. Связь между этими объектами (скорее всего) сохраняется в таблице объекта Case. Класс Case - это единственный класс, который знает об отношениях. Поэтому вы можете повторно использовать свой класс комментариев для других целей.

Класс вашего случая должен каким-то образом знать ваш класс комментариев, и это путь!

BTW, рассмотрите отношения «многие ко многим». Я предполагаю, что у Case может быть более одного комментария.

Удачи вам!

+0

$ comment не является примитивным типом, его ссылкой на экземпляр класса комментариев – GordonM

+0

Это предложило бы сделать свойство комментария приватным классу и обернуть методы класса комментариев в классе хостинга. Я понимаю преимущества, которые это дает, но, хотя я относительно новичок в ООП, я понимаю, что совместные зависимости между объектами, отличными от наследования, считались плохими? – GordonM

+0

Требование «многие-ко-многим» подразумевает некоторый внутренний сбор комментариев. Вероятно, это больше, чем просто ссылка на частный объект комментариев, вы можете иметь, скажем, массив комментариев, которые будут обрабатывать ваши методы Case. Вы изменили бы свой Случай, поскольку кто-то предложил добавить и удалить комментарии из коллекции. Вероятно, вы также захотите, чтобы методы получали конкретный комментарий по id или список комментариев. Вероятно, вы захотите построить свой класс комментариев, возможно, с модульными тестами, и получите эту работу. Затем добавьте методы Case для управления их коллекцией. –

1

Класс Case должен иметь свои собственные методы для добавления/удаления комментариев. Это позволяет вам изменить способ реализации комментариев в будущем. Эти методы можно просто переносить вызовы в ваш класс комментариев теперь, но полностью изменить их в будущем.

Смежные вопросы