Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
U-geneСкажите, почему же Вы тоже самое не скажете про ОО-системы программмирования, раз уж они так же являюься системами маппинга объектов в ОЗУ? Скажу: классы фактически отображаются на массивы структур (а те в свою очередь на ОЗУ). U-geneИли Вы ОО-языками программирования не пользуетесь принципиально? Имхо ООП - это стиль процедурного программирования, а выбор стиля - личное дело программера или компании. Лично мне объекты не нужны, мне больше подходят массивы, списки, таблицы, структуры и.т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 11:56 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
U-gene...и кстати - что такое - объект РМД? извините, элемент РМД (отношения) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 11:59 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
U-gene...и кстати - что такое - объект РМД? извините, элемент РМД (отношения) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 12:02 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
Имхо ООП - это стиль процедурного программирования... Ну это кому как :) Для меня ООП - приемлемая возможность использовать переменные необходимых мне типов (при необходимости описывая эти типы) . Лично мне объекты не нужны, мне больше подходят массивы, списки, таблицы, структуры и.т.д. Меня не прокидает осщущение, что Вы постоянно путаете реализуемую систему (где ИМХО полезмо мыслить с ОО-стиле) и уже реализованную систему (где речь идет о переменных одного из реализованных типов). Кстати, в связи с этим возник вопрос - есть два значения отношения с разными схемами. Это значения разных типов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 13:15 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
U-geneДля меня ООП - приемлемая возможность использовать переменные необходимых мне типов (при необходимости описывая эти типы) . Для этого достаточно С. U-gene Меня не прокидает осщущение, что Вы постоянно путаете реализуемую систему (где ИМХО полезмо мыслить с ОО-стиле) и уже реализованную систему (где речь идет о переменных одного из реализованных типов). Не очень понял, но реализуемая и реализованная системы это одно и то же поскольку любая система развивается. Но последовательность мысли всегда одна: сущности -> формальная модель->операции с ней->результат->сущности U-gene Кстати, в связи с этим возник вопрос - есть два значения отношения с разными схемами. Это значения разных типов? если два отношения имеют разные схемы - то это разные типы данных и их значения тоже разных типов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2006, 15:50 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
по поводу манифеста Ю-Ген а с этой книгой ты знаком? теория хранения и поиска информации http://c-books.info/books/rapid1/index59.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 01:46 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
по м оему, хорошая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 04:14 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2006, 04:23 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
2.1. Эволюция объектной модели Тенденции в проектировании Поколения языков программирования. Оглядываясь на короткую, но колоритную историю развития программирования, нельзя не заметить две сменяющих друг друга тенденции: * смещение акцентов от программирования отдельных деталей к программированию более крупных компонент; * развитие и совершенствование языков программирования высокого уровня. http://www.hardline.ru/1/5/1390/1789-4.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2006, 03:17 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
Интервьюер - далее И., Stroustrup - далее C.. И. Прошло несколько лет с тех пор, как Вы изменили мир разработки программного обеспечения. Что Вы теперь чувствуете, оглядываясь назад? C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните - все писали свои версии 'C', и проблема была в том, что все это делали чертовски замечательно. Университеты тоже чертовски замечательно преподавали этот язык. Это привело к понижению компетенции. Под 'компетенцией' в данном случае я подразумеваю феноменальность. Вот что породило проблему. И. Проблему? C. Да, проблему. Помните когда все писали на Cobol? И. Конечно, я тоже это делал. C. Ну вот, в начале эти ребята были как боги. Им платили кучу денег и относились как к королям. И. Да уж, вот это были времена... С. Именно. Ну и что же случилось? IBM прямо заболела этим и вложила миллионы в подготовку программистов, пока их не стало до ужаса много. И. Вот так и я вылетел из этой сферы. Втечение года зарплата упала настолько, что даже журналистом можно было зарабатывать больше... С. Точно. То же самое случилось и с программистами, писавшими на 'C'. И. Понятно, ну и что же Вы все-таки хотите этим всем сказать? C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка, как хоть немного восстановить баланс. Я подумал: интересно, что произойдет, если будет язык программирования такой запутанный и такой сложный для изучения, что никто бы уже не сможет заполнить рынок толпой программистов, пишуших на этом нем? У меня уже были тогда кое-какие мысли по этому поводу. Вот, знаете наверно, X10 и X windows. Это тогда была такая графическая система, которая работала на Sun 3/60. У нее были все ингредиенты, которые мне были нужны - комплексный синтаксис, сложные для понимания мрачные функции, псевдо объектно-ориентированная структура. Даже сейчас никто не пишет напрямую под X-windows. Motif - единственный путь, если вы хотите сохранить рассудок. И. Шутите? C. Ничуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то, что любой программист, пишущий на 'C', мог очень легко стать системным программистом. Помните сколько обычно зарабатывали большинство системных программистов? И. Да, я же ведь тоже этим занимался. С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда ребята, знающие только DOS, тоже смогли бы прилично зарабатывать. И. Не верится в то, что Вы это сказали... С. Это уже происходит достаточно долго, но вроде сейчас большинство людей уже уяснили для себя, что C++ - это пустая трата времени, но должен сказать, что осознание этого происходило дольше чем я ожидал. И. Ну расскажите поточнее, как же Вы все-таки сделали это? C. Это была просто шутка, я никогда не думал, что люди воспримут эту книгу всерьез. Любой человек, даже с половиной мозга, может понять что объектно-ориентированное программирование интуитивно, нелогично и неэффективно. И. Что? С. И относительно 'повторно-используемого кода' - Вы когда-нибудь слышали, чтобы хоть одна компания 'повторно-использовала' что-либо? И. Ну, вообще-то не слышал, но... С. Вот так-то. Некоторые, кстати, пытались. Была такая компания из Орегона - Mentor Graphics, в которой просто заболели тем, что пытались переписать все что можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но думаю, что люди по крайней мере, научились чему-то на их ошибках. И. Очевидно у них ничего не вышло? С. Вообще ничего. Но было бы сложно объяснить держателям акций компании ущерб в 30 миллионов долларов и вот, надо отдать им должное , они все-таки заставили это работать в итоге. И. Так все-таки у них получилось? Это доказывает что 'объектное-ориентирование' работает. C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут на рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет камнем преткновения, но это никого особенно не заботило. Sun и HP были очень рады продавать до ненормальности мощные ящики с огромными ресурсами для выполнения на них тривиальных программ. Знаете, когда мы в AT&T откомпилировали нашим первым компилятором C++ программку 'Hello World', я не мог поверить своим глазам: запускаемый файл получился размером 2.1Mb. И. Да уж... Но компиляторы с тех пор прошли долгий путь. C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней версией g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще множество примеров со всего мира. У British Telecom чуть было не возникли большие проблемы, но к своему счастью они вовремя догадались свернуть проект и начать все заново. И им больше повезло, чем Australian Telecom. А теперь я слышал, что Siemens cоздает какого-то динозавра и все больше и больше волнуется по поводу размера того, что у них получается. Не правда ли забавно смотреть на это всеобщее заблуждение? И. Да, но C++ -то, в общем, вполне нормальный язык. С. Вы в это так верите? Попробовали ли вы когда-нибудь сесть и поработать над проектом на C++ ? Во первых, я расставил достаточно ловушек, чтобы просто так работали только тривиальные проекты. Под конец проекта получается что одни и те же операторы в разных модулях означают совершенно разные вещи. А теперь попробуйте соединить все эти модули в единое целое, особенно если у вас их штук 100. Боже, я иногда не могу удержаться от смеха, когда слышу о проблемах разных компаний, которые не могут сделать так, чтобы их модули общались между собой. И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы сказали что сделали это для того, чтоб повысилась оплата труда программистов. Но это же бессмыслица. С. Не совсем так. У каждого есть его выбор. Я не предполагал, что все это так выйдет из-под контроля. Но все-равно, практически все у меня получилось. C++ cейчас уже умирает, а труд програмистов продолжает нормально оплачиваться - особенно тех, кто имеет дело со всей этой чепухой - вы же понимаете, что невозможно использовать эффективно большой программный модуль на C++ , если не вы сами его написали. И. Как это? С. Не понятно что-ли? Помните typedef ? И. Конечно. С. А теперь вспомните сколько времени приходится копаться в заголовках для того, например, чтобы просто найти, что какое-нибудь там 'RoofRaised' - число с двойной точностью. Представьте теперь сколько времени уйдет на нахождение всех определений типов в большом проекте. И. Значит, Вы утверждаете, что Вам все, что Вы хотели удалось... C. Ну, вспомните сколько занимает реализация проекта среднего размера на 'C'. Это около 6 месяцев. Не достаточно долго чтобы парень с женой и детьми мог заработать себе на нормальное существование. Попробуйте тот же проект реализовать на C++ , и что получится? Вам понадобится 1-2 года. Не правда ли, это замечательно? Кроме этого: в университетах уже так давно не преподают 'C', что теперь стало мало людей программирующих на 'C', особенно таких, которые знают все о программировании под Unix. Как вы думаете : сколько парней смогут сообразить что делать с 'malloc' , после того как втечение многих лет они пользовались 'new' и никогда не заботились о проверке кода возврата? Большинство программистов на C++ вообще не выбрасывают этот код возврата. Что произошло со старой доброй '-1' ? По крайней мере было сразу понятно, что у тебя где-то ошибка без всяких там 'throw', 'try' и 'catch'... И. И все же, наследование экономит кучу времени? С. Нет, я же говорил... Замечали, в чем разница между стадиями планирования проектов на 'C' и C++ ? Для проекта на C++ эта стадия в три раза дольше. Время уходит на то, чтоб убедиться что все что надо наследуется, а все что не надо - нет. И все-равно без ошибок не обходится. Кто слышал когда-нибудь об утечке памяти в программе на 'C' ? Теперь нахождение этих утечек - целый труд. Большинство компаний сдаются, так и выпускают продукт, зная что утечка памяти существует. И. Но есть различные программные инструменты... С. Большинство из которых написаны на C++. И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ? C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Ни одна компания без предварительного тестирования теперь не начнет проект на C++, а если будет тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так им и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на C++. И. О Боже. И что же он сказал? C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и Brian понимали что я тогда делал. Он ответил, что может мне помочь написать версию DOS на C++, если я захочу. И. Ну и как? Вы захотели? С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20 в другой комнате. Просто летает на четырех процессорах и занимает всего то 70 мегабайт на диске. И. На что же это похоже на PC ? С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем величайшем успехе. И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может сидеть парень, которому придет в голову сделать это... С. Но не после того, как он прочитает это интервью. И. Я сожалею, но врядли мы сможем опубликовать даже часть этого интервью. С. Но это же история века. Я просто хотел чтоб мои приятели-программисты помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается программирование на C++ ? И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в час. С. Понимаете теперь? И я уверен, что он заслуживает этих денег. Отслеживание всех этих ловушек, которые я встроил в C++ - не легкая работа. И, как я говорил раньше, каждый программист на C++ чувствует себя связанным тем обстоятельством что он должен использовать каждый элемент языка в каждом проекте. Вообще это и меня часто раздражает, даже тогда, когда это служит моим целям. Но сейчас, когда прошло столько времени, мне уже начинает нравиться этот язык... И. Имеете ввиду, что раньше Вам C++ не нравился? С. Ненавидел его. Он даже выглядит неуклюже, вы не согласны? Но когда стали там выходить разные книги... вот, тогда-то я и увидел полную картину. И. Погодите, а как насчет ссылок? Вы подтверждаете что улучшили указатели 'C' ? С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с парнем, который писал на C++ с самого начала. Он говорил, что не мог запомнить были ли ссылки на его переменные или нет, поэтому он всегда использовал указатели. И. Обычно на этой стадии я говорю 'большое спасибо за интервью', но сейчас это как-то не к месту. С. Пообещайте мне, что опубликуете это. И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по этому поводу. С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию этой записи? И. Это я могу. Примечание переводчика : Я не программирую на C++. Я не являюсь знатоком русской словестности. Посему прошу извинения за возможные ошибки в переводе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2006, 13:15 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
мод tchingizпока не написать обьект поле, обьект запись, обьект таблица и обьект базаданных. я же могу сделать обьект база данных, в котором таблицы будут полями базы, а операторы select, delete, insert, update - методами таблиц? Конечно можно просто подменить термины, но от этого РМД не изменится и проблема останется: сущности моделируются соответствующими классами а классы придется отображать в РМД, затем манипулировать объектами РМД, а вот результат обратно в классы и сущности не преобразовывается. Поэтому лучше сразу работать с РМД, объекты лишние. не допонял про подмену терминов. РМД не изменится. согласен. Согласно реляционной модели данных результат манипулирования будет отношение (таблица по рабоче-крестьянски). Я предложил считать таблицу - обьектом, согласно следующему определению. любое поименованное множество - тип данных. На множестве всех типов данных вводим отношение наследования (в некотором языке программирования Л). если два типа данных находятся в отношении наследования Л, то эти типы называются классами. Любой элемент класса называется обьектом. Берем класс виртуальную таблицу T, таким образом, что бы там были определены методы select, insert, delete, update. например в http://users.iptelecom.net.ua/~agp1/ru/gsau.html 5.6. Описание нового типа данных Relation. /* Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. потом наследуешь конкретную таблицу, например, в 5.4. Описание таблицы типа TPump. если берем этого класса, t: TPump, тогда можно писать t.delete(ids), где id: Key:set - множество значений первичных ключей (для некоторого абстрактного класса Key). см. например, в раздел 5.3.2. Использование оператора DELETE. То есть ничего никуда преобразовавать не надо. Любая конкретная таблица - это обьект класса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2006, 05:53 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
2eys Интересно, но... НЕ ВЕРЮ, вот в это - Stroustrup - далее C !!! Ссылку на первоисточник можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2006, 01:24 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
это шутка /topic/16555&hl=%e8%ed%f2%e5%f0%e2%fc%fe ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2006, 03:50 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
tchingizесли два типа данных находятся в отношении наследования Л, то эти типы называются классами. это не понял. тип decimal наследник типа number и кто здесь класс ? Конечно можно назвать все множество любых таблиц классом, каждую таблицу объектом а реляционные операторы методами, но это просто игра терминами ничего не меняющая по сути. Подход ООП в том чтобы разные сущности моделировать разными классами (а не одним !) отказавшись при этом от РМД за ненадобностью ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2006, 10:03 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
класс будет родитель и наследник. они же оба состоят в отношении наследования. авторПодход ООП в том чтобы разные сущности моделировать разными классами (а не одним !) отказавшись при этом от РМД за ненадобностью ну если именно в этом состоит подход ооп, то я с Вами согласен. отказываться от рмд смешно. вот у меня статья 1994 года. http://users.iptelecom.net.ua/~agp1/ru/kbd.html я там в рмд располагал описание географических обьектов. я тогда говорил - это обьект и сейчас говорю это обьект. в борланде с++ (шобы не соврать, может уже забыл) были написаны обьект для работы с ней. по крайней мере сейчас. я могу написать класс географический_обьект, а из него классы наследовать географический_обьект_дорога, географический_обьект_фонарь и т.д. ))))) согласен считать, что мой подход (как следует из Вашего тезиса) не будет называться ооп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 02:15 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
ээ. уточнить решил. а обьект класса географический_обьект читает/пишет свое описание из/в реляционной базы данных, используя ранее упомянутые обьекты таблица, запись и поле. не усматриваю особых проблем моих обьктов с рмд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 02:30 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
tchingizа обьект класса географический_обьект читает/пишет свое описание из/в реляционной базы данных, используя ранее упомянутые обьекты таблица, запись и поле. не усматриваю особых проблем моих обьктов с рмд. Проблема в том что объект (в вашем случае географический) существует только на время выполнения программы, т.е. при каждом запуске программы надо выполнять конструкторы, т.е создавать "новые" объекты. Но это логически неверно, ведь объекты уже были когда-то созданы и сохранены (в виде таблиц) в РБД. Поэтому имхо гораздо логичнее считать что существует не объект а его информационная модель в РБД и работать не методами объектов а операциями с таблицами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 09:57 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
Какой-то тухлый разговор :) модПодход ООП в том чтобы разные сущности моделировать разными классами (а не одним !) отказавшись при этом от РМД за ненадобностью С первой половиной фразы я, может быть, и соглашусь. Но связи между первой и второй половиной не вижу. Вторая половина - это ИМХО широко распространенное (к сожалению), абсолютно идиотское и никем не обоснованное утверждение. На самом деле всё наоборот - РМД вполне может сосуществовать с описанием сущностей в виде классов. Возращаясь немного назад.... модИмхо ООП - это стиль процедурного программирования, а выбор стиля - личное дело программера или компании. Лично мне объекты не нужны, мне больше подходят массивы, списки, таблицы, структуры и.т.д. Не понимаю - а какая связь (или противоречие) между процедурным программированием (хотя бы и ООП, хотя на самом деле это вообще разные вещи) и "массивами, списками, таблицами, структурами и.т.д". Объекты Вам не нужны? да и ради бога. Но ведь переменными то (списками, массивами, таблицами и тд) Вы же пользуетесь? Ведь списки, массивы, таблицы итп - это же так или иначе есть не что иное как переменные, правда?... модНе очень понял, но реализуемая и реализованная системы это одно и то же поскольку любая система развивается....Вот я про это и говорю. Это не одно и тоже. Под системой я подразумеваю набор переменных уже реализованных типов. А ООП предлагает подход к реализации типов. А если типы (массивов, списков и тп) уже реализованы - естественно ООП не нужно :). Переменные (объекты) описаны - можно пользоваться. Далее... мод...если два отношения имеют разные схемы - то это разные типы данных и их значения тоже разных типов То есть получается, что, что в результате некой предопределёной операции (например декартово произведение) над значениями в системе может появиться значение нового типа? В РМД нет отдельно взятых операций над схемами. Существуют только опреации над отношениями. Конечно , когда долго общаешся с SQL СУБД может возникнуть впечатление, что де можно манипулировать схемой. Например когда мы добавляем в таблицу столбец, кажется, что мы манипулируем схемой. Однако, с позиций РМД мы просто выполнили декартово произведение. Отношение (= значение) состоит из заголовка и тела. Исходя из этого можно предполагать, что заголовок - это тоже значение. Хоть и мета... ,а все же ...данные. :). Другими словами любые значения отношений с любыми заголовками принадлежат одному и тому же типу. Это так или иначе подтвердждаете Вы сами, когда говорите, что "можно назвать множество любых таблиц классом ". То есть любые таблицы есть переменные(объекты) одного и того же типа(класса). Что же касается операций, когда требуется ,что бы заголовки операндов совпадали, так это просто ограничение на значение.... например в арифметике есть такое ограничение "делить на нль нельзя". Здесь возможность(невозможность) выполнения операции зависит от значения. Точно так же вопрос "совпадают ли заголовков" есть вопрос сравнения значений отношений, точнее той их части, которая описывает схему, но не вопрос сравнения типов . Это все я к тому, что описывая схему данных в терминах РМД Вы не создаете новые типы. Вы пользуетесь уже реализованной системой, которая реализует модель данных (т.е. в этой системе модель данных уже реализована). А ООП нужно, не когда мы пользуемся реализованной системой, а когда мы ее только реализуем . Возвращаясь еще дальше назад.... мод U-gene модно от этого РМД не изменится и проблема останется: сущности моделируются соответствующими классами а классы придется отображать в РМД, затем манипулировать объектами РМД, а вот результат обратно в классы и сущности не преобразовывается. Поэтому лучше сразу работать с РМД, объекты лишние. Скажите, почему же Вы тоже самое не скажете про ОО-системы программмирования, раз уж они так же являюься системами маппинга объектов в ОЗУ? - а именно (перефразирую Вас применительно к соотношения ОО-систем и оперативной памяти, с некоторыми моими дополнениями) ...но от этого ОЗУ не изменится и проблема останется: сущности моделируются соответствующими классами а классы придется отображать в ОЗУ, затем манипулировать объектами ОЗУпусть это будут ячейки памяти :), а вот результат обратно в классы и сущности не преобразовывается. Поэтому лучше сразу работать с ОЗУ(т.е.пользовать ассемблер), объекты лишние....: Скажу: классы фактически отображаются на массивы структур (а те в свою очередь на ОЗУ).УПС..... но тогда почему же вы говорите (продолжаю перефраз) модПодход ООП в том чтобы разные сущности моделировать разными классами (а не одним !) отказавшись при этом от ОЗУ за ненадобностью.... Никто же не собираетесь отказываться от ОЗУ... ну потому что ООП без ОЗУ ну никак не реализовать То есть "маппинг" я использую Вашу интетерепацию этого термина, хотя ИМХО он здесь мягко говоря ни к чему...хотя может быть это я в маппинге не разбираюсь "объектов в ОЗУ" является вещью никаких проблем не вызывающей, а вот маппинг объектов в реляционные структуры вдруг стал проблемой. Почему? Может быть этот самый "маппинг" из объектов в отношения какой то не такой, какой нужно? То есть "маппинг объектов в ОЗУ" удался (явно удался, даже если ООП Вам и не нужно), но с маппингом объектов в отношения как то пока не сраслось. Хорошо, а Вы поможете мне с маппингом разобраться?... Начнем с маппинга объектов в отношения. Моему мысленному взору рисуется следующая картина. В процессе релизации системы кто-то и как-то замутил это самый маппинг. И вот система реализована . В ней существуют переменные (которые описывались в процессе реализации как объекты) и благодаря маппингу данные из этих переменных аутоматично распихиваются по где-то там существующим в РБД таблицам и потом собираются обратно в переменные системы. То есть если мод...объект (в вашем случае географический) существует только на время выполнения программы, т.е. при каждом запуске программы надо выполнять конструкторы...... то система маппинга так или иначе позволет не фиксироваться в процессе описании переменных(объектов) на распихивание данных из этих объектов в таблицы и, затем, при восстановлении объекта, на вызове конструкторов, собирающих данные из таблиц и других т.п. вещах и проблемах, возникающих при взаимодействии программы с БД? Скажите, правильно ли я понимаю, что именно этим и занимается маппинг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2006, 20:42 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
2 U-gene вы так много написали не знаешь на что и отвечать но попробуем U-gene РМД вполне может сосуществовать с описанием сущностей в виде классов. это надо бы доказать U-gene Ведь списки, массивы, таблицы итп - это же так или иначе есть не что иное как переменные, правда? не совсем. надо различать тип данных массив и переменную этого типа. U-gene Под системой я подразумеваю набор переменных уже реализованных типов. А ООП предлагает подход к реализации типов. Возможность создавать свои типы появилась задолго до ООП и не имеет к нему никакого отношения. U-gene То есть получается, что, что в результате некой предопределёной операции (например декартово произведение) над значениями в системе может появиться значение нового типа? да, может появиться отношение нового типа. U-geneВ РМД нет отдельно взятых операций над схемами. А DDL ? create table xxx as select ..... U-geneЭто все я к тому, что описывая схему данных в терминах РМД Вы не создаете новые типы. каждая новая таблица это новый тип данных наследник общего типа таблица U-gene система реализована . В ней существуют переменные (которые описывались в процессе реализации как объекты) и благодаря маппингу данные из этих переменных аутоматично распихиваются по где-то там существующим в РБД таблицам и потом собираются обратно в переменные системы. В том то и дело что не аутоматично (в отличие от ОЗУ). Это все придется программировать для каждого класса отдельно. Только вот зачем все это? Какие цели преследуем ? Сохранить ООП как религию ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 09:48 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
.... Я то думал автор U-gene Под системой я подразумеваю набор переменных уже реализованных типов. А ООП предлагает подход к реализации типов. Возможность создавать свои типы появилась задолго до ООП и не имеет к нему никакого отношения.Я нигде не говорил, что до ООП такой возможности не было. Более того - я говорил обратное. И там же я говорил, что ООП всего лишь более удобен по ряду причин - но это значительные удобства. мод U-gene То есть получается, что, что в результате некой предопределёной операции (например декартово произведение) над значениями в системе может появиться значение нового типа? да, может появиться отношение нового типа. Нет это не новый тип.ответ в вашем стиле:). Я уже сказал, что иная схема не означает иной тип - это просто иное значение. мод U-geneВ РМД нет отдельно взятых операций над схемами. А DDL ? create table xxx as select ..... В огороде бузина(РМД) в Киеве дядька (SQL). Еще раз повторяю - в РМД нет операций над схемами. С точки зрения РМД выполнена предопределнная операция проекции над значением отношения - и все. А с точки зрения системы создана новая переменная позволяющая хранить значение предопределенного типа relation, и это все тот же тип и никаких новых типов при этом не создается. мод U-geneЭто все я к тому, что описывая схему данных в терминах РМД Вы не создаете новые типы. каждая новая таблица это новый тип данных наследник общего типа таблица ...идея ясна, но аргументов нет. мод U-gene система реализована. В ней существуют переменные (которые описывались в процессе реализации как объекты) и благодаря маппингу данные из этих переменных аутоматично распихиваются по где-то там существующим в РБД таблицам и потом собираются обратно в переменные системы. В том то и дело что не аутоматично (в отличие от ОЗУ). Это все придется программировать для каждого класса отдельно. ...если не аутоматично, то это тупое ручное кодирование процесса сохранения данных в СУБД и восстановления их оттуда. Никакой системой маппинга тут вообще не пахнет. То есть когда речь заходит о маппинге, что ИМХО идея в том, что бы как то облегчить этот тупой ручной труд. Но я спрашивал в общем то не о том, насколько аутоматичен этот процесс. Основная цель - уточнить, что маппинг так или иначе подразумевает перенос данных из объектов в СУБД и обратно. Это так? модТолько вот зачем все это? Какие цели преследуем ? Сохранить ООП как религию ? Всего лишь как удобный подход. мод U-geneРМД вполне может сосуществовать с описанием сущностей в виде классов. это надо бы доказать Доказать вряд ли, поскольку ООП есть лишь набор идей, но показать могу... я же уже два разворота предлагаю сделать это, но Вам коньяк жалко что ли...:)....тем более, что вы верны, что это невозможно и сдледовательно, должны быть уверены в том, что ничем не рискуете...И потом - исходя из того, как лихо Вы агрументируете фразы про РМД выряжениями на SQL , я опасаюсь, что эта демонстрация может быть Вам не совсем очевидна....:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 11:18 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
Работающая ссылка на то, где и что я говорил, про сохдание переменных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 11:20 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
давайте о главном U-geneОсновная цель - уточнить, что маппинг так или иначе подразумевает перенос данных из объектов в СУБД и обратно. Это так? Да. При этом я считаю это лишним преобразованием, не дающим никаких преимуществ, но вызывающим логические несуразности типа неоюходимости создания уже существующих объектов. Собственно этого вполне достаточно для того чтобы не использовать ООП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 11:38 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
моддавайте о главном Не видать мне коньяка мод U-geneОсновная цель - уточнить, что маппинг так или иначе подразумевает перенос данных из объектов в СУБД и обратно. Это так?Да. При этом я считаю это лишним преобразованием, не дающим никаких преимуществ, но вызывающим логические несуразности типа неоюходимости создания уже существующих объектов. Собственно этого вполне достаточно для того чтобы не использовать ООП. Подождите-подождите. Я еще с маппингом не разобрался. Дело в том, что Вы тут сказали,что де объекты в ОЗУ -это тоже маппинг. Но ведь перенос информации из объетов в ОЗУ не происходит. Итак - есть набор простейших перменных, логически сгруппированных в виде объектов. Это ОО система. Есть набор простейших перменных, логически сгруппированных в виде отношений. ЭТО РБД. При маппинге происходит перенос данных из одного набора простейших переменных в другой набор. А "маппинг объектов в ОЗУ", это никакой не маппинг и никакого переноса данных тут нет - это просто логическое представление данных. Это я к тому, что может быть ООП вообще ни в чем не виновато? То, в чем вВы его обвиняете - это всего лишь проблемы обмена данными? Тоесть если данными не обмениваться, то все глядишь и получится. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 12:08 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
U-geneЭто я к тому, что может быть ООП вообще ни в чем не виновато? То, в чем вВы его обвиняете - это всего лишь проблемы обмена данными? Тоесть если данными не обмениваться, то все глядишь и получится. :) Для этого необходим автомат (транслятор-компилятор), который любой класс отображает по заданному правилу в РМД - это можно сделать и это уже сделано. А вот наоборот - РМД в классы не получается. И вся конструкция падает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 12:43 |
|
||
|
Будь моя воля, я бы ООП вообще запретил!
|
|||
|---|---|---|---|
|
#18+
модДля этого необходим автомат (транслятор-компилятор), который любой класс отображает по заданному правилу в РМД - это можно сделать и это уже сделано. Отображать в общем то ничего и не надо. Всего то и надо - описывая значения, определяющие состяние объекта, пользоваться типами, допустимыми в РМД (т.е. использовать типы-скаляры и тип-отношение)....Ну вот - я уже наговорил на бутылку пива :) модА вот наоборот - РМД в классы не получается. А раз туда не надо, то и обратно - оно само собой получается. Правда. мод И вся конструкция падает. дык....я же сказал - они просто не сумели ее правильно приготовить. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2006, 23:32 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=33794350&tid=1346688]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
1ms |
| others: | 265ms |
| total: | 436ms |

| 0 / 0 |
