Как правильнее с точки зрения ООП?

[korchasa]

Автор оригинала: Angerslave
korchasa
В том-то и дело, что первоначально поставленный вопрос "Какой вариант правильнее с точки зрения ООП? А какой вариант лучше использовать?", имхо, подразумевает ответ "никакой - это всё функциональный стиль".

Почему?

Автор оригинала: Angerslave А уже дальше плясать - что важнее - абстрагирование сообщения от контейнера или гостевая книга как просто контейнер каких-то данных. И тут мы пытаемся сесть одной задницей на два стула - и представить гостевуху как контейнер, и представить сообщение как очень независимый объект. По-моему, эти цели плохо уживаются вместе Разве что юзать функциональный стиль, как в первом посте.

Например, стало ли утверждать, что сообщения надо выделить в отдельный класс, если бы они, для каждой книги, хранились в одном файле, и выводились бы все вместе? Т.е. было бы две операции getMessages и addMessage.

ИМХО "некрасивой" наша реализация станет, как только мы признаем, что сообщение это отдельная сущность. И пусть там всякие id и отдельная таблица даже не намекают нам на это.

 

[phpcode]

Автор оригинала: Angerslave
Alexandre
А я бы предпочёл так:

<?php

$message = new Message($id);// if exists - get data from db, else - just create object
$message->setText($text);
$message->setAuthor($user1);
$message->save();//save in DB
$message->delete();

А всю эту буйню с суперобъектами - я не понимаю, чем это отличается от статических методов класса и т.п. функциональщины.

-~{}~ 15.11.08 15:24:

UPD: если в конструкторе объявить $id = null, то можно будет отслеживать создаётся ли новое сообщение или берётся имеющееся из базы.

Тогда получается будет существовать таблица messages (id, author, text) и guesbook(id, msg_id) ? А есть смысл делать такое разделение в БД?
или предлогаете в таблицу messages добавлять все другие сообщения, например Коментарий к статье?

 

[Ilya Bous]

Автор оригинала: korchasa
Почему?
Например, стало ли утверждать, что сообщения надо выделить в отдельный класс, если бы они, для каждой книги, хранились в одном файле, и выводились бы все вместе? Т.е. было бы две операции getMessages и addMessage.

ИМХО "некрасивой" наша реализация станет, как только мы признаем, что сообщение это отдельная сущность. И пусть там всякие id и отдельная таблица даже не намекают нам на это.

Ваще-то ничего некрасивого не будет от того, что появится сущность которая и так есть (только предлагаемый Active Record тут имхо как из пушки по воробьям). Тут упоминался Table Data Gateway дык вот он предполагает наличие сущности которая сохраняется в таблице (кто не верит - тому сюда: http://martinfowler.com/eaaCatalog/tableDataGateway.html )

А аффтар поста спрашивал о другом - какой вариант ему выбрать. Дык вот - первый вариант - это ересь. Второй - это типичный Transaction Script. Стало быть и выбирать ему второй вариант. Но аффтара стоит предупредить, что будет он писать много методов, где одни будут что-то выводить, вторые удалять, третьи добавлять. В принципе при ограниченной функциональности это нормально. А вот если он к такому привыкнет - трудно ему будет жить. Ну и от MVC наверно ему придется видимо отказаться, даже в указанном случае.

И да, я б GuestBook статическим бы сделал наверно ( если он один конечно ).

 

[AmdY]

у топикстартера первый и второй вариант _идентичны_. и если не по людски, то скорее смахивает на dao, причём с отказом от отдельной сущности message в пользу единой доменной модели guestbook.
но за пол года, надеюсь, автор уже решил эту проблему

 

[Ilya Bous]

ну вообще говоря не идентичны....
а на дату не посмотрел... каюсь =))))))))))))))

 

[AmdY]

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

 

[Ilya Bous]

Автор оригинала: AmdY
в первом заранее передается айдишник, а во втором этот айдишник передается прямо в метод, больше отличий нету.

хм хм...

рассмотрим кейс:

$id = $_SESSION["id"];
$gb->setMessageId($id);
someFunction($gb);
$gb->deleteMessage(); //Onotole negoduet

function someFunction($gb)
{
    $id = $_REQUEST["id"];
    $gb->setMessageId($id);

    // Here we do our magic...
}

а во втором случае такого быть не может - отличие какбе существенное...

 

[exxbrain]

1). Передать идентификатор атрибуту объекта и затем, вызвав соответствующий метод, удалить сообщение? Т. е. код примерно такой: $gb->setMessageId($id);
$gb->deleteMessage();

2). Или предусмотреть и вызвать несколько другой метод, которому нужно передать идентификатор? Т. е. код примерно такой: $gb->deleteMessage($id);

Насчет первого примера - странно конечно книге передавать идентификатор сообщения. В этом стиле:

$gb->setMessageId($id);
$gb->setUserId($user->getId());

$gb->readMessageForUser();
$gb->sayThanksForUser();
$gb->deleteMessage();
$gb->makeUserSurprisedAboutMessageRemoval();

1. По сути книжка сама по себе не может удалить сообщение.
2. Допустим она может найти сообщение, при этом логично, что сообщение может само себя удалить, соответственно, если $db это один из возможных экземпляров книги, то смысл такой:

BookService::instance()->findById($bookId)->findMessage($id)->delete();

Если же возможен только 1 экземпляр гостевой книги то:

Book::instance()->findMessage($id)->delete();

3. Я бы удалял так

MessageService::instance()->delete($id);

т.к. в обоих случаях из 2-го пункта сообщения может просто не оказаться в книге, и мы получим сообщение об ошибке


Ilya Bous
С точки зрения ООП правильнее не пользоваться глобальными функциями.

 

[grigori]

Не пост, а подборка афоризмов.

>логично, что сообщение может само себя удалить
>$db это один из экземпляров книги
>сообщения может не оказаться, и получим сообщение об ошибке
>С точки зрения ООП правильнее не пользоваться глобальными функциями.

аффтар жжот пешы исчо

 

[exxbrain]

1.

$db это один из экземпляров книги

Кажись $db - это опечатка по Фрейду . gb - не слишком удачно подобранное название

2.

сообщения может не оказаться, и получим сообщение об ошибке

на null проверять надо.

3.

логично, что сообщение может само себя удалить

Имеется ввиду, что наши объекты слишком уж самостоятельные

4.

С точки зрения ООП правильнее не пользоваться глобальными функциями.

Нахрена нам объекты если всю инкапсуляцию загубим накорню с такими вот подходами

 

[grigori]

4. а с точки зрения echo правильнее не пользоваться print

 

[exxbrain]

grigori
С точки зрения названия темы форума об этом лучше подискусировать в другом месте

 

[Ilya Bous]

Автор оригинала: exxbrain

Ilya Bous
С точки зрения ООП правильнее не пользоваться глобальными функциями.

Про глобальные функции не понял. Если речь о примере, я думаю все в состоянии представить функцию как метод какого-либо класса. Факт остается фактом - первый вариант небезопасен.

P.S. А вообще ООП - это инструмент, а не религия. Это я так, про функции...