Освобождение ресурса в finally

← →
Восхищенный (2008-04-25 10:28) [200]

> Игорь Шевченко © (25.04.08 10:16) [199]

Если в голове разруха - то да. А если вся иерархия четко спроектирована, если понятно, для чего каждый класс нужен, что и как он делает - то нет.

← →
Ega23 © (2008-04-25 10:39) [201]

> Тоже не факт. Иные напишут с десяток классов в иерархии
> - вааще не прочитаешь, не то, что изменения какие вносить

Игорь, ты же сам говорил, что универсальных решений не бывает.
Но вот уже достаточно длительное время у меня никак не получается процедуры-фунции-метода более, чем на 50 строк кода. Чаще - 10-20 между основным begin..end

← →
Anatoly Podgoretsky © (2008-04-25 10:59) [202]

> Игорь Шевченко (25.04.2008 10:16:19) [199]

Ну так любуб вещь можно испоганить, дело то не хитрое.

← →
Игорь Шевченко © (2008-04-25 11:03) [203]

Восхищенный (25.04.08 10:28) [200]

А если в голове разрухи нет, можно и с goto вполне читабельно написать

← →
sniknik © (2008-04-25 11:08) [204]

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

> Да. По п.2. В принципе ИНОГДА имеет смысл открыть и несколько сессий для ускорения.
коннект может держать собственные потоки (асинхронность), т.е. нет нужды в дополнительных сессиях, если только эти сессии не к разным sql серверам. ("ИНОГДА" еще на 100 поделить, для определения реальной нужды в использовании)

← →
ANB (2008-04-25 11:14) [205]

> Тоже не факт. Иные напишут с десяток классов в иерархии
> - вааще не прочитаешь, не то, что изменения какие вносить

+1.

Смотрел я как то модуль импорта в новом проекте. 20 методов по 3-5 строчек в каждом. Вызываются друг из друга. Черт ногу сломит. Хотя процедура и алгоритм довольно простые.
А так сам автор пол-часа искал, где у него что живет.

← →
ANB (2008-04-25 11:17) [206]

> коннект может держать собственные потоки (асинхронность),
> т.е. нет нужды в дополнительных сессиях

Не. У оракла если сессия чего то делает, пусть и асинхронно, второй запрос параллельно уже не пустишь. Там с сессиями все строго.
А для мс скл - не наю. Когда сталкивался с ним, понял, что понятие "сессия" у него более гибкое и сложное.

← →
Игорь Шевченко © (2008-04-25 12:06) [207]

> Не. У оракла если сессия чего то делает, пусть и асинхронно,
> второй запрос параллельно уже не пустишь. Там с сессиями
> все строго.

Э...я как бы запускал несколько запросов параллельно в одной сессии...

← →
ANB (2008-04-25 12:09) [208]

> Э...я как бы запускал несколько запросов параллельно в одной
> сессии...

Невозможно.
Чем пользовались (компоненты) ?
Есть подозрение, что сессии были созданы автоматически.
ОДАК и ДОА такого не допускают.
Можно только распараллелить запрос, но при этом все равно оракл под кажную порцию сам запустит свою сессию.

← →
Palladin © (2008-04-25 13:14) [209]

> ANB (25.04.08 09:51) [195]

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

1. В какие десять строк? 6 компонентов, 6 присваниваний в Nil, 6 конструкторов, 6 вызово free, сколько? 24 строчечки... + try finally end, 27 строчечек, + еще десятки строк на работу с объектами и сам по себе парсинг.
2. Я не привел тебе код для копирования и вставки, я привел тебе метод решения задачи.
3. До какого цикла? Ты где у меня циклы увидел вообще?
4. Вот именно что отличается принципиально. Перед нами сущность созданная для функционала, а не для конкретной работы. Сегодня текстовые файлы, завтра файл с определенной структурой, после завтра XML. И что будет менятся? Не вся жирная процедура, а только методы этой сущности, которые отвечают за работу с внешними данными.

← →
ANB (2008-04-25 13:40) [210]

> 3. До какого цикла? Ты где у меня циклы увидел вообще?

Цикл подразумевается в методе "Все сделать".

← →
ANB (2008-04-25 13:44) [211]

> Да, у меня каскадом вложенных try блоков и не пахнет.

Дык это Ega23 любит вложенные трай. Вот я и попросил его распилить на методы при таком подходе.
А у нас получается подход одинаковый. Просто мои строки перенесены в отдельные методы. Суть от этого не поменялась. И код короче не стал.
Вот только у меня привычка - я переношу в отдельную функцию код, если он повторяется более одного раза. Мне так понятнее.

← →
Игорь Шевченко © (2008-04-25 13:57) [212]

ANB (25.04.08 12:09) [208]

> Невозможно.

Выдержку из оракловской доки, плз.

> Чем пользовались (компоненты) ?

Своими.

Где-то такой код:

procedure TdmMember.DataModuleCreate(Sender: TObject);
begin
...
if Options.RunBirthdayThread then
TBirthdayThread.Create;
if Options.RunExpiredTempThread then
TExpiredTempThread.Create;
end;

procedure TBirthdayThread.Execute;
...
dmMember.BirthdayThreadRunning := true;
with dmMember.qMemberBirthday do
begin
Prepare;
Params[0].AsString := Today;
Open;
try
while not Eof and not Terminated do
begin
....
end;
...
end;
...
end;

...

procedure TExpiredTempThread.Execute;
begin
....
dmMember.ExpiredTempThreadRunning := true;
with dmMember.qExpiredTemp do
begin
Prepare;
Open;
try
while not Eof and not Terminated do
begin
....
end;
...
end;
...
end;

← →
Восхищенный (2008-04-25 14:35) [213]

> ANB (25.04.08 13:44) [211]

> я переношу в отдельную функцию код, если он повторяется более одного
> раза.

Нормальный подход для процедурного программирования, но неполный для ООП. Для ООП нужно еще учитывать, нужен ли данному коду полиморфизм (то есть, может ли его функциональность быть изменена в классах-потомках). Если да, то код тоже надо выносить в отдельный метод и делать его виртуальным (или динамическим, если замещение маловероятно).

← →
ANB (2008-04-25 14:44) [214]

> Восхищенный (25.04.08 14:35) [213]

Да я как то не прусь от ООП. Пользуюсь, только если очень надо. Как то без него быстрее и понятней получается. Есно, это сугубо личное впечатление.

> Игорь Шевченко © (25.04.08 13:57) [212]

Вот выдержку не найду. Не уверен, что запрещены параллельные фетчи из одной сессии. Скорее всего опен у вас быстро отрабатывает и вы не нарывались на пересечение, когда они работают одновременно.
А сессия лежит на ДМ основного потока и на ошибку не нарывались при работе с ней из доп.потоков ?

Попробуйте для чистоты эксперимента следующее :
Запустите хранимку, которая долго работает. И из под той же сессии попробуйте выполнить любой запрос.

← →
jack128_ (2008-04-25 14:51) [215]

> Для ООП нужно еще учитывать, нужен ли данному коду полиморфизм
> (то есть, может ли его функциональность быть изменена в
> классах-потомках). Если да, то код тоже надо выносить в
> отдельный метод и делать его виртуальным (или динамическим,
> если замещение маловероятно).

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

← →
Ega23 © (2008-04-25 14:57) [216]

> Дык это Ega23 любит вложенные трай.

Где я такое говорил? Моё максимальное, что за 8 лет было -
...... try ........ try ........ try ....... except end; finally end; ....... except end

Я просто такой фигнёй не страдаю, чтобы создать 6 объектов и в finally их грохать. Если тебе так писать понятнее и удобнее - ради бога.

← →
Восхищенный (2008-04-25 14:57) [217]

> jack128_ (25.04.08 14:51) [215]

> полиморфизм используется для того же, для уменьшения дубляжа кода,
??????????????!!!!!!!!!!!!!!!!!!!

> так же подподает под критерий ANB
??????????????

← →
ANB (2008-04-25 15:10) [218]

> Ega23 © (25.04.08 14:57) [216]

А для 6 как сделаешь ?

← →
Ega23 © (2008-04-25 15:21) [219]

> А для 6 как сделаешь ?

1. Я постараюсь такого не делать. Ну не встречал я ещё такой необходимости по созданию 6 объектов внутри одного метода, с обязательным их гроханием в том же методе.
2. Если всё-таки надо создать больше одного (ну, например, битмап в jpg), то тупо
bmp := TBitmap.Create; jpg := TJPEGImage.Create; try ..... работаем с ними finally jpg.Free; bmp.Free; end;

Дело в том, что вероятность того, что TBitmap или TJPEGImage дадут exception в конструкторе - ну практически нулевая.

← →
ANB (2008-04-25 15:26) [220]

> ну практически нулевая.

"ну практически" и совсем нулевая - разные вещи.

Обниление до трая сожрет несколько тиков проца. И намного меньше, чем само создание объектов. Это так критично ?

Фри нилового объекта тоже пара тактов.

← →
jack128_ (2008-04-25 15:27) [221]

> > полиморфизм используется для того же, для уменьшения дубляжа
> кода,

function TMyClass.MyFunc1(D: Double): Double; begin Result := 152*D - D*D + sqr(D) + sin(D); end; function TMyClass.MyFunc2(D: Double): Double; begin Result := 152*D - D*D + sqr(D) + cos(D); end;

различие в двух функциях минимальное.

теперь прикрутим сюда полиморфизм:

type
TMyBaseClass =class
function VirtMethod(D: Double): Double; virtual; abstract;
function MyFunc(D: Double): Double;
end;

// теперь мы вынесли общую часть кода - в статический метод. Уменьшили дубляж кода..

function TMyBaseClass.MyFunc(D: Double): Double;
begin
Result := 152*D - D*D + sqr(D) + VirtMethod(D);
end;

function TMyClass1.VirtMethod(D: Double): Double;
begin
Result := sin(D);
end;

function TMyClass2.VirtMethod(D: Double): Double;
begin
Result := cos(D);
end;

> так же подподает под критерий ANB

ну цитирую:

> я переношу в отдельную функцию код, если он повторяется
> более одного

я сделал тоже самое - нашел повторяющийся кусок кода - и вынес его в отдельную функцию(метод)

← →
Ega23 © (2008-04-25 15:39) [222]

> "ну практически" и совсем нулевая - разные вещи.

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

← →
Восхищенный (2008-04-25 15:41) [223]

> jack128_ (25.04.08 15:27) [221]

> я сделал тоже самое - нашел повторяющийся кусок кода - и вынес его в
> отдельную функцию(метод)

Таким образом, для уменьшения дубляжа кода ты использовал наследование, а никакой не полиморфизм. Для чего это самое наследование, собственно, и предназначено.

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

← →
jack128_ (2008-04-25 15:43) [224]

> Таким образом, для уменьшения дубляжа кода ты использовал
> наследование, а никакой не полиморфизм.

хе. чем поможет наследование БЕЗ полиморфизма??

← →
Anatoly Podgoretsky © (2008-04-25 15:44) [225]

> ANB (25.04.2008 15:10:38) [218]

Хочешь знать как я сделаю?
Это будет зависить от задачи и от настроения иногда.

← →
jack128_ (2008-04-25 15:44) [226]

в данном случае, я имею в виду..

← →
Leonid Troyanovsky © (2008-04-25 15:44) [227]

> jack128_ (25.04.08 15:27) [221]

> // теперь мы вынесли общую часть кода - в статический метод.
> Уменьшили дубляж кода..

Не. Статический не нужен.
function TMyBaseClass.VirtMethod(D: Double): Double; // virtual; begin Result := 152*D - D*D + sqr(D); end; function TMyClass1.VirtMethod(D: Double): Double; // override; begin Result := inherited VirtMethod(D); Result := Result + sin(D); end;
--
Regards, LVT.

← →
jack128_ (2008-04-25 15:45) [228]

>
> Не. Статический не нужен

Ну с такой позиции - статические методы вообще не нужны ;-) Кроме хаков, а-ля TObject.Free

← →
Восхищенный (2008-04-25 15:46) [229]

> jack128_ (25.04.08 15:27) [221]

Кстати, в отдельный метод ты вынес как раз НЕповторяющийся кусок кода (Sin и Cos). Что полностью противоречит [211] и о чем говорилось в [213].

> Восхищенный (25.04.08 14:35) [213]

> и делать его виртуальным
> (или динамическим, если замещение маловероятно).

Наоборот.
Динамический - компактней.

--
Regards, LVT.

← →
Восхищенный (2008-04-25 15:49) [231]

> jack128_ (25.04.08 15:43) [224]

> чем поможет наследование БЕЗ полиморфизма??

??????????????!!!!!!!!!!!!!!

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

← →
Восхищенный (2008-04-25 15:51) [232]

← →
Восхищенный (2008-04-25 15:55) [233]

> Leonid Troyanovsky © (25.04.08 15:48) [230]

Небольшое уточнение: но медленнее при замещении наследниками (особенно, многократном). Поэтому ты неправ.

← →
jack128_ (2008-04-25 15:57) [234]

> А класс-потомок может добавить парочку своих, статических

см [226]

> Что полностью противоречит [211] и о чем говорилось в [213].

ты не находишь, что "вынес изменяемый кусок кода" и "вынес НЕизменяемый кусок кода" - это лингвистические изыски??

Главное: было X функций -> стало Y функций. При этом - совпадающих участков кода - стало меньше.

> Восхищенный (25.04.08 15:51) [232]

> Динамический действительно компактнее. Но медленнее. Поэтому
> ты неправ.

Мне лень искать, но была такая рекомендация от борландов, мол,
чем чаще предполагается замещать метод, тем предпочтительней
его сделать динамическим, например, для обработки событий.

А, во-ще, тут и не стоило даже поминать динамический.
Virtual forever.

--
Regards, LVT.

← →
Восхищенный (2008-04-25 16:06) [236]

> Leonid Troyanovsky © (25.04.08 15:58) [235]

> была такая рекомендация от борландов, мол, чем чаще предполагается
> замещать метод, тем предпочтительней его сделать динамическим,
> например, для обработки событий.

Ты перепутал. Рекомендация на эту тему от борландов действительно была, но полностью противоположная той, что ты изложил.

Кстати, они сами своей же рекомендации и следуют. Загляни в VCL - все методы диспетчеризации событий у них динамические. А вот методы, которые наследники наверняка перекроют - все до одного виртуальные.

> jack128_ (25.04.08 15:57) [234]

Спор прекращаю. Извини, но у тебя небольшие проблемы с пониманием сути базовых терминов ООП, поэтому смысла нет.

> Мне лень искать, но была такая рекомендация от борландов,
> мол,
> чем чаще предполагается замещать метод, тем предпочтительней
> его сделать динамическим, например, для обработки событий.
>

С точностью до наоборот, чем реже, тем больше смысла делать динамическим

> ANB (25.04.08 09:51) [195]

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

В этом и отгадка того, почему обычно не стоит обрамлять вызов
конструктора, бо, в ООП для хранения ссылок на объекты более
естественны поля, а вовсе не локальные переменные.

--
Regards, LVT.

← →
Восхищенный (2008-04-25 16:11) [239]

> Leonid Troyanovsky © (25.04.08 15:58) [235]

Тут смысл простой. Если динамический метод не перекрыт, то по скорости он не уступает виртуальному, а по компактности - лучше. То есть, имеет преимущество. Но как только мы начинаем его перекрывать, это преимущество начинает снижаться - и чем больше наследников его перекрыли, тем больше снижение. Поэтому динамический метод хорош как раз тогда, когда вероятность его перекрытия невелика.

> Игорь Шевченко © (25.04.08 16:07) [237]

> С точностью до наоборот, чем реже, тем больше смысла делать
> динамическим

Путаница между "частыми вызовами" и "частыми перекрытиями".
А про диспетчеризацию (это ж юзеровские действия) -
time-critical - не критично.

--
Regards, LVT.

Освобождение ресурса в finally Найти похожие ветки