Зачем нужны классы в php?

Не совсем понимаю о чем вы. Что тут забывать? Как это состыкуется с тем, что я говорил про настройки?

Пример в студию, каким образом вы будете держать 5 открытых подключений в одной переменной!

Пример не надуманный, а вполне себе реальный!

Хотел бы я посмотреть на производительность функции монстра!

о да, а структурное программирование привнесло столько понятного и простого!

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

BoyStav добавил 03.02.2009 в 01:46

самое настоящее ООП

А состыкуется это примерно следующим: я как-то дописывал систему, в котором были глобальные переменные $CONFIG, $Config, $_Config, $_config... Ей-богу не вру. Вот как в такой каше разобраться? При учете, что кода кило на стописят, как минимум...

Спорим, не обойдется без массива? =)

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

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

Ну запихните все настройки из базы в глобальный массив по такому принципу $CONFIG[тип настроек][переменная], это ж удобно. Можно дублировать в классы иногда $this->OPTIONS=$GLOBALS['OPTIONS'][тип], ничего в этом страшного я не вижу.

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

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

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

Devider, я все-равно не понимаю, нахрена костыли...

Не проще сделать так:

<?php
// На этапе инициализации
$UserConfig = new ConfigObject();
Dispacher::registerObject($UserConfig, 'userConfig');

$UserConfig->setSource('database', 'configTable');
$UserConfig->read();


// На этапе использования, где-нибудь в классе Users
$this->_configs = Dispatcher::getObject('userConfig');
// Все, готово к использованию. Улыбаемся и машем машем и улыбаемся

Чем полезен такой подход:

При serialize(Dispatcher::getInstance()) можно и нужно проверять типы объектов, хранимых внутри. Ложить все конфиги в единый файл (почти нативное кеширование получается). При wakeup - просто заполнять объект данными из массива.

В случае с глобальным конфигом - нужно еще понимать, что у тебя в глобальной перменной можно кешировать, а что нет... Как понять? На уровне объектов - все просто:

<?php 

if( $object implements Serializable &&
   $object->cacheEnabled()) {
 serialize($this->_data['userConfig']); // __sleep, разумеется
}

Финита

-------------

Название топика, если что: "Зачем нужны классы в php". Тут никто не спорит о том, какой подход лучше.. Скорее - как можно применять ;)

для конфигов столько е**и. мазохисты рулят видимо. имхо все это ООП ради ООП.

ТС, ощущение такое, что ВЫ пищите курсак или реферат на эту тему.

Классы, неважно в каком языке, это одна из основных частей ООП.

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

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

PS Если ВЫ не понимаете, зачем нужно ООП, значит Вы еще не приступаки к программ, которые это требуют.

Напомнило "Я пони. Обоснуйте". Доказать можете, что ооп здесь не нужен? Чтобы вас уверовать в жизнь - приведу пример своей реализации системы конфигурации:

A_ConfgInterface - интерфейс

A_ConfigAPI - Адаптер для работы с конфигами

A_ConfigFabricanto - фабрика объектов конфига.

Приступим? =)

<?php

$Config = new A_ConfigAPI();



$Config->extract('configName', 'database', 'tablename'); // АPI запускает фабрику объектов с сигналом 'database', просматривая перед этим наличие кеша. Ложит в свой стек имя полученого конфига, регистрирует в диспетчере

$Config->extract('configName2', 'fs', 'app::configs::users'); // То же самое. Только фабрика инстанциирует другой объект работы с конфигом, который так же имплементирует A_ConfigInterface



$singleConfig = $Config->get('configName');

$allConfigs = $Config->getMerged('configName', 'configName2', 'confgName3',...);

$Config->cache($allConfigs);

Что получили?

1. Стандартный интерфейс работы с конфигурацией в системе. Не нужно помнить как работает система конфигурирования в ядре, а как - в приложении

2. Стандартный интерфейс для хранения и кеширования конфигураций

3. Стандартный интерфейс доступа к конфигам

4. Расширяемость за счет фабрики (XML/YAML/FTP/Oracle...)

5. Центральный валидатор конфигураций - A_ConfigAPI

Могу долго так продолжать... А в процедурном секса нас ждет, чтобы такое реализовать - мама не горюй (

Для каждого типа отдельный файл всмысле? Ну вот, допустим, есть у нас тип catalog (раз уж речь зашла о интернет-магазине). Что для него нам может потребоваться? Парсер БД-запросов, настройки продуктов, настройки каталога, корзина покупок... То есть один тип может затрагивать другие типы или подтипы, а кешировать их будем под каталогом. Оформление заказа - это уже другой файл с настройками.

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