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

Вурдалак

Продвинутый новичок
Вот ты каждый раз впадаешь в гадания о том
Никакого гадания, статические конструкторы — это перегрузка конструктора и есть. Плюс ещё в том, что мы даём конструктору имя, поэтому даже в языках с перегрузкой нередко используют именно такой подход.

так как они хардкодят зависимости в проектах. вместо foo(Contact\User $user) будут использовать User::register()
Каким образом User::register() тут поможет? User::register() даст нам новый инстанс, а чтобы передать уже существующий потребуется именно его передать в явном виде. User::register() — это не локатор, это сахар для new User(...).

Я как будто общаюсь не с человеком, который себя сеньором-помидором считает, а с бабкой, которая выступает за запрет трансплантации органов, потому что это грех.
 

AmdY

Пью пиво
Команда форума
Ну разница в том, что в первом случае передастся зависимость и через DI её можно подменить, тем самым упростив поддержку и реиспользование кода.
 

ivanov77

Новичок
У меня имеются объекты, которые должны существовать в единственном экземпляре, понятно что синглтон, но чтобы не было жесткой завязки, что думаете насчет применения такого фасадика? (для Yii2):
Код:
//В конфиге для DI
\Yii::$container->set('app\components\BookingInterface', 'app\components\BookingService');

//Сам фасад
class BookingFacade
{
  private static $instance;
 
  private static function getInstance()
  {
    if (null === self::$instance) {
      // Создадим через DI инстанс нужного типа
      self::$instance = \Yii::createObject('app\components\BookingInterface');
    }
    return self::$instance;
  }
 
  // а теперь публичные методы для работы с внутренним объектом
 
  public static function initialize($a, $b)
  {
    self::getInstance()->initialize($a, $b);
  }
 
  public static function getData()
  {
    return self::getInstance()->getData();
  } 
 
}
И теперь
- в экшене контроллера можно вызывать без всяких инжекций в конструктор
BookingFacade::initialize()
И жесткой зависимости нет, т.к. реальный обрабатывающий объект конфигурируется через DI
- в виевсе тоже спокойно получить эти данные
BookingFacade::getData()

Т.е. это будет по сути работать как Yii ServiceLocator (Yii::$app->get('someComponent')->getData()) но без завязки на тот ID компонента из конфига и не надо думать в какие конфиги компонент указывать.
 

Andreika

"PHP for nubies" reader
а зачем тут вообще фасад, если BookingService вроде как можно объявить сингтоном напрямую?
 

fixxxer

К.О.
Партнер клуба
А что, в yii настолько тяжело использовать DI по прямому назначению, что приходится использовать его как сервис-локатор с костылями?
 

ivanov77

Новичок
а зачем тут вообще фасад, если BookingService вроде как можно объявить сингтоном напрямую?
У меня синглтон всегда ассоциировался с четко определенным классом, жесткой зависимостью, но смотрю что в yii вроде можно сделать и "интерфейс синглтон".
На статике просто у меня сейчас эти вещи реализованы, и не хотел вызывающий код(BookingFacade::initialize()) много где менять, но видимо придется...
 

fixxxer

К.О.
Партнер клуба
звучит как "если очень хочется, то можно вырезать гланды не через анус" :)
 

Вурдалак

Продвинутый новичок
Ебутся два гея:
— Надевай фасад!
— И закончим быстро!
— Больно!
— Терпи, потом поменяем проект!
 

Adelf

Administrator
Команда форума
Какой неожиданный поворот дискуссии.
 

AmdY

Пью пиво
Команда форума
Т.е. это будет по сути работать как Yii ServiceLocator (Yii::$app->get('someComponent')->getData()) но без завязки на тот ID компонента из конфига и не надо думать в какие конфиги компонент указывать.
насколько я понял из документации, то никакого айди ID не надо указывать, прописал в конфиге DI сервис, а в контроллерах он автоматически будет инджектиться. У вас будет явная зависимость, которой вы сможете управлять через конфигурацию только одного конфига DI, а не лазить по всему коду в случае изменений. Опять же есть setSingleton, если считаете что эти данные реально надо шарить.
Another example is to take advantage of the automatic constructor injection of the DI container. Assume your controller class depends on some other objects, such as a hotel booking service. You can declare the dependency through a constructor parameter and let the DI container to resolve it for you.
Хотя выше предлагают не использовать фасад, а зафигачить статик конструктор с красивым именем прямо в Booking. Едь если судить по названию getData, то вы считате что у вас какой-то VO и значит можно шпилиться в статик методы, раз так видите.
 

Adelf

Administrator
Команда форума
Едь если судить по названию getData, то вы считате что у вас какой-то VO
Ну чего ты так разгорячился :) Там почти наверняка обычный сервис и конструктор-инъекция с BookingInterface - простейший и самый правильный вариант. Не надо много думать тут.
 

AmdY

Пью пиво
Команда форума
Ну чего ты так разгорячился :) Там почти наверняка обычный сервис и конструктор-инъекция с BookingInterface - простейший и самый правильный вариант. Не надо много думать тут.
ну, видишь чуваки укушенные тейлором, считают что di правильнее использовать через фасад, а не конструктор. хотя в случае laravel эта была вынужденная мера при переходе на php 5.3 между L3 и L4
 

fixxxer

К.О.
Партнер клуба
В случае с ларавелом это был скорее костыль для перехода с коханаподобной статики на DI с сохранением BC (ну, условно, понятно что там многое сломалось в любом случае). 5.3 с __callStatic просто позволил это сделать.
 

AmdY

Пью пиво
Команда форума
В случае с ларавелом это был скорее костыль для перехода с коханаподобной статики на DI с сохранением BC (ну, условно, понятно что там многое сломалось в любом случае). 5.3 с __callStatic просто позволил это сделать.
А почему ты думаешь что что-то поломалось? Учитывая появление и неймспейсов, думаю там всё прошло ок, статик вызовы превратили в обращение к фасадам, а оригинальные классы вынесли в неймспейсы. Ничего не должно было сломаться.
 
Сверху