Спасибо! А вот надо ли бороться за сокращение времени жизни объекта?
Зачем!? Нормально написанный класс никак не "напрягает"
ни систему ни другие обьекты. Если, конечно, размер
данных, используемый этим обьектом, не превышает разумных
границ! Или, к примеру, в коде какого-либо метода этого
обьекта не используются бесконечные циклы, написанные,
к тому-же, без учета правил много -задачности и -поточности.
И если кто знает как оценить затраты связанные с инициализацией
обекта?
Что ты имеешь в виду?
Если отбросить пока код, выполняемый в конструкторе обьекта,
то инициализация нового обьекта зависит от способа его обьявления:
- если обьект обьявлен как статический (не STATIC-аттрибут!) типа
tMyObj CLASS.,TYPE
MyObj1 CLASS(tMyObj).
MyObj2 tMyObj
то вся инициализация таких обьектов производится на этапе
компиляции приложения и при входе в область видимости этих
обьектов производится автоматическая очистка буфера их
данных и вызов их конструкторов (если есть).
- если обькт обьявлен как динамический типа
MyObj1 &tMyObj
то при входе в область видимости этих обьктов НИКАКИХ действий
по их инициализации автоматом не производится.
Только при выполнении оператора MyObj1 &= NEW(tMyObj)
производится выделение из локальной кучи памяти под буфер
данных этого обьекта, очистка этого буфера и запуск
конструктора (если есть).
Если тебя этот вопрос волнует в плане производительности
выполнения программы, то следует иметь в виду только одно -
если производится многократное выделение/освобождение
мелких кусков памяти, то может на некотором этапе наступить
значительное замедление выполнение программы из-за
свойств (ошибок?) менеджера памяти Клариона.
Например, создаешь очередь, запись которой содержит
рефералы на некоторые обьекты, и добавляешь в нее большое
число записей (несколько сотен тысяч и более), а потом
удаляешь эти записи с одновременным уничтожением обьектов,
рефералы на которые в них содержались. Так вот, если
повторно выполнять вышеописанное (заново добавление записей),
то могут наблюдаться тормоза выполнения.
P.S.
В эхе есть люди располагающие нормальным толкованием устройства и
происходящего в файлах ...bc.clw - ...bcN.clw, что то никак не найду
таких? 
ABC не пользую, так что - увы, ничем помочь в данном вопросе не могу!
=============================
С уважением,
Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
(Добавление)
А если задача все-таки
этого требует, то делай соотв. методы protected, чтобы можно было унаследоваться
от твоего класса. Все остальное - private, и пользователи твоего класса (в т.ч.
ты сам) никоим образом не должны зависеть от реализации.
Максим, я пока разбираюсь со стандартными решениями CW в ООП и пытаюсь
понять почему и что они делают. На сколько я понял кларион АБС для
приложения для каждой обявленной таблицы при инициализации АПП создает
ряд объектов. Мне показалось что это противоречит ООП принципам ( с
одной стороны использ ряд решений по изоляции, а с другой задолго до
использования создаются объекты ). Кроме того для приложения средней
тяжести в 100-200 таблиц на подобную инициализацию уйдут ресурсы. Вот
мне и хотелось получить разъяснения по поводу ..bc.clw - ...bcN.clw (
возможно хоть кто-то написал себе комментарии к этому коду) и
мнение людей пользующих ООП.
--
С уважением,
SAN
Я не уверен, что ставить самодостаточность класса во главу угла это правильно.
Создавай public интерфейс таким, чтобы всем его
хватало и не возникало желания влезть во внутренности. А если задача все-таки
этого требует, то делай соотв. методы protected, чтобы можно было унаследоваться
от твоего класса. Все остальное - private, и пользователи твоего класса (в т.ч.
ты сам) никоим образом не должны зависеть от реализации.
Я стараюсь применять немного другие принципы:
- Если метод используется внутри самого класса, то он должен быть виртуальным
В этом случае класс-наследник при необходимости может изменить алгоритм
этого метода.
- Создавать защищённые методы (PROTECTED) только в крайнем случае - только
если ДЕЙСТВИТЕЛЬНО необходимо, чтобы данный метод нельзя было использовать
вне классов-наследников.
Вообще я с трудом представляю зачем это нужно.
- Использовать вместо частных методов процедуры прописанные в том же самом
модуле, где и класс. Т.е. по хорошему объявление класса должно быть "чистым".
В общем-то PRIVATE-методы для наследников бесполезны.
- Для связи с внешними классами (или для использования их возможностей)
использовать интерфейсы (INTERFACE).
Это обеспечивает гораздо меньшую зависимость классов друг от друга.
Вообще, ООП удобно (и предназначено!) для создания унифицированных
механизмов и мне не совсем понятно, зачем вводить какие-либо ограничения
на использование класса его наследниками. Особенно это касается базовых
классов.
Сергей -
chusha@mail333.com ;
chusha@hotbox.ru
(Добавление)
Я не уверен, что ставить самодостаточность класса во главу угла это правильно.
Я считаю (и некоторые другие товарищи тоже), что очень желательно, чтобы класс
максимально близко отображал реальную сущность, которую он представляет. В
пределах, требуемых задачей, конечно. Это позволяет делать использование класса
максимально прозрачным для его пользователей (нас с вами, т.е. программистов).
Я стараюсь применять немного другие принципы:
- Если метод используется внутри самого класса, то он должен быть виртуальным
В этом случае класс-наследник при необходимости может изменить алгоритм
этого метода.
Не следует увлекаться виртуальностью без нужды.
- Создавать защищённые методы (PROTECTED) только в крайнем случае - только
если ДЕЙСТВИТЕЛЬНО необходимо, чтобы данный метод нельзя было использовать
вне классов-наследников.
Вообще я с трудом представляю зачем это нужно.
RTFM тут на самом деле не поможет пока в жизни с этим не столкнешься, тогда
поймешь, точнее _прочувствуешь_, зачем.
Вообще, ООП удобно (и предназначено!) для создания унифицированных
механизмов и мне не совсем понятно, зачем вводить какие-либо ограничения
на использование класса его наследниками. Особенно это касается базовых
классов.
Реализация должна оставаться реализацией, и что там внутри не должно волновать
никого, даже наследников (если проектирование не подразумевает альтернативную
реализацию в процессе развития данной библиотеки классов этим же или другими
разработчиками).
--
Best regards,
Maxim Yemelyanov
(Добавление)
Максим, я пока разбираюсь со стандартными решениями CW в ООП и пытаюсь
понять почему и что они делают. На сколько я понял кларион АБС для
приложения для каждой обявленной таблицы при инициализации АПП создает
ряд объектов. Мне показалось что это противоречит ООП принципам ( с
одной стороны использ ряд решений по изоляции, а с другой задолго до
использования создаются объекты ). Кроме того для приложения средней
тяжести в 100-200 таблиц на подобную инициализацию уйдут ресурсы.
[Кусь!]
Хм, мне кажется что ты роешь не совсем в ту сторону :/
Ну скажи на милось, тебя ОЧЕНЬ сильно волнует, будет твоя прога
потреблять памяти 20 Мбайт или 20,05 Мбайт (из расчета 250-500 байт
дополнительных ресурсов на таблицу)?! Я ещё понимаю, когда
речь заводится о порядка 10% от УСТАНОВЛЕННОЙ на компьютере
памяти. А когда речь идет о десятых (и даже сотых!!!) долях процента,
ну честное слово - не понимаю я этого! Угрохаешь кучу времени на
изучение теории, разбор "полёта", оптимизацию и в результате
получишь... ноль эффекта :/ Тебе это надо?!!
Не знаю как в других языках, а в Кларионе по моему, введением ООП
не ставилась задача экономии ресурсов, скорее наоборот. За счет
потребления доп.ресурсов добиться унификации кода. А вот уже
за счет унификации кода добиться сокращения затрат на
непосредственно кодирование, модификацию и развитие продукта
(в частности, ABC), т.е. труд. А это НАИБОЛЕЕ затратно в единичном
и мелкосерийонм производстве, как известно. Ведь кларион и
позиционируется как инструмент для создания единичных и
мелкосерийных программ (клиентских приложений - АРМов).
Хотя с его помощью и можно создать что хочешь, но тема топора и
мастера, им владеющего - это уже другая тема
)
Думаю, что даже не ставилась задача на сокращение размеров
самой проги, хотя при аккуратном и продуманном подходам к ООП
на относительно больших прогах можно получить заметное сокращение
размера полученной программы. Но это опять же, не главное в ООП.
Главное в ООП - это экономия трудозатрат, как и в шаблонах собственно.
IMHO, конечно...
Сергей
(Добавление)
Максим, я пока разбираюсь со стандартными решениями CW в ООП и пытаюсь
понять почему и что они делают. На сколько я понял кларион АБС для
приложения для каждой обявленной таблицы при инициализации АПП создает ...
Для каждой _используемой_ в приложении таблицы.
... ряд объектов. Мне показалось что это противоречит ООП принципам ( с
одной стороны использ ряд решений по изоляции, а с другой задолго до
использования создаются объекты ). Кроме того для приложения средней ...
Это следствие принятой парадигмы - таблицы/файлы являются глобальными
объектами. В какой-то степени это отражает тот факт, что время жизни БД
больше времени работы использующего ее приложения и она является объектом
внешнего, по отношению к приложению, мира.
... тяжести в 100-200 таблиц на подобную инициализацию уйдут ресурсы.
Ты посмотри сколько ресурсов берет такой объект (FM + RM). Где-то ок 350
байт. Из них 260 на имя файла. Методы кодируются вообще всего один раз. 350
х 200 = 70 к. Это так критично? Если критично, то ответь на вопрос, нужно ли
в задаче иметь одновременный доступ ко всем 200-м таблицам? Если нужно, то
куда ты в конце концов денешься? А если нет - дели приложение на части.
WBR,
Nick Tsigouro. MailTo:
Nick@arsis.r
Написал: ClaList(2)
) В этих модулях идет
