Pull to refresh
28
0

User

Send message
Думал над такой вещью, но не знал, что она есть.

Спасибо.
ошибся на 8 :)
1 Гб на 768 Кбит за 23 минуты
Не уверен, что целесообразно всегда передавать array в сложных проектах.
Наглядность пропадает.

function name($input){
  if ($input[0]){
    str_replace($input[1], $input[2])…
  }
}
1000-й в рейтинге хабралюдей… Можете напиться ;)
Хорошо.
Значит это не Синглтон :)
Я не вижу смысла использовать в PHP статический класс вместо функции…

$mod=modules::getInstance() — я считаю, что это идиотизм. (касательно PHP)
$mod->cache('a.php');
$mod->include('a.php');

Вариант выглядит намного яснее:
mods()->cache('cache.dat')->phpcache('cache.php')->include('a.php')->include_modules();
Либо:
$mod=mods();
$mod->cache('a.php');
$mod->… ну итд

Если вы мне объясните, какое преимущество в «объектной моделе» (касательно PHP), я приму иную точку зрения. А «Так НАДО» — это, простите, тупизм.
p.s. Если хотите, могу не называть это singleton — смысл не потеряется. :)
Я в курсе — у самого такая реализация есть. Я о другом…
Как вы перебор вызовов функций С ПАРАМЕТРАМИ повесите на якорь?
Причём здесь паттерны?
В чём оригинальность?
Я уже говорил о производительности.

Я работал с системой Эвентов — после данной модификации:
1) код стал намного чище
2) система ускорилась в 3 раза.
Динамика в несколько раз медленее. Я уже говорил, что не от хорошей жизни это было реализованно.
Короче уехали мы не туда.
Я понимаю, что вы называете эвентами.

Класс Эвентов на PHP (особенно в реализации call_user_func) будет вызываться в несколько раз дольше, чем готовый, собранный класс.
Не нравится пример, пользуйтесь $ship->energy->get()

class Energy{
  var $maxenergy, $incenergy;
  function get(){...}
  function use(){...}
}

//Интерфейс энергии
class Ship{
  public $energy;
  function __construct(){
      $this->energy=new energy();
  }
}
Пример не очень верный… Но Лазер можно убрать из игры вообще, простым удалением файла.
>>> А если вам понадобится использовать лазер где-то в другом проекте отдельно от корабля, то придётся писать $laser->laser_heatEmergency()? По-моему это начало моего второго варианта.

Вы совершенно не поняли суть идеи.

Я не прав, потому что плохо объяснил всё.

Суть идеи НЕ РЕАЛИЗОВЫВАТЬ лазер внутри корабля. Нет!
Суть идеи (я немного в конкретику вдарюсь):
1) Дополнять 'корабль' независимыми друг от друга разработчиками, зависимыми устройствами.
2) Каждое устройство — это отдельный класс.
3) Интерфейс устройств описывается к классе корабля.
4) Файлы должны быть независимыми.

То есть:
Energy.php
//Всё, что связанно с энергией на корабле
class Energy{
var $maxenergy, $incenergy;
}

//Интерфейс энергии
class Ship{
  public $energy;
  function __construct(){
     $this->energy=new energy();
  }
  function energy_get(){...}
  function energy_use(){...}
}

Уберите этот файл из модулей — система продолжит функционировать (если другие устройства не зависят от energy_get/energy_use). Просто на корабль невозможно будет поставить устройство Energy.

Я предложил метод, который упрощает разработку, НО не настаивает в том, чтобы лепить классы в ОДНО.
Эвент:
energy()->get_ship_energy($ship)
Мой метод:
$ship->get_energy();

Что нагляднее?
Что быстрее выполнится?

Information

Rating
Does not participate
Location
Россия
Registered
Activity