sedminВо-первых, чтобы твои предложения не затерялись, ты пиши их в отдельную ветку.
sedmin писал(а) 01. Июня 2006 :: 04:55:1. В defcls.prm указывать только расположение файла класса. Все описание класса иметь в файле класса. В том числе его иерархия, параметры по умолчанию, и т.д.
Примерно как в Яве.
Тема такая поднималась, но дело не пошло. Не помню, почему.
Цитата:2. Иметь возможность загрузить все файлы классов из каталога. Опять же как в Яве.
Это, думаю, возможно. Но если делать, то делать оба пункта вместе.
По обоим пунктам перспективы туманные, т.к. не понятно, кто это будет делать.
Но в багзиллу написать можно.
Цитата:Мое мнение: ну его нафиг, такое счастье. Давайте не будем делать того, в чем нет потребности. (Мантра экстемальных программистов: "Нам это никогда не понадобится".)
Да уж, зачем делать то в чем
у вас нет потребности. Я критику просил, а не эмоциональное отношение.
Проблему сейчас вижу в одном - не будет отладки. Не проблема, я обойдусь.
Зачем это нужно.Представь, у меня есть грубо многофирменная Торговля и разные Бухгалтерии (это базы).
Есть механизм переноса документов, который нужно сделать удобным и надежным.
Для этого мы объявляем интерфейс:
Цитата:// основной класс обработки данных
class transfer
{
[pure] virtual ФильтрФирм(); // это виртуальная или чисто виртуальная функция
[pure] virtual ФильтрКонтрагентов();
[pure] virtual КонверторСкладов();
}
// фильтр документов по фирме
// класс transfer_filter_firm
{
virtual ФильтрФирм(); // конкретный фильтр по фирме
}
// фильтр документов по контрагенту
// класс transfer_filter_customer
{
virtual ФильтрКонтрагентов();
}
// конвертор складов
// класс transfer_convertor
{
virtual КонверторСклад();
}
В обработке переноса данных мы конструируем класс переноса в зависимости от текущей ситуации.
Нужен фильтр по фирме - пожалуйста, нужен фильтр по контрагенту - нате, нужна замена складов на один - нет проблем.
И заметь, это чистое ООП, без каких-либо нарушений, это полиморфизм в чистом виде.
Если у меня n фильтров и m конверторов, мне нужно описать всего m+n+1 классов, реализующих интерфейс.
Если делать сейчас, то мне потребуется m*n классов, которые будут описывать возможные сочетания.
Поэтому сейчас эта задача не реализуема красиво. Реально - вообще не реализуема.
Да, конечно, фильтры и конверторы можно делать в одной процедуре через параметры.
И еще можно в лаптях ходит и ездить на кобыле.
Кроме того, я уже высказывал идею насчет динамического создания
модулей классов.
Сюда она также отлично вписывается.
Я уже практически не вижу возможности
не реализовывать эти предложения.
Однако если в логике есть реальные проблемы, прошу высказываться.
Все мнения обязательно буду учитывать.
Страницы: 
Полиморфизм ЗаменитьЭксзБазовогоКласса (число прочтений - 86105 )
