ООП: объявление методов, оперирующих данными extends классов

[grigori]

x-yuri
скорее всего - чтобы меньше зависеть от метода другого класса

 

[sverel]

У меня похожая ситуация и вопрос: как из радительского класса обратиться к СТАТИЧЕСКОЙ переменной наследника?

Необходимо реализовать вот такую конструкцию:

abstract class API_MODEL {
	
	protected static $_TABLE;
	
	public static function getById($ID)
	{
		var_dump(self::$_TABLE);
    }
}

class MODEL_NEWS extends API_MODEL {
	
	protected static $_TABLE = 'news';

}

MODEL_NEWS::getById(23); // переменная  self::$_TABLE является NULL - т.е. родитель получает собственное значение.

Можно ли как то получить СТАТИЧЕСКОЕ значение класса-потомка?

 

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

Зачем тут статическая переменная? А если мы хотим использовать этот класс с другой таблицей?

 

[sverel]

Для каждой сущности (таблицы) свой класс наследник:

class MODEL_USERS extends API_MODEL {
protected static $_TABLE = 'users';
}

class MODEL_ARTICLES extends API_MODEL {
protected static $_TABLE = 'articles';
}

MODEL_NEWS::getById(23);
MODEL_USERS::getById(32);
MODEL_ARTICLES::getById(2332);

 

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

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

 

[sverel]

ты привязываешь имя таблицы к класс

Именно это и надо сделать.

Зачем использовать этот класс для другой таблицы???
Для другой таблицы есть другой класс.

Твой вопрос из разряда:
"А если мы на этом классе захотим в космос полететь???"

Ты можешь просто ответить на вопрос: как обратиться из родителя к статической переменной наследника? Тоже самое, что делаешь ты, но не через объекты, а статически.
Типа как parent::$var только наоборот child::$var

 

[dimagolov]

sverel, такого не надо хотеть со статическими переменными. почему ты не можешь из наследника менять статическую предка?

 

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

потому что он не хочет в каждом наследнике повторять getById() метод, в котором прописана реализация, использующая self::$Table

 

[sverel]

dimagolov, потому что предок один, а наследников много. Я хочу организовать работу Модели через статические классы вот таким образом:

MODEL_NEWS::getById(23);
MODEL_USERS::getById(32);
MODEL_ARTICLES::getById(2332);


Сейчас у меня реализованно вот так:
MODEL_EVRY::getById(TBL_NEWS, 23);
MODEL_EVRY::getById(TBL_USERS, 32);
MODEL_EVRY::getById(TBL_ARTICLES, 2332);
т.е. один универсальный класс, но хочется переделать что б было как выше.

 

[whirlwind]

бррр... скока ужасов

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

 

[sverel]

Между прочем, Zend Framework реализует аналогичную архитектуру:

class Articles extends Zend_Db_Table_Abstract
{
       // Имя таблицы
       protected $_name = 'articles';
}

$model = new Articles();
$model->delete($where); // метод из родителя который обращается к переменной наследника $this->_name;

Мне хотелось бы сделать так же, но статическое без создания объектов.

 

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

каких объектов?

 

[sverel]

Вот таких:

$modelArticles = new Articles();

 

[x-yuri]

Мне хотелось бы сделать так же, но статическое без создания объектов

это невозможно, на данный момент

 

[Lightning]

Мне хотелось бы сделать так же, но статическое без создания объектов.

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

 

[sverel]

А зачем все статическое?

А для чего нужны объекты?

 

[AmdY]

Lightning синглтон здесь ни каким боком, как раз вообще не хочет создавать объекта и использовать процедурное программирование

 

[Lightning]

А для чего нужны объекты?

Ну раз не нужны объекты, зачем тогда классы? )

modelGetById(TBL_NEWS, 23)

и все.

-~{}~ 05.03.09 01:17:

sverel
А много у тебя методов в родителе, или только GetById() ?

-~{}~ 05.03.09 01:18:

Или все методы в родителе, а в потомках только имена таблиц?

 

[sverel]

Классы нужны:
1. для объединения набора ф-ций. (эстетика + приватные методы).
2. Расширяемость методом наследования. Т.к. в потомках требуется переопределять методы для костомизации. Например так:

class MODEL_USERS
{
      static $_TABLE = 'users';


     protected function _prepareFrom(&$item) // в родителе этот метод пустой.
     {
            $item['^DETAIL_PAGE'] = 'users/' . $item['id'];
      }
}

В родителе порядка 20-30 методов (включая приватные).

 

[john.brown]

sverel
Ну вот, а объекты нужны для всего того же самого, пльюс для того, чтоб у них были свойства, и эти свойства можно было переопределить в потомках