ООП vs функции

Miracle, Больше верьте своему опыту и поменьше слушайте крики, особенно ярых сторонников/противников

Может пригодится либо

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

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

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

Например: Есть группы функций работающие с различными базами данных (MySQL, Microsoft SQL, Portress и т.п.), выполняют почти одинаковые действия за исключением коннекта и например получение значения автогенерирующего поля, тогда имеет смысл сделать их в виде классов.

То же самое с различными видами авторизации (через сессии, post, get и т.п.), парсерами

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

Т.е. везде где функций несколько, а действия не сильно отличаются друг от друга.

P.S. Аналогия с функциями если у вас есть три функции которые на 99% одинаковые, имеет смысл добавить лишние аргументы и сделать одну на их основе, если у вас есть целые группы функций делающие одно и тоже имеет смысл использовать классы.

P.P.S. Плюсы использования классов на этом не ограничиваются, но они имеют смысл только при крупных и очень крупных проектах (например, то ООП реализует концепцию так называемых черных ящиков).

ИМХО для использования ООП нужно иметь подходящий стиль мышления.

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

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

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

Почитайте пару умных книжек про ООП.

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

Естественный "путь", это сначала хранить настройки в глобальных переменных типа

$host,$login,$pwd

потом проект подрастает и появляется

$mysql_host, $ftp_host, $mysql_login...

потом Вы обнаруживаете что переменных слишком много и упаковываете их в

$mysql['host'], $ftp['login'];

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

function getGlobal ($var) {
static $globals;
//тута какой-нибудь полезный код отслеживающий изменение переменных
return $globals[$var];
}

или не дай бог даже нечто вроде

function getGlobal ($var) {
static $globals;
//тута какой-нибудь полезный код отслеживающий изменение переменных
//а тут нечто вроде кэширования
if($var=='newlogin' && !isset( $globals[$var])) { connect_to_FTP; get_file_from_FTP; save_var; }
return $globals[$var];
}

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

class globs {
   static $gl;
   function __set($var,$val) {
     $this->gl[$var]=$val;
   }
   function __get($var) {
     return $this->gl[$var];
   }
}
globs::$var=5;
echo globs::$var;

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

Какое же дальнейшее логичное развитие, опять же приведем аналогичный пример.

Если у Вас сначала был код вида

mysql_query(, это ок

потом Вы сделали возможность логирования запросов, mysql_query переименовали в mysql_query2 а функцию mysql_query2 реализовали вида

function mysql_query2($sql) {
static $sqls=array();
$sqls[]=$sql;
return mysql_query($sql);
}

но потом Вы решили добавить еще один тип обращения к БД и Вам понадобилось нечто вроде

function query2($sql,$dbtype='mysql') {
static $sqls=array();
$sqls[]=$sql;
if($dbtype=='mysql) return mysql_query($sql);
else return mssql_query($sql);
}

И вот именно в этот момент Вы начинаете реализовывать велосипедное ООП, поэтому лучше перейти к настоящему вида

class db {
private $dbtype;
function __construct($type) {
$this->dbtype=$type;
}
function query($sql) {
if($this->dbtype=='mysql) return mysql_query($sql);
else return mssql_query($sql);
}
}

На функциях несложно сделать то же самое, но так Вы банально используете более распространённый подход.

Примеры привели намеренно упрощенные и наверное с очепятками, просьба не докапываться, а смотреть в суть.

Я не говорил что нельзя ООП реализовать через функции, делать эмуляцию можно, но зачем?

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

Уже 3 года на основной работе занимаюсь явой, поверьте когда в проект'е миллиарды строк кода и десятки тысяч сотрудников без ООП не обойтись, поэтому для таких вещей самые популярные чисто ООП языки Ява и C#.

P.S. Для PHP ООП вовсе не является обязательным и для многих задач просто бесполезным, т.к. назначение ООП это крупные проекты, а не небольшие скрипты. И я не призываю всех немедленно идти учить ООП, как правило 99% кода в PHP можно реализовать функциями без всякого ООП и это будет и понятнее и проще, просто вопрос был "Когда ООП может пригодится".

чтобы не создавать класс там где он не нужен.

А никогда не приходило в голову что именно вследствие ООП

?

10 тыс сотрудников это ж вы что за проект пишите?

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

Нету стандартных правил где стоит применять ООП. ООП надо чувствовать и понимать.

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

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

Так что мой совет - не спрашивайте где и как надо его применять, а просто пишите. Без практики толку не будет. Just code!

Ну и конечно желательно почитайте что-то типа "Рефакторинг" М. Фаулера или "Совершенный код" Макиавелли(вроде).

P.S. Зачастую за процедурное программирование выступают люди поверхностно знающие ООП, которым оно тяжело дается и главное не правильно. Есть такие люди которые сдаются, а чтоб не выглядеть неудачниками, начинают обсырать ООП или говорить что процедурное лучше. Да, есть области где процедурное допустимо или мастхев, но в 90% это именно 1 случай.

Почему придумал? http://netcracker.com

Проект по большому счету конечно не один, но программный продукт один (просто у каждого заказчика своя реализация основного кода) и его делают десятки тысяч человек (это кстати для ява проектов не предел, см. к примеру размеры продуктов Oracl'a).

Кстати подобные вещи делаются либо на яве, либо на C#, даже на С++ слишком тяжело проектировать при таких объемах. И вот при таких объемах ООП это жизненая необходимость.

Нет, просто весь функционал БД Oracl'a не сделать одному прграммисту на коленке даже с использованием процедурного программирования. :)

Макконнелл. Макиавелли - это, иезуит который "цель оправдывает средства" :)