Как в системе именования PEAR именовать классы-интерфейсы?

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

Что-то я не врубаюсь. Вот, прочитал в каком-то блоге, что

Интерфейсы должны следовать таким же правилам, как и классы, и заканчиваться словом “Interface” (например: Zend_Log_Adapter_Interface)

Вот тут я не врубаюсь.

Допустим, у меня есть такая иерархия:

Db_Mysql_Statement - объект результата. Сейчас надо интерфейс создать для этого класса. Как он должен называться, т.е. где он должен лежать?

 

[AmdY]

Db_Statement_Mysql
Db_Statement_Interface

 

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

Т.е. получается, что мы создаем иерархию не по типу драйвера БД, а по типу инструмента?.. вот не знаю, правильно ли это? Вспоминается пост баева, где он критиковал меня, что я пытаюсь хранить программы не по их естественному типу, когда программы А и Б лежат отдельно, а когда все разделено по директориям .bat, .exe, .c и т.д

 

[Вурдалак]

Нет, ну если уж baev сказал, то так делать нельзя.

 

[grigori]

зависит от чего ты абстрагируешься интерфейсом: если от типа базы, то интерфейс - по типу инструмента
а от чего можно абстрагироваться, создавая интерфейс Statement_Mysql_Interface? в чем различие реализаций?

 

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

зависит от чего ты абстрагируешься интерфейсом: если от типа базы, то интерфейс - по типу инструмента

это как? поясни на примере

а от чего можно абстрагироваться, создавая интерфейс Statement_Mysql_Interface? в чем различие реализаций? :

mysql и mysqli, например

 

[itprog]

interface Zend_Log_Adapter_Interface {}

duplicate code - зло.

 

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

duplicate code - зло.

Ты о чем?

 

[grigori]

>это как? поясни на примере
обычно интерфейс делают для создания абстракции от чего-то, например, от типа базы данных
с какой целью ты его делаешь?
это определит, что ты делаешь, и станет ясно, как это назвать

>mysql и mysqli, например
это абстракция от драйвера

 

[itprog]

Духовность™
о том, что способ именования интерфейсов в pear и зенде дурацкий. Зачем повторять слово interface два раза в определении интерфейса?

 

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

Духовность™
о том, что способ именования интерфейсов в pear и зенде дурацкий. Зачем повторять слово interface два раза в определении интерфейса?

где про это написано?

с какой целью ты его делаешь?
это определит, что ты делаешь, и станет ясно, как это назвать

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

<?php
class DB_Mysql_Statement
{
    /**
    * Рузультат SQL-операции в виде ресурса.
    *
    * @var resource
    * @access private
    */
    private $result;

    /**
    * Возвращает количество рядов в результате.
    * Эта команда верна только для операторов SELECT.
    *
    * @access public
    * @param void
    * @return int
    */
    public function getNumRows()
    {
        return mysql_num_rows($this->result);
    }

    public function __construct($result)
    {
        $this->result = $result;
    }

    public function getResult()
    {
        return $this->result;
    }

    public function fetch_assoc()
    {
        return mysql_fetch_assoc($this->result);
    }

    public function fetch_row()
    {
        return mysql_fetch_row($this->result);
    }

    public function fetch_assoc_array()
    {
        $array = array();

        while(($row = mysql_fetch_assoc($this->result)) !== FALSE)
        {
            $array[] = $row;
        }

        return $array;
    }

    public function fetch_row_array()
    {
        $array = array();

        while(($row = mysql_fetch_row($this->result)) !== FALSE)
        {
            $array[] = $row;
        }

        return $array;
    }

    public function getOne()
    {
        $row = mysql_fetch_row($this->result);

        return $row[0];
    }

    public function free()
    {
        return mysql_free_result($this->result);
    }

    public function __destruct()
    {
        $this->free();
    }
}
?>

 

[grigori]

офтоп: imho интерфейс Statement лучше брать из PDO/MySQLi, а не урезать общий стандарт для обратной совместимости

>создаем иерархию не по типу драйвера БД, а по типу инструмента?
если ты делаешь абстракцию _от_ типа драйвера, то иерархию делай по общей черте - тип инструмента, фаза луны, количество коньяка

 

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

>создаем иерархию не по типу драйвера БД, а по типу инструмента?
если ты делаешь абстракцию _от_ типа драйвера, то иерархию делай по общей черте - тип инструмента, фаза луны, количество коньяка

т.е. как AmdY предложил?

 

[Krishna]

Имхо самое верное Db_Statement_Mysql implements Db_IStatement

 

[Вурдалак]

Зачем повторять слово interface два раза в определении интерфейса?

— пространство имён классов и интерфейсов общее, так что добавить постфикс «_Interface» или «I» где-то придётся.

 

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

как это будет выглядеть?

 

[Вурдалак]

Духовность™, ты кого спрашиваешь?

 

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

Вурдалак
Вурдалака

 

[Krishna]

Имхо самое верное Db_Statement_Mysql implements Db_IStatement

Поправлюсь,

Db_Statement_Mysql implements Db_Statement_IStatement

чтобы структуру пакетов соблюдать.

 

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

Получается, что в Db/Statement/ будут храниться Mysql.php, Mysqli.php, OtherDb.php и IStatement.php

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