Классы - когда использовать

[vinniepooh]

Просто немного смущает, что мы создаём "объект работы с БД" в этом случае. Обычно создают объект: базу, подключение и т.п. То есть, то что в реальности есть. А тут... Хотя в принципе нормально.

[vinniepooh]

 $aMyData = $DB->getAll('SELECT * `my_table` ......'); // вернет данные из базы в виде массива или объекта

Вот я про это, например. Может вернуть данные в виде объекта. А зачем нам объект, ведь можно обойтись массивом (ассоциативным). Усложнение вроде как?

[vinniepooh]

class Tea
{
private  $name;
private  $brand;

//array
// $$arr['name']='Чёрный';
// $$arr['brand']='Нури';

};

Вот такое можно сделать. Класс чай (коробка с чаем - бренд и тип чая).
Или аналогично.

[Gorychev]

Зачем нужен класс для работы с БД:
1. Коннект к базе очень ресурсозатратная операция. В классе с помощью синглтон возврашаем один и тот же коннект, а не каждый раз подключаемся.
2. Пишите методы которые возвращают вам данные в удобном виде.
3. Если нужно поменять драйвер доступа к базе например mysqli на PDO, то переписываете 1 класс, а не в 100500 местах меняете код.
4. Т.к. все запросы проходят через одну точку входа, просто прикрутить логирование, узнать время выполнения запроса и тп.
5. Меньше кода в моделях, код более читаем.
Наверняка есть еще преимущества. Сразу все не вспомню.

[Alex11223]

Так все 5 пунктов и без ООП реализовать можно.

[Gorychev]

Так все 5 пунктов и без ООП реализовать можно

Мона. Но не будет столь изящно ООП же существует для удобства организации данных.

[Pavia]

Если вам не нужно. То и не используйте.

Функции хороши когда у вас задача простая. А если задача сложная, то стоит использовать ООП.

Что значит сложная задача? Да пожалуй такая которую не под силу охватить одному разуму.
Когда у вас в задаче переплетаются, данные, функции, машина состояний, иеархия.

Пока задача простая её можно решить простыми данными. Обойтись функциями. Как только задача становиться сложнее появляются структуры данных: записи, деревья списки.

Но как только у вас появляются разнообразные списки и вы хотите иметь один унифицированный интерфейс, для выполнения нужных действий. Поиск в списке. Сериализация дерева из разных объектов.

Вот тогда ООП и начинает работать и приносить плоды. За вас уже написали код выделили общие функции и методы присущи определённым классам.

Знаний становиться так много, что прикладной программист использующий ООП учиться догадываться о том что делает тот или иной объект, та или иная функция лишь взглянув по названию. Он перестаёт вникать в суть работы.

В этом и заключается, то что разум уже не способен в одиночку охватить всю задачу. А кто может тот сам начинает делать ООП объекты и иерархию. Это архитекторы и ведущие программисты.

[vinniepooh]

Спасибо. Да, пожалуй, когда используешь готовые объекты, то всё понятно, особенно когда документация под рукой - и всё работает.
А вот когда создавать надо свой класс или объекты - тут уже вопросы. Можно создать письмо, заметку, файл и т.п., но объект "работа с базой данных" не совсем соответствует какой-то реальной вещи/предмету.
Если только иметь в виду сам процесс. Тут часто и появляются искусственности/загвоздки.

[vinniepooh]

Насчёт 5 преимуществ - чтобы освоить все эти шаблоны и правильно применить, нужно много времени, особенно если нет заготовки в IDE.
ООП оправдано обычно, если в редакторе подставляется код

[Alex11223]

Ну дык возьмите IDE если нужна.

объект "работа с базой данных" не совсем соответствует какой-то реальной вещи/предмету.

Не обязано ничего соответствовать вещи, примеры с реальными вещами просто для упрощения объяснений.