Програмёрalex564657498765453,

Эх... добрался домой... потратил 20 минут, что бы почитать что ты написал, разобраться...

С твоими рассуждениями типа "шаблон - это всего ли шаблон, и не надо ему следовать. Если надо - меня под свои нужды" (не цитата... приблизительная передача смысла) я не согласен.

Так вот, всегда есть 3 варианта действий:
1. Шаблон подходит - значит его используем при написании кода
2. Шаблон не подходит - взять другой, который теоретически подойдёт и вернуться к пункту 1.
3. Ни один из желаемых не подошёл - не обращать внимания на паттерны и писать как удобно тебе.


Так вот, ты говоришь о третьем пункте, как о немного модифицированном первом!

Как часто ты пытаешься из ботинок сделать летние босоножки? А вот перепиливание шаблона и его использование вне его области применения - это как-раз попытка ботинки в босоножки превратить.

Есть установленные правила, высчитанные и продуманные, и нефига от них уходить! Ушёл от правила - ушёл от шаблона! (прикольный лозунг получился надо бы предложить как девиз шаблонизации)

Почему отклонение от ТЗ называют отклонением, а не адаптацией?! представляешь такое?

"Уважаемый клиент,
мы адаптировали Ваше ТЗ под наш движок.
Первая адаптация в подарок.
С уважением и заботой Сайтострой"

От ТЗ отклонились, а вот шаблон почему-то адаптировали. Двойные стандарты :)

"если на проекте стоят такие потребности, не надо изобретать велосипед - смело надо ставить смарти." - у меня есть потребность забить гвоздь... я знаю что с этой задачей без проблем справится каток (который асфальт закатывает)... Стоит ли мне его использовать для решения задачи, или по-нормальному взять молоток и забить?!
Так вот, я не утверждал, что смарти не справляется с задачей... ровно наоборот. Однако, я считаю смарти катком, которым пытаются забивать (закатывать) гвозди.

отнюдь. ты малёк переиначил мои слова, а потом уже на переиначеной версии делаешь выводы.

цитата - Ушёл от правила - ушёл от шаблона!
шаблон это не правило!!!.

рассмотрим простой пример. сингл-тон. в чистом виде в пхп не применим, ибо надо ещо позакрывать магические методы, которые могут создать объект. хотя всё-равно остаётся возможность создать обьект. мы отошли из ботинок сделали сандали? или просто взяли штаны которые нам подходят, но в талии жмут и малёк расширили...

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

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

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

.... вот на это я в эпусе своём и пытался сделать акцент, но согласен плохо. шаблон это не правило, не закон, - шаблон это шаблон.
я согласен с тобой, что важно как именно назвали то или инное, ибо в этом скрыт смысл.
не зря говорят - оступить от ТЗ, но и не зря говорят
шаблон, но никто не назовёт COM - шаблоном, или SOLID REST JSON OOP...

wikipedia
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context

Архитектурный шаблон целом, многоразовые решение для часто встречающихся проблем в архитектуре программного обеспечения в рамках определенного контекста

понимаете, уважаемые (впервые кстате перевёл для себя с английского)

многоразовое решение для часто встречающейся проблемы.

то есть, есть частая проблема, есть её оптимальное решение - этому решению дали имя, ну смысл давать имя решению, которое каждый 100ый програмист встретит...

это как...вот аналогично
для водителя - прерывистое торможение. у меня АБС, мне пофигу(может и нет но я этого не понимаю) , при торможении иногда нажимаю педаль не один раз...перед торможением если время есть хочу мигнуть жопашнику(в зад авто пристроился) что счас буду тормозить.

есть проехать накатом.

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

взять тотже синглтон, я про него услышал на собеседовании, овтетил что не знаю, на меня посмотрели с видом что дебил, потом пришол домой, нагуглил - и понял, дебил не я...вот сам как думаешь, я за более 15 лет програмирования сталкивался с задачей, когда себе думал...надо добавить контроль единичности обьекта- тупо изза спотыканий что возникала вторая копия и сбой...наверно было..

как думаешь ,да первые решения были глобальные переменные маркеры - создан обьект или нет, но когда пришло понимание пользоватся статикой классов, в результате моё решение не стало таким как сингл тон...стало, я гениальный , раз сам к это пришол? нет.

ибо это практика. и для частых задач, распространнёное решение получило своё название.

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

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

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

а не только подумав про слово один обьект, сразу сингл тон, а потом лепить костыли или переделывать, потому что один обьект но не синглтон..

Програмёрalex564657498765453,

"можно посмотреть иначе. называть синглтоном не заготовку кода описания класса, а как саму идею" - а кто сказал, что шаблон ПРОЕКТИРОВАНИЯ - это заготовка кода?! Вообще-то это идея... на то и шаблон ПРОЕКТИРОВАНИЯ, а не кода.

шаблон проектирования, это в редакторе юмл, где собственно и проектируют(...в уме продумывают, а проектируют всегда на бумаге, или в соответствующем редакторе)!!!
как мы с тобой оба знаем, названия понятиям дают не случайные, а осмысленные.

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

Програмёрalex564657498765453,

если уж про википедию, читать первую строчку и её же цитировать - плохой тон :)

Вот я прочитал ещё 4 строки и нашёл вот такое определение:
wiki Patterns are often defined as "strictly described and commonly available".[2][3] For example, the layered architecture is a call-and-return style because it defines an overall style to interact. When it is strictly described and commonly available, it is a pattern.

жёстко? )) перевод: Шаблоны часто определяются как "чётко описанные и общедоступные". Например, многослойная(?) архитектура - это вызови-и-верни стиль, потому что определяет общий стиль прерываний. Когда же она чётко описана и общедоступна - это ШАБЛОН .

Замечаешь разницу между стилем проектирования и шаблоном проектирования? :)

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

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

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

а вообще да, я согласен с такой разницей между стилем и шаблоном - шаблон, он строго описан. но я в своём эпусе изначально это и подразумевал - АЛЯ
шаблон - чёткое описание, в среде проектирования при инжениринге кода шаблона - получим вполне определёный код. итого, длязаданой среды(ИДЕ) и языка программирования, шаблон == коду этого шаблона на этом языке.

Програмёр,
насчёт синглтона для пхп. раз уж клон закрыл, то надо бы и __wakeup() закрыть.

но остаються методы по типу ..._fetch_object
они в обход конструктора работают.

это просто заметка. и сдесь дело не в том что програмист хочет обмануть.

но с тобой согласен, это стандартный код для синглтона.

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

ну нупример - тоже подключение к базе, но у нас подключение к одному серверу баз данных должно быть единственным, но самих серверов несколько.

итого надо
$obj1 = Database::factory('statdb');
$obj2 = Database::factory('statdb');

$nobj1 = Database::factory('generaldb');
- первые две переменные ведут к одному и томуже обьекту, третья, к другому.
и вот когда я гуглил синглтон , гдето встречал мильтитон, но один фанат похихикал... это пример того что я имел ввиду, когда человек к шаблону относится как к науке, всё что не по шаблону лоховство. притом, раз он прочитал целую книгу по шаблонам, то он уверен что он знает все их ... бывают же.

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

Програмёрalex564657498765453,

источники не смотрю - виноват :) Да и сейчас влом... верю на слово )

шаблон = код - близко к моему пониманию, но тут я немного поясню (далее по тексту)

__wake_up() - согласен
_fetch_object - если то, что думаю, тогда не согласен :)

знакомый шаблонизаторщик руль вообще


Итак, по порядку:
1 . шаблон = код. Если мы говорим про шаблон программирования, безусловно это так. Но в данном случае проектирования. То есть это некая заготовка, но не в виде кода, а в виде структуры этого кода.
Другими словами, открывая IDE, я получаю вопрос "какой шаблон проектирования стоит применить к проекту?". Представим я выбрал MVC (самый близкий мне).
Следующий шаг - это при нажатии на кнопку применить, передо мной разворачивается некое окно из трёх частей (образно), на левой надпись модели, на средней - контроллеры, на правой - представления.
Кликнув на кнопку "создать модель" в левом окне, я получаю нечто похожее на структуру таблицы sql, где мне предлагают указать атрибуты характеризующие данную модель. Когда я всё ввёл и жму "готово", мне предлагают указать связи с другими моделями. По окончанию вопрос: "укажите основные методы управления данными модели и её связями". Тут я указываю конструкторы, валидаторы, апдейтеры, делиторы (уж сори за англорусские слова... "удаляторы" - не звучит).

Насоздавав все модели, я вроде как описал некую частичку мира (некий процесс, явление). Теперь мне надо представить его как-то пользователю.

Для этого я создаю представление. Меня в том же ключе опрашивают что я хочу выводить, как я это хочу выводить и т.д.

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

Вот так я и понимаю для себя шаблон проектирования . Если с кодом - это готовый код, то с проектирование - готовая архитектура

2 . ...fetch_object - это из серии типа mysql_fetch_object?! :) Бугага.... Это как-раз косяк в архитектуре. Создавая объект-одиночку, надо делать так, что бы быть уверенным, что этот объект будет сохранять своё состояние от обращения к обращению (вызвав кучу методов других объектов в своём, я не должен после каждого проверять, а не изменилось ли состояние объекта).
Отсюда мультитон - синглтон с возможностью настройки и контроля состояний (не знаю как описывают эту архитектуру другие, всего лишь рассказываю как я к ней пришёл, после ознакомления с синглтоном).

Так вот, по отношению к базе данных синглтон (ну или уже для нас это мультитон) применяется очень сложно. Для этого требуется отсутствие какой либо возможности управлять соединением напрямую. Мы должны отобрать возможность написания произвольного запроса, получения выборки вне нашего объекта, закрытия соединения и т.д. Среди этого, также требуется запоминать состояние "начата транзакция", активная база данных, состояние сессионных переменных (если есть возможность их изменения).

В общем, для того, что бы это сделать, нужно полностью обернуть mysql в апи для php :)
Признаться честно, я много раз начинал эту затею, но ещё ни разу не хватило терпения и сил довести её до конца.

3. Шаблонизаторщик... мх :) Нечего сказать... кажись получилось высказаться одним словом

согласен. шаблон проектирования для иде, это шаблон структуры для сингл тона это

класс Синглтон1
протектид чтатик поле инстанс типа указатель
протектид метод конструктор без парамтеров, возвращает войд
публичный статичный метод инстанс - возвращает указатель.
и в зависимости от среды, возможна добавка относительно кода последнего, но скорей всего нет - просто коментарий, проверить наличие значения у статичной переменой, если нету поместить туда обьект данного класса, вернуть статичное поле.

и потом при генерации кода, мы получим файл синглтон1, в нём описан класс, с коментариями ято для чего.(если мы в проекте после применения шаблона не меняли ничего).

хех. похоже пришли к согласию.

по заказам турдящихся ORM.

Я: - фуфло ваши ORM

1.На предыдущем проекте, были демоны написаны на шеле, ибо пхп долго будет работать(например сканировать рекурсивно директорию, и отбор фалов по критериям и подсчёт мд5 для выбранных - find -type f .... гораздо быстрее, и главное надёжней.)
но надо в базу обращаться. хорошо что у меня небыло орм(было подобие, но не полное) часть логики была прямиком в базе на тригерах и хранимках и заданиях. благодаря этому код на шеле правильно в тупую работая с таблицами, работал.

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

это что, везде дублировать логику?

3 есть интересные вещи(в мускле нету) - что чтение данных и запись данных может ити в разные таблицы(чтение из представления реально идёт) - это делать две модели.. зачем.

4 а главное, зачем отрывать логику от самих данных. мы почему тащимся от ооп
что вместо



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

зачем в базу мы передаём хеши для паролей..что за мудизм?

вставка пароля - "мой пароль", тригер сам хеширует, используя хранимую функцию - хеш_пароля_юзера

при выборке, выборка идёт из представления - где уже нету поля пароль, оно не читаемо.

при логине, вызывается хранимая процедура(если сесию логина храним в базе ещо лучше)
куда передаёться пароль, база сама=хранимка, пользуясь функцией хранимой хеширующей правильно пароль, сверит , и выдаст либо одного юзера или тру, или ноль юзеров или фолс...

зачем наплевали на процедурное расширение языка sql, triggers, events(jobs), procs(functions, procedures) и лепим орм...


верх лоховства,

отедльным запросом в одной транкзанкции после смена у юзера статуса записывать в таблицу лог о этом изменении.

или при удалении категории, потомков удалять в транкзанкции делая запрос отдельный.
действительно... пускай лок продлится на 300-400 мс дольше при малой скорости передечи другого запроса в базу.

делать сложные запросы которые орм сделать то сделает, но если хочется оптимизировать, начинаются танцы с бубмно, или ORM::byquery('select .....');

============
Я не говорю что понятие модели надо исключить, я не говорю что ОРМ плохо.

я спрашиваю, зачем из базы всю логику перетащили в ОРМ, даже по контролю целостности данных, обновление щётчиков(вставляем юзеру дочерню запись, обновляем счётчик(пре агрегация))

зачем????

Програмёрalex564657498765453,

Всё это имело смысл в плане масштабируемости.
Ты не знаешь с какой базой работаешь. Авось это sqllite или ещё что проще. Часть функционала отрезана...
Есть разные драйвера. Один драйвер может вернуть массив, а другой не может... а третий только массив и может вернуть. Заточив функционал, рассчитывая, что база данных сможет его чем-то своим дополнить - не правильно. Оставить возможность дополнения функционала средствами базы - это да. Но вот полагаться на это не стоит. В системах реализующих ORM модель как-раз пытаются и не полагаться. Таким образом, если драйвер чего-то не умеет, то система сможет сделать это сама, а драйверу отдать результат, который тот обработает.


Насчёт ООП, суть не в том :) Суть в повторении модели мира. Есть объект, у него есть атрибуты. Изменение одного атрибута влияет на изменение другого, на вызов некого метода, или отработку события. То есть ООП - это группировка сущностей программы исходя из логики восприятия мира человеком (мы выделяем некий объект "человек" не для того, что бы связать понятия "кушать" и "вес", а для того, что бы выделить один логически обоснованный объект, и последующего выделения его характеристик, методов и т.д.)

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

другая сторона дела - не видел проекта который бы хвастался, мы перешли на другую субд.
тут видишь ли... ты автомобиль берёшь, а потом надо мощнее , ты двигатель переставляешь или автомобиль меняешь.
я пишу систему, например доска обьявлений для интернета. шаблоны верстки через смарти...хочешь бери переиначивай на свой манер. испльзую мускл, который справиться с проектной модностью - пускай милион вставок в течении суток равномерно более менее, и 50 млн чтений.
я пользуюсь этим решением, потом оказывается, что мне надо 100млн вставок в день. типо база это единственное место, которое станет узким? нджинкс типо выдержит на одной машине на раз?... тоесть полетит не только база. чегож тогда ОРМщики пытаясь подготовиться к замене базы, не готовятся к замене одного сервера на облако?

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

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

а иначе это пустая трата времени. сделать проект, вложиться что можно будет поменять субд легко... супер!!! а зачем такая замена??? или в орм есть метамодельный уровень, что то что в одной субд будет списком , в другой будет кольцом, или граф будет таблицей, или таблица ввиде графа(реляционная ... сетевая модель данных) , или проще - в постгри есть джейсонби в мускле нету, для мускла связаная таблица - связаная таблица, для постгри это будет джейсон обьект. сможет ОРМ , тот же доктрина сделать?