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

[Lightning]

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

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

if(MyValidator :: is_valid($var)) {

выглядит предпочтительней чем

$my_validator = new MyValidator();
if($my_validator->is_valid($var)) {

Кроме того, я использую статический вызов для доступа к синглтону, который является контейнером "звездных объектов", таких как БД, сессия и т.д., чтобы не передавать этот контейнер во все методы. Как-то так:

$db = myframework_Context :: get_instance() -> get_db();

Но статические вызовы порой затрудняют блочное тестирование и имеют еще ряд недостатков.

Вопросы:
1. В каких случаях Вы используете статические вызовы?
2. Если Вы не используете статические вызовы, то как Вы реализуете описанные выше примеры?
3. Если Вы используете статические вызовы, то как Вы решаете проблемы с блочным тестированием?

 

[HraKK]

$my_validator = new MyValidator();
if($my_validator->is_valid($var)) {

if( $this->isValid( $var, new MyValid() ) )

 

[AmdY]

я делаю с точностью до наоборот.
для валидации создаю объект и создаю цепочку, а для "звёздного" чисто статику Registry::getDb()

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

 

[Lightning]

if( $this->isValid( $var, new MyValid() ) )

Дело не в том во сколько строчек записать. Дело в том, что зачем в таком простейшем случае вообще создавать объект?

 

[HraKK]

Спичечная оптимизация детектед

 

[Lightning]

HraKK
Я про оптимизацию что-то писал что-ли?

-~{}~ 20.04.09 22:41:

Зачем создавать объект, который нужен в этом же методе в следующей же строке кода и больше нигде дальше не используется?

 

[dimagolov]

HraKK
Я про оптимизацию что-то писал что-ли?

-~{}~ 20.04.09 22:41:

Зачем создавать объект, который...

вот, сказал же

 

[Lightning]

HraKK
Можешь ответить по пунктам на мои вопросы из первого поста?

-~{}~ 20.04.09 22:44:

вот, сказал же

Что сказал?

 

[dimagolov]

если тебя волнует вопрос создавать или нет объект, то это уже спичечная оптимизация

 

[Lightning]

если тебя волнует вопрос создавать или нет объект, то это уже спичечная оптимизация

Откуда эта предвзятость? Почему ты думаешь, что меня это волнует в плане производительности?

Меня волнует недостаточная мотивация использования объекта. Что мы в данном случае получаем, используя объект?..

Короче, примеры кода:
1. Использование объекта мотивировано:

    //...

    $my_validator = $this->get_my_validator();
    if($my_validator->is_valid($var)) {

    //...

    $my_validator = $this->get_my_validator();
    if($my_validator->is_valid($var2)) {

    //...

    private function get_my_validator() {
        //...
        if($condition1) {
            return new MyValidator1();
        } elseif($condition2) {
            return new MyValidator2();
        } //...
    }

    //...

2. Использование объекта не мотивировано:

//...
$my_validator = new MyValidator();
if($my_validator->is_valid($var)) {
//...

 

[dimagolov]

Lightning, у тебя странная мотивация. Тут уже была тема, где обсуждалось, почему статика это зло. Ты же аргументируешь создание статического класса (то есть глобальный неймспейс) нежеланием создавать объект, который необходим однократно. Честно говоря непонятно, почему тебе однократное использование объекта (который можно сделать от класса реализующего интерфейс и передать как проверяемый по типу интерфейса параметр) нравится больше, чем статическое привязывание кода к классу. Если тебя не волнует производительность, а чистота ООП, то наличие статического класса должно пугать сильнее. Он в твоем случае ничем не лучше имени ф-ии валидатора, только допускает lazy-load

 

[Lightning]

dimagolov

чем статическое привязывание кода к классу

И здесь

if(MyValidator :: is_valid($var)) {

и здесь

$my_validator = new MyValidator();
if($my_validator->is_valid($var)) {

привязка кода к классу есть !!! И тут мне не надо передавать никуда объект !!! Это простейший случай. Тут объект ничего не дает!

-~{}~ 20.04.09 23:54:

Если тебя не волнует производительность, а чистота ООП

Меня чистота кода волнует !

-~{}~ 20.04.09 23:57:

В первом посте я задал относительно конкретные вопросы, я надеюсь что найдутся добрые люди, которые будут отвечать именно на них

 

[dimagolov]

привязка кода к классу есть !!!

HraKK тебе сразу написал:

if( $this->isValid( $var, new MyValid() ) )

то есть объект получает валидатор параметром, для которого контролируется интерфейс и потом использует этот интерфейс. Привязки к конкретному валидатору нету, есть привязка к интерфейсу. В случае же MyValidator :: is_valid нам надо аналогично делать интерфейс для параметра $var, чего у тебя нету, и валидатор может получить то, что проверить он не сможет.

В общем, тут все упирается прежде всего в то, кто о ком должен больше знать и кто кем пользоваться.

Объясни, почему ты не сократишь

if(MyValidator :: is_valid($var)) {

до

if(is_valid($var)) {

? ведь видимой пользы от статического класса нету, так же как по-твоему и от объекта.

-~{}~ 20.04.09 17:07:

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

 

[Alexandre]

$db = myframework_Context :: get_instance() -> get_db();

так проще

$db = db:: get_instance()

использую статику для звездных объектов:
- конфигурация
- БД
- кеш
хотя динамические объекты - предпочтительнее. Просто используя синглетоны - код становится гламурнее.

 

[Lightning]

Объясни, почему ты не сократишь

if(MyValidator :: is_valid($var)) {

до

if(is_valid($var)) {

? ведь видимой пользы от статического класса нету, так же как по-твоему и от объекта.

Чтобы можно было использовать класс как статически так и не статически.

-~{}~ 21.04.09 00:18:

так проще

$db = db:: get_instance()

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

-~{}~ 21.04.09 00:21:

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

Как ты работаешь со "звездными" объектами?

 

[dimagolov]

мыши плакали, кололись, но продолжали есть кактус (с)

Иногда статические вызовы помогают мне сделать код компактнее и проще

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

 

[Lightning]

dimagolov
Потому и создал этот топик

-~{}~ 21.04.09 01:15:

Как ты работаешь со "звездными" объектами без статики?

-~{}~ 21.04.09 01:25:

Помниться вроде кто-то на форуме писал, что обходиться вообще без статики...

-~{}~ 21.04.09 01:27:

Это был whirlwind. Хотелось бы его по этому поводу послушать.

 

[pilot911]

статика рулит поскольку очень сильно упрощает жизнь...

как говорит Страустру:

Использование статических членов класса может заметно сократить потребность в глобальных переменных. Описывая член как статический, мы ограничиваем его область видимости и делаем его независимым от отдельных объектов его класса. Это свойство полезно как для функций-членов, так и для членов, представляющих данные.

 

[Духовность™]

поскольку очень сильно упрощает жизнь...

но в один прекрасный момент она так её усложняет, что приходится огого сколько переписывать.

 

[whirlwind]

На мой взгляд, это так же не верно

if( $this->isValid( $var, new MyValid() ) )

из-за инстанцирования. Привязка к именам класса практически ничем не отличается от статических вызовов.

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

-~{}~ 21.04.09 11:37:

ЗЫ. кстати, когда мне нужно создать объект в 1 экземпляре, я использую фабричный метод.