Наследование

Тема в разделе "Delphi - FAQ", создана пользователем Mun2, 5 авг 2009.

  1. Mun2

    Mun2 Гость

    Здравствуйте!
    у меня такой вопрос возник:

    описывается класс
    TParentClass = Class
    fa: double;
    ...
    end;

    можно ли все классы ,порожденные от него, например,

    TClass1 = Class(TParentClass)
    //fa: String;
    ...
    end;

    "вынудить" ввести поля с теми же именами, что и в родительском классе, но других типов.

    т.е. своего рода аналог применения VIRTUAL; Abstract; но только не для методов, а полей объекта?
     
  2. Titan

    Titan Well-Known Member

    Регистрация:
    10 июн 2004
    Сообщения:
    105
    Симпатии:
    0
    А что Variant не походит ?
     
  3. Mun2

    Mun2 Гость

    наверное не совсем ясно вопрос описал.
    поле в родительском может быть любого типа, если в потомке объявим поле с таким же именем, но другого типа, то оно перегрузится. и без Vаriant это произойдет.

    проблема в том, чтобы объявить в родителе какие-то поля, не важно какого типа, чтобы они ОБЯЗАТЕЛЬНО были перегружены(переопределены) в потомках.
     
  4. vital

    vital Больной Компом Детектед

    Регистрация:
    29 янв 2006
    Сообщения:
    2.468
    Симпатии:
    27
    Ну так.. Переопределяйте в потомках и добавляйте директиву Overload, которая для этого и придумана и, если я вас правильно понял, будет вам счастье)
     
  5. Mun2

    Mun2 Гость

    TParentClass = Class
    fa: double;
    ...
    end;

    TClass1 = Class(TParentClass)
    fa: String;
    ...
    end;

    будет ли)
    поля перегружаются и без Overload.
    проблема в том, что в потомке это поле может быть не объявлено вовсе.
    задача: вынудить разработчика переопределить тип каждого поля, объявленного в родителе.
    возможно ли такое вовсе?
     
  6. vital

    vital Больной Компом Детектед

    Регистрация:
    29 янв 2006
    Сообщения:
    2.468
    Симпатии:
    27
    Дурная затея какая-то. Ведь наследование для того и придумано, что бы использовать старый функционал, добавляя к нему новый. А у вас получается вроде как наследование, но при этом, писать нужно все-равно все заново.. Бред какой-то)
     
  7. Mun2

    Mun2 Гость

    верю) потому и спросил вовсе реализуемо ли это.
    здесь идея наследования заключается лишь только в объявлении переменных.
    попробую поменять идею, раз уж она так похожа на бред <_<

    Variant работает только с родными типами?
     
  8. zubr

    zubr Гость

    Сделай родительский класс таким:
    Код (Text):
    TTest = class
    private
    FPole: string;
    protected
    function GetPole: variant; virtual; abstract;
    procedure SetPole(value: variant); virtual; abstract;
    property pole: variant read GetPole write SetPole;
    end;
    Тогда разработчик в наследуемом классе будет вынужден переопределять методы Get, Set - иначе у него будет Abstract error выскакивать.
     
  9. Mun2

    Mun2 Гость

    у меня потомка к TTest компилит без вопросов :unsure:

    Код (Text):
    type
    TTestChild = class (TTest)
    procedure some;
    end;

    implementation
    procedure TTestChild.Some;
    begin

    end;
     
  10. vital

    vital Больной Компом Детектед

    Регистрация:
    29 янв 2006
    Сообщения:
    2.468
    Симпатии:
    27
    Компилить оно будет. При использовании будет ошибка.. Или нет?
     
  11. Titan

    Titan Well-Known Member

    Регистрация:
    10 июн 2004
    Сообщения:
    105
    Симпатии:
    0
    Variant types

    Sometimes it is necessary to manipulate data whose type varies or cannot be determined at compile time. In these cases, one option is to use variables and parameters of type Variant, which represent values that can change type at runtime. Variants offer greater flexibility but consume more memory than regular variables, and operations on them are slower than on statically bound types. Moreover, illicit operations on variants often result in runtime errors, where similar mistakes with regular variables would have been caught at compile time. You can also create custom variant types.

    By default, Variants can hold values of any type except records, sets, static arrays, files, classes, class references, and pointers. In other words, variants can hold anything but structured types and pointers. They can hold interfaces, whose methods and properties can be accessed through them. (See Object interfaces.) They can hold dynamic arrays, and they can hold a special kind of static array called a variant array. (See Variant arrays.) Variants can mix with other variants and with integer, real, string, and Boolean values in expressions and assignments; the compiler automatically performs type conversions.
     
  12. Mun2

    Mun2 Гость

    добавил

    Код (Text):
     private
    FPole: string;
    protected
    function GetPole: variant; virtual; abstract;
    procedure SetPole(value: variant); virtual; abstract;
    property pole: variant read GetPole write SetPole;
    в своего предка. Программа, использующая потомков работает как и раньше.
    Не вызывает ни хинтов, ни предупреждений...
     
  13. zubr

    zubr Гость

    Mun2
    ну а теперь попробуй создать класс-потомок, затем создай объект класса-потомка и обратись в программе к свойству pole
     
  14. Mun2

    Mun2 Гость


    спасибо! :)

    интересный подход :) спасибо :(
     
  15. Mun2

    Mun2 Гость

    быть может в такой ситуации применение интерфейса будет более оптимально?
    иль класс только реализует интерфейс, а не наследует его?
     
  16. vital

    vital Больной Компом Детектед

    Регистрация:
    29 янв 2006
    Сообщения:
    2.468
    Симпатии:
    27
    Мне вот самому интересно что скажет zubr..)
     
  17. zubr

    zubr Гость

    Можно и интерфейс использовать, только тогда в классе-наследнике придется обязательно реализацию интерфейсных методов писать или заглушки.
     
  18. Mun2

    Mun2 Гость

    Интерфейс с обязыванием реализации методов в классе аналогичен классу с (virtual; abstract;) методами.
    Но интерфейс не обязывает объявленные в себе свойства ввести в реализующем классе.
    А основная моя проблема заключалась в этом.

    Код (Text):
     ITest = interface
    procedure proc1;
    function GetStringProp: String;
    property Prop: String Read GetStringProp;
    end;

    TTest = class (TInterfacedObject, ITest)
    FField1: String;
    private
    function GetProp: String;
    procedure proc2;
    function GetStringProp: String;
    //  function GetIntProp: Integer;
    procedure proc1;
    //  property Prop: Integer Read GetIntProp;
    end;
    такой код компилится без претензий по поводу свойства Prop в классе

    Т.е. применение интерфейса в данном случае не лучше и не хуже применения описанного выше "zubr"ом способа с описанием (virtual; abstract;) методов для чтения и записи свойства.
     
  19. etc

    etc Гость

    Ерундой вы занимаетесь, вам надо с архитектурой что-то делать. а вы костыли придумываете.
     
  20. etc

    etc Гость

    Можно и посоветовать, только пока непонятно, что вы делаете. А из того что тут написано, ясно одно - архитектура неправильная.
     
Загрузка...
Похожие Темы - Наследование
  1. Dragon108
    Ответов:
    23
    Просмотров:
    5.531
  2. vladis222
    Ответов:
    4
    Просмотров:
    1.620
  3. vladis222
    Ответов:
    4
    Просмотров:
    1.926
  4. Stashevckiy
    Ответов:
    10
    Просмотров:
    3.161
  5. olimp72
    Ответов:
    2
    Просмотров:
    2.437

Поделиться этой страницей