Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Перенес тредище в programming, имхо, там ему самое место 10.07.04 17:39 Число просмотров: 3466
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
|
<site updates>
|
Объектная парадигма провалилась 07.07.04 18:30
Publisher: dl <Dmitry Leonov>
|
Объектная парадигма провалилась
Ричард П. Гэбриэл, перевод - Александр Майборода
Вводное выступление Ричарда П. Гэбриэла на диспуте по поводу ООП.
Конференция OOPSLA [ http://www.oopsla.org/2002/ ], Сиэтл, 6 ноября 2002г.
Перевод "парного" выступления Гая Л. Стила "Объектная парадигма не провалилась" расположен здесь [ http://bugtraq.ru/library/programming/objectshavenotfailed.html ].
Оригинал находится по этому адресу [ http://dreamsongs.com/ObjectsHaveFailedNarrative.html ].
Что это такое вообще — провал парадигмы программирования? Парадигма терпит неудачу, когда содержащийся в ней посыл утрачивает адекватность, или когда приверженцы парадигмы продолжают держаться её вопреки здравому смыслу. Причиной утраты адекватности являются сильно изменившиеся требования, предъявляемые к программному обеспечению в XXI веке, и так называемые усовершенствования в ОО, перечеркнувшие его первоначальные преимущества. Одержимость ООП переросла в продвижение частного решения в качестве панацеи от всех...
Полный текст
|
|
На ZDNet.ru интересная статья вышла про событийное программирование... 12.10.04 16:56
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 12.10.04 16:57 Количество правок: 1
|
Цитирую:
«В целом бизнес-приложения становятся все более сложными для программирования. В последнем отчете аналитики Forrester Research приходят к выводу, что разработка корпоративных приложений стала «труднее, чем следует». «Техническое и архитектурное усложнение явилось результатом технологий, не сдержавших своих обещаний, инструментов, не поспевающих за изменениями в реализации технологий, и все более распределенной природы внедряемых решений», — говорится в отчете Forrester.»
Что-то мне это напоминает ;-)
Новое событие в программировании?
|
| |
Да ну... 12.10.04 18:30
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> Что-то мне это напоминает ;-)
Этих горе-революционеров уже было воз и тележка. Настоящих революций было немного и о том, что это революция, узнавали почему-то постфактум.
|
|
практически все ,что написано в статье полный бред. 18.08.04 09:52
Автор: cybang Статус: Незарегистрированный пользователь
|
> Объектная парадигма провалилась
> Ричард П. Гэбриэл, перевод - Александр Майборода
>
практически все ,что написано в статье ПОЛНЫЙ бред.
как только ООП перестанет удовлетворять требованиям
ОСНОВНЫХ разработчиков ПО они перейдут на новые методы
написания программ.
А плач по поводу Smalltalk это ...
Автор наверное не занимается програмированем ,а только пишет статьи ,
иначе бы он не стал утверждать, что все пишут в ООП.
многое ,если не большинство низкоуровневое ПО пишеться на pure C
и асме.
|
| |
Типа что-то новое сказал... 18.08.04 10:51
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 18.08.04 10:57 Количество правок: 1
|
> практически все ,что написано в статье ПОЛНЫЙ бред.
> как только ООП перестанет удовлетворять требованиям
> ОСНОВНЫХ разработчиков ПО они перейдут на новые методы
> написания программ.
Перейдут... когда они (новые методы) появятся. Откуда?
> А плач по поводу Smalltalk это ...
> Автор наверное не занимается програмированем ,а только
> пишет статьи ,
> иначе бы он не стал утверждать, что все пишут в ООП.
> многое ,если не большинство низкоуровневое ПО пишеться на
> pure C и асме.
«Заниматься программированием» и «Экспериментировать/развивать компьютинг» — есть разница, не правда ли? Этим отличается фельдшер от профессора медицинских наук.
|
|
Перенес тредище в programming, имхо, там ему самое место 10.07.04 17:39
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
|
|
Супернапильник в кривых руках 09.07.04 07:40
Автор: Zef <Alloo Zef> Статус: Elderman
|
Просто, на рекламу ООП, как "легкого в освоении" повелись толпы ламеров и стали пихать классы "куда не надо". А куда надо - не пихать. Умудряются использовать ООП даже в драйверах ядра! (тут недавно проскакивало, да еще с "Борландовским" акцентом). А вот, деловые БД по сей день все пишут в табличной форме, хотя "сам Бог велел":
class CSclad : public CRecordSet
{
public:
Put(tovar_type tt, measure_unit EdIzm, int Col_vo);
Get(tovar_type tt, measure_unit EdIzm, int Col_vo);
.............................
};
а таблицы, серверы и запросы зарыть в недра класса, создать библиотеку структурных подразделений и из них строить модель предприятия.
>> А идея мутирующих программ хороша только на словах.
>Поздравляю! Однако, мы телесны и осязаемы и суть продукт миллионолетних крошечных мутаций... А >говорите, "на словах"... ;-)
А вот этого не надо! Никогда! Оно же нас съист...
Искусственный интеллект не естественный интеллект и уж, тем более, не твой собственный. Умный слуга - "себе на уме", а уж ни как не хозяину. Лифт у нас в здании, интеллектуальный, с "перехватом" и "памятью", сами проектировали - теперь мучаемся. Его перехватят, а ты как дурак, машинально, не на своем этаже выходишь, думаешь - приехал: холлы-то одинаковые. Или вызова запомнит, все уже давно разбегутся со злости, что он не едет, а он потом пол часа ездит пустой с этажа на этаж.
Техника должна быть тупой и исполнительной, как фельдфебель.
|
| |
В последние полгода постоянно слышу похожие мысли от своих... 21.08.04 10:51
Автор: anw Статус: Незарегистрированный пользователь
|
>А вот, деловые БД по сей день
> все пишут в табличной форме, хотя "сам Бог велел":
>
> class CSclad : public CRecordSet
> {
> public:
> Put(tovar_type tt, measure_unit EdIzm, int Col_vo);
> Get(tovar_type tt, measure_unit EdIzm, int Col_vo);
> .............................
> };
> а таблицы, серверы и запросы зарыть в недра класса, создать
> библиотеку структурных подразделений и из них строить
> модель предприятия.
В последние полгода постоянно слышу похожие мысли от своих программеров... Идея хорошая, эмоциональный посыл при этом у говорящего обычно соответствующий... Только вот как при этом с реализацией идеи? Настрогать классы, которые в скуль будут плеваться простейшими запросами аля пут-гет эт можно. Что потом? Потом методы этого класса юзать из его потомков... В базу пойдёт большой поток простейших запросов. А его высочество Скуль штучка та ещё - она ДЛЯ ОПЕРАЦИЙ НАД МНОЖЕСТВАМИ сделана - хорошо написаный "вручную" запрос к большому объединению она сдеалает быстренько, а ту же работу, разбитую на десяток простых операций (пут-гет) - нет! Если база "не детского" размера, то с таким "Объектным" подходом можно попрощатся с производительностью, с проектом, с заказчиком.. ИМХО, проблемма тут закопана.
;/
|
| | |
Хороший пример 23.08.04 11:42
Автор: amirul <Serge> Статус: The Elderman
|
> запросов. А его высочество Скуль штучка та ещё - она ДЛЯ
> ОПЕРАЦИЙ НАД МНОЖЕСТВАМИ сделана - хорошо написаный
> "вручную" запрос к большому объединению она сдеалает
> быстренько, а ту же работу, разбитую на десяток простых
> операций (пут-гет) - нет! Если база "не детского" размера,
Конечно, можно и объектное решение написать так, чтобы исполнение операций откладывалось до момента, когда операцию можно выполнить наиболее эффективно. После чего кешировалось во избежание повторных запросов.
У страуструпа есть пример иерархии классов, реализующих арифметические операции. Семантика всех операций сохраняется (запись a+b приводит в общем случае к вызову некоторой функции add(a,b), возвращающей значение данного типа), но некоторые операции аггрегируются. Например, на некоторых архитектурах умножение двух чисел и прибавление к ним третьего - элементарная операция (очень часто используется в численных методах, матричной алгебре и пр), иногда можно еще и указать, куда поместить результат (отказ от использования временных переменных необходим например при вычислениях с произвольной точностью или матричными вычислениями). Так вот страуструп привел набор классов, при которых запись
a = b*c + d;
в конце концов сворачивается к некой
mul_add_and_assign(a, b, c, d); - суть тетрарный оператор
Отложенное исполнение и кеширование могут помочь реализовать эффективную объектную модель базы данных. Но ведь ООП претендует на упрощение понимания, а вот простые ручные запросы на мой взгляд гораздо понятнее и проще, чем извратная структура классов.
|
| | | |
этистина работает только при решении маленьких задач, в тоже... 24.08.04 16:31
Автор: DgtlScrm Статус: Member
|
> Но ведь ООП претендует на упрощение понимания, а вот простые
> ручные запросы на мой взгляд гораздо понятнее и проще, чем
> извратная структура классов.
этистина работает только при решении маленьких задач, в тоже время намного приятнее и проще применять ООП для написания объемных приложений. Поверь, когда у нас исходники весят по 80 метров то изменять код намного проще, когда ты видишь не 80 метров кода а 80 метров объектов :) а это большая разница...
|
| | | | |
Не факт 25.08.04 10:45
Автор: amirul <Serge> Статус: The Elderman
|
> этистина работает только при решении маленьких задач, в
> тоже время намного приятнее и проще применять ООП для
> написания объемных приложений. Поверь, когда у нас
> исходники весят по 80 метров то изменять код намного проще,
> когда ты видишь не 80 метров кода а 80 метров объектов :) а
> это большая разница...
А 80 метров модулей? С четко определенными межмодульными интерфейсами и небольшими размерами самих модулей. Вот тут уж зависит от качества модулей и объектов. Априорного преимущества я не отдам ни тем ни другим.
|
| | | | | |
Тут понимашь какая ситуация, есть десяток систем которые... 25.08.04 11:38
Автор: DgtlScrm Статус: Member
|
Тут понимашь какая ситуация, есть десяток систем которые предоставляют свои интерфейсы. Каждая система может(а чаще всего наверняка) имеет несколько подсистем которые не доступны из вне. Есть второй уровень, ето интерфейс движка и именно через него осуцествляется доступ к системам. А весь програмный код пишеться на луа :)
Я даю предпочтение именно этому варианту, поскольку у нас на фирме это за последний год уже четвертый движок и пока он показал себя лучше всех как в плане стабильности так и в плане удобства внесения изменений. Хотя если нам дали бы еще пол годика новый движок был бы по лучше :) Но несомненно ОО! Потому как первый был процедурный... поверь писался он всего лишь месяц, но разбираться в нем или искать ошибки... это было самое большое наказание :)
|
| | | | | | |
Ну дык системы-подсистемы - это отлично. Но вот при чем тут... 25.08.04 13:35
Автор: amirul <Serge> Статус: The Elderman
|
> Я даю предпочтение именно этому варианту, поскольку у нас
> на фирме это за последний год уже четвертый движок и пока
> он показал себя лучше всех как в плане стабильности так и в
> плане удобства внесения изменений. Хотя если нам дали бы
> еще пол годика новый движок был бы по лучше :) Но
> несомненно ОО! Потому как первый был процедурный... поверь
> писался он всего лишь месяц, но разбираться в нем или
> искать ошибки... это было самое большое наказание :)
Ну дык системы-подсистемы - это отлично. Но вот при чем тут ОО? Ни инкапсуляции, ни полиморфизма, ни наследования. Нет там никакого ОО - чистая процедурная архитектура. Вот я и говорю, лучше хорошая процедурная программа, чем плохая ОО.
|
| | | | | | | |
Как нет? Минимум - это то что все системы унаследованы от... 25.08.04 16:12
Автор: DgtlScrm Статус: Member
|
> Ну дык системы-подсистемы - это отлично. Но вот при чем тут
> ОО? Ни инкапсуляции, ни полиморфизма, ни наследования. Нет
> там никакого ОО - чистая процедурная архитектура.
Как нет? Минимум - это то что все системы унаследованы от абстрактного класса системы, которы й реализует все необходимые базовые функции любой системы. А инкапсуляция и полиморфизм присутствуют в интерфейсе для движка и внекоторых системах(там где есть необходимость).
|
| | | | | | | | |
Ну а если нет "базовых функций любой системы". Какой... 25.08.04 17:16
Автор: amirul <Serge> Статус: The Elderman
|
> Как нет? Минимум - это то что все системы унаследованы от
> абстрактного класса системы, которы й реализует все
> необходимые базовые функции любой системы. А инкапсуляция и
Ну а если нет "базовых функций любой системы". Какой интерфейс ты бы предоставил для базового класса например WinNT-шных подсистем: ввода/вывода, справочного монитора безопасности, менеджера объектов, менеджера конфигурации (проще говоря реестра) и прочего. Эти подсистемы очень хорошо друг от друга отделены, но используя чисто процедурные приемы. А кода немало: одного ядра - почти 40 метров (такое за месяц не напишешь).
> полиморфизм присутствуют в интерфейсе для движка и
> внекоторых системах(там где есть необходимость).
Ну и в чем выражается полиморфизм?
|
| | | | | | | | | |
В движке все это кстати есть. Все вводы выводы(доги,... 28.08.04 12:42
Автор: DgtlScrm Статус: Member
|
> > Как нет? Минимум - это то что все системы унаследованы
> от
> > абстрактного класса системы, которы й реализует все
> > необходимые базовые функции любой системы. А
> инкапсуляция и
> Ну а если нет "базовых функций любой системы". Какой
> интерфейс ты бы предоставил для базового класса например
> WinNT-шных подсистем: ввода/вывода, справочного монитора
> безопасности, менеджера объектов, менеджера конфигурации
> (проще говоря реестра) и прочего. Эти подсистемы очень
> хорошо друг от друга отделены, но используя чисто
> процедурные приемы. А кода немало: одного ядра - почти 40
> метров (такое за месяц не напишешь).
В движке все это кстати есть. Все вводы выводы(доги, консоль, файл, память, клавиатура, контроллеры и сеть) имеют файлоподобный интерфейс. Тоесть открыть читать, писать... и т.д.
Все коллекции порождены от менеджера коллекций, это менежер объектов, ресурсов, событий, графичесских ресурсов и граф. объектов. Каждый менеджер очень прост потому как изменяются только функции подгрузки выгрузки и контроля за коллекцией.
А все настройки читаются из файла (а это может быть и сеть и память, покрайней мере чаще всего это файл :) )( XML, LUA и возвращаются уже в виде дерева.
Чем больше думаешь над взаимосвязями тем больше их замечаешь... Хуже всего, когда весь движок уже в виде UML-ки и ты думаешь... а можно было сделать по другому, но влом очередной раз переписывать :) Ведь срока как всегда горят %)
> > полиморфизм присутствуют в интерфейсе для движка и
> > внекоторых системах(там где есть необходимость).
> Ну и в чем выражается полиморфизм?
Это Что?Где Когда? :)
Дело в том, что движок написан так чтобы на LUA у меня небыло никаких неудобств. Поэтому много методов(в основном обработки данных) имеют перегруженые интерфейсы, чтобы мне не приходилось производить конвертирование из скриптов. И вто же время gInterface должен на лету создать сотни графичесских объектов, анимаций; система ввода со старта загружает все доступные ей " источники информации о человечесских действиях". С сервера подгружаются административные скрипты, с архивов читаются конфиги, делается mmap крохотного раздела и мы уже подключены к системе внутреннего хранилища пользовательских данных. И когда я писал систему чтения конфигурационных файлов, я даже не знал откуда будут грузится данные, с начала это было "file#main.lua", а потом пошло поехало... "zip#data.zip", "net#127.0.0.0.1/port/configname"... Я предполагаю ты догадываешся, что все создается на лету... ладно, что они создаются по имени... Если, такого объекта нет, то создается фиктывный экзепляр объекта который ничего не делает... Ну а подключаясь к файловой подсистеме, тебе возвращается указатель на базовый клас файла, хотя на самом деле это полиморфные классы порожденные от него.
Вобщем берем к примеру объект gCard - это игровая карта(пиковый король, дама трефь, етц...) Но вот незадача, у меня есть колода которая нарисована с лева... карты лежат стопкой. Когда тебе сдают карты они появляются у тебя на игровом поле, а при дупляжке они маленькие... Так вот, все это дело сделано так, что есть понятия gCard это просто карта она умеет вращатся, прятаться вообщем это даже не ее методы... все они унаследованы от gObject. Некоторые из них перегружены но это не факт важно. Зато есть понятия gCard, gCardFromPack, gCardFromMainScene, gCardFromBonus. И их единственная разница - это Draw и Rotate. При прорисовке, они фигурируют как gObject, помоему это и есть полиморфность...
|
| | | | | | | | | | |
Я совершенно не о том спрашивал 30.08.04 11:36
Автор: amirul <Serge> Статус: The Elderman
|
> > WinNT-шных подсистем: ввода/вывода, справочного
> монитора
> > безопасности, менеджера объектов, менеджера
> конфигурации
> > (проще говоря реестра) и прочего. Эти подсистемы очень
> > хорошо друг от друга отделены, но используя чисто
> > процедурные приемы. А кода немало: одного ядра - почти
> 40
> > метров (такое за месяц не напишешь).
>
> В движке все это кстати есть. Все вводы выводы(доги,
> консоль, файл, память, клавиатура, контроллеры и сеть)
> имеют файлоподобный интерфейс. Тоесть открыть читать,
> писать... и т.д.
Файлоподобным интерфейсом занимается ОДНА из перечисленных подсистем - менеджер объектов. Он предоставляет функции для создания/удаления/поиска/открытия/закрытия обобщенных объектов, присваивает им типы и прочее. В принципе его конечно можно считать базовым для всех остальных, которые реализуют его интерфейсы. Но вот память при всем желании очень трудно сделать объектом (вернее очень трудно сделать это эффективно), монитор безопасности работает параллельно с менеджером объектов и контроллирует доступ к объектам на всех уровнях, другие подсистемы предоставляют ГОРАЗДО более широкие интерфейсы, чем просто реализацию интерфейсов менеджера объектов, что тоже выглядит скорее не обобщением, а просто вынесением повторяющихся частей в отдельную функцию. Поясню на примере. И файл и процесс - объекты, но кроме включения их в общую иерархию с ними больше нельзя сделать практически ничего общего: в файл можно писать, в процесс - нельзя, зато процессу можно повысить приоритет, а файлу - нельзя. Короче эти объекты настолько разные, что выносить в общий базовый класс практически нечего.
Есть еще окна, таймеры, токены безопасности и куча прочего. Сущности настолько разные, что пересечением их свойств будет только то, что они сущности, а следовательно выносить в базовый класс можно только управление ими - создание/удаление/открытие/закрытие.
|
| | | | | | | | | | |
Но у каждого есть своя специфика. Например память -... 28.08.04 12:59
Автор: Killer{R} <Dmitry> Статус: Elderman
|
> > > Как нет? Минимум - это то что все системы
> унаследованы
> > от
> > > абстрактного класса системы, которы й реализует
> все
> > > необходимые базовые функции любой системы. А
> > инкапсуляция и
> > Ну а если нет "базовых функций любой системы". Какой
> > интерфейс ты бы предоставил для базового класса
> например
> > WinNT-шных подсистем: ввода/вывода, справочного
> монитора
> > безопасности, менеджера объектов, менеджера
> конфигурации
> > (проще говоря реестра) и прочего. Эти подсистемы очень
> > хорошо друг от друга отделены, но используя чисто
> > процедурные приемы. А кода немало: одного ядра - почти
> 40
> > метров (такое за месяц не напишешь).
>
> В движке все это кстати есть. Все вводы выводы(доги,
> консоль, файл, память, клавиатура, контроллеры и сеть)
> имеют файлоподобный интерфейс. Тоесть открыть читать,
> писать... и т.д.
Но у каждого есть своя специфика. Например память - закрепить в физической, просто зарезервировать, выделить по обычному. Файл - открыть с кэшированием,без, оптимизации кэширования, наконец Memory mapping. Про контроллеры и сеть так тут вообще муть полная с их кучей протоколов и доп. фич. Все это при попытке все обобщить в виде какого то общего классалишь_усложнитситуацию. Конечно можно сказать - а зачем все эти фишки нужны, можно ведь файл открывать по дефолту или написать супер-умную систему которая все будет сама угадывать. Но еслибы это было возможно это бы уже сделали. А идеального ничего не бывает.
> Все коллекции порождены от менеджера коллекций, это менежер
> объектов, ресурсов, событий, графичесских ресурсов и граф.
> объектов. Каждый менеджер очень прост потому как изменяются
> только функции подгрузки выгрузки и контроля за коллекцией.
А еще проще когда нет никакого менеджера, а есть только функции Ж)
|
| | | | | | | | | | | |
система нифига не угадывает и не должна. В данном случае... 28.08.04 14:38
Автор: DgtlScrm Статус: Member
|
> Но у каждого есть своя специфика. Например память -
> закрепить в физической, просто зарезервировать, выделить по
> обычному. Файл - открыть с кэшированием,без, оптимизации
> кэширования, наконец Memory mapping. Про контроллеры и сеть
> так тут вообще муть полная с их кучей протоколов и доп.
> фич. Все это при попытке все обобщить в виде какого то
> общего классалишь_усложнитситуацию. Конечно можно
> сказать - а зачем все эти фишки нужны, можно ведь файл
> открывать по дефолту или написать супер-умную систему
> которая все будет сама угадывать. Но еслибы это было
> возможно это бы уже сделали. А идеального ничего не бывает.
система нифига не угадывает и не должна. В данном случае есть метот Setup, но он используется только в крайних случаях, вместо него идет SetupFromConfig() где интерфейс конфигурирует себя сам, согласно конфигурационному файлу.
>
> > Все коллекции порождены от менеджера коллекций, это
> менежер
> > объектов, ресурсов, событий, графичесских ресурсов и
> граф.
> > объектов. Каждый менеджер очень прост потому как
> изменяются
> > только функции подгрузки выгрузки и контроля за
> коллекцией.
> А еще проще когда нет никакого менеджера, а есть только
> функции Ж)
Может ты еще скажешь что ненадо ни сборщиков мусора, ни исключений... и т.д. У меня сложилось мнение, что ты никогда не принимал участие в разработке крупных проэктов...
|
| | | | | | | | | | | | |
Извините, что вмешиваюсь 30.08.04 02:20
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 30.08.04 02:36 Количество правок: 2
|
> Может ты еще скажешь что ненадо ни сборщиков мусора, ни
> исключений... и т.д. У меня сложилось мнение, что ты
> никогда не принимал участие в разработке крупных
> проэктов...
Я еще не видел хорошо написанного all-purpose сборщика мусора, следовательно - см. ответ Killer'а. Special-purpose сборщик нужно самому писать и отлаживать, и далеко не всегда выигрыш от его использования оправдывает затраченные усилия-время-деньги. Динамическое создание объектов себя оправдывает также далеко не всегда - даже в очень больших проектах. Вообще, на основе личного опыта я утверждаю, что размеры проекта не являются критерием для использования подобных достаточно дорогостоящих в плане потребляемых ресурсов вещей.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
