Использование объектов для простых типов. Стоит ли?

← →
Kolan © (2006-10-14 20:46) [0]

Здравствуйте,
В книге Design Patterns говорится(не буду цитировать, думаю и так повереите :) - используйте объекты даже для простых типов, это не про string или integer, это про например тип "диапазон".
Можно его выразить двумя числами (начало и конец), а можно сделать в виде объекта.

Так вот пользуетесь вы этим предложением? Оборачиваете ли такие веши в объекты?

PS
С диапазоном попробовал - понравилось. А работать удобно через интерфейс, чтобы о памяти не волноваться...

← →
MeF Dei Corvi © (2006-10-14 20:50) [1]

ИМХО, если оборачивать, то нарушается принцип KISS

← →
Джо © (2006-10-14 20:50) [2]

> Так вот пользуетесь вы этим предложением? Оборачиваете ли
> такие веши в объекты?

Случается... :)

← →
Kolan © (2006-10-14 20:57) [3]

> Джо © (14.10.06 20:50) [2]

О вас то я и пождидал:) Вопрос вот с чем связан. У два типа массивов, которые пользуются очень много где:

TByteArrayObject = class; TDoublePoint = record X: Double; Y: Double; end; TDoublePointArray = array of TDoublePoint; TByteArray = array of Byte;

Хочу переделать их на объекты. Вот думаю стоит ли? И стоит ли оба. TByteArray - может не трогать его?

PS
Серьезный рефакторинг предстоит, так что можно за одно и это поменять...

← →
Джо © (2006-10-14 21:02) [4]

TByteArray я бы оставил, как есть.
TDoublePointArray, скорее всего, сделал бы объектом-контейнером. Со своими методами добавления, удаления, доступа к элементам. Плюс методы чтения/сохранения и т.п.
Впрочем, все, как всегда, от задачи зависит :)

← →
Джо © (2006-10-14 21:04) [5]

P.S. Я не большой любитель всяких формальных методов (не очень в них верю). Как я считаю удобным для формирования нужной мне абстракции, так и делаю :) Поэтому очень многое зависит от того, что в каких дальнейших операциях будут учавствовать упомянутые тобой типы.

← →
Kolan © (2006-10-14 21:05) [6]

> Впрочем, все, как всегда, от задачи зависит :)

Блиин, я тоже так думаю, правда начал с TByteArray и уже почти доделал... :)

Лана пойду все сотру.. :)

← →
Kolan © (2006-10-14 21:07) [7]

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

Так TDoublePointArray в 3 основных:
1. Отрисовка на TCahrt
2. Данные полученые в TByteArray преврашаются в TDoublePointArray
3. На основе TDoublePointArray вычисляются числа Double или еще один(два..)TDoublePointArray

← →
Kolan © (2006-10-14 21:11) [8]

Может мне TDoublePointArray вообще через списочек сделать?
А TDoublePoint оставить записью или опятьже объектом?

Забыл в массивчике по 40000 тысяч точек-бывает, а бывает и больше.

← →
Джо © (2006-10-14 21:15) [9]

Обсуждение лично мне очень интересно, но, к сожалению, приходится из него устраняться — убегаю, дела... :)

← →
Kolan © (2006-10-14 21:17) [10]

> Обсуждение лично мне очень интересно, но, к сожалению, приходится
> из него устраняться — убегаю, дела... :)

Надеюсь продолжим после :)

← →
Юрий Зотов © (2006-10-14 21:23) [11]

Буду очень признателен человеку, который внятно обьяснит мне, какие преимущества имеет объект перед своим прототипом вида
TDoublePoint = record
X: Double;
Y: Double;
end;

← →
Kolan © (2006-10-14 21:33) [12]

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

Я заметил, что с первого взгляда кажется, что объект не будет имет "+". Их понимаешь потом, когда что-то понадобится.

Пример с диапазоном.
Казалось бы тоже два числа. Однако в процессе использования понадобилось расчитать длину: Конец-Начало. Естественно я в класс включил. Теперь всегда под рукой.

Пример с TDoublePointArray уже вижу что в класс засуну разные ф-ции обработки, например пересечение графика(этот массив-это график) с прямой и тд...

Вот с TDoublePoint пока не знаю, может понадобится.

Кроме того если и TDoublePoint и TDoublePointArray объекты, создавать TDoublePoint буду с помощью фабричного метеда, те в будущем смогу добавить что-то не изменяю остальной код...

← →
TUser © (2006-10-14 21:38) [13]

Имхо, не стоит. И не пользуюсь. Другое дело, если вокруг простого типа надо какие-то оберточные пассы совершать. А Иначе это напоминает метод SetTrueIfFalseOrSetFalse IfTrue (c).

← →
MeF Dei Corvi © (2006-10-14 21:52) [14]

> Казалось бы тоже два числа. Однако в процессе использования
> понадобилось расчитать длину: Конец-Начало. Естественно
> я в класс включил.

А почему сразу в класс? Почему не
TRange = record First, End: Integer; function Length: Integer; end;

← →
vidiv © (2006-10-14 22:03) [15]

> TRange = record
> First, End: Integer;
> function Length: Integer;
> end;

опа.... пойду проверю...

← →
MeF Dei Corvi © (2006-10-14 22:03) [16]

> опа.... пойду проверю...

Сорри. Забыл указать, что BDS2006 needed...

← →
vidiv © (2006-10-14 22:04) [17]

> > TRange = record
> > First, End: Integer;
> > function Length: Integer;
> > end;
>
> опа.... пойду проверю...

обманщик :(

← →
Kolan © (2006-10-14 22:06) [18]

> TRange = record
> First, End: Integer;
> function Length: Integer;
> end;

2 причины:
1. Еще не отложилось что так можно.

2. Для объекта можно наследника сделать...

← →
Petr V. Abramov © (2006-10-14 22:11) [19]

имеет смысл, если появлятся методы. в крайнем случае недолго и переделать, что у доступа к record, что у доступа к объекту синтаксис одинаковый

← →
Petr V. Abramov © (2006-10-14 22:12) [20]

насчет диапазона - имеет смысл, т.к. в методе set можно сразу сделать проверку корректности (например, конец не меньше начала)

> имеет смысл, если появлятся методы

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

> Можно написать обьычную процедуру и туда передавать в явном виде параметр.
если у метода кроме self есть еще параметры, букв меньше в результате

> [21] TUser © (14.10.06 22:13)
>
> > имеет смысл, если появлятся методы
>
> Можно написать обьычную процедуру и туда передавать в явном
> виде параметр. Реально смысл есть, еслит будет наследование.

Вклинюсь на минутку...
То, что у объекта есть свойство Length — гораздо проще запомнить и понять, чем то, что где-то (в каком-то там модуле) есть специальная процедура для вычисления его Length. А если этих функций с десяток? Это всего лишь одно (пусть, небольшое), но, ИМХО, преимущество.

Короче за завтра переделаю проектик(небольшой) доложу о плюсах, которые получил.

Уже сейчас скажу что кода будет меньше. Пока получается не намного меньше, но меньше:
Было:
SetLength(ImaginativePart, Range.Length); I := Range.LeftAge; while I <= Range.RightAge do begin ImaginativePart[I].X := I; ImaginativePart[I].Y := EvalImaginativeConductivity(I, C); I := I + Range.Step; end;

Стало:
I := Range.LeftAge; while I <= Range.RightAge do begin RealPart.Add(TDoublePointObject.Create(I, EvalRealConductivity(R))); I := I + Range.Step; end;

То что вверху ImaginativePart а внизу RealPart не вожно.

Вообщем переделал. Сделал точку - объектом, массив точек через TObjectList.
Вот результат по времени:

Колво точек Массив Объект 50000 32 15 100000 62 15 500000 328 125

Мой вывод. для часто используемых сущностей и для большого кол-ва данных не годится.. :(

> Мой вывод. для часто используемых сущностей и для большого
> кол-ва данных не годится.. :(

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

Есть такое слово - инкапсуляция, оно действительно хорошо, когда не надо никому раскрывать внутренней реализации объекта, неважно, большой он или маленький. Например AnsiString и Variant в Delphi, которые по сути тоже являются объектами с классической точки зрения, другое дело, что вызовы методов этих объектов (неявные) генерируются компилятором.

И ничего, годятся для частого использования и для большой количества данных тоже...

Если слишком часто делать
SetLength(X,1+Length(X))
то лучше использовать объекты

> То, что у объекта есть свойство Length — гораздо проще запомнить
> и понять, чем то, что где-то (в каком-то там модуле) есть
> специальная процедура для вычисления его Length. А если
> этих функций с десяток? Это всего лишь одно (пусть, небольшое),
> но, ИМХО, преимущество.

Дело привычки, имхо.

Использование объектов для простых типов. Стоит ли? Найти похожие ветки