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

Если интересует скорость то функции быстрее, но классы в большинстве случаев удобнее

А если функции быстрее))) То наверно на них и останусь))

<sarcasm>В Си функции ещё быстрее, можно писать на нём</sarcasm>

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

Я бы не сравнивал эти 2 разных подхода. Все зависит от задачи.

Это розжиг и повод ля холивара
Делайте как вам удобнее или как требуется для проекта.
Оба пути возможны и работоспособны.

ЗЫ
лично предпочитаю классы, хоть они и чуть медленнее, но фактическое быстродействие упирается в СУБД и не важно классы или функции.

Скорость прежде всего зависит не от подхода, а от того, насколько качествен и оптимален сам код. Можно одно и тоже приложение написать и на функциях и с ООП подходом, где ООП окажется быстрее.

У ООП есть масса преимуществ. Обычно эти преимущества ощущаются при попытке спроектировать сложное приложение.

Более того, с использованием ООП подходов, есть много готовых и отлаженных решений, мощные фреймворки и всякие полезные библиотеки. Так же есть множество удобных подходов при проектировании, яркий пример - Шаблоны проектирования, которые как правило заточены под ООП.

Мой тебе совет, сначала просто изучи возможности ООП, узнай, как это работает технически, не вдаваясь в подробности проектирования. Для этого можно воспользоваться официальной документацией:
http://www.php.net/manual/ru/language.oop5.php

А когда ты все это изучишь, то будешь готов для понимания удобства ООП подхода. Тогда уже начни изучать шаблоны проектирования и фреймворки. Быстро забудешь про функции. Но учти, потеть придется постоянно

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


Технически ООП никак не работает, это лишь подход. Технически работает его реализация в конкретно взятых языке и платформе.


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


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

По теме - почитайте про S.O.L.I.D. подход, тестирование кода (особенно про интеграционные тесты (то есть, как с ними работать и как свести их число к минимуму), так как с юнитами и так всё ясно). Классика Макконела тоже пригодится. Ах да, ещё про S.T.U.P.I.D. код тоже пройтись можно. Хороший набор анти-паттернов.

Да, но в корне мысль одна и та же.


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

Надеюсь так я выразился более корректно -)

Вконтакте на функциях наляпяли и ниче , не хужее фейсбуку

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


Во-первых, это отдельная история (со своими решениями), во-вторых, ради этого им пришлось.. разработать методику тестирования. И - у них не "наобум" сделана структура. Создано упрощение, но умышленное и направленное.