Скрыть public-метод в наследнике.

← →
Alexander Panov © (2005-05-30 20:10) [0]

Как можно скрыть public-метод в наследнике класса?
К примеру, TStringList имеет 2 метода - Add и AddObject.
Как сделать невидимым для наследника метод Add?

← →
Гаврила © (2005-05-30 20:12) [1]

В принципе никак не сделаешь.
Ибо всегда можно закастить под предка и вызвать метод

← →
Alexander Panov © (2005-05-30 20:14) [2]

Гаврила © (30.05.05 20:12) [1]

А если без приведения типов?
Например:

TGetList=class(TStringList) private function Add: Integer; reintroduce; end;

В этом случае цель достигается, но получаем хинт, что метод нигде не используется.

← →
begin...end © (2005-05-30 20:16) [3]

> Alexander Panov © (30.05.05 20:10)

Сужение области видимости невозможно. Если бы это было возможно, то и полиморфизма не было бы.

← →
Alexander Panov © (2005-05-30 20:17) [4]

Ладно.
Спасибо всем.
Буду Exception выдавать в случае использования.

← →
Anatoly Podgoretsky © (2005-05-30 20:28) [5]

Alexander Panov © (30.05.05 20:10)
И зачем? Психологичестки мешает? Если он виртуальный то сделай пустой в наследники, а также можно и скрыть через reintroduce

← →
Alexander Panov © (2005-05-30 20:33) [6]

хм.
Я, наверное, немного ввел в заблуждение.
Хотел сказать - скрыть в наследнике от наследника.

TGetList=class(TStringList) private function Add: Integer; reintroduce; public constructor Create; end; TGetChildList=class(TGetList) end; constructor TGetList.Create; begin Add; end;

В принципе, если перенести метод в private-секцию, как заглушку и использовать при вызове, например, конструктора, то хинт выдаваться не будет.-)
И в наследнике не видно.

← →
Alexander Panov © (2005-05-30 20:35) [7]

Anatoly Podgoretsky © (30.05.05 20:28) [5]
И зачем? Психологичестки мешает? Если он виртуальный то сделай пустой в наследники, а также можно и скрыть через reintroduce

А ведь пользователь класса ожидает, что метод работает по аналогии с родительским классом. Хотелось бы исключить любую ошибку.

← →
Anatoly Podgoretsky © (2005-05-30 20:37) [8]

Alexander Panov © (30.05.05 20:35) [7]
Возбуди исключение, это самый нормальный метод. И документируй

← →
Alexander Panov © (2005-05-30 20:43) [9]

Anatoly Podgoretsky © (30.05.05 20:37) [8]
Возбуди исключение, это самый нормальный метод. И документируй

А метод в [6] не подойдет?

← →
Чапаев © (2005-05-30 21:06) [10]

Можно "предка" сделать приватным/защищённым полем "наследника" и делегировать нужные методы... Но это, конечно, не то, что хотел бы автор.

← →
Anatoly Podgoretsky © (2005-05-30 21:12) [11]

Alexander Panov © (30.05.05 20:43) [9]
Я не понял его, особенно его вызов в Create.
Я никогда не пробовал сделать так, проверь сам пройдет или нет.

function Add: Integer; virtual; abstract; reintroduce;

Если получится то ты будешь иметь новую цепочку наследования и одновременно абстрактный метод, скрывающий метод предка.

← →
Alexander Panov © (2005-05-30 21:28) [12]

Anatoly Podgoretsky © (30.05.05 21:12) [11]
такая цепочка не проходит, к сожалению.

← →
Anatoly Podgoretsky © (2005-05-30 21:32) [13]

А жаль, я так надеялся. Ну тогда без abstract

← →
Defunct © (2005-05-30 21:41) [14]

Извиняюсь за возможную грубость.

> В этом случае цель достигается, но получаем хинт
Ой ли, а не пофигу на тот хинт?

← →
BFG9k © (2005-05-30 21:43) [15]

> В принципе, если перенести метод в private-секцию, как заглушку
> и использовать при вызове, например, конструктора, то хинт
> выдаваться не будет

Дался тебе этот хинт. Хинты - обычное дело. Например при любом использовании PChar дельфи ругается - unsafe type. У нас своя голова за плечами :)

← →
Alexander Panov © (2005-05-30 21:44) [16]

Defunct © (30.05.05 21:41) [14]
Ой ли, а не пофигу на тот хинт?
BFG9k © (30.05.05 21:43) [15]
Дался тебе этот хинт. Хинты - обычное дело. Например при любом использовании PChar дельфи ругается - unsafe type. У нас своя голова за плечами :)

У меня перед релизом не остается хинтов в программе.

← →
Defunct © (2005-05-30 21:46) [17]

Alexander Panov © (30.05.05 21:44) [16]

Ясно, значит дело принципа ;>
и Pointer вы никогда не используете и PChar?

← →
Alexander Panov © (2005-05-30 21:49) [18]

Defunct © (30.05.05 21:46) [17]

Использую, конечно.

← →
Defunct © (2005-05-30 22:09) [19]

Alexander Panov © (30.05.05 21:49) [18]

А как же ж удается используя Pointer и PChar избегать всех hint"ов?

← →
Alexander Panov © (2005-05-30 22:21) [20]

Defunct © (30.05.05 22:09) [19]
Приведи пример, в которм хинты выдаются?

← →
Defunct © (2005-05-30 22:40) [21]

Alexander Panov © (30.05.05 22:21) [20]

const
Someconst : PChar = "А вот и хинт";

type
TSomerecord = Record
Addr : Pointer; // А вот и второй хинт
...
End;

Someproc = Procedure(Addr:Pointer); // третий хинт

Могу привести еще

← →
Alexander Panov © (2005-05-30 22:42) [22]

Defunct © (30.05.05 22:40) [21]
Странно, у меня нет хинта ни в одном из 3-х примеров.
(D6)

← →
Гаврила © (2005-05-30 22:43) [23]

Саш, хинт - не проблема, его можно погасить соответствующей директивой
{$HINTS OFF}
Я не совсем пойму - зачем это надо
2 Вопроса
1 кто будет пользоваться классом - потомком - ты или не ты?
2. метод статический или виртуальнй?

← →
Гаврила © (2005-05-30 22:46) [24]

Если взять именно этот пример (Add, AddObject), то лучше наверно сделать так: переписать метод Add в секции паблик, но добавиьт параметр (сделать так же, как и в AddObject) (если например в стринг листе не должно оказаться итемов без обжектов)

← →
Defunct © (2005-05-30 22:46) [25]

Alexander Panov © (30.05.05 22:42) [22]

Простите, Warning а не Hint в D7 звучит так:

1 - "Unsafe type PChar"
2 и 3 - "Unsafe type Pointer"

← →
Anatoly Podgoretsky © (2005-05-30 22:48) [26]

Гаврила © (30.05.05 22:43) [23]
function Add(const S: string): Integer; override;
У предка
function Add(const S: string): Integer; virtual;

← →
Anatoly Podgoretsky © (2005-05-30 22:50) [27]

Alexander Panov © (30.05.05 22:42) [22]
Появится в Д7, там это уже не безопасные типы, из-за .NET.

← →
Alexander Panov © (2005-05-30 22:51) [28]

К сожаленю, я ошибся - спрятать метод все равно не удалось.
Это возможно только при условии вынесения предка в другой модуль, как я понял.

← →
Alexander Panov © (2005-05-30 22:53) [29]

Ну что же, спасибо всем.
Похоже, что фокус не удастся.
---------
PS.
Гаврила © (30.05.05 22:43) [23]
1 кто будет пользоваться классом - потомком - ты или не ты?

Пользоваться буду я. Но ведь не надо зарекаться-)

← →
Anatoly Podgoretsky © (2005-05-30 22:56) [30]

Ну спрятать невозможно по определению, можно начать новую цепочку наследования.

← →
Alexander Panov © (2005-05-30 22:59) [31]

Anatoly Podgoretsky © (30.05.05 22:56) [30]

Да, увы мне-)

← →
Anatoly Podgoretsky © (2005-05-30 23:06) [32]

Все таки так и осталось не понятным почему именно хочешь скрыть, ведь вполне достаточно изменить поведение, только надо учитывать и другие методы, например этот метод вызывает Insert который у предка как раз абстрактный, в отличии от Add, также еще есть и ряд других аналогичных методов.

Может надо подумать над перепроектированием? Что то хдесь не то, раз такое потребовалось.

← →
Alexander Panov © (2005-05-30 23:11) [33]

Anatoly Podgoretsky © (30.05.05 23:06) [32]
Кратко опишу задачу:

Наследник от TStrinList используется для хранения списков объектов.

В наследнике объекты можно добавлять только методом AddObject(тоже переписанным).

← →
Alexander Panov © (2005-05-30 23:12) [34]

Это делается для того, чтобы список формироваля строго по определенным правилам.

← →
Eraser © (2005-05-30 23:14) [35]

Alexander Panov ©

А почему именно наследник от TStringList, а не TList например?

← →
Alexander Panov © (2005-05-30 23:17) [36]

Eraser © (30.05.05 23:14) [35]
т

Мне необходимо наличие свойства Strings...

← →
Anatoly Podgoretsky © (2005-05-30 23:18) [37]

Alexander Panov © (30.05.05 23:12) [34]
Почему бы не написать в наследнике методы, которые будут вызывать скажем исключение если они будут вызваны? Благо все они виртуальные или изменить их поведение, чтобы они следовали твоим требованиям. Ну не вижу острой необходимости скрывать.

← →
Alexander Panov © (2005-05-30 23:18) [38]

Eraser © (30.05.05 23:14) [35]

По существу, в Strings хранятся ключи, по которым производится сортировка и поиск.

← →
Alexander Panov © (2005-05-30 23:19) [39]

Anatoly Podgoretsky © (30.05.05 23:18) [37]

Анатолий, я уже понял, что не удастся скрыть-)
Поэтому последую твоему совету - перепишу метод с исключением.

← →
Anatoly Podgoretsky © (2005-05-30 23:22) [40]

Alexander Panov © (30.05.05 23:19) [39]
Только просмотри все методы, чтобы не оказалось неожиданных обходных путей, например Delete ведь и удаление наверно должно следовать новому поведению. Все методы InsertXXX

← →
Alexander Panov © (2005-05-30 23:23) [41]

Anatoly Podgoretsky © (30.05.05 23:22) [40]
Ну пока вот так класс-наследник определен.
от него будут наследоваться уже остальные.

TMasterList=class(TStringList) private // FDB: IDBInterface; //Интерфейс для работы с БД // FNet: INetInterface; //Интерфейс для работы с сетью FG: TGuard; //Для работы с несколькими потоками FSortDirect: Boolean; FQuantity: Integer; procedure Add; reintroduce;//Скрываем метод procedure FreeObject(Index: Integer); procedure CheckKey(aKey: String); //Проверка на пустой ключ function GetKeys: TStringList; function GetForumObject(Index: String): TForumObject; procedure SetForumObject(Index: String; const Value: TForumObject); procedure Enter; procedure Leave; // procedure CheckQuantity; protected function CompareStrings(const S1, S2: string): Integer; override; //Перекрыт для метода QuickSort public constructor Create; virtual; destructor Destroy; override; function AddObject(aForumObject: TForumObject): Integer; reintroduce; procedure InsertObject(Index: Integer; aForumObject: TForumObject); reintroduce; procedure Delete(Index: Integer); reintroduce; overload; procedure Delete(aId: String); reintroduce; overload; procedure Delete(aObject: TForumObject); reintroduce; overload; function IndexOf(const S: string): Integer; override; function Exists(aId: String): Boolean; { function DeleteFromDB(aId: String): Boolean; virtual; function SyncToDB; virtual; function SyncFromDB; virtual; function SetObjectFromDB; virtual; function AddObjectFromDB; virtual; function WriteObjectToDB; virtual; } property Keys: TStringList read GetKeys; property SortDirect: Boolean read FSortDirect write FSortDirect; property ForumObject[Index: String]: TForumObject read GetForumObject write SetForumObject; property Quantity: Integer read FQuantity write FQuantity; end;

← →
Eraser © (2005-05-30 23:24) [42]

Alexander Panov © (30.05.05 23:18) [38]

Ситуация понятна, сам так частенько делаю, в Strings храню UID на объект, но с написанием своего класса не заморачивался...

Как вариант можно использовать IndexOfObject, но о сортировки тут конечно речь не идёт.

Вообще конечно универсальный вариант - наследовать TStrings, а нужные методы переносить Copy/Paste.

← →
Alexander Panov © (2005-05-30 23:25) [43]

Eraser © (30.05.05 23:24) [42]

С TStringList как раз удобно тем, что не надо методы вытаскивать в свой модуль;)

← →
Гаврила © (2005-05-30 23:33) [44]

Я в таком случае сделал бы по варианту [10].
Тем более, если планируется дальнейшее наращивание наследников

← →
palva © (2005-05-30 23:33) [45]

begin...end © (30.05.05 20:16) [3]
> Сужение области видимости невозможно. Если бы это было возможно, то и полиморфизма не было бы.

В языке C++ возможно при определении класса объявить тип наследования. Если он, к примеру, private то публичные методы наследуемого класса в наследующем становятся private.

← →
palva © (2005-05-30 23:51) [46]

palva © (30.05.05 23:33) [45]
Поясню, хотя это, возможно, off topic
#include <iostream.h> class a { public: int i; }; class b : a { public: int j; }; int main() { b bb; bb.j = 7; bb.i = 8; // cannot access public member declared in class "a" cout << "adfasdf"; return 0; }
Если написать публичное наследование (в делфи оно всегда публичное)
class b : public a
то диагностика исчезнет

← →
jack128 © (2005-05-31 00:09) [47]

palva © (30.05.05 23:51) [46]
Если я передам в функцию, которая принемает a, объект реально являющийся b , то такая диагностика не работает..

← →
palva © (2005-05-31 00:24) [48]

jack128 © (31.05.05 00:09) [47]
Это - да. Меня просто смутило утверждение "Если бы это было возможно, то и полиморфизма не было бы" Честно говоря, смутно представляю себе, что такое полиморфизм, но в C++ это возможно.

← →
default © (2005-05-31 00:29) [49]

palva © (31.05.05 00:24) [48]
jack128 имеет ввиду что это работает только на стадии компиляции
"сместить" VMT для удаления закрываемого в потомке метода нельзя(по-хорошему) ибо весь полиморфизм работающий на этих VMT поломается

← →
SergP © (2005-05-31 02:04) [50]

> TGetList=class(TStringList)
> private
> function Add: Integer; reintroduce;
> end;

А если не делать TGetList наследником TStringlist? А сделать типа так:

TGetList=class
...
private
SL:TStringList;
...
end;

← →
Alexander Panov © (2005-05-31 02:42) [51]

SergP © (31.05.05 2:04) [50]

Тогда придется переписывать методы для доступа к SL.

>>Alexander Panov © (31.05.05 02:42) [51]

Э-э-э.. так Вам шашечки или ехать? :-)
Если нужно по-честному именно скрыть, то делегирование, IMHO, один из лучших вариантов. Если не единственный.

>>SergP © (31.05.05 02:04) [50]

См. [10]. "Всё уже украдено до нас" (c)

VMcL © (31.05.05 7:32) [52]
Э-э-э.. так Вам шашечки или ехать? :-)
Если нужно по-честному именно скрыть, то делегирование, IMHO, один из лучших вариантов. Если не единственный.

Ну скрыть - это ведь побочная задача, и далеко не самая важная-)
Более приоритетная - удобство использования класса.
Поэтому - ну не удалось скрыть, ну и ладно-)

Еще раз спасибо всем за обсуждение.

Не надо использовать наследование. Надо использовать композицию.
Пост [50] наиболее подходящее решение.

Не надо путать программистов всякими reintroduce использующимися не по прямому назначению :)

Игорь Шевченко © (31.05.05 10:33) [55]
Не надо использовать наследование. Надо использовать композицию.

А чем лучше?
Впервые решил использовать наследование, а тут обломать хочешь намерение такое;)

Alexander Panov © (31.05.05 11:04) [56]

"Если родительский класс в большинстве случаев будет "подменять" своего потомка, то используется наследование. Если же родительский класс нужен лишь, чтобы класс-потомок мог использовать некоторые его свойства, то лучшим выбором будет композиция.

Одной фразой: чем больше класс-потомок похож на родительский класс, тем предпочтительнее использовать наследование, а не композицию."

Наследование должно сдохнуть.

Игорь Шевченко © (31.05.05 11:40) [57]

А как, например, изменить порядок сортировки в TStringList без наследования?
Да и большинство свойств родительского кдасса используется по назначению.

> Alexander Panov © (31.05.05 12:09) [59]

> А как, например, изменить порядок сортировки в TStringList
> без наследования?

StringList.CustomSort(...)

:-)

DiamondShark © (31.05.05 12:06) [58]

Вместе с полиморфизмом или отдельно ?

Alexander Panov © (31.05.05 12:09) [59]

> А как, например, изменить порядок сортировки в TStringList
> без наследования?

CustomSort вызывать ?

> Да и большинство свойств родительского кдасса используется
> по назначению.

А зачем тогда такой геморрой с скрытием метода Add ?

begin...end © (31.05.05 12:12) [60]
StringList.CustomSort(...)

Я же не буду после каждой операции со списком CustomSort вызывать?

Игорь Шевченко © (31.05.05 12:14) [61]
А зачем тогда такой геморрой с скрытием метода Add ?

Это, в общем-то, был единственный непонятный на тот момент вопрос.-)

> Игорь Шевченко © (31.05.05 12:14) [61]

Отдельно, конечно.
Для полиморфизма есть своя чёткая, однозначная концепция -- реализация интерфейсов.
Для реюза -- тоже. Композиция.

Наследование, как оно существует в распространённых языках, слишком мутно и перегружено: оно одновременно и описание интерфейса, и реализация интерфейса и реюз кода.

DiamondShark © (31.05.05 12:26) [63]

А вот народ пишет такое:

"Наследование является полезной концепцией программирования, но не всегда стоит прибегать к ней. Зачастую с подобными задачами лучше справляются интерфейсы. Данный раздел и раздел Случаи использования интерфейсов помогут выбрать нужный подход.

Наследование лучше использовать в следующих случаях.

1.Иерархия наследования представляет собой отношения тождественности (is-a), а не отношения включения (has-a).
2.Можно повторно использовать код из базовых классов.
3.Необходимо применить тот же класс и методы к другим типам данных.
4.Иерархия класса содержит довольно мало уровней, и другие разработчики вряд ли будут добавлять в нее другие уровни.
5.Необходимо внести коренные изменения в производные классы путем изменения базового класса. "

http://msdn.microsoft.com/library/rus/default.asp?url=/library/rus/vbcn7/html/vaconwhenuseinheritance.asp

Из диалога с директором школы, получившим в подарок класс ДВК
- Посоветуйте, как нам получить от этого максимальную пользу.
- Этого я не могу. Но могу посоветовать, как получить от этого минимальный вред.

> Игорь Шевченко © (31.05.05 12:48) [64]

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

Посмотрите лучше сюда:
http://zonnon.ethz.ch/papers/Zonnon_Language_Report_v02r02_2_y041101.pdf

Эта, не убивайте ветку, плиз. У меня в свете этого обсуждения тоже вопрос. Просто сейчас некогда. ;0)

Я солидарен с [10] и [50]. Я бы сделал так. Если, конечно, Александру не нужно передавать свой список
куда-то, где ожидается интерфейс базового класса TStringList.

А вообще, все зависит от задачи, которая стоит перед Александром.
В некоторых случаях, я ничего плохого в совете Анатолия (возбуждать исключение) не вижу.

Если не ошибаюсь, то в плюсах можно именно прятать методы/конструкторы/деструкторы.

Это если надо сделать иммитацию абстрактного метода или просто предотвратить неверное использование. Но все определяется задаче, я же подробностей не знаю.

Тут высказывалось отрицательное отношение к наследованию.
Не вижу ничего в нем плохого. ИМХО в дизайне должно быть все сбалансировано.

В качестве баланса могу привести в пример библиотеку "свинг" в java.
Полагаю, что реализованный у них подход по использованию полиформизма и наследования очень лаконичен.

Скрыть public-метод в наследнике. Найти похожие ветки