Здравствуйте, igna, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>ЗЫ. Для .NET существует довольно мощная библиотека OpenXML SDK, можешь там посмотреть как оно делается.
I>Посмотрел. Просто способа использовать, к примеру, WordprocessingDocument как read-only XmlDocument не нашел. Похоже его вообще нет.
Значит без надобности.
Приведи конкретную задачу, которую тебе решить надо.
Здравствуйте, igna, Вы писали:
F>>А кто говорил про изменяемые фигуры? Изменяемые фиругы или неизменяемые — это уже часть описания доступных для них операций. F>>И я про то и говорю — сперва надо определиться с возможными операциями над объектами, потом уже их классифицировать (и в частности — строить иерархии наследования).
I>А ответ на второй вопрос? В каком случае наследование прямоугольника от квадрата не нарушает LSP?
Самый простой — неизменные фигуры.
Или частично неизменные — ну нет у них SetWidth/SetHeight и проблема решена в корне, зато цвет и местоположение менять можно.
А кто сказал что по в любой задаче работющей с квадратами и прямоугольниками им объязательно требуется менять ширину и высоту?
Здравствуйте, gandjustas, Вы писали:
G>А какие операции планируется делать с таким классом? Без этого непонятно почему нарушается LSP (имхо вообще не нарушается).
Проще говоря, для OpenOfficeXmlDocument, должны быть доступны все константные методы XmlDocument, которые не изменяют класс. Подразумевается, что Xml можно читать методами XmlDocument и дополнительными методами OpenOfficeXmlDocument, но модифицировать его можно только методами OpenOfficeXmlDocument (например, нельзя вставлять теги методами XmlDocument).
Если брать Рихтера, то
В некоторых языках, в том числе в неуправляемом C++, можно определять методы и параметры как константы, которые запрещают коду экземплярного метода менять какие-либо поля метода, или объекты, передаваемые в метод. CLR не поддерживает этой возможности, и многие программисты (igna, примечание мое) жаловали на ее отсутствие. Так как исполняемая среда не поддерживает этой функции, естественно, что она отсутствует во всех языках (в том числе в C#)
В некоторых языках, в том числе в неуправляемом C++, можно определять методы и параметры как константы, которые запрещают коду экземплярного метода менять какие-либо поля метода, или объекты, передаваемые в метод.
Честно говоря и в C++ все далеко не так замечательно. Мой пример позволяет преобразовывать OfficeOpenXmlDocument& в const XmlDocument&, но не OfficeOpenXmlDocument* в const XmlDocument*. И писанины больше чем следовало бы. А вот как было бы можно:
class XmlDocument {};
class OfficeOpenXmlDocument : public XmlDocument const {
// . . .
};
void f(XmlDocument const&);
void use_f(OfficeOpenXmlDocument& ooxd)
{
f(ooxd);
}
Здравствуйте, igna, Вы писали:
I>Честно говоря и в C++ все далеко не так замечательно. Мой пример позволяет преобразовывать OfficeOpenXmlDocument& в const XmlDocument&, но не OfficeOpenXmlDocument* в const XmlDocument*. И писанины больше чем следовало бы. А вот как было бы можно:
Это потому, что никто об этом не думал
Лично для меня деление на const и не const методы в некоторых местах напрягает. Главным образом тем, что решив выдерживать везде, где надо, const, я про это забываю и натыкаюсь на ошибки. Ошибки обычно многострочные, и копируются в текстовый редактор, где выравниваются оба типа и выясняется, чего же именно ему не нравится. Конечно, чаще это происходит с очепятками. Так что я не сильно страдаю по этом поводу.
Но а если так сильно надо, то просто на этапе проектирования разделить интерфейсы IXmlReader и IXmlBuilder. Соответственно, XmlDocument поддерживает оба интерфейса, а наш класс агрегирует XmlDocument но поддерживает только IXmlReader.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>ЗЫ. Для .NET существует довольно мощная библиотека OpenXML SDK, можешь там посмотреть как оно делается.
I>Посмотрел. Просто способа использовать, к примеру, WordprocessingDocument как read-only XmlDocument не нашел. Похоже его вообще нет.
Если что файл OOXML это zip-архив с xml и другими файлами (Parts) и связями между ними (Relations).
Поэтому сам WordprocessingDocument как XmlDocument представить нельзя в принципе. Зато можно у корневого элемента некоторого Part-а получить OuterXml и использовать его как захочется, в том числе сделать XmlDocument.
Что касается первого вопроса в теме. То никакой связи WordprocessingDocument и XmlDocument не существует, поэтому ничего не надо делать.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Ни в каком, а вот квадрат вполне может наследоваться от прямоугольника, если весь интерфейс — get_width, get_height и (только для квадрата) get_side.
Аналогично прямоугольник вполне может наследоваться от квадрата, если весь интерфейс — set_width, set_height и (только для квадрата) set_side.
Здравствуйте, gandjustas, Вы писали:
G>Зато можно у корневого элемента некоторого Part-а получить OuterXml и использовать его как захочется, в том числе сделать XmlDocument.
То есть сначала преобразовать "корневой элемент некоторого Part-а" в строку, а затем создать XmlDocument распарсив эту строку.
G>Что касается первого вопроса в теме. То никакой связи WordprocessingDocument и XmlDocument не существует, поэтому ничего не надо делать.ocument и XmlDocument не существует, поэтому ничего не надо делать.
Хорошо, тогда как выразить связь "корневого элемента некоторого Part-а" и XmlDocument-а?
Здравствуйте, igna, Вы писали:
G>>Что касается первого вопроса в теме. То никакой связи WordprocessingDocument и XmlDocument не существует, поэтому ничего не надо делать.ocument и XmlDocument не существует, поэтому ничего не надо делать.
I>Хорошо, тогда как выразить связь "корневого элемента некоторого Part-а" и XmlDocument-а?
Ты еще не понял? Этой связи просто нет.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Ты еще не понял? Этой связи просто нет.
I>Ты еще не понял? Этой связи только в том смысле нет, что .NET не позволяет ее выразить.
А причем тут .NET?
1)Контракты Part_ов ни какой частью не похожи на контракты XmlDocument, поэтому связей is-a быть не может.
2)Реализация Part_ов никак не использует XmlDocument, поэтому has-a и uses тоже отсутствуют.
Наличие какой-либо связи — только у тебя в голове, а переносить такое в код — верный путь к хреновому дизайну.
Совершенно независимо от языка.
Здравствуйте, gandjustas, Вы писали:
G>1)Контракты Part_ов ни какой частью не похожи на контракты XmlDocument, поэтому связей is-a быть не может. G>2)Реализация Part_ов никак не использует XmlDocument, поэтому has-a и uses тоже отсутствуют.
Хорошо, хрен с ними, с Part-ами, возьмем другой пример. Положим я использую библиотеку, в которой есть XmlDocument и хочу при его помощи реализовать MyXmlDocument. MyXmlDocument является read-only XmlDocument-ом, и C++ позволяет это выразить наличием оператора преобразования MyXmlDocument-а в XmlDocument const&, C# похоже никакой сравнимой возможности не имеет, только вот через строку и будешь преобразовывать, причем повторяя преобразование каждый раз при изменении документа.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>Положим я использую библиотеку, в которой есть XmlDocument и хочу при его помощи реализовать MyXmlDocument. MyXmlDocument является read-only XmlDocument-ом, и C++ позволяет это выразить наличием оператора преобразования MyXmlDocument-а в XmlDocument const&, C# похоже никакой сравнимой возможности не имеет, только вот через строку и будешь преобразовывать, причем повторяя преобразование каждый раз при изменении документа.
Ну во-первых const легко обмануть, он не дает никаких гарантий, только немного помогает. Во-вторых, как уже выяснилось в куче холиваров, для mutable и immutable лучше иметь разные интерфейсы. А вот immuutable дает гарантий очень много.
Здравствуйте, igna, Вы писали:
RO>>Ни в каком, а вот квадрат вполне может наследоваться от прямоугольника, если весь интерфейс — get_width, get_height и (только для квадрата) get_side.
I>Аналогично прямоугольник вполне может наследоваться от квадрата, если весь интерфейс — set_width, set_height и (только для квадрата) set_sid
Контравариантность? Теперь бы понять, зачем нужен такой интерфейс «только для записи»?
Здравствуйте, gandjustas, Вы писали:
G>Ну во-первых const легко обмануть, он не дает никаких гарантий, только немного помогает. Во-вторых, как уже выяснилось в куче холиваров, для mutable и immutable лучше иметь разные интерфейсы. А вот immuutable дает гарантий очень много.
А какие именно преимущества immuutable? Не могли бы обьяснит чайнику? Или ссылочку на статью какую-то... )))
Здравствуйте, OlgaNaft, Вы писали:
ON>Здравствуйте, gandjustas, Вы писали:
G>>Ну во-первых const легко обмануть, он не дает никаких гарантий, только немного помогает. Во-вторых, как уже выяснилось в куче холиваров, для mutable и immutable лучше иметь разные интерфейсы. А вот immuutable дает гарантий очень много.
ON>А какие именно преимущества immuutable? Не могли бы обьяснит чайнику? Или ссылочку на статью какую-то... )))
1)Не требуются блокировки
2)Возможность шарить части объектов
3)Проще писать, immutable можно передать куда угодно и принять откуда угодно и знать что никто ничего плохо с ним не сделает (в отличие от const).
В КСВ этот вопрос обсуждался, но я не помню в какой теме.
