Как передать объект БД в класс?

Это тоже почти вариант 1. Спасибо)

Макс Васильев, это вообще рядом не лежит с вариантом 1.
Класс передается по ссылке снаружи(то есть создается 1 раз и передается во все объекты где нужен, а не как в вашем случае создается новый экземпляр в каждом новом объекте). Так как это у вас реализовано - классический анитипаттерн.

ThunderCat, принял. Последний вопрос.. Вот так верно?)

class App{
  protected $db;
  public function initDB(PDO $db){
    $this->db = $db;
  }
}

class DB{
  public $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }
}

$db = new DB();
$app = new App($db);

или так

$db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
$app = new App($db);

пардон за грубый "код", но вопрос как раз больше про объект базы данных
:)

ой. в App тоже конструктор

class App{
  protected $db;
  public function __construct($db){
    $this->db = $db;
  }
}

Макс Васильев, первый вариант естественно работать не будет вообще, вы передаете в конструктор объект, но в коде класса конструктор не принимает никаких параметров, то есть сначала надо создать объект с пустым конструктором, затем вызвать метод initDB(), тогда по сути это будут очень близкие реализации, разница только методе передачи объекта ДБ внутрь апп. Оба варианта приемлемы, единственно что передача через конструктор это более короткий код и меньше операций. Единственно когда есть смысл использовать 2 вариант(с поправкой) это когда в конструктор нужно передать какие-то другие инициализирующие данные вместо ДБ.

Макс Васильев,

ой. в App тоже конструктор

у вас все немного смешалось. Либо конструктор принимает БД, либо отдельный метод, а то так у вас вообще 2 метода делают одно и то же.

В целом, мне все понятно. Большое спасибо.

То есть это вариант 1?

Макс Васильев, Нет.

Макс Васильев, в текущих обстоятельствах, как вы описали, да — вариант 1.

Макс Васильев, Почитайте про SOLID. Особенно про SRP. В идеале ваш App ничего не должен знать об устройстве класса для работы с БД. А значит иницализация БД не должна в App происходить.
То есть можно взять третий вариант и доделать его. Ну и если App нужна БД для работы, то нет никакого смысла принимать её в App::initDb() вместо конструктора.

Алексей Скобкин, туго я что-то понимаю по последней фразе. (По остальному гуд)

никакого смысла принимать её в App::initDb() вместо конструктора.

То есть, вариант 2 вообще плохой? и если и делать, то как в третьем? ну +-

Алексей Скобкин, частично согласен. Но в данном случае, как я вижу устройство приложения, мы имеем дело с God-объектом.
Вся реализация БД уходит в руки PDO. Потому можно было бы сказать, что App и не знает ничего об этом. И опять возвращаюсь к исходному — лишнее усложнение в текущей реализации не нужно.

Артур Э., ну я экспериментирую) Сделал класс App, который соединяет по сути всё приложение. То есть в этот класс передается объект БД, массивы там всякие GET, POST. и уже дальше работает MVC.
Видать я запутался не с классом App, а с классом DB)
Вот это

class DB{
  public $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost.....');
  }
  return $this->db;
}
$db = new DB();
$app = new App($db);

эквивалентно этому?

$db = new PDO('mysql:host=localhost;....'); //просто, переменная
$app = new App($db);

?

Макс Васильев, фактически — да.
Если App в конструкторе просто достает значение переменной $db->db

class App{
  protected $db;
  public function __construct(DB $db){
    $this->db = $db->db; // Тут фактически объект PDO
  }
}

Артур Э., А я, вроде, и не предлагал оборачивать PDO во что-то пока нет необходимости. Ну и да, App тут тоже против SRP идёт. Но я отвечал автору вопроса с поправкой на выбранную архитектуру. Он изобретает свой Laravel, но можно было бы предложить ему изобрести свой Symfony :)

Макс Васильев, А зачем вы в классе DB делаете свойство $db публичным? Ну и return вне методов прямо в теле класса - это дичь какая-то.

Алексей Скобкин, не изобретаю, а разбираюсь) Каждый двиг сделан по своему. Реально они отличаются. Хотя бы реализацией.)))

Спасибо парни. Буду изучать дальше)

Алексей Скобкин, поддерживаю "архитектурную чистоту".
Только применительно к топику я бы и упростил всё максимально. Иначе, действительно, получится новый Laravel, с кучей огрехов))

Мне, как раз синглтон, не нужен) В рамках, даже простого ооп, это уже не актуально.

И да, у вас класс БД, а речь о классе - оболочке App.

Макс Васильев, а может, вы просто не умеете их готовить? (с)

Чем вам синглтон не угодил как оболочка? Внутри него делаете статические методы, а потом обращаетесь к ним из ЛЮБОГО подключённого файла проекта, без всяких require. ИМХО, это очень удобно. А класс себе весело висит в памяти в единственном экземпляре.

Пример:

<?php
class App{
  protected static $_instance;

  private function __construct(){
    return new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }

  # Singlton methods
	public static function getInstance()
	{
		self::$_instance = self::$_instance ?? new self;
		return self::$_instance;
	}

	public static function useDB()
	{
		// Чего-то делаем с созданным экземпляром PDO, обращаясь к нему, как к self
	}

	private function __clone() {}

	private function __wakeup() {}
}

# Init
App::getInstance();

# Из любого файла вызываем метод обёртки на манер:
App::useDB();
?>

Это не удобно???

Павел Корнилов, Я такую же конструкцию и использую :) В проектах без ООП.
В классах, пробросить объект дело пары строк. И по моему сама идея синглтона особо не завязана конкретно на ооп.

Макс Васильев, идея синглтона завязана на создании единственного экземпляра класса. То есть второй создать просто не возможно. Все обращения будут идти именно к нему.

Из очевидных плюсов - глобальная доступность всех методов: как экземпляра, так и оболочки

Из минусов - пожалуй, только постоянное зависание в памяти сервера. Но, если использовать это с умом, это тоже можно превратить в плюс.

ООП ради ООП - далеко не всегда гуд. Есть много ситуаций, когда описанный мной подход намного более оправдан, чем абстрактная возможность наследования. К тому же, экземпляр, возвращаемый синглтоном - это тоже объект. Поэтому, в какой-то степени - это тоже ООП.
Повторюсь - его нужно правильно готовить (использовать там, где очевидны преимущества его использования).

Павел Корнилов, пока что ооп оправдывает себя, особенно в моделях. Сейчас у меня тоже создан синглтон и я заметил, что это единственный объект, который живет своей жизнью, при том, что другие объекты отлично структурированы и взаимосвязаны.
На самом деле верная мысль, что нужно "уметь готовить". Не всегда одно и тоже в рамках разных проектов полезно.
Касаемо моего App, это оболочка, внутри доступен объект БД. он доступен всему приложению, аналогично глобальной переменной.

Макс Васильев,

Касаемо моего App, это оболочка, внутри доступен объект БД. он доступен всему приложению, аналогично глобальной переменной.

Именно это я вам и предложил в своём решении.

Павел Корнилов, ))

Больше антипаттернов богу антипаттернов!

Павел Корнилов, подключение к БД не может быть синглтоном по определению. По очевидными причинам: Соединений к БД может быть несколько.

Да не, как раз я и хотел в основном классе объявить (или передать из вне) объект бд и уже дальше передавать его в наследники.