Недостатки ООП

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

Имея опыт в разработке сайтов на чистом коде более 7-ми лет, я распишу всё по пунктам, самые главные минусы:

Много кода. Люди настолько привыкли к ООП, что пишут на нём все задачи. Возьмем ту же знакомую нам регистрацию пользователя. Для этого пишут класс, в нём свойства, конструктор, функцию, которая содержит код обработки формы и запись данных пользователя в базу. Потом создают экземпляр класса, и через него вызывают функцию. Чуть ниже мы показываем решения этой задачи на ООП, а трак же руками программиста. Без лишнего кода (ООП) возможно решить любую задачу!
Очень много действий. Как бы Вы не старались писать чище скрипт, используя ООП, интерпретатору многих действий не избежать.
Время интерпретации готового проекта на ООП больше в 80-500 раз, чем проект на чистом коде. Чем больше действий - тем больше времени надо, для их совершения и обработки. На это влияет объем скриптов, и количество действий, т.к. сервер израсходует время на загрузку тяжёлого файла ООП в оперативную память, синтаксический анализ и выполнение. Все последние версии готовых CMS и фреймворков используют PDO, для подключения к базе. Если углубится, то можно выяснить, что по времени одно подключение к сторонней базе равно времени обработки проекта на чистом коде.
Неэффективно с точки зрения оперативной памяти сервера. Оперативки на сервере ООП "сьедает" в 100 (самый простой сайтик на ООП), а то и миллионы раз больше (фреймворк, CMS) по сравнении с проектом на чистом коде.
Незадействанный лишний код. Любой проект, написанный на ООП имеет незадействованный код. Приведу пример ООП класса модели товаров, в котором есть такие функции: получить все товары, получить конкретный товар, получить товары по фильтру... Если нужно показать конкретный товар, отработает функция, отвечающая за это, в то же время другие функции будут не задействованы, что очень нехорошо.
Подход ООП делает путаницу в коде. Любая CMS-система, фреймворк, шаблон проектирования настолько запутаны, что можно отрастить бороду ниже колен, пытаясь разобрать каждую строку кода, что за что отвечает.
ООП - это небезопасно, поскольку 99% веб-студий пользуются готовыми шаблонами (паттернами проектирования), а они все широко распространяются в открытом интернете и хакеру не составит никакого труда найти "дырку" в коде и произвести взлом.

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

Решение задачи большинством исполнителей используя ООП


//Файл класса проверки валидации "CheckValid"
class Forms{
	publick $valid;
	publick $error='';
	
	publick function validName($name){
		if(mb_strlen($name,'UTF-8')>20){return false;}
		return true;
	}
	publick function validMess($mess){
		if(mb_strlen($mess,'UTF-8')>500){return false;}
		return true;
	}
}

//Класс отправки формы
class Forms{
	publick $valid;
	publick $error='';
	
	publick function __construct(){
		$this->valid = new CheckValid();
	}
	publick function sendForm(){
		$name='';if(isset($_POST['name'])){$name=htmlspecialchars (strip_tags (trim($_POST['name'])));}
		$mess='';if(isset($_POST['mess'])){$mess=htmlspecialchars (strip_tags (trim($_POST['mess'])));}
		
		if(!$this->valid->validName($name)){$this->error[]='Некорректно заполнено поля ИМЯ';}
		if(!$this->valid->validMess($mess)){$this->error[]='Некорректно заполнено поля СООБЩЕНИЕ';}
		
		if(!is_array($this->error)){
			return $this->SendEmail($name,$mess);
		}else{return $this->error;}
	}
	publick function SendEmail($name,$mess){
		$mess='<p>Имя: <b>'.$name.'</b></p><p>Сообщение с сайта: <b>'.$mess.'</b></p><p>Дата и время отправки: <b>'.date('Y/m/d в H:i:s').'</b></p>';
		return mail('admin@gmail.com','Тема сообщения',$mess);
	}
}

if(isset($_POST['sends'])){
	$forms=new Forms();
	$res=$forms->sendForm();
	if(!is_array($res)){
		echo 'Ваше сообщение отправлено на E-mail администратора';
	}else{
		foreach($$res as $v){echo $v.'<br>';}
	}
}

В реальности нужно выполнить доп. проверки и задать заголовки для отправки E-mail-письма. Но дело не в этом. А теперь пример решение такой же самой задачи на чистом коде:


if(isset($_POST['sends'])){
	$name='';if(isset($_POST['name'])){$name=htmlspecialchars (strip_tags (trim($_POST['name'])));}
	$mess='';if(isset($_POST['mess'])){$mess=htmlspecialchars (strip_tags (trim($_POST['mess'])));}
	
	if(mb_strlen($name,'UTF-8')>20){$this->error[]='Некорректно заполнено поля ИМЯ';}
	if(mb_strlen($mess,'UTF-8')>500){$this->error[]='Некорректно заполнено поля СООБЩЕНИЕ';}
	
	if(!is_array($this->error)){
		$mess='<p>Имя: <b>'.$name.'</b></p><p>Сообщение с сайта: <b>'.$mess.'</b></p><p>Дата и время отправки: <b>'.date('Y/m/d в H:i:s').'</b></p>';
		return mail('admin@gmail.com','Тема сообщения',$mess);
	}else{
		foreach($$res as $v){echo $v.'<br>';}
	}
}

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


<?php
//Вызов напрямую, не оборачивая в функции и объекты
$i=0;while($i<900000){
	//Какой-то участок кода
$i++;}

//Вызов участка кода через пользовательскую функцию (function)
function Send(){
	//Какой-то участок кода
}
$i=0;while($i<900000){
	Send();
$i++;}

//Вызов участка кода через CLASS (объект, экземпляр класса)
class Forms{
	public function Send(){
		//Какой-то участок кода
	}
}
$i=0;while($i<900000){
	$forms=new Forms();
	$res=$forms->Send();
$i++;}
?>

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

Вызов напрямую 900000 раз за: 0.076004028320312 сек. (чистый код)
Вызов через функцию 900000 раз за: 0.19101095199585 сек.
Вызов через Class 900000 раз за: 0.63403606414795 сек.

У сколько раз медленнее ООП и функции - сейчас узнаем! Для этого время вызова через функцию, объект делим на время прямого вызова:

Функция проигрывает у 2.5131687914074 раз.
Вызов через Class проигрывает у: 8.3421376229673 раз.

Важное замечание: PHP - это интерпретируемый язык, который тратит много времени на синтаксический анализ и каждое лишние действия приводит к существенному снижению скорости выполнения программы.

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

Не секрет, что на ООП пишут много программ, для Windows. Вспомните, какой лёгкий и быстрый был XP и 7-я версия Виндовс, но после того, как вышла 8 и 10-е версии, система стала работать с тормозами, а причина - использование ООП. В этом случае пользователь ОС Windows один. Представьте, какую большую нагрузку берут на себя сервера, обрабатывая не одного пользователя, как ОС, а много в единицу времени. Хочу предупредить, что очень легко "положить" сервер, обрабатывающий проект / сайт, написан на ООП, в отличии от сайта на чистом коде нужны в сотни, а то и тысячи раз больше усилий, гарантирую!

Все веб-студии говорят, что ООП везде используют, что это принято везде и без этого невозможно написать любой проект. Обратите, к примеру, внимание на соц. сеть "Facebook" , который так же написан на ООП и результатом перехода на ООП стало невыносимое притормаживание этой соц.сети, возлюбленной многими пользователями. Если присмотреться, можно заметить, что сайты созданные 99% веб-студиями жестко тормозят. Почему так, спросите Вы? Потому, что веб-студии работают как китайцы, на количество, соответственно о качестве речи никакой идти не может. Программист имея приоритет смотреть на качество продукта, подходя к написанию индивидуально, сравнивается с мастерами Швейцарских часов!

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

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

P.S. Скоро мы запишем видео и покажем недостатки ооп на примере конкретных задач, проведём тесты по скорости выполнения, памяти.