Перегрузка виртуальных методов

[3D Hunter]

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

[mongolores]

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

[GunSmoker]

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

Вариант первый:

ILogger = interface
  procedure DumpStr(const S: String);
  procedure DumpInt(const I: Integer);
  procedure DumpRAW(const Ptr: Pointer; const Sz: Byte);
end;

Смысл в том, что базовый класс предоставляет некоторые примитивы, которые:
а). Должны быть реализованы конкретным классом-наследником.
б). Могут использоваться классом-наследником для комплексного вызова.

К примеру, DumpXML(const XML: IXMLNode) в наследнике может сводиться к набору вызовов DumpStr.

Вариант 2:

ISerializable = interface
  function ToString: String;
end;

ILogger = interface
  procedure Dump(const AItem: ISerializable);
end;

Иными словами, базовый класс умеет работать с некоторым универсальным элементом. Тип этот должен поддерживать все операции, которые тебе могут понадобится от элемента лога. А все классы-наследники должны будут приводить свои конкретные типы (XML, String и т.п.) к этому универсальному типу. Причём тут будут не только наследники логгера, но и кастомные реализации ISerializable. Теоретически, их можно использовать исключительно парами.

[3D Hunter]

ТС, обойдите проблему внимательно вокруг сделать класс прилагательно к чему? К логгеру, чтобы он мог логгировать в разных фоматах: xml, html, txt и т.д. Что передавать параметром в абстрактный виртуальный метод исходного класса-предка? Правильно, текст события для логгирования, т.е. строку. Так почему бы не сделать всю реализацию логгирования локальной в соответствующих методах классов-потомков? Например, вы переопределяете метод Log(const AStr:AnsiString). Вот в нем и записывайте строку в том формате, в котором вам надо. Т.е. не нужно параметром передавать КОНЕЧНЫЙ формат данных, а лучше ИСХОДНЫЙ. Надеюсь, мысль понятна.

[mongolores]

GunSmoker, спасибо, попробую поработать над интерфейсами.
3D Hunter, да, изначально так и планировал. Но сразу столкнулся со сложностью, что лог-сообщение может быть не только "плоской" строкой, но и структурированной. И если я передам такую строку в класс, который работает с XML форматом, то в этой процедуре Log(const AStr:AnsiString) мне придется каким-то образом парсить строку, чтобы получить в итоге что-то типа
<ENTRY>
<DATETIME>2012-05-10 12:25:20</DATETIME>
<MODULE>Sheduler</MODULE>
<MESSAGE>Task execution is finished</MESSAGE>
</ENTRY>

[3D Hunter]

Так используйте перегрузку методов, чтобы передавать столько параметров, сколько вам надо в данном потомке (например, то же время, имя модуля и текст лога для xml-логгера).
Зачем вы так рьяно и шаблонно следуете концепциям ООП? Кто сказал, что нужно программировать ТОЛЬКО так? Кажется, вы сами придумали себе ограничение и пытаетесь его преодолеть.

[mongolores]

Передо мной была также поставлена задача учесть и то, что лог-сообщением может выступать не только строка (собственно, и XML же по сути это набор символов, только структурированный), но и полноценный объект, который также придется скидывать в файл, т.е. делать сериализацию. И вот тут уже объект как строку не передашь (хотя наверное все что угодно можно перевести в набор символов, но разве это будет самым элегантным решением?).
На решение создать один базовый класс, как я описал в самом начале, подтолкнуло то, что по сути круг задач для логгера в принципе то один: как минимум скинуть некий лог в файл. А вот научить классы-потомки работать с разными типами этих сообщений выросло вот в этот "огород".

[mongolores]

3D Hunter, да-да, получается, что я когда-то узнал, что можно создавать общий класс, который будет решать задачи в общем виде, а от него уже плясать дальше. И значит пока не хватает опыта, чтобы определиться до каких пор нужно "так рьяно следовать концепциям ООП". Хотя изначально, умозрительно, задача казалась простой: есть базовый класс-шаблон, нужно лишь разработать несколько производных от него классов, которые будут по своему реализовывать запись в файл ))
Благодарю за дельные советы

[=master=]

А как вы собираетесь использовать? я к тому что, а оно надо ваще эта абстракция?

[mongolores]

Я собирался передавать в процедуру потомка лог-запись определенного типа. Концепция казалось простой. Теперь я вижу, что проще отказаться от такой абстракции. Но, как говорится, осадочек остался. Стало безумно интересно как бы эту задачу решили например ребята из Борланда? А так конечно мне еще придется очень многому научиться, в том числе и у всех вас.