Процедурный подход в PHP и ОО. Налицо несовместимость синтаксиса.

[whirlwind]

Получение/установка атрибутов через специализированные методы сохраняет класс полиморфным. Тут у некоторых камрадов факторы удобства не с той стороны растут. Удобство - это не тогда, когда сокращается количество набираемых буковок. Удобство - это когда модификация кода не требует переписывания проекта с нуля (утрировано намеренно, что бы дошло, о чем речь). Чем меньше полиморфности, тем сложнее вносить модификации. Полиморфизм - это свойство интерфейса (т. е. поведения). А у атрибутов нет поведения, они представляют собой состояния и они не полиморфны. Надеюсь это поможет понять почему говорят нет паблик пропертям и почему говорят да геттерам-сеттерам.

 

[Fortop]

whirlwind
Вы все правильно говорите, за исключением одного.

Все же стоит спуститься на землю и жить реалиями.
Удобство это когда инструмент адекватен (соответствует) задаче.

Если у нас простой скрипт для парсинга одного конкретного лога, то полиморфизм, геттеры/сеттеры, да и вообще ООП вкупе с TDD будут мягко говоря излишни. Данный скрипт пишется "лапшой" за 5 минут, еще 5 минут тестируется и будет работать годами. Написать 5-7 классов и 50-70 тестов к ним для данной задачи - это апофеоз неадекватности.

 

[whirlwind]

Fortop В данной теме рассматривается не скрипт парсинга одного конкретного лога, а общий вопрос. А реалии у каждого свои собственные, как и задачи, и способы их решения.

 

[Fortop]

whirlwind
Общий вопрос таков -
Удобство это когда инструмент адекватен (соответствует) задаче.
А это
Удобство - это когда модификация кода не требует переписывания проекта
лишь частный случай для достаточно крупных проектов.

Выгоды полиморфизма в общем случае - не видны. Что ТС весьма успешно доказал еще в своем первом сообщении ничего не сделав и удивляясь(возмущаясь?), что массив не приводится к нужному типу.

 

[whirlwind]

Fortop вы мне-то что доказываете? Вы сказали что не признаете геттеров/сеттеров, а я просто всем объяснил в каких случаях это используется. Мне по большому счету плевать кто как и что пишет. Я просто разъясняю те моменты, которые думаю что понимаю.

 

[Fortop]

Вы сказали что не признаете геттеров/сеттеров

Большая просьба не стоит переиначивать мои слова.

Я сказал что я не терплю геттеры/сеттеры везде ради них самих - они мне банально неудобны. Вы же пропагандируете именно этот бездумный подход.

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

В неявном виде геттеры/сеттеры там где они нужны - вполне используемая вещь.

 

[whirlwind]

Fortop за мыслями своими следите

Автор оригинала: Fortop
Мне? Я вообще не перевариваю геттеры/сеттеры везде. Но скажите об этом авторам ZF.

Я в упор не вижу смысла когда весь код геттера и сеттера содержит только присваивание без какой-либо обработки.

а теперь, где я пропагандирую?

-~{}~ 17.02.10 14:18:

PS. кароче, это у же на троллизм смахивает. Будут конкретные вопросы, задавайте - обсудим.

 

[Fortop]

whirlwind
И где Вы умудрились усмотреть противоречия в сказанном мной выше и в том, что Вы процитировали?

Поэтому Вы абсолютно правы

это у же на троллизм смахивает. Будут конкретные вопросы, задавайте - обсудим

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

 

[fixxxer]

Автор оригинала: korchasa
fixxxer
А что вместо них? Есть у пользователя имя, например. Его надо выводить в письмах, на страницах и т.д. Как это будет выглядеть в вызове?

class User implements RenderableInterface {

    protected $name;

    public function renderTo($Template) {
        $Template->assign(array(
            'name' => $this->name
        ));
    }

}

 

[Вурдалак]

Автор оригинала: C_TIGER
вообще я при разработке пишу где могу empty()
но нотисы у меня выключены

— ты до сих пор не знаешь различий между

! empty($var)

и

isset($var)

?

 

[C_TIGER]

Вурдалак
хватит троллить
ясно же что я писал о if($var['key'])

 

[fixxxer]

C_TIGER

Ты у себя можешь писать @ в каждой строке, отключать нотисы и ковыряться урановым ломом в носу. Кто ж тебе запретит. Но за такие советы тут принято награждение почетным орденом "Read Only". Так что лучше поуспокойся. И пойми, будь ты на собеседовании у нормального руководителя разработки, оно бы закончилось уже на этих твоих, гхм, предпочтениях.

 

[korchasa]

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

class User implements RenderableInterface {

    protected $name;

    public function renderTo($Template) {
        $Template->assign(array(
            'name' => $this->name
        ));
    }

}

Нормальное решение, че. Правда приходится в голове держать, что имя пользователя всегда суется в переменную шаблона name, и список пользователей вывести невозможно.

 

[fixxxer]

Список пользователей выводит UserList::renderTo()

Насчет держать в голове - ну тут я упростил просто, обычно все такие переменные описываются в phpDoc и оттуда все видно.

 

[Fortop]

Список пользователей выводит UserList::renderTo()

Логично вобщем-то. Но малость запутано. Что если мне надо 2 списка пользователей?
Кстати у Вас не опенсорс случаем? С удовольствием посмотрел бы как у Вас все организовано.

ну тут я упростил просто, обычно все такие переменные описываются в phpDoc и оттуда все видно.

Можно чуть подробнее?
в phpDoc шаблона? Или где?

 

[C_TIGER]

fixxxer
тут принято<<<
а еслиб было принято головой о стенку биться? бейся тогда.

Зы. мне такой руководитель не нужен. который исходит из предрасудков а не результатов

 

[fixxxer]

> в phpDoc шаблона? Или где?

В самом классе сущности (например user). Я обычно делаю сам простые шаблоны вида h1-h2-p, и уже их передаю верстальщику на натяг дизайна. Если же организовано иначе, просто ставится {{ debug }} в шаблоне и все видно.

Фреймворк вообще под LGPL, но показывать пока стыдно, ибо пока что он в весьма зачаточном состоянии, а с покрытием тестами вообще беда =)

-~{}~ 18.02.10 00:43:

C_TIGER

ну не хочешь по хорошему твое дело

 

[Fortop]

Фреймворк вообще под LGPL, но показывать пока стыдно, ибо пока что он в весьма зачаточном состоянии, а с покрытием тестами вообще беда =)

Ну с тестами я сам не сильно дружу. Для них нужна просто иная культура программирования.

А подпосмотреть идеи всегда любопытно.

Но вот статик метод меня смущает. Получается я не могу иметь 2 объекта например и рендерить их в разные места/подшаблоны

 

[fixxxer]

тут я тоже упростил.

там на самом деле структура, через __get клонирующая себя, и выглядит это в контроллере страницы примерно так

$Users = UserList::construct()->findByName($this->Form->name);
$OnlineUsers = OnlineUserList::construct()->load();

$this->View->Users->bind($Users);
$this->View->StatusPanel->ActiveUsers->bind($ActiveUsers);

Если нужны разные механизмы рендеринга - это решается тоже:

$UserList->setRenderer(new FancyUserListRenderer);
....
UserList::renderTo($Template) {
    $this->Renderer->fillFrom($this)->renderTo($Template);
}

Но надо заметить, что нужно это бывает нечасто. Причем если это view логика (что чаще), то можно и иначе - в контроллере страницы

$this->View = new UserListFancyView;

и уже постобработка в его методе.

На самом деле ни разу не приходилось делать такое - все решаю через хелперы. =)

 

[cDLEON]

OnlineUserList::construct()

о_О