ООП: взаимодействие объектов

[pamgmen]

День добрый.
Изучаю ООП, возник такой вопрос:

Имеется простая функциональность анализатора:
1. Загрузить текст.
2. Вычленить регулярками нужные данные
3. Эти данные обработать. (например даты в нужный формат привести)
4. Сохранить в БД данные.

Проблема собственно появилась такая:
Один объект класса textPage делает функционал 1 и 2.
Обработка данных у меня идет объектом другого класса.

1. Как правильно передавать вычлененные данные находящиеся в объекте textPage - другому классу для их обработки?

Можно у первого объекта сделать public-переменную - и второй объект скачивает ее... Но по-моему это тупость)) т.к. должно как-то проще все решаться...
Еще прочитал что для взаимодействия создают специальные методы - но пока не нашел ничего конкретного...

2. И как бы вы спроектировали данный функционал в ООП?

Спасибо заранее.

 

[c0dex]

передавать как параметр метода

 

[флоппик]

Обсуждение противоправных действий по воровству чужого контента на этом форуме не обсуждается.
Даже в ключе теории ООП.

 

[pamgmen]

передавать как параметр метода

Если не трудно, можно чуть подробнее объяснить?

$objectProcessing -> process($objectTextPage -> data);
Так?

 

[С.]

Не надо ничего никуда передавать, все должно быть в одном месте. Объект он и есть объект, подлежащее, существительное. В данном случае "текст". А "обработать" это глагол, он не может быть объектом, а лишь методом объекта.

При нормально спланорованной архитектуре даже код должен читаться членораздельно и естественно.
Processing->process() всяко не естественная запись (масло маслянное).

 

[pamgmen]

Не надо ничего никуда передавать, все должно быть в одном месте. Объект он и есть объект, подлежащее, существительное. В данном случае "текст". А "обработать" это глагол, он не может быть объектом, а лишь методом объекта.

При нормально спланорованной архитектуре даже код должен читаться членораздельно и естественно.
Processing->process() всяко не естественная запись (масло маслянное).

так как должен быть примерно спроектирован такой функционал? (классы/объекты)

 

[Вурдалак]

Ты как-то делаешь работу наоборот: сначала думаешь о парсере, а потом пытаешься придумать контекст для него.

 

[С.]

$text->process();

 

[pamgmen]

хорошо.
но рано или поздно данные от одного объекта все же придется передавать другому..
например сохранение данных в БД - за это же отвечает другой объект...
как быть тогда?

 

[С.]

$text->save();

например сохранение данных в БД - за это же отвечает другой объект...
как быть тогда?

Какой объект (подлежащее, существительное)? Это либо не объект, а библиотека. А если объект, то обект "соединение" (с базой). Какое отношение объект "соединение" имеет отношение к объекту "текст"? Как он может чего-то сохранить, если ничего не знает об устройстве (и не имеет права знать) "текста"?

 

[pamgmen]

$text->save();


Какой объект (подлежащее, существительное)? Это либо не объект, а библиотека. А если объект, то обект "соединение" (с базой). Какое отношение объект "соединение" имеет отношение к объекту "текст"? Как он может чего-то сохранить, если ничего не знает об устройстве (и не имеет права знать) "текста"?

Спасибо за подсказку..
Может еще кто-нибудь что-нибудь добавит?
Как правильно спроектировать ОО-модель для такой задачи?

 

[varan]

$text->save();

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

Я бы лучше сделал так

$text->process($processingResultStorage);

а объект $processingResultStorage реализует интерфейс с нужными методами сохранения типа save($data); и использует объект базы данных, в котором грубо говоря есть метод query

 

[С.]

А какая разница, у "текста" много ответственностей или у "процессинга" много сущностей с которымы он работает? В первом случае по крайней мере больше соответствий с "реальным" миром (идея, из которой родилось само ООП).

 

[varan]

Разница такая же как между изделием, собранным из деталей и цельнолитым. Возможность менять запчасти.
И почему меня должны волновать первоначальные идеи ООП и его соответствие реальному миру? Меня больше интересует поддерживаемость кода.

 

[AmdY]

>>Один объект класса textPage делает функционал 1 и 2.
твоя проблема в том, что ты пытаешься наделать объектов с высокой связанностью, он и данные забирает и парсит их и форматирует. каждый объект должен заниматься своей работой, тогда ты сможешь использовать их по отдельности.

$content = new Content();
$content->loadFromFile('filename.txt'); 

$parcer = new Parcer();
$parcer->addRuleRegExp('currentDate', '~(\d+-\d+-\d+)~');
$parcer->addRuleRegExp('title', '~<p class="title">(\w+)</p>~');
$parcer->paceContent($content->__toString());

$news = new Model_News();
$news->insert(array(
    'title' => $parcer->getRule('title'),
    'date' => $parcer->getRule('currentDate')
));

// а теперь один из классов используем просто для вывода
$content = new Content();
echo $content->loadFromUrl('localhost://test.txt');

и т.д.

 

[С.]

Разница такая же как между изделием, собранным из деталей и цельнолитым. Возможность менять запчасти.
И почему меня должны волновать первоначальные идеи ООП и его соответствие реальному миру? Меня больше интересует поддерживаемость кода.

А кто утверждает, что тот-же "текст" должен быть монолитным? Использование взаимозаменяемых деталей в нем (как то запись базу) никто не запрещает. Запись

$text->save();

более волкосытна и овцецела, чем

$db::save($text->data);

хотя сводится технически к тому же самому.

 

[stopkran]

А кто утверждает, что тот-же "текст" должен быть монолитным?

Тот, кто сказал: "Объект он и есть объект, подлежащее, существительное". Если Текст, с которым мы работаем - подлежащее, а методы, которые меняют Текст - сказуемые, тогда они никак не должны содержаться друг в друге. Сказуемое "укусил" можно применить к Змее или к Волку. Не Змея->Укусил, а Укусил(Змея), Укусил(Волк).

parse($text);
save($text);
display($text);

 

[pamgmen]

Забудем на время по функционал парсера...

Как вам такая конструкция взаимодействия объектов: (в целом)

$obj1->var1($obj2->return_var2());

 

[Alien85]

$myPage = new Page();
$myPage->title = 'I like the PHP';
$myPage->text = 'some text';
$myPage->Save(); // Сохранение в БД

По вашему так плохо?

 

[С.]

Как вам такая конструкция взаимодействия объектов: (в целом)

$obj1->var1($obj2->return_var2());

Да блин же! Только об этом и говорим, что все зависит от семантического смысла объектов. На твой вопрос не существует ответа, пока не станет известно, что за $obj1, $obj2 и как они соотносятся друг с другом.