Встроенные классы

← →
upc (2011-11-30 23:20) [0]

Использовать встроенные классы - плохо?

type TMyClass = class type TMySubClass = class ... end; ... end;

← →
Кто б сомневался © (2011-11-30 23:25) [1]

А нахрена это надо?
Ну то что оно затрудняет читабельность кода это факт, а вот зачем это надо по факту кто знает? Видимо чтобы структурировать классы. Хотя опять же, проще структурировать классы по модулям либо отделять комментами.

Интересно классы как то автоматом связываются? Например срабатывает ли конструктор автоматом у дочернего класса?

← →
DVM © (2011-11-30 23:33) [2]

> Например срабатывает ли конструктор автоматом у дочернего
> класса?

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

> Использовать встроенные классы - плохо?

Не плохо. Но я не использую. Привык так.

← →
DVM © (2011-11-30 23:36) [3]

> upc (30.11.11 23:20)

Чтобы ответить самому себе на свой вопрос подумай, что дает определение одного класса внутри другого. Вот и поймешь.

← →
upc (2011-11-30 23:40) [4]

Мне это дает то, что я могу ссылаться на TMyClass из TMySubClass и наоборот.
Или когда у меня возникает такая необходимость - это не хорошо?

← →
Petr V. Abramov © (2011-11-30 23:52) [5]

> Использовать встроенные классы - плохо?

это как молоток, не хорошо и не плохо.
кто-то гвоздь забьет эффективнее, чем плоскогубцами, а кто-то и гвоздь погнет, и обои портит, и без пальцев останется, и врачам работы прибавит.

← →
DVM © (2011-12-01 00:15) [6]

> upc (30.11.11 23:40) [4]
> Мне это дает то, что я могу ссылаться на TMyClass из TMySubClass
> и наоборот.

но это можно утроить и без вложенных классов.

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

← →
Ega23 © (2011-12-01 00:16) [7]

> А нахрена это надо?

Дабы скрыть от шаловливых ручек внутренний класс.
Использую. Не часто, но использую. Вот не далее как сегодня (точнее, уже вчера):

type TDocumentReader = class strict private type TTokenPos = record case Integer of 0 : (PosOnPage, PageNr: Word); 1 : (AbsValue: Cardinal); end; strict private type TParagraphAlign = (paToStart, patoStop); private function GetNextToken(Value: TTokenPos): TTokenPos; function GetPrevToken(Value: TTokenPos): TTokenPos; ...... public ..... end;

← →
Ega23 © (2011-12-01 00:22) [8]

> Мне это дает то, что я могу ссылаться на TMyClass из TMySubClass
> и наоборот.

TParentClass = class; TChildClass = class private FParent: TParentClass; public constructor Create(aParent: TParentClass); end; TParentClass = class private FItems: TObjectList<TChildClass>; public constructor Create; destructor Destroy; override; function AddChild: TChildClass; end;

И никаких внутренних классов.

← →
Petr V. Abramov © (2011-12-01 00:42) [9]

> Ega23 © (01.12.11 00:16) [7]
>
>
> > А нахрена это надо?
>
>
> Дабы скрыть от шаловливых ручек внутренний класс.

по белым ручкам бы да упомянутым инструментом.
при реализации DOA голландцы толи курнули, толи не прочитали документацию до конца, толи был глюк OCI, когда DOA писали, в результате лезет с десяток нефиговых roundtrip`ов к базе, которые сводят на минус кошернейшую фичу (bulk binding с клиента).
в общем и целом DOA написано хорошо, проблему можно было бы решить наследованием от их компонентов, но: много вспомогательных классов - в implementation и довольно самодостаточных методов в private...
теперь приходится городить якобы свой огород путем надергивания больших кусков их исходников.

← →
upc (2011-12-01 00:43) [10]

> Ega23 © (01.12.11 00:22) [8]

Спасибо! Буду знать!
Но по сути, если у меня сейчас сделано на встроенных классах, то в этом нет ничего плохого, или стоит переделать?

← →
upc (2011-12-01 00:44) [11]

Переделаю всё-таки, а то как-то не очень.

← →
Ega23 © (2011-12-01 00:53) [12]

> Переделаю всё-таки, а то как-то не очень.

Ну вот простой пример.
Есть у нас класс-калькулятор (TCalculator). Задаёшь ему строку с формулами всякими, он её парсит и вычисляет.
Есть у него внутренний класс (TCalcItem). Тип, значение, children и т.п.
Товарищу, который этот юнит использует, про этот класс знать вообще ничего не надо, это чисто внутренняя сущность класса калькулятор и "наружу" она не показывается.
Но.
Если мы объявим это дело так, как в [8] - при подключении данного юнита пользователь увидит этот вспомогательный класс, т.к. он в интерфейсной секции описан.
А вот если сделаем, как в [7] - не увидит, что суть хорошо.

Другой простой пример: TTreeView и TTreeNode. Вот тут уже скрыть это дело нельзя, т.к. сам класс TTreeNode нужен пользователю. Тут обратная ситуация.

Ну а как уж нужно тебе - это дело сугубо твоё.

← →
Ega23 © (2011-12-01 00:55) [13]

> в общем и целом DOA написано хорошо, проблему можно было
> бы решить наследованием от их компонентов, но

Кривая архитектура, конечно, не так фатальна, как ошибочная женитьба. Но тоже крайне некошерна.

← →
upc (2011-12-01 01:13) [14]

Удалено модератором

> Понял. Но к TCalcItem всё равно можно "достучаться" через
> TCalculator.TCalcItem...

Нет. Потому, что оно в секции strict private объявлено.

← →
Компромисс (2011-12-01 09:34) [17]

> в общем и целом DOA написано хорошо, проблему можно было
> бы решить наследованием от их компонентов, но: много вспомогательных
> классов - в implementation и довольно самодостаточных методов
> в private...
> теперь приходится городить якобы свой огород путем надергивания
> больших кусков их исходников.

Вот поэтому лучше бы они protected использовали по умолчанию.

← →
iZEN (2011-12-01 09:42) [18]

> Кто б сомневался © (30.11.11 23:25) [1]
>
> А нахрена это надо?

Как нахрена?

Встроенные классы в ООП-языках аналогичны лямбде LISP"а (анонимные функции). http://ru.wikipedia.org/wiki/Лямбда-исчисление
А анонимные вложенные классы, к тому же, реализуют концепцию замыкания. http://ru.wikipedia.org/wiki/Замыкание_(программирование)

← →
upc (2011-12-01 11:13) [19]

Встроенные классы Найти похожие ветки