ООП или процедурка?

Да не пришли к единому мнению. Хотя так или иначе вектора мышления сходятся на:

1. Если проект не однопоточный (как все пышные) и требует эффективной работы с объектами хранящимися в памяти - ООП (тут оно вполне оправдано)

2. Если проект делают много разных разработчиков - ООП (тут оправданность "притянута" как презерватив на пятую точку)

В остальном процедурка попроще будет и часто поэффективнее.

поправте меня если сильно переврал...

malls, править не буду, но приврал неплохо)

Зря - лучше поправь... В данном случае это мое видение топика - т.е. я никак не претендую на беспристратность и объективность...

а где, если не секрет?

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

$xx_aaa_zz_bbb_ccc показывая тем самым их принадлежность к той или иной группе "переменных" (обектов так сказать).

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

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

это все имхо конечно. холиварить поднадоело) темка скучная, куда интереснее холиварить натему "кто нить кидала".

Граждане, опомнитесь! Вы что? 😂 Кэшер это обращение к базе, которое длится вечность по сравнению с различием по времени в вызове функций разными методами

Различия по скорости, заметного глазом, вы не увидите никогда. Там счет идет на доли процентов. Намутил тут edogs со своими собачьими сайтами и "трехкратным увеличением скорости" ... :-/

Вопрос между ООП и процедурным стилем - это вопрос только целесообразности применения.

dlyanachalas добавил 10.12.2009 в 06:05

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

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

dlyanachalas, вы вообще слышали про опкоде кешеры? похоже нет, погуглите.

bearman добавил 10.12.2009 в 06:26

dlyanachalas, кстати кешировать в базе имхо самый имбицильный метод кеша.

Хам и лгун.

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

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

То что Вы не знаете что такое оптимизация и бенчмарки - нас не удивляет.

А вот на скобочках у Вас определённо пунктик.

А, религиозный фанатик. Микрософт святая икона и "4мб enough for everyone".

Симптомы на лицо:

1) В теме уже приводилась ссылка на java.sun

но Вы старательно изображаете, что о существовании java.sun не знаете, ведь это не микрософт.

2) Нелепый вывод в адрес скрипта. Вы понятия не имеете что за скрипт, но заранее говорите что он кривой. ЧИсто совковое "Не читал, но осуждаю" (с) с примесью телепатии.

Процедурки все-таки быстрее:) Вопрос в том, что не всегда они настолько быстрее, насколько ООП нужнее.

Забудем на секунду об ООП. Мы несколько лет назад занимались оптимизацией одного скриптика. Из изначальных 0.5-1 секунд на генерацию страницы в среднем сделали 0.01-0.02 секунды (и за счет кода и за счет кэширования) при сохранении совместимости. И что? Думаете это кому-то сильно надо? Реальная необходимость была дай бог у 1% из тех, кто его ставил. При этом все у кого были проблемы с нагрузкой на прежней версии, имели уже достаточный доход, для аренды сервера. Поэтому смысла особого не было в этом, и проект мы забросили.

Face the truth - никому не нужна скорость работы в стандартных скриптах. То о чем Вы говорите - это "premature optimization - root of evil":)

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

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

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

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

Вы серьезно в это верите? Собственные решения для любых задач? Но не фреймворки, без граблей и без лишнего кода? Как-то даже руки опускаются это комментить. Покажите хотя бы пару таких, а? Может их купить можно? Не, не продают? Они такие секретные? Ах да, они такие совершенные, что их кому-то показывать или упаси боже продавать ни в коем случае нельзя:)

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

Фактически Ваша аргументация сводится к тому, что "надо выбирать свое потому что оно свое" (с). Умные жквериписатели НЕ будут редактировать код жквери. Потому что это либа и она должна быть неизменной. И вся суть фреймворков в том, что бы уметь использовать их АПИ, а не лезть внутрь.

Напомним, php сам по себе в общем-то фреймворк. Надстройка над c. А cи надстройка над асмом.

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

$("#tab1").slideUp(slow) - вот эту "фантазию" мы можем пойти и найти в мануалах по jquery. При чем наверняка 50% прогеров эти мануалы уже читает и знает. А вот malls("tab1").DoSomethingBeautiful извините в мануалах Вы не найдете. И Ваш пример с аяксом выше что Вы приводили - просто шикарен. Потому что в Вашу функцию надо сидеть и втыкаться, пусть и не долго. А $("form").post понятно и так.

Почти так.

1) Если нужны ООП-шные фичи в проекте, то используется ООП.

2) Если не нужны ООП-шные фишки в небольшом проекте, то по фиг что использовать.

3) Если проект делает команда, то только ООП.

4) Узкие места или небольшие скрипты в случае критичности использования памяти и проца - лучше делать на процедурках

ООПисты настолько часто аргументируют переменными вида $xx_aaa_zz_bbb_ccc , нахваливая var::$server->http_host, что возникает острое ощущение, что о массивах им не известно, а идея называть переменные понятно в голову не приходит:)

Чем $var['server']['http_host'] хуже var::$server->http_host ? Или опять же то же vars('get','server','http_host') если хочется использовать функции и завернуть переменные?

Учите матчасть.

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

я знаю о массивах (это раз :) )

довод в пользу ддлинных переменных - ide подскажет переменную при code assyst, а вот элемент массива увы нет :)

зы: я не фанатик, просто наблюдаю за вашей баталией тут.