Задачка с классами (ООП vs процедуры)

За версту пахнет Явой. Да, это все верно. Одно но: для PHP это — излишняя нагрузка, и большая. Это ж скриптовый язык, как никак. В итоге, спор выливается в «Пригоден ли PHP для маштабных проектов?» который в пределах PHP.RU — закончиться однозначно. )

 

что большая нагрузка? объекты или объемы? Я вот пишу локально на пхп, а не на С++, из-за скорости разработки. Скорость выполнения, если не лепить что попало, меня устраивает.

 

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

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

 

ну это уже на тему "откуда растут руки у php разработчиков".

Вопрос на засыпку. "Для каких целей вообще (в абстракции) и всвязи с чем программисты начали разработку ОО подхода". Причем далеко не глупые люди, которые много чего повидали в структурном подходе.

Это в тему планирования.
А на счет 20 000 строк и "сверх...", то не надо к словам придираться. Вы же понимаете к чему это было сказано.

 

Наследование, интерфейсы, абстрактные методы, перезагрузки... — PHP - некомпилируемый язык. Это будет происходить при каждом обращении к приложению. Чем сложнее приложение, тем больше абстракций прийдется разрешить при _каждом_ вызове скрипта. И, в итоге, как я сказал,

 

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

 

ООП или процедуры?
Испорчу-ка флейм хорошим стихом!

© Тоява

 

В голову сразу пришла нехорошая перефразеология... =)

 

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

 

Тьфу на тебя. Суть была в том, что

 

dark-demon

это, простите, в какой строке кода происходит?

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

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

 

ИМХО спор какой-то странный, ООП (само по себе) это не зло а добро, а то что совать его куда попало (например в "Hello, world!") не следует, думаю должно быть очевидно (увы оказывается далеко не очевидно)

 

$db->query(...) - для разных субд будут вызваны разные функции.

станет. не будет таких вот функций-обёрток...

не надо впадать в маразм и всё будет хорошо.

ps: ты скажи честно, какие кавычки используешь - одинарные или двойные?

 

dark-demon

в вашем примере нет такого метода

покажите на примере

согласен на все 100

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

Vladson
а ооп -- это абсолютное добро, или есть что-либо ещё добрее ;-)

 

*Хитро прищуривается*
Смарти — зло. Смарти — ООП. ООП — зло? ))

 

однозначно ли? ;-)

 

Снайпер он стрелок, но стрелок не обязательно снайпер *ещё более хитро растягивает улыбку*

 

не придирайся. $db->get2d(), которая, кстати, в процессе своей работы вызывает $db->query() - свою для каждой субд.

Код (Text):

1. class SQLDB {
2.     // определяем общие для всех субд функции
3. }
4. class SQLDB_mysql extends SQLDB {
5.     function query (...) {
6.        // делаем запрос
7.     }
8.     function get2d (...) {
9.        $res= $this->query(...);
10.        // парсим результат и возвращаем его
11.     }
12.     /* другие полезные функции */
13. }
14. class SQLDB_sqlite extends SQLDB {
15.     function query (...) {
16.        // делаем запрос
17.     }
18.     function get2d (...) {
19.        $res= $this->query(...);
20.        // парсим результат и возвращаем его
21.     }
22.     /* другие полезные функции */
23. }

это был риторический вопрос...

 

халтура. get2d вызавается из $SQLDB, а там он не определён. даёшь работающую реализацию! в своей реализации я опустил функции подключения. но в остальном это работающий код. сделайте так же. если хотите, опустите метод connect, но дайте нормальную реализацию get2d. если в вашем коде есть хитрый момент, позволяющий в $SQLDB переключаться на использование функций из $SQLDB_mysql -- приведите его. но я буду очень удивлён, если такое окажется возможно (код наследуется сверху вниз, а не снизу вверх).

и в любом случае ваш $SQLDB есть ничто иное как большая обёртка для потомков.

 

в данном случае SQLDB_sqlite и SQLDB_mysql - да самостоятельных класса реализующих один и тот же интерфейс, которые являются наследниками SQLDB.
если хочется унифицировать конструктор (new SQLDB('mysql://...')), то в конструкторе SQLDB производится подгрузка нужного драйвера и с помощью __call происходит делегирование функционала драйверу.

Код (Text):

1. function __call ($method, $args) {
2.     return call_user_func_array(array($this->driver,$method),$args);
3. }

 

я так понимаю, работающего кода сегодня не будет?

 

на тебе работающий код:
http://mojura.googlecode.com/svn/trunk/db/dbclass.onc
http://mojura.googlecode.com/svn/trunk/ ... /mysql.onc

 

СТЫД И ПОЗОР!
Тема закрыта.