Статические вызовы

Lightning

Трудоголик
Привязка к именам класса практически ничем не отличается от статических вызовов.
Да, именно!
Я не совсем понял, вопрос-то о валидаторах или о статике вообще?
О статике вообще. Просто я в первом посте привел два примера, где я использую статику, и началось...
А вот если у вас валидация конкретно в контроллере (т.е. речь уже не столько о проверки соответствий, сколько о принятии решений), вот тут может иметь смысл разделение на реализации.
Не понял. Что разделять? Контроллер знает какие данные получает и знает как их проверить, это разве неправильно?
ЗЫ. кстати, когда мне нужно создать объект в 1 экземпляре, я использую фабричный метод
Всегда фабричный метод? Зачем? Если от класса нет наследников и какой-либо объект создается в нем в одном месте один раз, зачем фабричный метод?
whirlwind
И еще вопрос: Как ты работаешь со "звездными" объектами без статики?
 

whirlwind

TDD infected, paranoid
Автор оригинала: Lightning
Что разделять? Контроллер знает какие данные получает и знает как их проверить, это разве неправильно?
Ну правильно, если рассматривать контроллер как черный ящик. Но контроллер ведь то же с чем-то работает, например с моделью. Одна и та же модель используется разными контроллерами, так почему бы валидацию не реализовать в модели, а обработку невалидных данных выполнять в контроллере.

Всегда фабричный метод? Зачем? Если от класса нет наследников и какой-либо объект создается в нем в одном месте один раз, зачем фабричный метод?
Даже не знаю как ответить. Встречный вопрос - а как ты тестируешь например http запрос из твоего класса? Для того что бы тебе реализовать тестирование класса черного ящика, тебе нужно зафикстурить туеву хучу данных. Никто этот геморой оплачивать не будет. Но тестировать-то надо? Как это сделать? Как подменить код классов, пользовательских по отношению к тестируемому? Что бы подменить реализацию (например моком), нужно иметь либо сеттер, либо фабричный метод (что бы сделать частичный мок из тестируемого класса).

И еще вопрос: Как ты работаешь со "звездными" объектами без статики?
А что такое звездный объект? Почему нельзя их инжектить или передавать аргументами?
 

korchasa

LIMB infected
Автор оригинала: whirlwind
Ну правильно, если рассматривать контроллер как черный ящик. Но контроллер ведь то же с чем-то работает, например с моделью. Одна и та же модель используется разными контроллерами, так почему бы валидацию не реализовать в модели, а обработку невалидных данных выполнять в контроллере.
Ну кроме доменной валидации есть еще и интерфейсная (каптча, совпадение значений паролей). Ее то в модельку не засунешь. Как ты ее реализуешь? Отдельных класс?
 

whirlwind

TDD infected, paranoid
Частные случаи в контроллерах. Ну для $pass1 == $pass2 класс писать это, согласитесь, маразм уже.

PS. Просто частные оно на то и частные, что редкие. 20/80
 

whirlwind

TDD infected, paranoid
Автор оригинала: Lightning
Напрмер БД, сессия, конфиг и т.д.

Можно, но лишнее усложнение кода.
Я это знаю, я спрашиваю почему они называются звездными? У них звездная болезнь чтоле?
 

Lightning

Трудоголик
Эти объекты могут понадобиться где-угодно, т.к. предоставляют основные "системные" возможности, и как следствие они являются самыми популярными объектами (т.е. их используют очень большое кол-во объектов), поэтому наверное их и называют звездными.
 

whirlwind

TDD infected, paranoid
Попса, короче :) Ты только забыл написать при чем здесь статический вызов. Почему например не общий базовый класс, который обеспечит доступ к помоеч... популярным объектам? Потому что так все делают? :)

ЗЫ. а где же смекалко тру-программера?
 

Lightning

Трудоголик
Ты только забыл написать при чем здесь статический вызов.
В первом посте написал.
Почему например не общий базовый класс, который обеспечит доступ к помоеч... популярным объектам?
Но в этом общем базовом классе будет же один статический вызов.
 

whirlwind

TDD infected, paranoid
1. Я не сказал что это правильное решение
2. 1 статический вызов лучше чем очень большое количество статических вызово
3.

upd. даже так
PHP:
class MegaBase {
    private static $global;
    
    function getGlobal()
    {
        return MegaBase::$global;
    }
    
    function setGlobal($value)
    {
        MegaBase::$global = $value;
    }

}

class Bar extends MegaBase {

    function printGlobal()
    {
        echo $this->getGlobal();
    }

}

require_once 'PHPUnit/Framework.php';

class TestTest extends PHPUnit_Framework_TestCase {

    function testPrint()
    {
        $bar = $this->getMock('Bar', Array('getGlobal'));
        $bar->expects($this->once())
            ->method('getGlobal')
            ->will($this->returnValue('foobar'));
        ob_start();
        $bar->printGlobal();
        $this->assertEquals('foobar', ob_end_clean());
    }

}
Ну все же лучше чем статический вызов. Но мне не верят и продолжают есть кактусы :)
 

Lightning

Трудоголик
whirlwind
1. Я так и знал.
Кстати, а есть все-таки правильное решение? Или это тайно?
3. а я думал как-то так
PHP:
abstract class Base {
    protected $context;

    public function __construct() {
        $this->context = Context :: get_instance();
    }
}

class MyClass extends Base{

    public function __construct() {
        parent :: __construct();
        //...
    }
}
 

whirlwind

TDD infected, paranoid
Смотри я апнул предыдущий пост

-~{}~ 21.04.09 23:08:

Серебряной пули нет. Есть интуиция, которая говорит мне что статика - зло, и опыт, который говорит, что без статики можно обойтись.
 

Lightning

Трудоголик
Ну все же лучше чем статический вызов. Но мне не верят и продолжают есть кактусы
Теперь я тоже тебе не верю :)
У тебя статическая переменная используется.
И вообще, этот код попахивает подстройкой под тестирование, а это мне не нравиться. Т.е. у тебя метод setGlobal() нужен только для тестирования. Мне не нравиться когда смешивается тестируемый код с тестовым кодом.
Подменить звездные объекты при тестах я могу без использования set-еров в тестируемом коде.
Есть интуиция, которая говорит мне что статика - зло
Мне тоже что-то говорит, что статика - зло. Создал топик, чтобы развеять сомнения. Но пока что вижу, что от статики не уйти...
 

whirlwind

TDD infected, paranoid
А я сразу сказал что это не лучший метод :) Мало ли что тебе не нравится, мне вот статики не нравятся :) Я не вижу чем он хуже кучи статиков, даже если он позволяет тестировать. А лучший метод, когда у тебя классы взаимодействуют с соседними классами, а не со всем миром. Но это очень мегатрудно и по этому я использую такое смешивание. И вообще это не смешивание, это частичный мок :)
 

whirlwind

TDD infected, paranoid
хммм.. насчет этого пока не знаю :) скорее нет, чем да. Зависит от того, о чем речь. Если у тебя там валидация примитивов, то наверное добро, а если сложная валидация, то наверное зло :)

-~{}~ 21.04.09 23:50:

PS. я же правильно понимаю, что это сферический класс в вакууме? :)
 

whirlwind

TDD infected, paranoid
Что о нет? Можно подумать у тебя идеальные тесты :) Случаи разные бывают. Если фабричный метод то какие варианты? Но в основном сеттеры.
 

Lightning

Трудоголик
PS. я же правильно понимаю, что это сферический класс в вакууме?
Ну почему же в вакууме? Это просто случай, когда набор валидаторов известен заранее и валидацию можно спокойно прямо в контроллере хардкодить. У тебя не бывает таких примитивных случаев валидации?
 

whirlwind

TDD infected, paranoid
Блин чесслово надоело тыщи раз одно и то же повторять. Валидаторы (а особенно наборы) имеют такое вредное свойство как изменяться очень часто. Завтра тебе по алгоритму луна надо будет номера кредиток проверять, что ты будешь делать? Правильно, ковырять и потенциально ломать рабочий код статика, потому что иначе никак. Любишь править баги когда тут изменил, там отвалилось? :) Я нет. И у меня они (баги) не водятся.
 
Сверху