» В чем преимущество ООП ?

Так про сложности согласиться с утверждением. Говнокод есть говнокод, думаю никак не один человек это видит и разделяет.

Цитата:

VAR qip: TQip;
       edit:IRichEdit;
begin
  qip := TQip(Hist);
  if qip.QueryInterface(IRichEdit, edit) then
     работаем с edit
  else
     работаем c Hist

А где обещаный говнокод? Использованы два интерфейса один преобразовывается в другой. Если Вам так удобнее, ради Бога, пишите так, а в чём говнокодистость?

Добавлено:
Представим что он есть, тогда с его слов по Вашему, напишите пожалуйста? Если совершенство лени то это обратное от говнокода. Если что другое так экстрасенсов нет.

Eternal_Shield
Цитата:

Не будет. Чтобы достать интерфейс IRichEdit через IHistory, то придётся юзать hist.QueryInterface.

Я примерно так и предполагал. В смысле, что перекрёстный каст, который на Плюсах выполняется не сложнее нисходящего, в Дельфи делается в два этапа: сначала к общему - хоть потомку, хоть предку, неважно - классу, затем к нужному. В принципе не суть важно, разве что требуется знать об иерархии больше, а именно помимо исходного класса и класса-назначения ещё и какой-нибудь промежуточный общий.
Кстати, рад, что не все дельфисты как только так сразу бегут исследовать RTTI руками. Бо я слишком уж часто встречал таких.

wasilissk, ты потроллить сюда заходишь или прикидываешься?

Цитата:

Все фразы про интерфейсы были написаны именно в контексте делфи.

Цитата:

Ну вот только не надо доказывать, что белое это черное.

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

Цитата:

Иерархия, в которой скрываются методы, опубликованные в предке, просто по определению не удовлетворяет принципу замещения Лисков, потому что потомок не может выступать на месте предка.

А я о чём? Он не выступает, и даже не собирается. Что дальше? Таки понял суть, или будешь сам себе противоречить?

Цитата:

Ты с этим спорить собираешься?

Нет, не понял.
...Ок, вопросов больше не имею.

Цитата:

Ложь и искажение, я не об этом писал.

Ну... Если ты имел в виду другое, надо было говорить это самое другое. А так ты сказал ровно то, что сказал. И кстати, я-таки не увидел, какой же всё-таки из тех нумерованных пунктов прокольный.

Цитата:

В предложенной тобой делфийской реализации интерфейсы не нужны.

Аха. Т.е. реализация интерфейсов может существовать и без наследования от них? Не, конечно можно так поступить, но во-первых, почему тогда это будет называться реализацей интерфейса, и во-вторых, а как-же полиморфизм, и в-третьих , а как же ТЗ? Вот дали ТЗ, там курсивом по ариалу написано "...должен реализовывать три интерфейса..." ТЗ выпущено консилиумом системных интеграторов доброго десятка специализаций, работавших над архитектурой системы добрых пол-года. И чё? И хде? Минус премия устроит за срыв сроков, или будешь искать аргументы для спора с кандидатами наук, своими кураторами, ибо твоя фирма - всего лишь подрядчик, и ведущими инженерами, у которых этот проект уже пятый по счёту? Я не шучу. Это не дядя с кипой флешек в кармане пришёл сайт заказывать, эти люди реально знают, как должен быть устроен самолёт или атомная станция.

Цитата:

Кастомизация это преобразование одного типа к другому.

Кастомизация - это customisation, настройка обощённого модуля под конкретику контекста. То что ты имеешь в виду - это каст, cast, и это сленг, ибо правильно тогда уж тайпкаст.

Цитата:

Если изначально посетитель проектировался исключительно для работы с IHistory, а его потомок с никоим образом не связанным с ним IRichEdit-ом стал работать - это называется полным переопределением поведение класса в его потомке.

Конструктива нет и не будет. Не верю, что ты прикидываешься, а троллей я ненавижу, и это ещё мягко сказано.

Цитата:

Переделывать посетителя,...

Уволен. Ты ещё TObject перепиши в подобной ситуации.

Цитата:

Т.е. объектное программирование, как не объектно-ориентированное, реализуют неимперативные языки?

Не обязательно. Чистое ОП плохо укладывается в императив. А для императива чистое ОП неудобно. Так что ООП - это золотая середина, но с большим перекосом в угоду императиву, чем в угоду ОП.

Цитата:

В перечисленном тобой списке условно к неимперативным можно причислить лишь common lisp, однако опять же незадача, про него написано, что он объектно-ориентированный.

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

Цитата:

Это утверждение о том, что в любой книжке по проектированию есть определение объектного программирования как не объектно-ориентированного?

Нет. Это есть утверждение о том, что в любой книжке по проектированию нет программирования. Если есть, то это уже не книжка по проектированию. Но это не означает, что чтобы получить предстваление об ОП, требуется именно книжка по проектированию. Можно рассмотреть и книжки по программированию, где рассматривается язык, реализующий множественное наследование лучше, чем C++.

delover
Цитата:

В Дельфи это реализуется весьма просто, до банальности, хотя если интерфейс уже прописан будет диссонанс между объявлением компилятору и саппортом Query.

Опять же. Не следует подходить к разговору об интерфейсах и их реализациях в контексте какого-либо языка. Это разговор в первую очередь об архитектуре некой подсистемы. Её реализация в коде вторична. И именно с этих позиций имеет смысл сравнивать ООП-модели языков. Иначе будет вот такой вот разговор, как у меня с wasilissk-ом.

Ага, ну вот и ты тоже написал, нечто подобное как у Eternal_Shield. Только я за qip := Hist AS TQip; тогда уж, потому как далеко не каждая реализация IHystory является TQIP-ом.

Цитата:

Забываю, если сохряняется условие выполнимости, сложно согласиться с утверждением о невыполнимости множественного наследования.

Именно.
Множественное наследование ничем не отличается от простого. Ну вот просто ничем. Ну вот какая разница, столько у объекта непосредственных предков? Почему если они интерфейсы - это якобы нормально, а если нет, то якобы плохо? Если агрегацией успешно можно имитировать множественное наследование, зачем тогда нужно простое, если агрегация сможет его имитировать не хуже? Я тупо не понимаю логики. Если мы против множественного наследования, так мы и должны быть против. Если мы его допускаем, значит мы его просто допускаем, зачем ограничения? Я вижу единственное объяснение: байка о ненужности множественного наследования реализаций - это маркетинговый ход, ибо архитекторы языка не осилили или не хотят выпячивать недостатки принятой ОО модели, чтоб они стали заметны. Вот C++ не стал комплексовать по этому поводу, а Дельфи и C# решили не рисковать.
Ещё раз. Проблема ромба - это не проблема множественного наследования, это проблема задача дизайна подсистемы. Вот есть у нас классы TA, TB и TC. Нужно их собрать в единый компонент. Каждый их них является производным от TLog, некого логгера. Ну, допустим он пишет журналы, каждый экземпляр TLog в отдельный файл. Таков дизайн. Надо, чтобы TA и TC разделяли общий экземпляр, потому что у них один файл ждурнала, а TB имел отдельную копию журнала. Причём тут программирование, если таков дизайн системы? Да, вот так спроектировали. Что с ней не так? Почему это плохой дизайн, и таких существовать не должно? Та вся VCL такова вообще-то, если копнуть принципы её устройства. Просто этого не очень видно, потому что мало кто изучает её философию, а не предоставляемые возможности, и поэтому мало кто видит, где за динамическим полиморфизмом и ссылками на интерфейсы в параметрах конструкторов объектов на самом деле скрывается замаскированное множественное наследование с разделением или объединеним атрибутов. Разделять или объединять аттрибуты - это задача - задача, а не проблема! - архитектора. И как он спроектирует, так и должно быть. После этого проблемы ромба просто нет, потому что дизайнер явно указал, что и как дожно быть. Берём и пишем.
Что делают Дельфисты, когда получают в разработку такой компонент? Правильно, говорят, что это говнодизайн и перепроектируют подсистему. Хотя почему говнодизайн, вменяемых аргументов от них обычно не дождёшься, окромя отсыла к Help и литературе по Object Pascal, писанной авторитетами. Хотя аргумент есть и весьма прост - их ОО модель этого не позволяет. Ну, некоторые это понимают и честно так и говорят. И я не вижу тут ничего такого уж предосудительного. Они сами выбрали инструмент разработки, имели право, и идут на компромиссы с его требованиями, и это неизбежно. И когда это приемлимо, та ради бога. Только вот не всегда приемлимо.
Что делают Плюсовики? Та объявляют TLog виртуальным базовым классом для TA и TC и обычным для TB, и всех делов. Вопрос: почему по факту прямое следование требованиям должно считаться худшим решением, нежели витиеватый балет вокруг да около из каких-то религиозных соображений, да ещё и обманывающий по части реальных взаимоотношений между классами, реализуя не те отношения, которые заложены интерфейсами? C++ в общем-то тоже не идеален. Я могу привести по меньше мере два недостатка его ОО модели в части множественного наследования, и мне тоже придётся в реализации неких вещей нет-нет, да и подогнать дизайн под требования модели. Но я уж точно при этом не буду врать, что мне подсунули говнодизайн.

Добавлено:
К слову. Правда, немного оффтопному.
Повторяющие как мантру "множественное наследование не нужно, вредно, создаёт проблемы" нужное подчекнуть мне всегда напоминают простых обывателей, слышавших о парадоксе близнецов в Теории Относительности. Ни те, ни те не могут внятно ничего сформулировать, если попросить аргументы. Первые просто отбрыкиваются негативными прилагательными и обидными существительными, без каких бы то ни было аргументов, вторые... скажем так, ещё никто, кого я спрашивал, не смог его даже правильно сформулировать, не говоря уже о том, чтобы разрешить.

Qraizer

Цитата:

Интерфейс и реализация - это понятия из ОО проектирования, а не ОО программирования.

Я там даже твои фразы скопипастил, где русским по белому написано, что разговор идет об интерфейсах в Delphi. Продолжай доказывать, что белое это черное.

Цитата:

А я о чём?

А ты об отмене интерфейса в иерархии. Где в предке он доступен, а в потомке отменен.

Цитата:

В предложенной тобой делфийской реализации интерфейсы не нужны.

Цитата:

Т.е. реализация интерфейсов может существовать и без наследования от них?

В огороде бузина, а в Киеве - дядька. Не нужны, это значит - не нужны, т.е. вообще не нужны. Ни реализация, ни декларирование.
Это ТЗ придумал ты, а не консилиум, точнее высосал его из пальца, а еще точнее - все что касается реализации, а не поставленной задачи. Дабы придумать хоть какой-то аргумент в пользу множественного наследования, изюминкой этого ТЗ является жесткое, грязное и неправильное приведение типов. Если бы такую же глупость совершил бы консилиум, это бы ничего не изменило. Примеров самодурства высоколобых седых дядек в жизни уйма. Борька Моисеев богат и влиятелен, но это не отменяет того факта что он педик. Твое ТЗ неправильно и тот факт, что сам доцент поставит на нем свою резолюцию - его правильным не сделает.
Кстати страшным авторитетом кандидаты являются только для необразованных птушников. У нас в тестерах сидят два кандидата.

Цитата:

То что ты имеешь в виду - это каст, cast, и это сленг, ибо правильно тогда уж тайпкаст.

Ну конечно, а то что ты имеешь в виду - это конечно же не сленг, а самый что ни на есть энциклопедический термин.

Цитата:

Конструктива нет и не будет. Не верю, что ты прикидываешься, а троллей я ненавижу, и это ещё мягко сказано. Уволен. Ты ещё TObject перепиши в подобной ситуации.

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

Цитата:

Объектно-ориентированное - это лайт-версия для императивных языков.

Т.е. имеем множество ОП языков. Имеем его подмножество императивных ООП языков, оно нам не интересно. Так что это за дополнение до множества ОП языков, определение, примеры?

Цитата:

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

Ну коне-е-ечно, те же gof-ы, Буч - Объектно-ориентированный анализ и проектирование, куча книг Мартина, Бека, Нильсона это все книжки не по проектированию.

Qraizer

Цитата:

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

Тут надо чётко понимать, что в делфи интерфейс - это НЕ класс и не имеет с ним ничего общего. Поэтому, если объект (класс) имеет N интерфейсов, то каждый взятый интерфейс будет иметь СВОЙ адрес, а не адрес ОБЪЕКТА. Соотв., через приведение интерфейса к типу объекта, нельзя получить адрес объекта. Надеюсь я ясно выразился.

Следовательно, у интерфейса IHistory будет ссылка на таблицу с адресом AAAAAAAA, у интерфейса IRichEdit ссылка будет на таблицу с адресом AAAAAAAC. Вызов метода N через не родственного интерфейса сработает, если будет совпадение сигнатур и индекса в объявленных интерфейсах. Но вызов будет одного и того же метода. И не более того.

Если не совсем ясно, могу привести пример:


Код:
type
IHistory = interface
function getCachedLines: Cardinal;
....
end;

IRichEdit = interface
function getCurrentLines: Cardinal;
....
end;

wasilissk, почитай первый абзац последнего поста Eternal_Shield-а, успокойся и возвращайся в ВУЗ. С тобой разговор я окончил, тема наполнена материалом, чего и хотелось, собственно. Есть что анализировать интересующимся.
Прочитав умных книжек, нахватавшись аббревиатур и терминов и зазубрив приведённые там примеры, ты не становишься умнее. Умнее тебя делает понимание изложенных идей, знание причин, приведших именно к такому имеющемуся там дизайну инструментов, представление об их плюсах и минусах и плюсах и минусах альтернативных их дизайнов. Знать же назубок данный тебе материал - этого достаточно для кодера, но не программиста.
И кстати, только что ты сильно обидел конструкторов одного из подрядчиков Боинг-787. А до этого - подрядчика Gulfstream IV и V, Dassault Falcon 900, 2000 и 7X, Embraer, Cessna, AgustaWestland, Hawker Horizon. И это ещё не все, только те, к которым приложены в частности мои руки. Нет, я не хвастаюсь, всего лишь тебя ставлю на место. Пересчитай свои посты и покажи пальцем в агрументы в них, а не сферические слова и эмоции. Сравнивает он тут себя с кандидатами наук физики атмосферы, специалистами по аэродромному и самолётному радиооборудованию, профессорами сопромата и конструкторами-практиками в области авионики. Да ещё и работающими в компании, по инициативе которой никакой самолёт, не имеющий у себя реализованных по меньшей мере двух её новаторских инициатив, изобретённых, реализованных, запатентованных и предложенных в качестве мировых стандартнов, в небо Европы даже пустят. Ты ни на один вопрос не ответил, ни одного своего тезиса не аргументировал. Так что побереги свои гонор и самомнение для подружек.

Eternal_Shield
Цитата:

Тут надо чётко понимать, что в делфи интерфейс - это НЕ класс и не имеет с ним ничего общего. Поэтому, если объект (класс) имеет N интерфейсов, то каждый взятый интерфейс будет иметь СВОЙ адрес, а не адрес ОБЪЕКТА. Соотв., через приведение интерфейса к типу объекта, нельзя получить адрес объекта. Надеюсь я ясно выразился.

Более чем. Возможно, открою секрет, но в Плюсах всё точно так же. Окромя того, что интерфейсов там нет, их (почти) заменяют абстрактные классы. Именно преобразованием адреса и занимается dynamic_cast<>. Безусловно, каждый подобъект разделяет в цельном объекте, предком которого он является, некое пространство стораджа, и безусловно адреса подобъектов будут все разные, окромя может быть одного-единственного, чей адрес может оказаться равным самому цельному объекту.

Цитата:

Следовательно, у интерфейса IHistory будет ссылка на таблицу с адресом AAAAAAAA, у интерфейса IRichEdit ссылка будет на таблицу с адресом AAAAAAAC. ...

Под ... я спрятал уже несущественное. Применяя твои условности к моему вон тому коду, когда я подам на вход dynamic_cast<> указатель типа IHistory, указывающий на подобъект (некоего производного от него объекта, в данном случае - экземляра TQIP), чья VMT содержит ссылку на AAAAAAAA, на выходе из dynamic_cast<> я получу указатель типа IRichEdit, указывающий на подобъект (того же экземпляра TQIP), чья VMT содержит ссылку AAAAAAAC. Разумеется, только в том случае, если в пределах этого объекта действительно имеется такой маршрут от IHistory до IRichEdit, иначе dynamic_cast<> вернёт NULL. dynamic_cast<> гуляет и ищет любые маршруты по всей RTTI объекта, и способен от любого его подобъекта перейти к любому другому его же подобъекту. Полученный указатель будет указывать на этот подобъект как родной, и может использоваться со всеми прелестями полиморфного поведения цельного объекта. Если объект не содержит IRichEdit, или содержит, но он недоступен по причине неоднозначности (т.е. их больше одного доступного) или непубличности, или если маршрут до него пролегает по хотя бы одному неполиморфному классу, dynamic_cast<> будет бессилен. В случае использования ссылок вместо указателей, поведение не меняется, кроме как при неуспешном касте будет бросок исключения std::bad_cast вместо возврата NULL.
Я, если честно, ожидал от AS хотя бы подобного поведения, и в тайне надеялся, что ввиду явной поддержки агрегации на уровне языка AS умеет разгребать и их. Получается, что ошибался. Можешь тогда привести полную информацию, что AS умеет и чего не умеет? Интересно просто. И, да, чуть не забыл. dynamic_cast<> не работает с агрегатами. Просто потому, что они вне иерархии, и о них нет информации в VMT их "владельца".

Qraizer

Цитата:

Применяя твои условности к моему вон тому коду, когда я подам на вход dynamic_cast<> указатель типа IHistory, указывающий на подобъект (некоего производного от него объекта, в данном случае - экземляра TQIP), чья VMT содержит ссылку на AAAAAAAA, на выходе из dynamic_cast<> я получу указатель типа IRichEdit, указывающий на подобъект (того же экземпляра TQIP), чья VMT содержит ссылку AAAAAAAC.

Не выйдет, ибо при вот таком вызове:

Код:
var
Qip: TQIP;

....
getLinesCount(Qip);

Qraizer

Цитата:

почитай первый абзац последнего поста Eternal_Shield-а, успокойся и возвращайся в ВУЗ. С тобой разговор я окончил, тема наполнена материалом, чего и хотелось, собственно. Есть что анализировать интересующимся.

Во-первых, этот абзац был тебе адресован, для тебя может он и стал открытием, моим же словам это ни коим образом не противоречит.
Во-вторых, со своим пророчеством ты попал пальцем в небо, ВУЗ я закончил десять лет назад.

Цитата:

Прочитав умных книжек

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

Цитата:

И кстати, только что ты сильно обидел

Мдя, жесть, сам и не заметил как обидел Боинги, Фалконы, ну ладно хоть АйБиЭм и Майкрософт от меня не пострадали, а мировой кризис не я случайно начал, часовню не я развалил?

Цитата:

Сравнивает он тут себя

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

Цитата:

Пересчитай свои посты и покажи пальцем в агрументы в них

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

Eternal_Shield, то, что AS не подходит, ты уже говорил. И сказал, что подходит вместо него. Так а что тогда делает AS? Совсем бесполезная фича, получается, на уровне *(int*)&some_double?
Что касается сказанного про dynamic_cast<> ...хочешь продемонстрирую? Или так поверишь? В C++ dynamic_cast<> - отличная вещь. Вкупе с динамическим полиморфизмом и шаблонами в статике они RTTI в явном виде делают практически ненужным.
wasilissk, АйБиЭм и Майкрософт не занимаются созданием высококритичного ПО. Им без надобности вкачивать в проектирование и тестирование средств на три порядка больше, чем на программирование. И уж поверь, в авионике, атомной энергетике и медицине средства моделирования, используемые на этапах ТЗ -> system requirements -> high-level requirements -> low-level requirements, и методы описания целевых систем таковы, что какие-нибудь Rational Rose с UML-ем на их фоне детский лепет. На твои заявления, мол, так системы не проектируют, тебя просто уволят и заменят индусом, который сумеет перевести смоделированную, отлаженную и отточенную на кластере архитектуру в код. Хоть индусов там и не любят. Кодят они, кстати, весьма неплохо, это программить и дизайнить они не умеют, максимум - наттыкать паттернов и связать их прокси-классами. Перенести объектное представление с указанными взаимоотношениями между подсистемами на C, не то что C++ - после 3-го курса это дело техники. Не ври про ВУЗ, не верится. Им глубоко наплевать на твоё образование, как и чему тебя учили и откуда у тебя диплом. Они спроектировали систему, которая относительно проста и надёжна, модель которой прошла все испытания, показала соответствие заданным характеристикам и влезает в бюджет. И уж точно гибкая, потому как потом будет ещё одна система, а деньги считать они умеют. Кстати, в школе тоже учат дробные, равноудалённые от соседних целых, округлять в большую сторону, но жизнь оказывается богаче. Похоже, что если про ВУЗ и не брехня, то научить тебя учиться дальше опытом он не смог.
Менторский тон ты сам вынудил. Думаешь у пилота нету аналога QIP под рукой? А что тогда делает вон та коробочка, справа от пилота, на ней ещё MCDU написано? Ты не поверишь: помимо множества переключаемых экранчиков Radio, TCAS, XPDS итп, построчно выводит оповещения, при необходимости управляется со scratch pad-а и отчитывается обо всём в чёрный ящик. Ой, да? Так что уволен, уволен. От тебя одни вычитанные где-то тезисы и кивки в сторону авторов умных книжек. От меня, прости, практика. А также аргументы и примеры. В холиварах не ставится цель переубедить оппонента. На то он и холивар. Холивар нужен для обмена мнениями и точками зрения с аргументированием своих позиций, для демонстрации преимуществ и недостатков каждой. Чтобы любой заинтересованный товарищ, гуглящий свою проблему или даже простой вопрос "с чего начать учиться програмить" и наткнувшийся на эту тему, пришёл и почитал. Даже вдруг я неправ, ты его замечательно мотивировал, поздравляю.

Qraizer
Осталось добавить только, что самый Феерический момент ООП - инкапсуляция. Это только опыт, (имхо), но после опыта понимание ставит программиста на следующий уровень.

delover, ты может быть не поверишь, но инкапсуляция не есть прерогатива ООП. Модульное программирование вовсю использует непубличные сущности, "чтобы не засорять глобальное пространство имён", ага. Пространства имён зачастую являются куда как более удобным средством инкапсуляции.
Более того, она не обязательна в том виде, каково её определение. Аттрибуты объекта могут храниться вообще отдельно от объекта. Более того, объект может даже представления не иметь, сколько и какие аттрибуты он имеет. Весь вопрос в требуемом уровне абстракции. Если б из дискуссии не получился холивар, а из того в свою очередь дерьмо, я б привёл интересных примеров. Я скажу ещё более крамольную вещь: инкапсуляния в том виде, как она определяется, на самом деле нафиг не нужна. Она просто удобна, но не необходима. По-настоящему необходимым является только лишь запрет на неконтролируемый доступ к аттрибутам объектов, ибо в этом случае нет никаких гарантий касательно соблюдения инвариантов. Инкапсуляция служит этой цели наилучшим из простейших методов, да и то не полностью. Но эта цель может быть достигнута и иначе.

Qraizer
Э-эх, не хотел я с тобой общаться, но читая этот бред не могу молчать.

Цитата:

Более того, она не обязательна в том виде, каково её определение.

Ссылаясь на умные книжки, я делаю это не просто так. А для того, чтобы подчеркнуть, что это не мое личное мнение, а мнение авторитетного источника, ибо я на форуме это всего лишь частное мнение неизвестного никому человека. Тебе я того же советую, ибо твое мнение это всего лишь мнение и, очень спорное мнение.

Цитата:

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

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

wasilissk, в книжках пишут всё правильно. Просто там теория, а жизнь богаче.


Код:
class someClass_impl;

class someClass
{
std::auto_ptr<someClass_Impl> impl;

public:
/* ... */
};

Qraizer
Что из приведенных примеров делает инкапсуляцию не нужной?

Я тоже не буду отвечать. Надоело играть в одни ворота.

Qraizer
Т.е. чтобы ты продолжил свою мысль, необходим мой ответ на вопросы?
Ok.

Цитата:

Идиома PImpl

Вопроса не увидел.

Цитата:

Кто здесь за что отвечает и что инкапсулирует?

Понятия не имею.

Цитата:

Что тут инкапсулировал класс?

Две переменные и логику опубликованного интерфейса.

Цитата:

А что пространство имён?

Пространство имен ограничило пространство имен. Термин инкапсулирование тут вообще некорректно использовать.

Цитата:

Это ООП? Тут есть инкапсуляция?

Это структура с методами. Есть.

Теперь, пожалуйста, что же все таки из приведенного делает инкапсуляцию ненужной?

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

А здесь ты каким руководствовался?
Qraizer

Цитата:

Более того, она не обязательна в том виде, каково её определение.

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

Как нас учили в институте преимуществ основных два:
1. Эта концепция в наибольшей степени соответствует внутренней логике операционной системы. Программа, состоящая из отдельных объектов, приспособлена к реагированию на события, происходящие в операционной системе.
2. Большая надёжность кода и возможность повторного использования отработанных объектов.

indapublic

Цитата:

основных два

На все четыре набралось:

Цитата:

1. Эта концепция в наибольшей степени соответствует внутренней логике операционной системы.
2. Программа, состоящая из отдельных объектов, приспособлена к реагированию на события, происходящие в операционной системе.
3. Большая надёжность кода
4. Возможность повторного использования отработанных объектов.

И с первыми двумя я бы не согласился.

Добавлено:
По меньшей мере необходимо уточнять, что за операционная система и для какого круга задач. А в общем понимании, это не так.

Возможно, я не спорю. Как на лекции учили, так я и написал. Я в своей практике упор делаю пока на алгоритмическое программирование. Поэтому не проникся ООП в полной мере.

Да, я вспомнил, в лекции речь шла именно про операционную систему Windows

indapublic
особенно проникнуться ООП помогает программа а-ля MS Paint созданная своими руками. Вот тогда начинаешь въезжать, почему
Object.Draw лучше чем
if (Object.Type = Circle) then
DrawCircle(....)
else
if (Object.Type = Rect) then
DrawRect(....)

и т.д.

Особенно когда нужно изменить поведение для всех объектов при отрисовке... Скажем, если рисовать только черно-белым или инверсным цветом...
Попробуйте процедурным это все написать, а потом ООП...

salexn1
Верно подмечено: ООП - не панацея от всех проблем (не универсальное средство), а лишь средство для решения определённого множества задач. Глупо ограничивать себя или тем или этим.

Есть постановка задачи? Отлично! Оцени масштаб работы и сделай шаг в правильном направлении, а не пытайся копать асфальт лопатой, только потому, что ею ты успешно копал землю.

Цитата:

особенно проникнуться ООП помогает программа а-ля MS Paint созданная своими руками

Это конечно, но нужно оценивать задачу, если необходимо, например, найти площадь круга, то в ООП дольше будешь форму создавать, да ввод-вывод обеспечивать, чем реально решать задачу

ООП не панацея, но для решения большинства типичных задач использование ООП оправдано

Erazor84

Цитата:

ООП не панацея

Именно панацея. ООП позволяет описывать непредсказуемый мир, чем не блещет структурное программирование. Правда когда структурное программирование эмулирует ООП ему это изредка удаётся.

salexn1

Цитата:

особенно проникнуться ООП помогает программа а-ля MS Paint созданная своими руками. Вот тогда начинаешь въезжать

Альтернатива, надо видеть альтернативу и осознать отличия! Я не профи в программировании, много разных языков пощупал. Скажем, есть такой Liberty BASIC. Это ужас, летящий на крыльях ночи! Можно программировать Виндовские окошки, но - предлагается это делать через бесконечные go to. Короче, 100% Spaghetti code. Зато благодаря знакомству с этим языком я, наконец, понял, что означает директива self в Smalltalk: это перевод программы в состояние, в котором она ничего не делает, а только ловит в цикле ввод с клавы и прочие действия юзера!

Кто нибудь пробовал работать с TMS Aurelius? , я вообще никогда не сталкивался с ООП, до этого все на паскале + sql. Хочу перейти на другой уровень .

alexgala
TMS это не совсем программирование, если меня простят. ООП это определение модели наследования объектов, если быть точнее - полиморфизм делегация и ещё что-то. Инкапсуляция вроде была. Ваши вопросы лучше в топик с TMS чем сюда.

Цитата:

ООП не панацея, но для решения большинства типичных задач использование ООП оправдано

Конечно не панацея, все зависит от профессионализма программиста и его умения пользоваться конкретным инструментом.