1. Что лучше использовать для подключения к БД: переменные или константы?
2. Как лучше подключаться к БД: создать функцию, класс или незаморачиваться об этом?
3. Где стоит, а где не стоит использовать классы?
Спустя 7 минут, 32 секунды (23.03.2011 - 23:51) Arni написал(а):
Хорошая тема для поднятия дебатов, щас начнется. Борцы за прогрес станут по одну сторону, борцы за консерватизм по другую и понеслась 
.
Все зависит от того что какова цель кода, на мой взгляд. Класы здорово тем что инкапсуляция. Тоисть риск нарваться на одинаковое имя переменной, функции, можна свести к нулю. При грамотном подходе. И во всем этом есть смысл если код это больше чем 10 строк (ну минимум просто ужас, с учетом того что друпал очень долго избегал класов, на знаю что щас, также или уже сдались).
С подключением к базе аналогично. Константы или переменные тоже особо роли не наблюдаю. Константа будет видна везде в любом месте php кода. Оно вам надо? Сделайте переменную и сразу после подключения unset(); Подключаться два раза к той же базе вам думаю точно не понадобится.
.Все зависит от того что какова цель кода, на мой взгляд. Класы здорово тем что инкапсуляция. Тоисть риск нарваться на одинаковое имя переменной, функции, можна свести к нулю. При грамотном подходе. И во всем этом есть смысл если код это больше чем 10 строк (ну минимум просто ужас, с учетом того что друпал очень долго избегал класов, на знаю что щас, также или уже сдались).
С подключением к базе аналогично. Константы или переменные тоже особо роли не наблюдаю. Константа будет видна везде в любом месте php кода. Оно вам надо? Сделайте переменную и сразу после подключения unset(); Подключаться два раза к той же базе вам думаю точно не понадобится
. Спустя 41 минута, 11 секунд (24.03.2011 - 00:32) inpost написал(а):
nugle
1. Без разницы.
2. Ты видишь смысл заморачиваться и писать на 5-10 строк лишних при этом ничего не получая в замен? Надо быть алчным, тогда очевидно будет, что зачем отдавать больше усилий, если не получаешь выгоды?
3. Класс по своему роду - карман для функций. Хочешь объеденить несколько функций в одну, связав их между собой - класс и вперёд. Сегодня как раз столкнулся, надо делать перебор через foreach переменной (в JS), каждый раз отсылая данные, при этом если первый цикл прошел неудачно, запустить его же снова (сайт не отвечал). То есть данное действие мы запускаем из определённой функции, из неё запускаем функцию перебора, в случае неудачи запускается функция рекурсией, когда получаем положительный вариант выходим из рекурсионной функции в родительскую и продолжаем дальше цикл. То есть в таком примере очевидно, что одна функция принадлежит другой функции, но не используется за её пределами, почему бы не объединить в общий класс и тогда будет очевидно, что class googleTranslate отвечает как раз за перевод от гугла.
Если рассматривать ООП, то никогда =) Равняйся на гигантов, фейсбук, гугл и т.д. написаны были в раньше 2004 г., а значит ещё до использования ООП. Точнее никогда, пока не осознаешь сам, что ты зашел на процедурке в тупик, и тебе пора переходить на новый уровень.
1. Без разницы.
2. Ты видишь смысл заморачиваться и писать на 5-10 строк лишних при этом ничего не получая в замен? Надо быть алчным, тогда очевидно будет, что зачем отдавать больше усилий, если не получаешь выгоды?
3. Класс по своему роду - карман для функций. Хочешь объеденить несколько функций в одну, связав их между собой - класс и вперёд. Сегодня как раз столкнулся, надо делать перебор через foreach переменной (в JS), каждый раз отсылая данные, при этом если первый цикл прошел неудачно, запустить его же снова (сайт не отвечал). То есть данное действие мы запускаем из определённой функции, из неё запускаем функцию перебора, в случае неудачи запускается функция рекурсией, когда получаем положительный вариант выходим из рекурсионной функции в родительскую и продолжаем дальше цикл. То есть в таком примере очевидно, что одна функция принадлежит другой функции, но не используется за её пределами, почему бы не объединить в общий класс и тогда будет очевидно, что class googleTranslate отвечает как раз за перевод от гугла.
Если рассматривать ООП, то никогда =) Равняйся на гигантов, фейсбук, гугл и т.д. написаны были в раньше 2004 г., а значит ещё до использования ООП. Точнее никогда, пока не осознаешь сам, что ты зашел на процедурке в тупик, и тебе пора переходить на новый уровень.
Спустя 15 часов, 17 минут, 21 секунда (24.03.2011 - 15:49) Guest написал(а):
nugle
советую с самого же начала посмотреть на сайт - как нечто целое, единое.
"зачем отдавать больше усилий, если не получаешь выгоды?" - написали тут.
Выгоды по-моему очевидные:
1) Если правильно спроектировать класс БД, то в дальнейшем можно заменить СУБД, изменив во всем проекте всего одну строчку. Попробуйте сделать тоже самое в процедурном подходе.
2) Можно производить различные изменения/дополнения, изменяя ТОЛЬКО класс, не трогая остальной код вообще.
3) если использовать принципу ООП, то можно сделать сайт "одним целым", а не собирть из разных "кусочков".
4) про инкапсуляцию уже сказали.
5) Наследование, полиморфизм, интерфейсы - дают дополнительные мощные возможности, которых просто нет в обычном подходе.
Мое мнение - к этому приходят все равно очень многие. А не приходят в основном те, у которых есть какие-то свои ПРИНЦИПЫ по этому поводу.
Опыт веб-разработок у меня чуть меньше 1 года., но я уже ощутил все плюсы ООП, не навязанные никем.
Воот, поэтому советую уже сейчас оборачивать, такие важные вещи как бд в классы. В дальнейшем это слегка упростит вам жизнь )
советую с самого же начала посмотреть на сайт - как нечто целое, единое.
"зачем отдавать больше усилий, если не получаешь выгоды?" - написали тут.
Выгоды по-моему очевидные:
1) Если правильно спроектировать класс БД, то в дальнейшем можно заменить СУБД, изменив во всем проекте всего одну строчку. Попробуйте сделать тоже самое в процедурном подходе.
2) Можно производить различные изменения/дополнения, изменяя ТОЛЬКО класс, не трогая остальной код вообще.
3) если использовать принципу ООП, то можно сделать сайт "одним целым", а не собирть из разных "кусочков".
4) про инкапсуляцию уже сказали.
5) Наследование, полиморфизм, интерфейсы - дают дополнительные мощные возможности, которых просто нет в обычном подходе.
Мое мнение - к этому приходят все равно очень многие. А не приходят в основном те, у которых есть какие-то свои ПРИНЦИПЫ по этому поводу.
Опыт веб-разработок у меня чуть меньше 1 года., но я уже ощутил все плюсы ООП, не навязанные никем.
Воот, поэтому советую уже сейчас оборачивать, такие важные вещи как бд в классы. В дальнейшем это слегка упростит вам жизнь )