Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Классы на базе TList...

Страницы: 1 2 3 >
Knight © (2007-04-27 14:20:00)
Сколько раз хотел разобраться с этим вопросом, но всё время что-то отвлекало... но надоело, хочу таки разобраться! Мож поможите? :)

Допустим есть какой-то тип
TMyItem=record Str1:String; ... end;
Надо загнать эти итемсы в лист так чтобы обрачаться с ним
MyList[i].Str1
а не
PMyItem(MyList[i])^.Str1
Мож кто накидает скелет класса?
TMyList=class(TList) end;

default (2007-04-28 19:20:00) [1]
Игорь Шевченко
[35]
ситуации могут быть разные, отдельно взятый пример описывает лишь отдельно взятую ситуацию, это не повод для обобщений

а так рекомендуют по очень простой причине - когда всё делаешь через get/set ты никогда не проиграешь(в худшем случае просто будешь иметь никому не мешающую избыточность), а вот если этого правила иногда придерживаться, а иногда нет и делать это не очень дальновидно, то можно получить проблем, которых совсем не ждёшь, зачем идти на риск?впрочем, вольному воля

vovnuke (2007-04-28 16:01:00) [2]
> [42] Игорь Шевченко © (28.04.07 14:33)

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

> [43] ANB © (28.04.07 15:03)

По большому счету, согласен.

ANB (2007-04-28 15:03:00) [3]

> Можно считать, что мне не повезло, раз не сталкивался, но
> за опять же много лет программирования я пришел к одной
> простой истине - чем меньше в коде строчек, тем он лучше,
> разумеется, при условии, что код функционален и понятен
> визуально, без привлечение дополнительных средств, в том
> числе IDE

И я пришел к тому же выводу. И еще к одному - не завязываться на модные течения (типа ООП). Цель - получить компактный и понятный код. Если ООП этому помогает - хорошо. Если мешает - лучше написать функцию.

Игорь Шевченко (2007-04-28 14:33:00) [4]
vovnuke © (28.04.07 14:08) [41]

Требвания меняются, никто не спорит. Но вот что странно - за много лет программирования я лично не часто сталкивался с необходимостью менять именно реализацию механизма чтения/записи свойства так, чтобы не затрагивать вызывающий код. Гораздо чаще вызывающий код тоже затрагивался и довольно значительно. Вот такая вот практика.
Можно считать, что мне не повезло, раз не сталкивался, но за опять же много лет программирования я пришел к одной простой истине - чем меньше в коде строчек, тем он лучше, разумеется, при условии, что код функционален и понятен визуально, без привлечение дополнительных средств, в том числе IDE

vovnuke (2007-04-28 14:08:00) [5]
> [38] Игорь Шевченко © (28.04.07 13:45)

Вызывающему коду как раз и не следует видеть разницу в релизации объекта, для него он всего лишь структура отвечающая за выолнение определенных обязательств, и изменение в работе этой структуры не должны сказываться на работе клиента. А при изменении требований к ПО (а требования к ПО меняются всегда), придется поправить только реализацию механизма чтения/записи свойтсва, а не рыскать по коду и искать места которые могут сломаться или отлавливать ошибки.
Или этого мало?

Игорь Шевченко (2007-04-28 13:54:00) [6]
Ega23 © (28.04.07 13:49) [39]

> может - значение по-умолчанию присваивать.

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

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

Проще надо быть, как Эрик Реймонд советует.

Ega23 (2007-04-28 13:49:00) [7]
>То есть, вызывающий код должен иметь еще и обвязку вида
try FooInstance.Bar := some_value; except on E: Exception do ShowMessage ('Shit happens: '+E.Message); end;

А это уже зависит от ситуации. Может exception, а может - значение по-умолчанию присваивать.

Игорь Шевченко (2007-04-28 13:45:00) [8]
vovnuke © (28.04.07 13:32) [37]

Ну да. С точки зрения вызывающего кода - особенно видны различия в инкапсуляции. Ему (вызывающему коду) в данном случае пофиг, какая там инкапсуляция за одним лишь исключением - во втором случае Bar нельзя использовать как var-переменную. И вся инкапсуляция.

Ega23 © (28.04.07 13:18) [36]

> А вот если TFoo.Bar должна иметь ограничения (длина строки,
> или, например, неотрицательные значения, если integer,
> или ещё что-нибудь) - то очень даже

И что метод Set должен делать в случае ограничений ?
Exception возбуждать ?

То есть, вызывающий код должен иметь еще и обвязку вида
try
FooInstance.Bar := some_value;
except
on E: Exception do
ShowMessage ('Shit happens: '+E.Message);
end;

А как насчет разобраться в таком коде без стакана ? :)

> Я может не совсем точно выразился. Имел ввиду, что доступ
> к полям должен через property-прокладку идти.

То есть, надо переписать как
TFoo = class
private
FBar: string;
public
property Bar: string read FBar write FBar;
end;

?

И в чем здесь разница для вызывающего кода (за исключением var-переменных) ?

vovnuke (2007-04-28 13:32:00) [9]
> [35] Игорь Шевченко © (28.04.07 12:44)

Отличие в инкапсуляции.

Ega23 (2007-04-28 13:18:00) [10]

> кроме распухания кода до невозможности.

В таком случае - никакой разницы.

А вот если TFoo.Bar должна иметь ограничения (длина строки, или, например, неотрицательные значения, если integer, или ещё что-нибудь) - то очень даже.

Я может не совсем точно выразился. Имел ввиду, что доступ к полям должен через property-прокладку идти.

Игорь Шевченко (2007-04-28 12:44:00) [11]
Ega23 © (28.04.07 12:32) [33]

Ну вот и объясни мне, как прочитавший хрестоматийные книжки,
какая разница в двух случаях:

type
TFoo = class
public
Bar: string;
end;

и
TFoo = class
private
FBar: string;
function GetBar: string;
procedure SetBar (const Value: string);
public
property Bar: string read GetBar write Setbar;
end;

function TFoo.GetBar: string;
begin
Result := FBar;
end;

procedure TFoo.SetBar (const Value: string);
begin
FBar := Value;
end;

кроме распухания кода до невозможности.

Ega23 (2007-04-28 12:34:00) [12]

> не все любят бесконечные тайпкасты TMySuperClass(List[i])

+1.

Ega23 (2007-04-28 12:32:00) [13]

> Почему ?

Ну во всех хрестоматийных книжках я видел, что с полями надо через Set и Get работать. В принципе, я тоже это не всегда использую, но это уже на усмотрение разработчика...

Игорь Шевченко (2007-04-28 12:18:00) [14]

> Если ты понишь, то доступ к полям объекта нпрямую - не рекомендуется.

Почему ?

clickmaker (2007-04-28 12:17:00) [15]

> прекрасно реализуемых с помощью "отстойного" TList, выдумывать
> еще какие-то классы, в которых будет всего-то два метода
> "добавить" и "удалить" ?

не все любят бесконечные тайпкасты TMySuperClass(List[i])

MsGuns (2007-04-28 11:48:00) [16]
Вот ситуация:
имеется приложение, управляющее потоками обмена данными с сервером (что-то типа сервера приложений, но сильно упрощенный). Все потоки делятся на 4 группы: незапущенные (в смысле на SQL сервере), активные, завершенные нормально и прерванные - каждая группа визуализируется отдельно (например, в стрингридах - но это не важно).
В процессе работы потоки постоянно перемещаются из одной группы в другую, стартуют новые и т.д. и все это отображается в интерфейсе.
Причем в трингридах пользователь может информацию сжимать, удаляя "старые".

И ты предлагаешь вместо списков дескрипторов (объектов-записей) потоков (в которых помимо указателя на собственно поток хранится масса всякой фигни о потоке служебного характера), прекрасно реализуемых с помощью "отстойного" TList, выдумывать еще какие-то классы, в которых будет всего-то два метода "добавить" и "удалить" ?
Причем одинаковых для всех "классов" дескрипторов ???

Ega23 (2007-04-28 10:25:00) [17]

> Имелось в виду специфические для данного объекта (в явном
> виде :) )
>

Если ты понишь, то доступ к полям объекта нпрямую - не рекомендуется. С рекордом же - извините...

stakan (2007-04-28 10:23:00) [18]

> Методы всегда есть. В неявном виде.

Имелось в виду специфические для данного объекта (в явном виде :) )

Ega23 (2007-04-28 10:17:00) [19]

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

Методы всегда есть. В неявном виде.

stakan (2007-04-28 10:09:00) [20]

> Пихаем туда указатель на объект с разнородными данными,
> в чём проблема?

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »