Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Персистентные объекты это хорошо 11.03.05 11:13 Число просмотров: 3857
Автор: amirul <Serge> Статус: The Elderman
|
> и от SQL. Т. е. база должна содержать не таблицы и запросы
> к ним, а объекты "работник", "склад", "полка" и т.п. Их
> свойств и методов: Работник.Зарплата.Получить(сумма),
> Склад.Полка[n]->ВзятьГвоздь(количество).
Но прелесть баз данных не в том что они могут ХРАНИТЬ данные, а в том, что они могут хранить ОЧЕНЬ МНОГО данных и предоставлять методы БЫСТРОГО поиска среди этих данных. В целом мне кажется что ОО БД должна осуществлять откладывание запроса настолько, насколько это вообще возможно и собирать все это время данные
|
|
<site updates>
|
Теология ООП 13.11.04 23:18
Publisher: dl <Dmitry Leonov>
|
Теология ООП
Овик Меликян http://www.melikyan.com/dalshe/
В последние годы появились весьма неочевидные прогнозы, и даже чуть ли не
констатация факта о провале объектной парадигмы, ООП. Крайнюю позицию высказал
Ричард Гейбриэл в своем выступлении на OOPSLA
под прямым названием " Объектная
парадигма провалилась [ http://dreamsongs.com/ObjectsHaveFailedNarrative.html ]". Другой, более сдержанный и взвешанный прогноз
- это Пол Грэм со своей статьей " Языки
программирования через сто лет [ http://www.paulgraham.com/hundred.html ]".
Объединяет этих двух людей то, что они приверженцы функционального
программирования и языка Lisp. "А, да это брюзгливые математики, для которых
высочайшим достижением программирования является интерпретатор языка Lisp на
языке Lisp в 20 строк" - так бы я отреагировал на эти статьи годами раньше.
Но в статье Ричарда Гейбриэла есть слишком много правды, и в ответах оппонентов
(например здесь [ http://dreamsongs.com/ObjectsHaveNotFailedNarr.html...
Полный текст
|
|
Вообще-то ничего не провалилось. Всему есть своя ниша... 09.03.05 23:18
Автор: Drew_White Статус: Незарегистрированный пользователь
|
Вообще-то ничего не провалилось. Всему есть своя ниша применения. И ООП очень хорош для написания бизнес-приложений и СУБД. Попробуйте-ка написать при помощи процедур без структур и классов например приложение для обеспечения доступа к БД, где у Вас много сущностей и каждая содержит по 10-15 полей. Ничего у вас не выйдет. А если что-то и получится, то это будет настолько ужасно, что ни о каком удобстве и речи быть не может.
Насчет быстродействия Java - Вы правы конечно, что на С можно написать более быстро работающие программы. А Вы знаете, что на Ассемблере можно написать еще более маленькие по объему программы и по быстроте намного превышающие, то что написано на Си? Может быть давайте писать все на Ассемблере или в машинных кодах? ООП был придуман для того, чтобы было легче программисту писать сложные приложения и потом легко их изменять. Пример из жизни: система СУБД. Необходимо к сущности в БД добавить или удалить поле. Если СУБД написан с использованием ООП - это дело 10 минут. Необходимо добавить свойство объекту-сущности и модифицировать методы добавления/удаления записи модифицировав немного SQL запрос. Если же Вы использовали бы процедурное программирование, то вам несомненно пришлось бы переписывать полсистемы. И неизвестно, сколько бы бессоных ночей было бы проведено за компом. Так что всему есть свое применение. И нельзя говорить, что ООП совсем никому не подходит. У него конечно тоже есть свои недостатки, но пока ничего лучше нет. Логическое программирование, конечно, есть шаг вперед, но оно находится на академической стадии. Его еще нельзя применять на практике. Но скоро наверное будет можно и это будет революция. А сейчас вместо того, чтобы рассуждать о том что есть, а чего нет, не тратьте времени попусту и учитесь. Ведь весь интерес заключается в поиске новых решений, а не в ругательстве на старые.
|
| |
Особенно поразил "пример из жизни" :-) 10.03.05 11:57
Автор: amirul <Serge> Статус: The Elderman
|
> Вообще-то ничего не провалилось. Всему есть своя ниша
> применения. И ООП очень хорош для написания
> бизнес-приложений и СУБД. Попробуйте-ка написать при помощи
> процедур без структур и классов например приложение для
> обеспечения доступа к БД, где у Вас много сущностей и
> каждая содержит по 10-15 полей. Ничего у вас не выйдет. А
Вы хотя бы знакомы с парадигмой процедурного программирования? Что значит при помощи процедур без структур? Куда они вдруг делись?
> если что-то и получится, то это будет настолько ужасно, что
> ни о каком удобстве и речи быть не может.
Ха. А попробуйте ка привести ХОТЯ БЫ ОДИН пример СУБД промышленного масштаба выполненный полностью в рамках ОО парадигмы. В лучшем случае это будет ядро на С и обертки для джава/питона/лиспа и прочих.
> Насчет быстродействия Java - Вы правы конечно, что на С
> можно написать более быстро работающие программы. А Вы
> знаете, что на Ассемблере можно написать еще более
> маленькие по объему программы и по быстроте намного
> превышающие, то что написано на Си? Может быть давайте
> писать все на Ассемблере или в машинных кодах? ООП был
Кто Вам такое сказал? Читайте матчасть. Открою страшную тайну (только Вы никому не говорите), современные оптимизирующие компиляторы делают гораздо более хороший код (в большинстве случаев), чем может человек. Ну а если говорить о "бутылочных горлышках" - местах в программе, которые критическим образом влияют на ее производительность, то их и так сейчас всегда переписывают на ассемблере (только никому не говорите).
> придуман для того, чтобы было легче программисту писать
> сложные приложения и потом легко их изменять. Пример из
> жизни: система СУБД. Необходимо к сущности в БД добавить
Ну давайте-давайте. Ждем названия этой чудо СУБД на яве.
> или удалить поле. Если СУБД написан с использованием ООП -
> это дело 10 минут. Необходимо добавить свойство
> объекту-сущности и модифицировать методы
> добавления/удаления записи модифицировав немного SQL
> запрос. Если же Вы использовали бы процедурное
Э-э-э. Может я чего то не понял, но мне показалось, что Вы назвали SQL объектно-ориентированным? 8-O
> программирование, то вам несомненно пришлось бы
> переписывать полсистемы. И неизвестно, сколько бы бессоных
> ночей было бы проведено за компом. Так что всему есть свое
А скажите ка, сколько систем есть на Вашем счету?
> применение. И нельзя говорить, что ООП совсем никому не
> подходит. У него конечно тоже есть свои недостатки, но пока
> ничего лучше нет. Логическое программирование, конечно,
> есть шаг вперед, но оно находится на академической стадии.
> Его еще нельзя применять на практике. Но скоро наверное
> будет можно и это будет революция. А сейчас вместо того,
Кто Вам сказал такую глупость? Прологу уже годков поболе того же C++ и уж поболе чем джаве. И никто не кинулся на этот "шаг вперед". Вот как раз у логического программирования есть строго очерченная ниша, дальше которой соваться не стоит. А если будете ожидать революции от логического программирования, то и состариться можете не оправдав ожиданий
> чтобы рассуждать о том что есть, а чего нет, не тратьте
> времени попусту и учитесь. Ведь весь интерес заключается в
> поиске новых решений, а не в ругательстве на старые.
Ох, не учил бы отца... и баста.
|
| | |
Для того, чтобы создавать ОО БД нужно отказаться от реляционной модели. 11.03.05 04:10
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
и от SQL. Т. е. база должна содержать не таблицы и запросы к ним, а объекты "работник", "склад", "полка" и т.п. Их свойств и методов: Работник.Зарплата.Получить(сумма), Склад.Полка[n]->ВзятьГвоздь(количество).
|
| | | |
Персистентные объекты это хорошо 11.03.05 11:13
Автор: amirul <Serge> Статус: The Elderman
|
> и от SQL. Т. е. база должна содержать не таблицы и запросы
> к ним, а объекты "работник", "склад", "полка" и т.п. Их
> свойств и методов: Работник.Зарплата.Получить(сумма),
> Склад.Полка[n]->ВзятьГвоздь(количество).
Но прелесть баз данных не в том что они могут ХРАНИТЬ данные, а в том, что они могут хранить ОЧЕНЬ МНОГО данных и предоставлять методы БЫСТРОГО поиска среди этих данных. В целом мне кажется что ОО БД должна осуществлять откладывание запроса настолько, насколько это вообще возможно и собирать все это время данные
|
| |
Для того, чтобы сделать что-то новое, нужно возненавидеть старое — поэтому автор и ругается. А учиться, молодой человек, вам и самим не помешает... ;-) 10.03.05 08:56
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 10.03.05 09:28 Количество правок: 1
|
|
|
|
Те, кто ругают ООП, не предлагают взамен более достойной альтернативы. 14.11.04 15:07
Автор: Den <Денис Т.> Статус: The Elderman
|
Так, или иначе программисты всегда использовали то, что сейчас называется объектом. Я имею ввиду множество экземпляров структур данных (объекты), над которыми производились идентичные операции (методы объектов), и рождение ООП было предрешено как наиболее отвечающее принципам программирования. Конечно, некоторые детали концепции ООП требуют пересмотра, но не в коем случае не упразднения всей концепции в целом.
Известно, что объекты не содержат таблицы статических функций и если объект не использует другие типы функций, то в памяти он выглядит как обычная структура данных и лишь компилятор и разработчик знает где структура, а где объект; где функция, а где метод объекта.
По поводу черного ящика.
Куда не ткнись, везде один большой "черный ящик". ОС, SQL сервер, файловая система и т.д., для прикладного программиста - "черный ящик". Разница лишь в том, что для этих "черных ящиков", обычно, совершенно четко задана область применения, выражаясь математическим языком - "Область Определения Функции", а также есть достаточно подробное описание интерфейса с примерами. Если подобным образом описывать все классы объектов, то прикладному программисту не понадобиться заглядывать в черный ящик. Ведь вряд ли кому-либо из прикладных программистов придет в голову изучать код MS OLEDB, только потому, что он не знает как это все работает.
Могу сказать по своему опыту, что даже когда пишу на ассемблере, то некоторые вещи мне проще и удобнее реализовывать некоторым подобием объектов, так как это сокращает мне время разработки, позволяет качественно повысить потенциал использования кода в дальнейшем без внесения существенных изменений, сократить объем готового приложения и многое другое.
|
| |
Насколько я понимаю, речь не о том, что объекты - это плохо 14.11.04 23:57
Автор: Ktirf <Æ Rusakov> Статус: Elderman
Отредактировано 15.11.04 00:07 Количество правок: 2
|
Речь скорее о том, что у объектного подхода, как и у любого другого, есть своя область применимости. Если бы объектный подход был универсален, «все» писали бы на Smalltalk. Однако «все» почему-то пишут на C++/Java, которые не отличаются строгостью реализации объектной парадигмы.
Ведь объекты — это далеко не только сокрытие деталей реализации за интерфейсом. И далеко не только наследование, полиморфизм. Модули появились еще до ООП, и отлично использовались для инкапсуляции. Указатели на функции тоже появились до ООП. Вложенные структуры как способ «наследования» — тоже вполне нормальная вещь. Тем не менее писать по-настоящему объектно-ориентированные программы почему-то не любят. Видимо, человек все же в большей степени мыслит алгоритмически, а алгоритмическое мышление скорее ближе структурному программированию, чем ООП.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
