Опять мимо. Сегодня явно не твой день. Кстати у Оракла тоже есть nosql бд. К чему бы это?

Это сообщение отредактировал(а) k0rvin - 19.4.2013, 18:01

Для всех живых языков библиотеки есть, что намекает на ненужность Делфи.


Эм, ну да, ты упомянул «проблему всея ООП», я показал, что вовсе не всея. И что значит другая идеология? Всё то же ООП.

Добавлено через 7 минут и 9 секунд
http://redis.io/clients
http://docs.mongodb.org/ecosystem/drivers/
http://wiki.apache.org/cassandra/ClientOptions
http://wiki.apache.org/couchdb/Related_Projects

И ни одного упоминания Делфи. =)

Кстати там же в англовике:

Собственно возникает вопрос: какие современные ООП-языки позволяют при наследовании получить доступ к приватным членам суперкласса?

Это сообщение отредактировал(а) k0rvin - 19.4.2013, 18:19

Скорее ты плохо искал. Что впрочем не отменяет незначительности использования данных типов БД.



Дорогой мой, я тебе дал проблему, кстати, для меня достаточно очевидную, т. к. 100500 вопросов встает даже при проектировании несложного класса или дерева классов. Да и вообще любой библиотеки. И нигде не сказано, что эта проблема типична для какого-то одного языка. Объектные модели OP, C++, Java, и т. п. языков мало отличаются друг от друга, везде есть дерево наследования, такие детали как наличие множественного наследования, виртуальные конструкторы, порядок работы конструкторов и т. п. принципиально ничего не меняют. И самое главное, то что существует в этих языках принято называть ООП. Ладно, пусть будет ООП, а C++ пророк его. В конце концов мы пишем на этих языках, а не на СмоллТолке. Если в СмоллТолке используется какое-то свое ООП, где нет такого, что настроили дерево классов, попилили корень, оно и упало, или, например, вообще нет наследования, то тогда вопрос, а что же тогда вообще ООП? Может традиционные процедурные языки его и не имеют и существующие в них ссылочные структуры под название класс, хотя стоп, традиционные объекты Object Pascal'я, которые и в Delphi есть, и даже применяются в KOL вообще не ссылочные. В общем может никакого ООП ни в плюсах, ни в Паскале вообще нет, а есть только ссылочные и не очень структуры с методами и наследованием?   За "настоящим" же ООП в SmallTalk.

Это сообщение отредактировал(а) Beltar - 19.4.2013, 18:49

Лол, тебе совсем плохо что ли?


Ну ваш хваленый Torry.net молчит.


Т.е. ты мое сообщение про список юзеров просто проигнорировал? Так вот, я тебя огорчу, NoSQL DB используют намного больше, чем Делфи, и популярность этих БД только растет, в отличие от.


А я тебе дал решение этой проблемы, а так же цитату с вики.


Нет, в СмоллТоке используется вполне обычное ООП. Которое легло в основу например Objective-C и Ruby. И, внезано, «influenced by Pascal, Smalltalk».


Ты бы сам для начала прочитал, в чем «проблема», как она решается:

И как она решается в некоторых популярных языках: http://en.wikipedia.org/wiki/Fragile_base_class#Solutions
Упс, опять Делфи не упомянули. В СмоллТоке же вообще у объектов нет публичных полей, только методы.

Добавлено через 3 минуты и 34 секунды
Ну может английский трудности вызывает? Цитата с русской вики (важную часть я выделил, подумай):

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



В смысле дернуть унаследованный метод? В Delphi обычная практика в конструкторе\деструкторе, хотя как до родоначальника всей иерархии добраться я не скажу, наверное, можно как-то, в плюсах вроде никак, про Java, C# не знаю.

Гугл говорит, что на 2011-ый было для MongoDB пара драйверов, один на ранней стадии. Я что-то не врубился на его сайтике, что там качать. Вывод, MongoDB не такая пропащая.   

Это сообщение отредактировал(а) Beltar - 19.4.2013, 19:29

Думаю имеется в виду protected. Которого, кстати в СмоллТоке нет =)

Но вообще это похоже просто на какой-то фейк или хз что. Рассмотрим три ситуации:

1.

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

2.

Но, во-первых, protected есть не везде, а во-вторых, с для унаследованного класса protected-члены базового являются его (базового класса) публичным интерфейсом (это равносильно переменной уровня модуля в любом другом языке). Поэтому смотрим третью ситуацию:

3.

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

Это сообщение отредактировал(а) k0rvin - 19.4.2013, 19:34

Ситуация, есть некий класс в котором определен метод сортировки пузырькового типа, от него наследуемся 100500 раз. Пузырьковая сортировка хоть и тормозная, то никаких аварийных ситуаций не создаст. Меняем в базовом классе пузырьковую сортировку на быструю и какой-то наследник удумавший отсортировать унаследованным методом 10000 элементов улетает в Stack overflow.

Теперь пишем на любом другом языке, хоть на том же обычном паскале, функцию сортировки, используя метод пузырьковой, описываем 100500 функций, использующих ее. Меняем реализацию функции сортировки на быструю и какая-то другая функция, использующая ее, удумавшая отсортировать 10000 элементов улетает в Stack overflow.

Внимание вопрос: при чем тут ООП?

Русская педивикия что пишет:


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

Проблема хрупкого базового класса сильно снижает ценность наследования.

В общем случае проблема не решаема, и является одним из существенных недостатков ООП.

Проблема может быть обобщена и на системы, разработанные не на ООП языках, и не использующие понятие «класс». Любое повторное использование готового кода (без копирования) как части нового кода может повлечь за собой такую проблему.

В современных парадигмах программирования, разработанных под влиянием ООП, используются понятия «связи» и «связность», и качество дизайна определяется управлением связями, что, в частности, подразумевает под собой ослабление связей. Наследование же в понимании ООП создает сильнейшую возможную связь, и, таким образом, должно использоваться с большой осторожностью.


Это сообщение отредактировал(а) Beltar - 19.4.2013, 20:22

значит есть к чему стремиться   

Еще раз перечитай мое сообщение выше и попробуй ответить на вопрос.

На колу мочало, начинем ср... спор сначала.   

Сложный спор, одного понять немогу, а что? Класс создать сложно? Это все ровно что сделать колбасу.

Это сообщение отредактировал(а) Freyzer - 20.4.2013, 04:46

Нет, все-таки давай малость вернемся назад и вспомним из-за чего мы снова начали это обсуждать. Ты написал, что в дельфях в 2002-м году уже было все, к чему другие приходят только сейчас. Теперь ты уже говоришь, что в дельфях есть перспективная технология, которая в случае если эмбаркадера вложит в нее кучу бабла(а вряд ли она сможет вложить больше майкрософта), то тогда это, возможно, станет чем-то, что можно будет как-то сравнивать с впф. Ну не знаю, можно будет или нет: впф - как я уже сказал, не только векторная графика и аппаратное ускорение, там много новшеств, я например, пока толстую книжку по впф не прочитал, тоже смотрел на нее с колокольни своих знаний о гуестроительстве, а после книжки понял насколько я отстал от жизни. Так что не знаю, чем будет в перспективе огнеобезьяна, но сейчас пока в этом направлении спорить не о чем.

С практической точки зрения можно создавать очень гибкие интерфейсы, управляемые данными, которые будут меняться в зависимости от того, какие данные поступают. Взять к примеру обычный листбокс, там помимо шаблона самого листбокса есть еще шаблон для элементов листбокса. То есть если ты привязываешь к нему в качестве источника данных коллекцию неких объектов, то ты можешь сам определить как будет выглядеть каждый объект коллекции, то есть это не просто надпись появится, а ты можешь создать шаблон из нескольких контролов, которые расположишь как тебе удобно, каждый привяжешь к определенному свойству объекта данных и когда у тебя лисбокс отобразит список этих объектов, то информация по каждому будет более полной и более осмысленной. Это даже не будет выглядеть листбоксом, а больше будет напоминать какой-нибудь список товаров в интернет-магазине, где для каждого товара есть картинка, описание, цина и т.д. И тем не менее это будет обычный листбокс и подчиняться он будет логике заложенной в этот контрол. Другое применение - это шаблоны ошибок, то есть обычный текстбокс имеет такой шаблон и он проявляется если введены данные, которые не принял валидатор. С этим шаблоном можно делать тоже все что угодно. О скинах упоминал уже. Ну, о том, что одни и те же данные можно отображать разными способами и иногда надо иметь возможность переключать представление, тоже долго говорить не надо и так понятно. Ну и по части отделения логики от представления, там поддерживается шаблон проектирования MVVM, хотя тебе и без разницы, что в дельфах разделение обязанностей эмммммм... труднореализуемо.

Если в дельфах этого всего нет, то защищая дельфу, проще всего сказать, что все чего там нет вроде как и не нужно. Не забывай только о том, что более продвинутые технологии поднимают планку требований к тому же гую и плохой вид в конце концов будет и на спрос влиять. Относительно свистелок с перделками, вон на Злоху в дельфах в свое время впечатление произвели именно они, а теперь дельфисты пытаются убедить всех в том, что это для них не имеет значения. Что же тогда имеет?

Чарт-контрола в дельфах нет что ли?

А это еще зачем?  

Не знаю, что ты понимаешь под резиновостью, но если я правильно понял то в винформах она тоже есть. В впф более продвинутая модель компоновки, но в фомах есть у контролов свойства Anchor, Dock, LayoutEngine, Margin, Padding, событие Layout и несколько готовых панелек. Все это в сочетание дает довольно гибкую модель компоновки и для этого никакой скейлбай не нужен, чем бы он ни был  Просто в впф все еще круче.

Ну почему? Если человек привык писать на плюсах, то ему проще использовать их. Будучи мультиязычной платформой, дотнет просто предоставляет выбор. Кстати у плюсов под дотнет есть свои плюсы  

Не только впф. Еще раз повторюсь, что не в одном гуе счастье, так сказать: "Не гуем единым..." 

Добавлено через 13 минут и 38 секунд

Я не особо вникал в смысл ваших дрязг, так что не в курсе о чем вы тут.   Но в принципе какой смысл модификатора private, если доступ из других классов все равно будет? В языках это ессно недоступно, это нарушает принцип инкапсуляции, однако в дотнете есть ограниченная возможность доступа к приватным членам класса через механизмы рефлексии. Если класс расположен в другой сборке, то возможность доступа может быть ограничена политикой безопасности, но в принципе она есть.