Применение объектов.

[Alkinoy]

Применение объектов.

Вопрос теоритический.
Есть у нас возможность использовать объекты. Строить классы. Однако их применение в скриптовом языке несет много проблем. и такая прелесть как инкапсуляция, например, может быть источником дополнительного головняка при не совсем крректной работе 2 программистов - автора класса и пользователя класса (классический пример - ссылки в объекте и попытки запихнуть объект в сессию). Кто может поделиться примерами удачного использования объектов? то есть не просто ситуацией - можно объект - будет объект. А случаи, когда применение объектов принесло существенные выгоды! И наоборот, основные проблемы, возникающие от применения объектов.
Из личного опыта, плиз.

ЗЫ. я не пытаюсь вести священную войну ООП против процедурного программирования. Я хочу услышать реальные истории, возникавшие в прикладных задачах. Спасибо!

 

[StUV]

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

 

[Alkinoy]

матчасть читал. интересно именно реальные примеры. если кому не лень написать...

 

[StUV]

реально могу скопипастить куски текста с буча или фаулера и зареплейсить имена персонажей

-~{}~ 12.10.07 18:01:

зы:
как бы так сказать
реально ощутимо после перевода 10М фактически процедурного кода на объектный стало намного легче жить в поддержке проектов
написать полностью архитектурное решение выполненное в целом за год здесь - я не могу
пример вырванный из контекста "заменили небольшой пакет функций системой классов и всем стало хорошо" - сам понимаешь, будет совершенно никаким аргументом

 

[HraKK]

Alkinoy
Практика. Делай пока на процедурном/функциональном. Читай про ООП. Со временем созреешь и сам начнешь на таком писать. А ответа который откроет тебе глаза прям вот так сразу не бывает. Никкакой код тебе не обьяснит.

 

[Фанат]

интересно, а по делу кто-нибудь выскажется

 

[StUV]

интересно, а по делу кто-нибудь выскажется

имхо, как раз "по делу" приведет к холивар - так как появятся умники, которые начнут оспаривать данный конкретный пример

 

[Фанат]

Ну вот давайте возьмем объект "новость".
какие у него могут быть методы?
новость-читать
новость-править
новость-удалить

причем все три сводятся к банальным SQL запросам.
ну и зачем, спрашивается, городить класс, который будет всего лишь интерфейсом к БД?

 

[StUV]

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

+
я видел много _больших_ систем на пхп, написанных процедурно и объектно
в поддержке/расширении легче последние по причинам которые можно найти в гугл->Г.Буч->"что-нибудь про ооп"
о чем тут еще говорить ?

 

[Фанат]

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

 

[Nogrogomed]

я пока еще не пришел к осознанию всей ООП-картины, но попробую высказаться:

Ну вот давайте возьмем объект "новость".
какие у него могут быть методы?
новость-читать
новость-править
новость-удалить

Существуют также и другие объекты классов: сообщение гостевой, статьи и проч. Все они могут (не обязательно) иметь следующие методы:
Прочитать все
Прочитать одну
Добавить
Редактировать
Удалить

Итого: можно все это запихнуть в один класс напр Model. А остальные классы будут наследовать методы и свойства от Model. Итого создавая класс
News() уже не придется переписывать методы классов.

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

 

[StUV]

зачем тогда что-то писать?
взял джумлу и вперед...

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

как это сделать процедурно - я тоже знаю
но ковыряться в таком коде я устал...

зы:
если так важен вопрос производительности с разницей в 10% - тогда такие вещи лучше писать на перле или вообще на си

-~{}~ 12.10.07 18:58:

в котором непонятно - что куда инкапуслировать

это только первое время

-~{}~ 12.10.07 19:00:

нежели копипастить процедурный функционал

известное заблуждение
объектный аналог копипаста в процедурном коде - тоже будет копипастом =)))

 

[Фанат]

это только первое время

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

 

[StUV]

матчасть читал. интересно именно реальные примеры. если кому не лень написать...

Alkinoy, имхо, в теме
статей/книг халявных в нете много

что ты предлагаешь сдесь написать ?
трактат на 500 страниц?

я пытаюсь объяснить, что примеры на экран кода никогда не дадут опытному программисту явные преимущества одного подхода перед другим

новичкам в любом случае надо учиться, тестить, выбирать, сравнивать - это не один год опыта разработки/проектирования
для этого книги и придуманы - умные взрослые дядьки делятся многолетним опытом
если человек не доверяет доктору наук в теме - 20 строк кода и 5 строк разъяснений на форуме его убедят?.. я сомневаюсь

 

[whirlwind]

Кто может поделиться примерами удачного использования объектов? то есть не просто ситуацией - можно объект - будет объект.

require_once 'PayCash/PayCashRequestProcessor.php';
require_once 'YandexMoneyFunctionHandle/PrepareToPurchaseGoodsHandle.php';
require_once 'YandexMoneyFunctionHandle/AcknowledgePaymentHandle.php';

$processor = new PayCashRequestProcessor($YM['UserID'],$YM['EncryptionKey']);
$processor->setFunctionHandle('PrepareToPurchaseGoods',
	new PrepareToPurchaseGoodsHandle($YM['AccountKey']));
$processor->setFunctionHandle('AcknowledgePayment',
	new AcknowledgePaymentHandle());
$processor->run(isset($_REQUEST['ahw_data']) ? $_REQUEST['ahw_data'] : '');

А случаи, когда применение объектов принесло существенные выгоды!

Да, изоляция кода в классы позволяет

1. тестировать
2. свести процесс reuse до

svn:externals ServerAction svn://server/project/classes/ServerAction/

3. понять сущность по интерфейсу не заглядывая в код
4. заменить реализацию
5. и т.п.

 

[vasa_c]

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

Это не проблема скриптового языка, это проблема передачи объекта (внутренней структуры одного процесса) другому процессу.

которое выполняется доли секунды

А причем тут доли секунды? Каждая программа в процессе выполнения должна:
1. Запуститься, создать и инициализовать свои структуры данных
2. Выполнить нужные действия
3. Подчистить за собой и завершиться
Что меняется от того, что с точки зрения живого человека время выполнения одного процесса не столь велико? Или то, что при этом выполнении не происходит интерактивного взаимодействия с пользователем?
Если пытаться объеденить последовательность разрозненных запросов в одно "псевдоприложение" и пытаться в его рамках создать общие структуры данных, таская тудя сюда объекты через сессии, то в большинстве случаев ничего хорошего не выйдет. А если рассматривать каждый процесс отдельно, как законченную программу, задача которой сформировать на основании полученных от клиента и хранящихся на сервере данных нужный ответ, то всё гораздо проще. И ООП здесь имеет те же самые достоинства и недостатки, что и в "классических" программах.

Пример?

Делаю сейчас подсветку синтаксиса для различных языков программирования (задача, даже по меркам PHP, мягко говоря "ниже среднего"). Базовый класс с несколькими абстрактными функциями (подсветить код, подсветить отдельную строку...). От него наследуется класс, реализующий подсветку стандартных элементов для большинства языков (числа, идентификаторы, строки, комментарии). От этих двух классов наследуются классы для каждого конкретного языка. Добавить нужный язык — наследую новый класс, меняю несколько параметров, специфичных для данного языка, может быть перегружаю пару методов.
Можно ли делать это всё функциями? Конечно, можно. Нафиг нужно? Не знаю, мне не нужно. Может быть кому-то действительно это удобнее.

Ну и весь интерфейс библиотеки заключен в вызове <класс>::highlight(код, язык). В нем подгружается нужный класс и вызывается его метод подсветки синтаксиса. Полиморфизм и все дела. Есть объект — есть интерфейс, как он реализован, за какой язык отвечает, вызывающей стороне дела нету.


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

 

[jonjonson]

Ну вот давайте возьмем объект "новость".
какие у него могут быть методы?
новость-читать
новость-править
новость-удалить

Типичный пример не понимания ООП
Далее кусочек бессвязного кода:

$objNews1 = NewsManager::findNewsById(Request::get("news_id", null));
$array_of_obj_news = NewsManager::findNewsByDate(Request::get("news_date", null));

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

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

Кроме того, если кто-то лично потратил много сил на понимание работы какого-то кода (в том числе и с приставкой "говно"). То он может оценивать этот код вполне лояльно, если считает, что получает конкурентное преимущество. Опыт не пропьёшь, а заработать можно. И плевать на правильный подход, ибо мотивация от другого. Примеров думаю много не нужно: Windows, phpBB, Joomla, Битрикс, NetCat и т.д.

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

 

[cDLEON]

А можно поинтересоваться какие плюсы даёт
Request::get("news_date", null)
Вместо обычного $_REQUEST['news_date']

 

[jonjonson]

cDLEON, как я написал выше, субъективные

Хотя, например Request может в своём чреве контролировать get_magic_quotes_gpc().

 

[zerkms]

А можно поинтересоваться какие плюсы даёт
Request::get("news_date", null)
Вместо обычного $_REQUEST['news_date']

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