В чем преимущество ООП ? - [8] :: Прикладное программирование

Цитата:

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

Ты бы предпочёл увидеть скопипасченный пост? Странно. rrromano, ты прав, в моём посте всё есть, но.

Цитата:

Еще раз повторяю, в Delphi невозможно отменить интерфейс.

Цитата:

Если тебе этого не нужно, не стоит их выносить в этот интерфейс.

Цитата:

Интерфейс уже давно много больше чем com.

Цитата:

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

Цитата:

...

Секундочку и по порядку.
Во-первых, Дельфи тут причём? Я предъявил ТЗ, а к реализациям на языках я перешёл после этого. Ты даже этого не понял? Впрочем, ты и тут неправ, отменить интерфейс в Дельфи можно, а иногда и нужно, и опять же Дельфи тут не причём, причём - архитектура подсистем.
Во-вторых, и это связано с во-первых. Интерфейсы требуются для регламентирования требований к реализациям. Если некая сущность является внутренней деталью некой подсистемы, почему её нельзя регламентировать? И если можно, то почему при этом обязательно раскрывать наружу? Похоже тебе самому Лисков перештудировать не помешало бы.
В-третьих, вот чему-чему, но учить меня проектировать не следует. Дельфи вот - можно, я его не знаю достаточно хорошо, чтобы отвечать за все свои слова о нём. Но вот проектированию больших, гибких и масштабируемых систем... ладно, я реалист... есть куда ещё расти, но учить меня не тебе явно. Ты уже дваджы накололся на принципах Лисков.
В-четвёртых. Не понравился пример с браузером? А что с ним не так? Какая разница, как оно там внутри реализовано и как спроектировано? Но ведь он явно попадает под твоё определение говнопродукта, ибо вмещает в себя кучу разнородных сущностей.
В-пятых. Ладно. Предположим ты поколебал мою уверенность касательно TQIP. Тогда укажи пальцем, где просчёт. Вернёмся к ТЗ. Итак.

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

Жду комментов. Очень хочется в спойлере предсказать, каких именно, но сдержусь.

Цитата:

Полностью переопределять поведение класса в его потомке – дурнейшая практика, ничего нормального в ней нет. Читаем принцип замещения Лисков до просвещения.

Цитата:

передаем потомку этого посетителя интерфейсную ссылку IRichEdit от класс TQip в перегруженном конструкторе.

Ладно, и это разжую. Это не полное переопределение, а кастомизация. Предположим Посетитель используется для оценки эффективности кеширования строк объектами IHistory. TQIP (сейчас совершенно неважно, каким именно способом он составлен из кирпичиков) безусловно должен будет быть помещён в коллекцию к Посетителю для опроса. Так уж получилось, что реализация IRichEdit разделяет с IHistory несколько последних строк истории. Открой QIP, ну или вообще любой пейджер, так и есть. Поэтому для более точной статистики требуется это число получить также и от реализации IRichEdit и вычесть из значения, полученного у IHistory.
Посетитель используется во всём проекте, а не ради каких-то жалких экземпляров TQIP, всего IHistory в проекте десятки. Коллекция у него хранит ссылки на IHistory. С какого перепугу он должен нормально отнестить к передаче ему IRichEdit? Что делать? Переделывать? Я уже показал наиболее правильный метод, использующий только локальное вмешательство на уровне одной-единственной подсистемы. Разумеется от базового класса локальному посетителю придёт IHistory, но он-то знает, что некоторые из них могут оказаться экземплярами TQIP, и если это так, то требуется получить от него IRichEdit, вызвать там единственный метод и вычесть. Делов-то:
Код:

std::size_t getLinesCount(const IHistory* hist)
{
const IRichEdit *edit = dynamic_cast<const IRichEdit*>(hist);
std::size_t linesAmount = hist->getCachedLines();

if (edit != NULL) linesAmount -= edit->getCurrentLines();

return linesAmount;
}

Код:

FUNCTION getLinesCount(hist:IHistory):Cardinal;
VAR edit:IRichEdit;
BEGIN
Result := hist.getCachedLines;

TRY
edit := hist AS IRichEdit;
Result := Result - edit.getCurrentLines
EXCEPT
END
END;

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

Цитата:

Куда там в стратегии всунуть множественное наследование вообще ума не приложу.

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

Цитата:

Что еще за мир ОП? Хотелось бы почитать про мир, где потомок наследуется от четырех родителей, включая полностью или частично их тела в себя. Думаю будет увлекательное чтиво.

Объектное программирование. Объектно-ориентированное - это лайт-версия для императивных языков. Где почитать? Та хоть любую литературу по проектированию.
А можно и не читать. Думаешь C++ единственный в своём роде, с множественным наследованием реализаций? Python, Perl, Ruby, Eiffel, Curl (честно говоря, не знаю, кто такой), Common Lisp, OCaml (тоже не знаю, но отзываются неплохо) и даже Delphi, правда, весьма ограниченно и только с 7-й версии. И C++ в общем-то тут не первые по качесту и набору возможностей. Для ознакомления рекомендую Python, Eiffel или Ruby, но у последнего это не совсем штатная возможность, а скорее её имитация. Лучше всего - Лисп, но он не совсем императивный.

----------
Одни с годами умнеют, другие становятся старше.

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++ в общем-то тоже не идеален. Я могу привести по меньше мере два недостатка его ОО модели в части множественного наследования, и мне тоже придётся в реализации неких вещей нет-нет, да и подогнать дизайн под требования модели. Но я уж точно при этом не буду врать, что мне подсунули говнодизайн.

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

----------
Одни с годами умнеют, другие становятся старше.

Модерирует : ShIvADeSt
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10