Покинул форум
Сообщений всего: 979
Дата рег-ции: Окт. 2011 Откуда: Россия г. Нижний Новгород
Помог: 25 раз(а)
[+]
Я сразу оговорюсь, что эта статья для тех кто уже хоть чуть-чуть начал или начинает понимать принципы ООП. Я сам ещё можно сказать "New bie" в этом деле.
Итак думаю критики которые сейчас читают эту статью знакомы с понятием "Текучий интерфейс". Примеры можно встретить во многих фрейворках например Zend. Что-же это такое, рассмотрим пример класса Template :
$tpl->tpl('template/index.tpl');// Загружаем содержимое файла в переменную $content внутри класса
$header=$tpl->parse('template/header.php');// Загружаем содержимое файла в отдельную переменную $header, если разобрать метод класса parse видно, что в конце концов он возвращает строку ( return $this->parse_tpl; )
$body=$tpl->parse('template/header.php');// Аналогично с предыдущей переменной $header
$tpl->set('header',$header);// Метод заменяет в загруженном шаблоне index.tpl все повторы строки {header} на содержимое файла $header
$tpl->set('body',$body);// Аналогично с предыдущем.
$tpl->out_content();// Выводим содержимое
Итак это был обычный пример. А что если немного изменить наши методы класса, пусть они возвращают нам сам класс как объект после завершения :
->set('header',$tpl->parse('template/header.tpl'))// Парсим все {header} на содержимое файла header.tpl
->set('body',$tpl->parse('template/body.tpl'))
->out_content();// Выводим контент..
Сильно не критикуйте, это моя первая статья) Я ужасно нервничал и мог что-то упустить. Если я где-то тут произвел "подмену терминов" напишите всё поправлю.
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
Итак думаю критики которые сейчас читают эту статью знакомы с понятием "Текучий интерфейс".
Где вы такое "понятие" вычитали.
Цитата:
Какие преимущества нам это дает? Более удобный синтаксис :
Очень спорный вопрос. Конечно "цепочечные" вызовы выглядят компактнее но очен неудобны для чтения. Потому как непонятно где какой объект вызывается. Ведь во время следующего вызова обект может вернуть не $this а другой объект который тоже пойдет вызывать цепочку. И пойми где какой метод какого объекта и что он возвращает.
Кроме того чисто стилистически. Если функция по бизнес-логике ничего возвращать не должна - нефиг там писать return со всякой, не относящейся к логике рабты программы, херней.
В данном случае. С какого перепугу метод set который, судя по названию что то устанавливает, еще что то и возвращает? Максимум что он мог бы возвращать если по уму, это результат присвоения true/false (удвчно неудачно.)
Покинул форум
Сообщений всего: 979
Дата рег-ции: Окт. 2011 Откуда: Россия г. Нижний Новгород
Помог: 25 раз(а)
[+]
caballero пишет:
Где вы такое "понятие" вычитали.
Где - где. Известно где))
Я готов допустить что метод set не очень удачный пример. Возмножно его просто назвать чуть по другому надо было, и таких интуитивных ассоциаций у тебя не возникало бы..
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
Цитата:
Где - где. Известно где))
понятно - высосано из пальца
Цитата:
Я готов допустить что метод set не очень удачный пример
Неважно какой метод. Важен сам принцип - нефиг методу что то возвращать если ему по логике программы нечего возвращать. Тем более глупо переимновывать метод - вместо понятного имени писать что попало лишь бы вписаться в хрень под диковинным названием "текучий интерфейс".
Впрочем в некоторых экзотических фреймворках (типа onPHP) такой подход используется.
А теперь представьте равнозначный кусок без использования такого приёма. Сколько места займёт?
По классической концепции MVC, шаблон может и должен самостоятельно обращаться к модели за своими данными, не беспокоя контроллер по пустякам. При этом, такая запись весьма удобна и не выглядит нагромождением.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 16 Ноября, 2011 - 07:55:52
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Пусть даже так.
А если параметров не 1-2, а много? И они необязательны? Передавать массивом и в методе разбирать? Реализовывать методы вывода на все случаи жизни?
----- PostgreSQL DBA
EuGen
Отправлено: 16 Ноября, 2011 - 08:05:14
Профессионал
Покинул форум
Сообщений всего: 9095
Дата рег-ции: Июнь 2007 Откуда: Berlin
Помог: 707 раз(а)
Мне кажется, что не стоит спорить, что лучше - использовать такие вызовы и организацию методов или нет. Ведь всегда, при использовании любой технологии должно быть понимание, когда это делать нужно, а когда - нет.
Например, здесь -
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
caballero, ну. Метод param как раз ничего, кроме this не возвращает. Хотя является классическим сеттером с точки зрения внешнего наблюдателя.
----- PostgreSQL DBA
caballero
Отправлено: 16 Ноября, 2011 - 09:59:17
Активный участник
Покинул форум
Сообщений всего: 5998
Дата рег-ции: Сент. 2011 Откуда: Харьков
Помог: 126 раз(а)
тогда параметр должен быть в функции list()
тем более параметр предназначен для нее
а если параметр не только для нее то он должен быть в конструкторе класса (фабричном методе)
А в остальном согласен с EuGen. Должно быть четкое понимание где стоит делать такой "текучий интерфейс" а где нет.
Пацаны расслабьтесь ) я не гуру пхп, только учусь ) Я всего лишь попробовал написать, рад, что тема у вас вызвала хоть какой-то интерес )
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.