Класс обертки Mysqli by Koenig (Допилить)

Delphinum, Верно заметил ...

Delphinum, ты согласен что Стратегия не получилась, точнее в последний момент я ее совсем загубил)

Delphinum, в mysql(i) тоже фетч в объект есть. даже когда то хотел присобачить к шаблонизатору. эта штука мне сразу приглянулась и не даёт покоя. было бы круто если сеттеры сам фетч дергал, а не просто свойствами заполнял

# Koenig (28.12.2015 / 02:59)
Delphinum, ты согласен что Стратегия не получилась, точнее в последний момент я ее совсем загубил)

я вообще не любитель SQL билдеров. SQL на то и создавался в качестве языка со своим компилятором, чтобы его писали руками, а не собирали в виде PHP объекта, после конвертили в строку, а затем опять компилили. Потому я плохо понимаю, как это должно работать и как ее лучше реализовать. Лично я реализовывал сие с помощью шаблонов "Компоновщик" и "Интерпретатор" (если мне не изменила память).

# Koenig (28.12.2015 / 03:12)
Delphinum, в mysql(i) тоже фетч в объект есть. даже когда то хотел присобачить к шаблонизатору. эта штука мне сразу приглянулась и не даёт покоя. было бы круто если сеттеры сам фетч дергал, а не прос

а зачем сеттеры дергать? Я считаю, что сущности должны иметь публичную область видимости для своих свойств, которые заполняются с помощью fetchObject. Другими словами ничего плохого в том, что свойства сущности public, ведь на то есть одна довольно весомая причина: попробуй реализовать крупный проект на базе ORM с закрытыми (private) свойствами. Очень быстро ты заметишь, что все эти свойства сопровождаются геттерами и сеттерами (на пример getLogin, setLogin). Так же в этих методах в большинстве случаев не будет ничего, кроме прямого обращения к свойству. И становится непонятно, а зачем вообще их инкапсулировать, если к ним открыт прямой доступ? Раньше я занимался коммерческими проектами на Java, на базе одной платформы. Так там даже в документации было сказано: чтоб создать сущность, определите класс, его свойства, и getters/setters всех свойств ))

Иногда доступ к свойствам сущности через getters/setters полезен, на пример, когда установка значения свойства должно сопровождаться какими то перерасчетами, но это очень редкое явление и решается достаточно просто - реализацией дополнительного метода, занимающегося этими перерасчетами. На деле такое решение более краткое, чем десяток getters/setters методов в классе.

Позже я проникся философией BackboneJS и прицелом на JSON для обмена данными с RESTful API сервером. Тогда я еще больше полюбил простые, открытые сущности. С тех пор данные из базы хранятся у меня в сущностях с открытыми свойствами. Пусть это нарушает инкапсуляцию и адепты ООП плюются, но мне это удобно в использовании и просто в реализации.

Что касается шаблонизатора, описанный мной выше подход вообще позволяет передавать в шаблон целые сущности без необходимости как то их подготавливать (как нить доберусь и до этого вопроса в теме про Bricks).

Koenig, кстати, касаемо Стратегии: десять минут назад поймал себя на мысли, что вот уже пол часа пытаюсь прибубенить к классу паттерн, который там нах не нужен. В результате тупо удалил с класса пятак строк кода и ничего более не менял, класс заработал ) Мораль сей басни - не пытайся запихнуть паттерн ради паттерна.

# Delphinum (28.12.2015 / 03:52)
я вообще не любитель SQL билдеров. SQL на то и создавался в качестве языка со своим компилятором, чтобы его писали руками, а не собирали в виде PHP объекта, после конвертили в строку, а затем опять ко

а зачем там интерпритатор?
компоновщика вполне же хватает

# Delphinum (28.12.2015 / 04:00)
а зачем сеттеры дергать? Я считаю, что сущности должны иметь публичную область видимости для своих свойств, которые заполняются с помощью fetchObject. Другими словами ничего плохого в том, что свойств

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

Delphinum, и мне кажется интерпритатор ты решил присобачить, так как ява на твой код сильно повлияла

Koenig, компоновщик это структура, а интерпретатор реализует саму задачу билдера.