Создать класс или обойтись процедурками.

← →
ekto © (2008-07-11 12:49) [0]

Доброго времени суток.

В программе необходимо производить некие действия. Алгоритм реализуется 7-9 процедурами/функциями(пока не делал, но, ориентировочно, столько). Повторно код не будет использоваться.

Вопрос: стоит ли создавать класс или обойтись процедурами?

← →
Dennis I. Komarov © (2008-07-11 12:50) [1]

А при чем тут класс?

← →
Andy BitOff © (2008-07-11 12:51) [2]

> ekto © (11.07.08 12:49) [0]

Класс для тебя самоцель?

← →
Дуб © (2008-07-11 12:52) [3]

Результат ничто - обсуждление все.

← →
Skyle © (2008-07-11 12:53) [4]

Создай класс и реализуй всё класс-функциями.

Либо создай класс-синглтон и используй его.

Можно сделать типа API и слепить DLL. Можно в неё вонзить COM-объект.

А можно быстро написать 7 функций в отдельном юните и пойти пить пиво.

← →
ekto © (2008-07-11 13:00) [5]

> Andy BitOff © (11.07.08 12:51) [2]

> Класс для тебя самоцель?

понял.

Всем спс.

← →
oldman © (2008-07-11 13:00) [6]

> Алгоритм реализуется 7-9 процедурами/функциями(пока не делал,
> но, ориентировочно, столько). Повторно код не будет использоваться.

Не использую функций вообше.
Вставляй код функций в код основной программы.

← →
Поросенок Винни-Пух © (2008-07-11 13:01) [7]

ну вот, наступили на горло песне

← →
Поросенок Винни-Пух © (2008-07-11 13:04) [8]

надо было по классу на каждую процедуру

← →
Dennis I. Komarov © (2008-07-11 13:08) [9]

> [8] Поросенок Винни-Пух © (11.07.08 13:04)

И каждую в отдельном потоке...

← →
han_malign © (2008-07-11 13:13) [10]

Процедурами, потому как обернуть их потом классом - 15-минут, а изначально заложенный функциональный интерфейс позволяет, в случае нужды, сплясать в любую сторону...

Только контекст должен быть не глобальным, а всегда передаваться в функцию...

TMyContext = record SmbField: TSmbField; .... end; procedure MySmb(var Context: TMyContext; param1: TParamType); function MySmbCalc(SmbField: TSmbField; param2: TParam2Type): TMySmbResult;
мгновенно превращается в
TMyClass = class private FContext: TMyContext; public procedure MySmb(param1: TParamType); function MySmbCalc(param2: TParam2Type): TMySmbResult; end; ........ procedure TMyClass.MySmb(param1: TParamType); begin MySmb(FContext, param1); end; function TMyClass.MySmbCalc(param2: TParam2Type): TMySmbResult; begin Result:= MySmbCalc(FContext.SmbField, param1); end;

← →
Dennis I. Komarov © (2008-07-11 13:17) [11]

> [10] han_malign © (11.07.08 13:13)

Лучше скажи на кой ляд он тут сдался?

← →
Поросенок Винни-Пух © (2008-07-11 13:18) [12]

ну как. красива же.

← →
jack128_ (2008-07-11 13:21) [13]

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

а объектный интерфейс не позволяет ???

← →
wl © (2008-07-11 13:26) [14]

в чем проблема класс написать не понимаю? давно пора писать эти ключевые слова на автомате

← →
int64 (2008-07-11 13:46) [15]

han_malign © (11.07.08 13:13) [10]

А почему не запихнуть методы в рекорд?

← →
TUser © (2008-07-11 16:34) [16]

Я делаю класс, когда мне нужно наследование или независимое обращение многих процедур к одним и тем же данным (полям) при существовании многих экземпляров сущностей одного типа. Собственно, для того эти классы и придуманы, имхо.

← →
Украинец (2008-07-11 16:59) [17]

Класс лучше, так как всегда можно клонировать его с агрегированным контекстом и даже настроив один синглетон не маяться с передачей дополнительных параметров в него.

Например если мне нужно сохранить Integer в хранилище, то мне не интересно где оно находится, что оно делает, зачем оно - я просто вызываю метод SaveInteger для агрегированного хранилища, а хранилище его уже сохраняет.

Так что использование класса выгодно даже в случае статических методов без единого динамического(ну разве что Destroy).

+ Класс проще расширять функционально не переписывая вызов процедуры в 1001 строчке с новым контекстом.

Так что синглетон со статическими методами в 95% случаях выгоднее, а в 5% случаев он просто не мешает.

← →
ANB (2008-07-11 18:22) [18]

> Так что синглетон со статическими методами в 95% случаях
> выгоднее, а в 5% случаев он просто не мешает.

Вот только читать потом такую программу . . .

← →
b z (2008-07-11 18:47) [19]

> ANB (11.07.08 18:22) [18]
> Вот только читать потом такую программу . . .
Программу надо юзать, а не читать. :)

+1 за классы. :)

> Программу надо юзать, а не читать. :)

Это неверно. Программы уже давно пишутся с тем расчетом, что их читают

Зависит от разделяемых между ними данных. Если их нет, то класс не нужен, есть есть, то полезен.

oldman © (11.07.08 13:00) [6]
Не использую функций вообше.
Вставляй код функций в код основной программы.
И обязательно в одну строчку. Или не в одну, но главное - делать разрыв строки не на ";", а по какой-нибудь фиксированной границе, например, 80 символов.

han_malign © (11.07.08 13:13) [10]
Процедурами, потому как обернуть их потом классом - 15-минут, а изначально заложенный функциональный интерфейс позволяет, в случае нужды, сплясать в любую сторону...

Только контекст должен быть не глобальным, а всегда передаваться в функцию...

TMyContext = record
SmbField: TSmbField;
....
end;
procedure MySmb(var Context: TMyContext; param1: TParamType);
function MySmbCalc(SmbField: TSmbField; param2: TParam2Type): TMySmbResult;
Какой-то уродливый "расчлененный" класс получается. Про то, что перейти легко - то это в обе стороны легко.

Украинец (11.07.08 16:59) [17]
Так что использование класса выгодно даже в случае статических методов без единого динамического(ну разве что Destroy).
Нет, только своеобразная группировка методов и возможность при желании превратить в динамический. И возможность садить его методы на обработчики событий. А так то же самое, что процедуры с глобальными переменными.

> [0] ekto © (11.07.08 12:49)

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

Уже повод объединить в класс.

>
> Уже повод объединить в класс.

Такой же повод как в модуль.

← →
Украинец (2008-07-12 21:21) [24]

> oxffff © (12.07.08 19:58) [23]
>
>
> >
> > Уже повод объединить в класс.
>
>
> Такой же повод как в модуль.

В Delphi нет namespace как в C++ или Java. Так что класс удобнее для последующего разбора полетов.

> Украинец (12.07.08 21:21) [24]

В С++ нет виртуального конструктора, но на улице хорошая погода.

Создать класс или обойтись процедурками. Найти похожие ветки