ООП и arrays

← →
AAAlexeyAAA (2004-06-09 12:33) [0]

Добрый день мастера. Есть вопрос о том КАК красиво пользоваться ООП. У меня есть два динамических массива of integer. Ях их читаю из 2-ух тхт файлов. Далее я их преобразовываю и результат вывожу в тхт файл одним массивом. если бы это было бы в паскале, то:

procedure ReadTxtFiles;//читаю файлы и создаю дин. массивы
procedure Calculate;// считаю, пересчитываю
procedure WriteToFile; //пишу ответ в тхт
Все три процедуры запихиваю в процедуру Raschet и всё!

Вопрос: Как сделать это в ООП?...Неужели все три процедуры повесить на кнопку, обработчик события? и всё...и это всё ООП?

Или быть может создать кроме формы ещё один юнит...там создать свой объект...и т.д. и т.п...А в обработчике события на кнопке вызвать тот объект, из другого юнита. Моя проблема вот в чем: где НУЖНО создавать свой объект, а где нет? В чём удобство и превосходство ООП. Конкретно на моей задаче...

← →
Романов Р.В. © (2004-06-09 12:40) [1]

Если вы часто используете этот алгоритм то имеет смысл оформить его в класс.

← →
KSergey © (2004-06-09 12:41) [2]

Ну и не морочьтесь с ООП
Вот когда понадобиться - вы это сразу поймете ;)

← →
Sandman25 © (2004-06-09 12:45) [3]

Надеюсь, у процедур есть параметры...

← →
Романов Р.В. © (2004-06-09 12:49) [4]

Удалено модератором
Примечание: Дубль

← →
Anatoly Podgoretsky © (2004-06-09 13:52) [5]

Пока смысл использования объектов не виден.

← →
AAAlexeyAAA (2004-06-09 14:13) [6]

Я кажется понимаю.
А если бы это было поставлено на конвеер: считка файлов, пересчёт, и запись в новые,...к примеру раз 50-100 в минуту(в контексте какой-то операции программы), то смысл бы имел бы создать свой объект, верно?

← →
Романов Р.В. © (2004-06-09 14:20) [7]

Можно вполне обойтись без объекта одной процедурой
ReadAndWrite(FileName1, FileName2, SaveName: string);

← →
Семен Сорокин © (2004-06-09 14:21) [8]

AAAlexeyAAA (09.06.04 14:13) [6]
Хочешь ООП?
Сделай наследника TFileStream (например), и читай в нем данные во внутреннюю (закрытую) структуру, туда-же добавь необходимые тебе закрытые\открытые методы.

← →
PVOzerski © (2004-06-09 14:24) [9]

IMHO, смысл появился бы, если бы: а) параллельно делалась бы обработка несколльких пар файлов (и то для удобства программирования, а не для эффективности самой системы); б) если бы пары файлов в разных случаях должны были бы обрабатываться по-разному, но в рамках одной схемы (т.е. имело бы смысл написание базового класса и классов-наследников).

← →
DieHard (2004-06-09 14:25) [10]

AAAlexeyAAA (09.06.04 14:13) [6]
Не 50-100 раз в минуту, а в 50-100 проектах

← →
PVOzerski © (2004-06-09 14:31) [11]

>Не 50-100 раз в минуту, а в 50-100 проектах
Разве что если тогда компонент делать, чтобы на форму "кидать" :^)
А так - достаточно написание юнита с процедурами.

← →
Weber © (2004-06-09 14:34) [12]

Примерно так:
TMyArray = class private FElems: TIntegerDynArray; function GetElem(AIndex: Integer): Integer; procedure SetElem(AIndex, Value: Integer); public function LoadFromFile(AFileName: String); published property Elems[AIndex: Integer]: Integer read GetElem write SetElem; default; end; procedure Calculate(var First, Second: TMyArray); { всё больше никаких функций/процедур не надо }

← →
Weber © (2004-06-09 14:35) [13]

> Weber © (09.06.04 14:34) [12]

Изврат заказывали?

← →
Семен Сорокин © (2004-06-09 14:36) [14]

Weber © (09.06.04 14:34) [12]
а зачем здесь published-секция?

← →
Sandman25 © (2004-06-09 14:43) [15]

+ зачем var у параметров Calculate?

← →
Романов Р.В. © (2004-06-09 14:45) [16]

Щас бы синий карандаш :)

← →
AAAlexeyAAA (2004-06-09 14:50) [17]

>Не 50-100 раз в минуту, а в 50-100 проектах
..т.е. например...у меня массивы real в объекте...
Нужно использовать объекты когда:
1 в первом случае мне нужно "сложить массивы" (одинаковые по размерам)
2. во втором округлить до целых выход массив
3. в третьем "вычесть из первого - второй"

тогда я наследую весь объект, а процедуру calculate заменяю...

это будет ООП, верно?

← →
GuAV © (2004-06-09 14:58) [18]

имхо, нефиг дин.массив в класс запузыривать!
для дин массива применим compliler magic - reference count и finalize по выходу из прцедуры, что помогает избежать утечки памяти и нерациональное использование оной.

зы я бы делал
type TCalcProc=procedure(A: array of Integer); procedure ExecCalcProc(Proc: TCalcProc);

← →
PVOzerski © (2004-06-09 15:08) [19]

Я-то имел в виду нечто такое:
type
tArray=array of real;
tArrayProcessor=class
private
...
public
procedure LoadFromFiles(const names:array of string);
function Calculate:tArray;virtual;
end;

← →
Weber © (2004-06-09 15:08) [20]

> Семен Сорокин © (09.06.04 14:36) [14]
> Weber © (09.06.04 14:34) [12]
> а зачем здесь published-секция?
>
> Sandman25 © (09.06.04 14:43) [15]
> + зачем var у параметров Calculate?

Чтобы поизвратнее!
Человек же просил ООП для динамических массивов, вот пжалста!
На большее фантазии не хватило, вот за это вы уж меня простите... :))))

← →
AAAlexeyAAA (2004-06-09 15:09) [21]

<<помогает избежать утечки памяти и нерациональное использование оной>>

<<применим compliler magic - reference count >>

а можно поподробнее...? (пример)

← →
Weber © (2004-06-09 15:16) [22]

Можно ещё извратистее:
TMyArray = class private ... public ... function Add(Param: TMyArray): TMyArray; end;

← →
GuAV © (2004-06-09 15:21) [23]

> а можно поподробнее...? (пример)

procedure P; var A: array of Integer; begin SetLength(A,10000); A[0]:=5; end;
этот код не должен вызвать утечки памети
procedure P1; var A: tArrayProcessor; begin A:=tArrayProcessor.Create; end;
этот должен вызвать

это про утечку. про reference-count по F1

← →
GuAV © (2004-06-09 15:22) [24]

> type TCalcProc=procedure(A: array of Integer);

type TCalcProc=procedure(var A: array of Integer);

← →
Weber © (2004-06-09 15:23) [25]

> A:=tArrayProcessor.Create;

Кто хоть так делает?

← →
PVOzerski © (2004-06-09 15:27) [26]

>procedure P1;
>var A: tArrayProcessor;
>begin
> A:=tArrayProcessor.Create;
>end;
>этот должен вызвать
Если деструктор не вызывать, то конечно. Только почему бы его не вызвать в свое время?

← →
GuAV © (2004-06-09 15:32) [27]

> Если деструктор не вызывать, то конечно. Только почему бы
> его не вызвать в свое время?

я про то что работать с дин.массивами - одно удовольствие, а с классами и налажать недолго.

← →
PVOzerski © (2004-06-09 15:38) [28]

>я про то что работать с дин.массивами - одно удовольствие, а с классами и налажать недолго.
IMHO это зависит только от кривости рук. Можно "налажать" не то что с динамическими массивами - даже со статическими :^)

[26] PVOzerski © (09.06.04 15:27)

А вдруг это наследник TComponent и в конструкторе вызывается какой-нибудь inherited Create(Application)? :)

> А вдруг это наследник TComponent и в конструкторе вызывается
> какой-нибудь inherited Create(Application)? :)

ВО! так и надо в этом случае поступить :)

Если это тот класс, который я выдумал в [19], у него предок один - tObject :^). А при наличии богатой фантазии насоздавать "подводных камней" на ровном месте можно где угодно.

> GuAV © (09.06.04 15:32) [27]
> я про то что работать с дин.массивами - одно удовольствие,
> а с классами и налажать недолго.

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

Предлагаю переделать под ООП сложение двух integer"ов и напридумывать как можно больше проблем! :^))

> имхо, нефиг дин.массив в класс запузыривать!

Хорошо, что "имхо". Я с этим категорически не соласен.

> я про то что работать с дин.массивами - одно удовольствие,
> а с классами и налажать недолго

Кому как (про удовольствие). Все зависит от задачи, а то и с дин. массивами можно "налажать", а класс один раз отладил и никаких проблем. Заботиться надо только о Create/Free.

[33] PVOzerski © (09.06.04 15:43)

Это слишком сложно. Лучше изменение знака у одного. Без метода проверки на 0 никак... :)

← →
AAAlexeyAAA (2004-06-09 16:02) [36]

так вот если сделать с помощью объектов(A) или в тупую под обработчиком... (кнопкой)... в классе TForm(B)
1. Объём кода (писанины)
2. Объём файла (exe)
3. Скорость рабоыт приложения
4. Простота (наглядность)
5. Возможность для более простого (будущего) изменения кода

> Лучше изменение знака у одного

сложная задача. учитывая что на некоторых платвормах максимальное положительное по модулю равно мин. отрицательному, и нуля два +0 -0. :)

идея реализации.
начинать с класса интежер в котором в protected доступ к битам как к массиву... разумеется бит - тоже класс :)

> разумеется бит - тоже класс :)

О боже, сумасшедший дом! ... Я по адресу! :))))

> Я по адресу! :))))

Разумеется переменную класса бит следует передавать по адресу а не по значению. Это же ООП :)

И в трехзвенной архитектуре

ООП и arrays Найти похожие ветки