VladD2 пишет: > ANS>Это почему не компонентная? Как по мне, то реализация вполне нормальная. > > Это только по тебе, так как ты не задумался как следует. А если бы > задумался бы, то понял бы, что в рамках компонентной модели дотнета или > Явы такая модель приведет к зависимости от компиляции. Если поместить > базовые классы в разные сборки, то добавление нового члена или изменение > публичного интерфейса приведет к необходимости перекомпиляции сборки > содержащей наследника. Сейчас же это не обязательно.
Это уж извините. Эмуляция редко полностью соответсвует своему прототипу.
ЗЫ. Как тут предлагают, такие классы нужно сделать sealed и объявить это
фичей.
--
Andrei N.Sobchuck
JabberID: andreis@jabber.ru. ICQ UIN: 46466235.
Здравствуйте, PeterZT, Вы писали:
PZT>Сейчас под .NET использую Spring.NET в основном в качестве сервис-локатора, но постепенно начинаю использовать его более полноценно. Поделитесь практиками использования в Java (насколько полно используете в своих приложениях)
Да я не то чтобы очень сильно его использовал. Единственное, что могу сказать — как-то сама собой получилась следующая картина: куча мелких компонентиков, каждый с очень простой функциональностью, которые связываются Spring-ом.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>Зато мы можем унаследоваться от File
СГ>Не надо. File самодостаточный объект. А чтение/запись идет через вспомогательные объекты: СГ>
СГ>Reader reader = File.NewReader();
СГ>Writer writer = File.NewWriter();
СГ>Scanner scanner = new Scanner(reader);
СГ>Formatter formatter = new Formatter(writer);
СГ>
Ну ты крут! Этож вся библия нафиг ((С) Игорь Угольников).
А у Formatter-ов своих атрибутов не будет? Как же Formatter будет про своего writter-а знать? И имеют ли право потомки Formatter-а изменять writter-а во время работы? Или иерархию Formatter-ов вообще делать не нужно?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
LuciferMoscow,
> LM>> Здравствуйте, Leshi, можешь привести пример, где не обойтись без множественного наследования? Наиболее реальный
> L> Я могу привести пример, где множественное наследование будет самым элегантным способом.
> Я этого и хочу
Можешь посмотреть на иерархию std::iostream, std::istream, std::ostream из стандартной библиотеки C++. Что такое "самый элегантный способ" можно спорить долго, но то, что множественное наследование в случае std::iostream применено по делу, по-моему, должно быть очевидно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это уж извините. Эмуляция редко полностью соответсвует своему прототипу.
А чё мне извинять? Я просто заметил, что решение не совсем хорошее.
ANS>ЗЫ. Как тут предлагают, такие классы нужно сделать sealed и объявить это ANS>фичей.
Давай уж оставим эту фичу для применения по назначению.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Тоже фигня — синтаксический сахар.
Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Синтаксический сахор облегчающий жизнь — это не фигня.
Что до DEFINITION, то по-моему — это неудачный варинт traits/mix-in-ов. Самое простое и логичное что я видел — это когда вводится специальный "тип класса" — trait. Его можно наследовать, но к нему нельзя привести. Таким образом содержимое trait-ов просто копируется в класс. Классы при этом могут иметь одиночное наследование. Причем и trait. Таким образом trait-ы позволяют подключать реализацию (как просто методов, так и интерфейсов).
За счет того, что сделать привидение к trait-у нельзя нет никаких проблем МН, а все пиемущества есть. Думаю Шарпу и Яве такой синтаксический сахар очень не помешал бы.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
Private-наследование уже выброшено. И, кстати, подилом. Дурь это.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
Бред. Это может проиворечить только кривым реализациям. Как, по-твоему, создавать разные библиотечные классы если раследоваться от классов в других модулях нельзя, а библиотека по опредлению другой модуль.
... << RSDN@Home 1.1.4 beta 4 rev. 359>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
E>>А разве private атрибуты в одиночном наследовании не скрывают от класса-потомка состояние? Может private-атрибуты вообще выбросить? А за ними и private-наследование?
VD>Private-наследование уже выброшено. И, кстати, подилом. Дурь это.
Из C++ выброшено?
А где про это прочитать можно?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Leshi, Вы писали:
L>Мне тут понадобилось переписать заново одну старую програмулину (написанную на С++). И я занялся изучением новомодных тенденций. Хотелось идти в ногу со временем и использовать что-то современное (ладно, кандидатами были C# и Java). Но беда заключается в том, что в старом коде используется множественное наследование почти везде. В двух словах, там есть несколько базовых функционалов (десятка три), реализованных своими классами. А рабочие классы используют то, что им надо (обычно от 5 до 15 родителей) и переопределяют некоторые операции. Так вот возник вопрос, как же без множественного наследования люди обходятся? Поделитесь опытом
L>ЗЫ: Вопрос о выборе средства разработки уже не стоит, С++ однозначно.
См. Паттерны дядьки Гаммы. Фабрика, шаблонный метод, стратегия и т.д.
ИМХО множественное наследование — от лукавого, т.е. появляется сильное связывание да еще и неявное. Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь .
Здравствуйте, Joker6413, Вы писали:
J>См. Паттерны дядьки Гаммы. Фабрика, шаблонный метод, стратегия и т.д.
Смотрел Мне не подходит J>ИМХО множественное наследование — от лукавого, т.е. появляется сильное связывание да еще и неявное.
И что? J>Если ты еще не убился с отлаживанием — рекомендую от м.н. не отказываться, через короткое время сам все поймешь .
Сколько же должно пройти времени? Я не первый день программирую на С++, почему-то желание отказаться от множественного наследования не возникало. Что я делаю не так?
VladD2 пишет:
> C>Тоже фигня — синтаксический сахар. > Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Именно
> Синтаксический сахор облегчающий жизнь — это не фигня.
Все от его качества зависит.
> Что до DEFINITION, то по-моему — это неудачный варинт > traits/mix-in-ов. Самое простое и логичное что я видел — это когда > вводится специальный "тип класса" — trait. Его можно наследовать, но к > нему нельзя привести. Таким образом содержимое trait-ов просто > копируется в класс. Классы при этом могут иметь одиночное > наследование. Причем и trait. Таким образом trait-ы позволяют > подключать реализацию (как просто методов, так и интерфейсов).
Скорее помогли бы конструкции типа
class A implements I1, I2, I3
{
[delegate default I1] I1Impl impl1;
};
То есть делегировать непереопределенные методы из интерфейса I1 в
I1Impl. Реализуется такое до смешного просто, компилятору нужно
сгенерировать стабы методов такого вида:
Здравствуйте, VladD2, Вы писали:
VD>Ну, да. А for/while синтаксический сахар скрывающий ассемблерные команды.
Самое смешное что в шарпе for действительно синтаксический сахар, на уровне IL превращающийся в while. Далеко не все декомпиляторы умеют использовать for.
Здравствуйте, eao197, Вы писали:
E>А у Formatter-ов своих атрибутов не будет?
Что Вы имеете в виду под термином атрибут? Может быть переменные/поля/члены?
E>Как же Formatter будет про своего writter-а знать?
Formatter formatter = new Formatter(writer) — объект "писатель" отдается объекту "форматировщик" в его конструкторе, он его запоминает и затем пользуется им.
E>И имеют ли право потомки Formatter-а изменять writter-а во время работы?
Посредством объекта "писатель" осуществляется запись writer.Write(byte[] buffer, int offset, int size), при этом позиция записи сдвигается на +size, т. е. состояние писателя изменяется.
E>Или иерархию Formatter-ов вообще делать не нужно?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>А межмодульное наследование классов, вообще-то, не сильно-то поощряется ибо противоречит КОП.
VD>Бред. Это может проиворечить только кривым реализациям. Как, по-твоему, создавать разные библиотечные классы если раследоваться от классов в других модулях нельзя, а библиотека по опредлению другой модуль.
Основной принцип КОП (так как я его понимаю) гласит: модуль должен экспортировать только abstract class/interface/definition..., а также экспортировать фабрику по производству объектов реализующих указанные интерфейсы. Но сами по себе конкретные классы этих объектов-реализаторов модуль экспортировать не должен. Объясняется это тем, что модуль должен оставлять за собой право на изменение реализации в последующих версиях этого же самого модуля которые не приведут к тому чтобы пользователи этого модуля должны были бы перекомпилироваться при смене версии модуля (тоже самое должно быть справедливо при замене этого модуля на аналогичный модуль от другого производителя). КОП в том и состоит, что мы в любой момент можем из работающей системы изъять старый модуль и заменить его новым модулем (быть может от другого производителя) на лету без перезапуска системы и тем более без перекомпиляции (ибо у нас может просто не быть исходников).
P. S.
В оригинальных оберонах, т.е. откуда КОП пошло, JIT компиляции не было — вот поэтому и был наложен запрет на межмодульное наследование... При наличии JIT компиляции этот запрет, возможно, снимается...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, eao197, Вы писали:
E>>А у Formatter-ов своих атрибутов не будет?
СГ>Что Вы имеете в виду под термином атрибут? Может быть переменные/поля/члены?
Имхо, понятия переменные (локальные, глобальные, автоматические, статические), поля (битовые?) и члены (методы-члены, атрибуты-члены) -- это все сильно перегруженные понятия. Поэтому раньше было принято использовать понятия -- метод (функция член) и атрибут (поле, член класса).
E>>Как же Formatter будет про своего writter-а знать?
СГ>Formatter formatter = new Formatter(writer) — объект "писатель" отдается объекту "форматировщик" в его конструкторе, он его запоминает и затем пользуется им.
Это я и так понимаю, запоминается writter куда? В атрибут. И, вероятно, не public-атрибут.
E>>И имеют ли право потомки Formatter-а изменять writter-а во время работы?
СГ>Посредством объекта "писатель" осуществляется запись writer.Write(byte[] buffer, int offset, int size), при этом позиция записи сдвигается на +size, т. е. состояние писателя изменяется.
Сергей, вы не понимаете суть вопроса. Пусть сначала Formatter был связан с writter-ом, который связан с файлом. Затем какому-то потомку захотелось перевязать этот же Formatter на writter, который связан с pipe. Можно ли такое допускать?
E>>Или иерархию Formatter-ов вообще делать не нужно?
СГ>Это по желанию, но скорее всего нет.
А почему нет? Пусть у меня есть Formatter, который строит XML и передает его в writter. Затем я делаю потомка для этого Formatter, который перед построением XML переводит все строки в UTF-8. Разве это запрещено? И нужно ли моему Utf8XmlFormatter-у знать, где XmlFormatter хранит ссылку на writter?
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодт, Вы писали:
К>У меня складывается впечатление, что есть какой-то глубокий изъян в методологии изучения и практики программирования. В основном он присущ изучению структурно-ориентированных языков. Вот что это за изьян: К>Мышление об объектах как о россыпи деталей (члены структуры, узлы графа, отдельные указатели и т.д.). К>Отсюда — написание функций, работающих со списком через указатель на головной узел; динамические массивы на уровне языка, управление которыми (перевыделение памяти, например) доступно кому попало; вот ещё добавляется боязнь скрытого состояния базовых объектов.
Самый простой объект — это действительно структура (члены структуры, узлы графа, отдельные указатели и т.д.).
Самая простая динамическая структура связанных объектов — это список.
Самый простой способ объединения объектов в один блок — массив на уровне языка программирования.
Самый простой взгляд на взаимодейсвие между объектами — это их композиция, а уж никак не "наследование скрытого состояния".
Так что "глубокий изъян" это, видимо, стремление к максимальной простоте.
Здравствуйте, eao197, Вы писали:
E>Это я и так понимаю, запоминается writter куда? В атрибут. И, вероятно, не public-атрибут.
Естественно. Но тут нет никакого наследования от какого-либо самостоятельного класса объектов. Здесь речь идет о композиции объектов.
E>Сергей, вы не понимаете суть вопроса. Пусть сначала Formatter был связан с writter-ом, который связан с файлом. Затем какому-то потомку захотелось перевязать этот же Formatter на writter, который связан с pipe. Можно ли такое допускать? E>А почему нет? Пусть у меня есть Formatter, который строит XML и передает его в writter. Затем я делаю потомка для этого Formatter, который перед построением XML переводит все строки в UTF-8. Разве это запрещено? И нужно ли моему Utf8XmlFormatter-у знать, где XmlFormatter хранит ссылку на writter?
Нет никаких потомков! Класс Formatter не является потомком от класа Writer. Это разные классы.
Самостоятельному объекту formatter ничего не известно о том куда самостоятельный объект writer осуществляет вывод.
Carrier, Reader, Writer, Scanner, Formatter, Client — это композиция из 6 разных объектов (классы которых не связаны друг с другом никаким отношением наследования). Стрелочки на рисунке обозначают поток информации от/в носител(я) Carrier, в роли которого может выступать кто угодно (File, Stream, Socket, ...) из/в Client.
Этот паттерн проектирования называется Carrier-Rider-Mapper.
Reader и Writer — это Rider-ы
Scanner и Formatter — это Mapper-ы
Каждый Carrier реализует свои собственные Reader и Writer (нет никакого наследования от других самостоятельных классов объектов).
Каждый Client реализует нужные только ему Scanner и Formatter (нет никакого наследования от других самостоятельных классов объектов).
Количество реализаций равно N + M, где N — количество разных Carrier-ов, а M — количество разных Client-ов. Если не использовать этот паттерн, а заставлять каждого клиента уметь работать непосредственно с каждым карриером, то количество реализаций взаимодействия из суммы N + M превратится в произведение N * M, что неэкономно.
И, кстати, подилом. Дурь это.
