Область видимости объектов в классах и методах

[maximing]

Область видимости объектов в классах и методах

Добрый день.

Есть код:

<?
$obj = new testClass();

class newClass {

 public function newMethod() {

    return $obj->testMethod();

 }

}
?>

В методе newMethod объект $obj не виден.

Неужели для того, чтобы объект был виден нужно:

создавать объект непосредсвенно в методе:

<?
class newClass {

 public function newMethod() {

    $obj = new testClass();
    return $obj->testMethod();

 }

}
?>

или объявлять объект глобальным

<?
$obj = new testClass();

class newClass {

 public function newMethod() {

    global $obj;

    return $obj->testMethod();

 }

}
?>

Или можно обойтись по-другому?

 

[Gremboloid]

передать как параметр метода

<? $obj = new testClass();  
class newClass {  
  public function newMethod(testClass $obj) {
    return $obj->testMethod(); 
  }
} ?>

забудь про global

 

[Adelf]

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

 

[dimagolov]

maximing, вставляя в код метода класса newClass ссылку на внешний объект ты делаешь этот класс зависимым от того объекта. Создавая его внутри метода ты делаешь один класс зависимым от другого. В зависимости двух классов может и не быть ничего плохого, но надо смотреть на конкретные абстракции. Что за классы у тебя в реальности?

 

[maximing]

Автор оригинала: dimagolov
maximing, вставляя в код метода класса newClass ссылку на внешний объект ты делаешь этот класс зависимым от того объекта. Создавая его внутри метода ты делаешь один класс зависимым от другого. В зависимости двух классов может и не быть ничего плохого, но надо смотреть на конкретные абстракции. Что за классы у тебя в реальности?

У меня есть класс для работы БД и есть с десяток классов, где нужно использовать методы класса для работы с БД.

<?
class DB {

}

class A {
// Нужно использовать методы класса DB
}

class B {
// Нужно использовать методы класса DB
}

class N {
....
}
?>

может быть наследовать?

<?
class DB {

}

class A extends DB {
// Нужно использовать методы класса DB
}

class B extends DB {
// Нужно использовать методы класса DB
}

class N extends DB {
....
}
?>

?>

 

[A1x]

Re: Область видимости объектов в классах и методах

Автор оригинала: maximing
Добрый день.

Есть код:

<?
$obj = new testClass();

class newClass {

 public function newMethod() {

    return $obj->testMethod();

 }

}
?>

В методе newMethod объект $obj не виден.

не существует "Область видимости объектов", есть область видимости переменных

если ты присвоил переменной $obj что-то (ссылку на объект) снаружи метода это не значит что это будет ни стого ни с сего видимо внутри метода
как и для любой другой переменной

 

[Gremboloid]

В большинстве случаев тут достаточно объект класса DB, передавать как параметр в конструктор объекта для классов A, B, N, ...

 

[whirlwind]

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

 

[Adelf]

class DB
{
    static $instance = null;
    function getInstance()
    {
        if(!is_null($this->instance)) return $this->instance;
        $this->instance = new self();
        return $this->instance;
    }
}

class N{
....
        $db = DB::getInstance();
        $db->...
....
}

Возможно тебе поможет такой код. Общее название данного подхода - шаблон Singleton(Одиночка). Если тебе нужно, чтобы везде ты мог использовать только один и тот же обьект данного класса, то это - наилучший вариант.

 

[whirlwind]

Ну вот, это был сон.

 

[Adelf]

whirlwind, )) чуток опоздал я.

-~{}~ 18.08.09 16:14:

Если только десяток(действительно правильный подход), то можно попробовать чтото вроде этого:

class AbstractModel
{
    protected $db;
    public function __construct()
    {
        $this->db = DB::getInstance(); // либо просто new DB() - если неважно
    }
}

class A extends AbstractModel
...
    $this->db->...
...

class B extends AbstractModel
...

и т.д.

 

[Gremboloid]

Adelf это не то что спрашивал ТС.

whirlwind, эти поварята всегда на чеку.

 

[Adelf]

Gremboloid, почему?

 

[Gremboloid]

да потому что, даже если и начинать сингтонить направо и налево, то конструции типа:
class A extends AbstractModel
тут не пришей кобыле хвост.

Для понимания надо обратиться к первоисточнику Карлу и Марксу.

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

 

[Adelf]

Ну мне действительно не очень понятны твои рассуждения. Во втором моем примере синглетонов нет. там можно как угодно создавать обьект. Можно принимать его и в качестве параметра к конструктору, неважно. Как удобно ТСу.

 

[tf]

паттерн Registry

 

[Gremboloid]

Adelf


dimagolov четко описал ответ на твой вопрос в самом начале. Ответь сам, себе, зачем городить весь этот огород в виде надстроек, не несущий в себе никаких выгод, кроме еще одной зависимости?

 

[A1x]

у ТСа проблемы с пониманием областей видимости а ему уже чего только не предлагают))

 

[Adelf]

Ну в данной ситуации вообще-то придется зависимости делать. Ибо эти классы полюбому будут зависеть от DB. Может приведете пример как бы вы сами решили данную задачу?

 

[whirlwind]

Надо делать зависимость от интерфейсов, а не от конкретный реализаций. Разницу понимаете?