1 - это просто класс с набором абстрактных методов. общих и необходимых для взаимодействия B с Ax, какие могут быть трудности с поддержкой?
Трудностей нет, а поддерживать (следить за актуальностью) нужно, что само по себе минус. Лучше не иметь то, что нужно поддерживать, если оно не приносит пользу. Пользу в TAbstractFoo я пока не вижу — и это я говорю не фигурально, я действительно не понимаю чем оно помогает.
Я понимаю зачем нужны абстрактные классы при использовании наследования и виртуальных методов по назначению (когда мы пишем общий код, работающий с разными типами потомков).
2 - ненадо создавать TAbstractFoo, надо создавать TFoo и передавать его из Ax в B. В ничего не знает о TFoo и работает с ним как будьто это TAbstractFoo.
Я говорил про «в некоторых вариантах не все методы есть». Если TAbstractFoo содержит абстрактные методы, которые могут быть не реализованы в TFoo, то это может привести к падающей в реалтайме программе. Или мы говорим про разное? Поправьте.
3 - нужны, что за задача такая что виртуальный метод даст заметный проигрышь статическому? на деле этим можно пренебречь
Пишу для себя фреймворк :) Программа использует фреймворк и не думает о платформах и внешних библиотеках, фреймворк внутри использует правильное в зависимости от настроек компиляции api. Хочу высокий уровень без потерь преимуществ низкого — концептуально это возможно.
Не для того я компиляторами пользуюсь, чтобы на производительность забивать.
4 - из пушки по воробъям, как собственно 3. Если это критично, то нечего использовать классы вообще, юзайте процедуры
Я использую object'ы и обычные методы можно считать обычными процедурами.
zub писал(а):а вот вещи типа
- Код: Выделить всё
type
ImplTFoo = TFoo;
TFoo = ImplTFoo;
это точно ничего хорошего не принесет
Я хочу простую вещь модульного программирования! :) Внутри B пробросить наружу тип, который видит сам B. Концептуально вещь элементарная и весьма естественная. Я был бы рад другому способу это сделать, советуйте.
Ответ в стиле «это сделать невозможно, поэтому переделывайте всю архитектуру и смиритесь с другими недостатками» очень грустный, не правда ли?
Что в задаче необычного? Другое дело что постоянно меняются условия, сначала перичислимое, потом класс, потом отказ от виртуальности...
Чтобы меня правильно поняли: я изначально дал минимальную информацию, чтобы задать вопрос, но мне дают советы, выходящие за рамки поставленного вопроса, и чтобы объяснить чем мне советы не подходят, приходится расширять условие задачи и объяснять мою мотивацию. Я могу сформулировать общую задачу целиком, если хотите.
Мне кажется, что у вас нетривиальная задача с декомпозицией, и решить ее, не вникая в детали, не удастся. Не для форума тема, короче.
В том-то и дело, что нет, всё очень плоско и тривиально. Для решения моих проблем не хватает сущих досадных мелочей! Например, вменяемого пробрасывания типов.
