[дискуссия] Зачем применять ООП в PHP ? (На примере IPB)

[cyberquoter]

Я не очень хочу спорить потому что это редко приводит к чемто хорошему, но у меня к вам вопрос: вы написали фактически что и процедурно писать плохо и ооп - зло.
Как же вы пишете?
...

2. Применение ООП нельзя обсуждать, в принципе. Ибо это есть зло

Вас в школе не учили читать с выражением и расставлять логические ударения?

Добавлено через 5 минут
Вот сейчас буду на языке примитива объяснять


Есть класс работы с БД. Называется он database.

	protected function __construct() {
		
		$selfPath = dirname ( __FILE__ );
		if (file_exists ( $selfPath . '/' . DB_TYPE . '.php' )) {
			include_once $selfPath . '/' . DB_TYPE . '.php';
			
			if (class_exists ( DB_TYPE )) {
				$sEval = 'self::$db = '.DB_TYPE . '::getInstance();';
				eval ( $sEval );
			} else {
				error::trigger('No database connection');
			}
		}
	}

Потом я делаю что:

$db = database::$db;
$db->connect();

Вне зависимости от того, какой тип СУБД я использую - я получаю соединение к базе данных. Мне даже не нужно знать какие функции будут при этом использованы - мне ДО БАЛДЫ.

Теперь напишите тоже самое в варианте процедурного языка. В нем будет пару свитчей (при каждом вызове функции), обязательно будут объявлены флаги СУБД и прочее

Кому не лень - напишите тоже самое в процедуре

 

[vaad2]

спорю

...С удовольствием поспорю с тем, кто будет оспаривать

полностью без него никак, согласен. В процедурном подходе никто не запрещает разбивать функционал по логике и запихивать в соответствующее файло. Проблема может быть только с полиморфизьмом, ну тогда можно и класс запендюрить...
А так не вижу смысла городить кучу классов, там где это не нужно. если проект будет успешный, то есть вероятность что и понадобиться. Только проблема в том, что без доков вся эта куча классов так же трудно читается как и в процедурном подходе.
вот эту бодягу Для просмотра ссылки Войди или Зарегистрируйся писал с пом. процедурного подхода (php-часть). Вынес в класс только работу с БД.
причем каждый блок можно разнести на отдельный сайт без всяких проблем.
Без чего точно нельзя, по-моему, так это без шаблонов - очень бесит когда в одном месте и отображение и обработка...

 

[General Fizz]

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

Что же на самом деле лучше - отвечаю: все зависит от конкретной задачи и от привычного стиля программиста. Если есть возможность упростить код и свести его к минимуму, то лучше использовать процедурный подход. Если на первом месте стоит универсальность кода, его безболезненная расширяемость и переносимость, то лучше использовать ООП. Также существует мнение, что ООП медленнее в работе, чем процдурный подход из-за более сложной реализации внутри PHP.

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

cyberquoter: поосторожнее с высказываниями о том, кого и чему учили в школе.

 

[vaad2]

точно подмечено

 

[Solon]

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

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

Также существует мнение, что ООП медленнее в работе, чем процдурный подход из-за более сложной реализации внутри PHP.

Сам столкнулся недавно с тем, что приложение с "массовым" применением ООП кроме всего прочего и "жрет" намного больше ресурсов сервера.
Элементарно не хватало памяти. Переписал его без использования ООП - проблемы исчезли.
Так что все хорошо в меру )

 

[B1rdEX]

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

Память - одна проблема.. А вот время на вызов - другая. Проверено на личном опыте: если в ДЛЕ заменить работу с бд через класс на простые функции, то скорость возрастает почти в 2 раза. Соответственно и наоборот.

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

Лучший подход -- ООП + Процедуры, то есть смешивание. При таком раскладе у вас всё читабельно, красиво, но и вас не особо напрягает. Именно так большинство и поступают..

Сам пишу по смешиванию и считаю этот способ наиболее удобным.

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

 

[cyberquoter]

Всем ненавистникам ООП посвящается:
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

Немного информации об ООП в PHP
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

 

[nnmkayf]

Обычно я воздерживаюсь от HolyWar но тут не удержался по поводу

Сам столкнулся недавно с тем, что приложение с "массовым" применением ООП кроме всего прочего и "жрет" намного больше ресурсов сервера.
Элементарно не хватало памяти. Переписал его без использования ООП - проблемы исчезли.
Так что все хорошо в меру )

Действительно частенько встречаются случаи, когда применение ООП или паттернов проектирования в веб жрет память. Яркий пример такого паттерна Iterator, его стоит использовать с осторожностью. Но это скорее исключение чем правило, тем более есть прекрасная поговорка, что с дури можно и сами знаете что свернуть.
При правильном подходе ООП на порядки увеличивает скорость разработки и поддержки ПО. При современных ценах на железо, труд программиста намного дороже 1Гб памяти и лишнего гигагерца
Действительно, существует ряд приложений, где стоит использовать процедурный подход (драйвера) - в основном они ориентированы на высокую производительность.
Но стоит лишь понять принципы ООП и возвращаться к процедурному коду не хочется.
Учите ООП.
Отвечая на вопрос TC - посмотри что такое ORM (Object-relational mapping) и ты поймешь, что то, что реализовано в IPB - это еще цветочки. Doctrine - пример ягодки.

 

[anarki]

Часто ООП используется как замена для неймспейсов, весь ООП код по сути базируется на одном из принципов ООП - инкапсуляции.

 

[MBH]

Вот лазил лазил по Гуглу... искал ответ на вопрос "зачем нужны классы в PHP" и как не странно сново попал на нулед . Итого я понял из всей дискуссии это:

Плюсы (за классы в PHP)
1. Удобочитаемость (неймспейсы) (и только тому, кто привык кодить через классы)
2. Удобство при разработке толпой

Минусы (против классов в PHP)
1. Избыток написания лишнего кода.
2. Путаница при разборе кода
3. Жрёт много памяти
4. Тормозит быстродействие

Всё правильно или есть чего добавить?

p.s. я не говорю про ООП вообще. Я прекрасно пользую его во Flash и без него реально было бы очень туго, я про классы в PHP