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

← →
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.

← →
VMcL © (2005-05-31 07:32) [52]

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

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

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

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

← →
Alexander Panov © (2005-05-31 10:00) [53]

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

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

← →
Alexander Panov © (2005-05-31 10:00) [54]

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

← →
Игорь Шевченко © (2005-05-31 10:33) [55]

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

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

← →
Alexander Panov © (2005-05-31 11:04) [56]

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

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

← →
Игорь Шевченко © (2005-05-31 11:40) [57]

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

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

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

← →
DiamondShark © (2005-05-31 12:06) [58]

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

← →
Alexander Panov © (2005-05-31 12:09) [59]

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

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

← →
begin...end © (2005-05-31 12:12) [60]

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

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

StringList.CustomSort(...)

:-)

← →
Игорь Шевченко © (2005-05-31 12:14) [61]

DiamondShark © (31.05.05 12:06) [58]

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

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

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

CustomSort вызывать ?

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

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

← →
Alexander Panov © (2005-05-31 12:16) [62]

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

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

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

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

← →
DiamondShark © (2005-05-31 12:26) [63]

> Игорь Шевченко © (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-метод в наследнике. Найти похожие ветки