Да ... я такой красоты не ожидал .... Вообще то можно было обратится к методу класса Color который бы производил 10 вычислений.
Ну библиотеки готовых процедур тоже никто не отменял, тот же php имеет огромную библиотеку готовых процедур, который собственно внутри транслируются в вызовы стандартных процедур языка C, как работают которые в точности тоже мало кто знает ООП-библиотеки просто удобнее использовать И заказчику обычно всё равно, взял ты кучу готового кода или всё писал сам. Ему надо быстрый результат. ООП - это для сложных проектов как раз, оно и придумано для более точного отражения в программе реального мира. На счёт математики - всё зависит от задачи, какую-то математику тоже можно удобно разнести по объектам. Какую-то нет. Процедурный подход никто не гнобит, он имеет право на жизнь, в конце концов, из него ООП и выросло Есть ещё некое "функциональное программирование". Но я ещё не разбирал толком, что это такое. Мои задачи на ООП прекрасно ложатся. Опять же, если код правильно написан на процедурах, он тоже будет и сопровождаемым, и более-менее расширяемым. --- Добавлено --- Как раз для простых проектов ООП слишком многословно,кстати.
Столько всего наговорили, а ситуация так и не прояснилась. Если смотреть в общем целом, с 7-й версии PHP все-таки прибавил в весе ООП, и в разных уголках заговорили, что вот он теперь язык программирования, зауважали. Но пока все это, словно обсуждение мужиками в гаражах, какую резину брать на зиму, шипы или липучку
@karmay семерка, особенно ООП в ней, реально работает гораздо быстрее (по крайней мере, так было в 2015 когда была актуальна 5.6.16 и только появилась 7). Надо протестить!
искал. разраб писал мне чат на файле. когда я узнал что файл прогружается полностью, тогда уже начал сомневаться. после разраб слился сославшись на нехватку времени. сам буду писать все. разраба я искал из-за времени. то что я буду писать за 3 месяца, заодно мучая местный форум, норм разраб напишет за 2 недели, ато и меньше. хорошую проблему затронул. очень много на данный момент людей называющих себя программистами, которые берут готовый код. процесс сдачи заказа превращается в поиск нужного скрипта и переделку дизайна. если честно - это обыкновенное кидалово. собственно как написаны функции пхп, знать программисту пхп не нужно, в тот момент когда ему нужны будут такие углубленные знания, это уже означает что для данной цели пхп не подходит. но когда используешь туже библиотеку jquery, нужно знать как написан тот или иной плагин. Хотя, в вебе 99 процентов сайтов не требуют супер быстродействие, так что впринципе это нормально что на практике 90 процентов кодеров не программируют, а собирают конструктор лего. Я не знаю, может это из-за времен когда я игрался на турбо паскале, но процедурный стиль мне даже легче читать чем ООП, хотя читабельность ООП приводят как плюс данного метода на тематических сайтах.
Мы вроде о PHP говорили, а не JS. Ну не настолько, конечно, но я предпочитаю, чтоб всякие дурацкие общие задачи типа роутинга были уже за меня решены, и я программировал только специфику заказа. Поэтому я использую фреймворки.
Если это не было оговорено заранее, то кидалово - это как раз заново писать всё сопутствующее бизнес-логике окружение на деньги заказчика. Вдвойне кидалово - вместо стандартных, повсеместно используемых компонент использовать свои, супер-крутые наработки, которые без тестов, документации (а если и есть, то не актуальных) и с поддержкой в виде одного себя. Ну а если не на деньги заказчика весь этот праздник торжества имени Сизифа и его горы - так это ещё и глупость.
Это ключевой момент - что оговорено, делать велосипед или собирать готовые модули, то и нужно делать.
имхо конечно, но прежде чем велосипедить, стоит рассказать заказчику о плюсах и минусах того или иного подхода. Взять тот же чат "на файле", если заказчик понимает, что это решение по природе своей хоть и быстрое "здесь и сейчас", но костыль и не выдержит большого количества людей, таки да, флаг ему в руки. Но если чат предполагается забитый и в комплекте сейчас или позже пойдут плюшки, то надо прямо сказать: решение будет временным и лучше сразу впиливать центрифугу, socket.io, прочие ratchet`ы. Короче, вот когда он будет понимать что именно заказывает (он ведь не обязан во всем этом разбираться), тогда да, что оговорено то и делать.
public function sendMessage ( $message ) { if ( !file_put_contents ( $this->chatFile, PHP_EOL.$message, FILE_APPEND | LOCK_EX ) ) { $this->sendMessage ( $message ); } js - просто пример в качестве аналогии. та да. не будет быстрее в любом случае. прогрузка всего файла - очевидно бред. если прогружать последнее, то я даже не представляю что это за чат, ни разу не видел ничего подобного на практике как простой юзер. если делать из файла подобие бд - зачем нужно изобретать велосипед если есть БД? про соккеты конечно интересно, но подобные чаты были популярны в 2000-ых, по сути любой ширп портал с анекдотами и эротикой имел свой чат. на чем он был написан? в лучшем случае на перле, в худшем на пхп3 и все это работало на железе в разы слабее чем сейчас, без ссд и т.д. Я прекрасно понимаю пропасть между разрабом и заказчиком, в далекой молодости первые деньги заработал версткой. Но тут не обычный случай "сделай мне то, не знаю что и чтоб свистелок перделок побольше". Т.з. у меня было написано в ворде и фотошопе где все видно визуально и подписано, то что лучше посмотреть, а не читать. Вообщем ушли мы от темы. Мораль басни такова, если хочешь чтобы было хорошо - делай сам. Проблема в этом только в том что придется изучать все с нуля и в дальнейшем переписывать по несколько раз, потому-что с опытом придет и понимание того что вчерашний твой код - мусор. Как раз поэтому не утверждаю что ООП кака, возможно с опытом я изменю свое мнение.
file_put_contents не грузит файл, а записывает в него Тогда люди трюкачили со всякими короткими и длинными опросами, поскольку не было технологии отправки сообщения от сервера к браузеру без запроса браузера. А сейчас нет смысла трюкачить, поскольку изобрели такую технологию. Вот и всё. А в 90-е вообще чаты перезагружали страницу каждые 5 секунд, вот весело было....
Вы вроде с программированием знакомы не со вчера, и если не пришло даже понимание разницы ооп и процедуры то и не факт что придет, да и в любом случае все не изучишь и есть люди которые могут сделать что-то лучше тебя. Так что мораль басни может быть что нужно уметь находить исполнителей.
Причем тут дельфи если я уже вторую страницу пишу о том что ООП удобно, но в сравнение с процедурным кодом менее читабельно. Возможно это из-за того что первое знакомство было именно с процедурным кодом пхп. ООП в том же js, судя по тем кодам которые я читал, так что рано или поздно придется освоить и его. Дельфи - это было 10 лет назад, я даже не помню открывающих тегов в паскале, если конечно они были. Помню конструкцию if then else из-за чего пхп показался легче чем тот же js. Тема исчерпала себя и мы уже оффтопим.
ну что значит менее читабельно)) и давайте все таки определимся)) Вы под ООП имеете ввиду ООП или все таки MVC структуру приложения основанную на классах а не на функциях))
Не смотрите на JS с этой точки зрения. ООП там...ну крайне специфичное, мягко говоря. Да, там есть объекты, но ООП там не такое, каким оно описано по канонамЪ.
Честно говоря, я немого не догоняю саму суть вопроса: ООП, процедурный, быстрее. Я бы больше переживал за ту же базу, правильно расставленные индексы, запросы к ней, о кешировании побеспокоился и т.д. Если такие моменты пропустить, то толку не будет ни от ОПП, ни от процедурного стиля, т.к. они - это всего лишь подход к написанию сценария. А измерять их быстродействие в наносекундах - какая-то чушь.
я не знаю что такое MVC)) вы переоцениваете мои знания)) beginner, начало начал)) я больше опыта имею в работе с б.д. правильная структура б.д. это первое что нужно сделать. на коленке разве что очень опытный кодер может строить б.д. да ито для стандартного проекта. не люблю ооп, потому-что мне его сложнее читать ввиду не опытности + был опыт когда написанное на ооп обрабатывалось 2-3 секунды, в отличие от моей процедурной версии которая обработалась на мили секунду. конечно, тут виновато не ооп, а прежний автор.