ООП

← →
Rouse_ © (2013-12-05 21:48) [40]

> а я почему-то думал, что респонс это биты и байты.

Ну так и думай так дальше - никто-ж не запрещает :)

← →
Медвешоног Порошог (2013-12-05 21:54) [41]

а что, у тебя есть пример реального респонса который есть не биты и не байты?
может покажешь?

← →
Медвешоног Порошог (2013-12-05 22:03) [42]

Вот вся причина почему респонс у автора стал объектом:

Объектами в дельфях (7) удобнее манипулировать — можно передавать в функции по значению, можно сложить в объектлист, а тот память сам почистит при освобождении, можно метод прикрутить при надобности. А так-то да, plain old data.

что реально мы видим:
1. автор хочет иметь мало параметров в процедурах обработки. в идеале один параметр.

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

3. так как респонсы разные он поимел иерархию то ли классов то ли интерфейсов и ломает голову как же красиво и удобно писать обработчики на основе ртти.

4. если бы у него была подходящая структура для хранения данных респонса то необходимость в объекте была бы лишняя. и это сразу было бы видно.

а вместо этого в ветке сейчас трут (и еще долго будут тереть) про то с какого конца разбивать яйцо.

← →
Rouse_ © (2013-12-05 22:08) [43]

> Медвешоног Порошог (05.12.13 21:54) [41]
> а что, у тебя есть пример реального респонса который есть
> не биты и не байты?
> может покажешь?

Не поток сырых данных, а структура? Та лехко, четай :)
http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx

← →
имя (2013-12-05 22:13) [44]

Удалено модератором

← →
Rouse_ © (2013-12-05 22:16) [45]

Удалено модератором

← →
Дмитрий Белькевич (2013-12-05 22:57) [46]

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

У нас местами обратные связи снизу вверх есть. Удобно, на самом деле и каши особой нет. Лучше бы, конечно, совсем отделить мух от котлет. Но в случае сильно связанных классов врятли получится.

>procedure UpdateDeviceState(device: TDevice); virtual; abstract;

А если так: procedure UpdateDeviceState(device: TObject); virtual; abstract; ?

Я особенно не вчитывался. Обязательно туда именно определенный класс передавать?

← →
Дмитрий Белькевич (2013-12-05 23:09) [47]

> Вот вся причина почему респонс у автора стал объектом:Объектами
> в дельфях (7) удобнее манипулировать — можно передавать
> в функции по значению, можно сложить в объектлист, а тот
> память сам почистит при освобождении, можно метод прикрутить
> при надобности. А так-то да, plain old data.что реально
> мы видим:1. автор хочет иметь мало параметров в процедурах
> обработки. в идеале один параметр.2. у объекта респонса
> ничего кроме полей и свойств не используется. возможная
> прикрутка методов в перспективе не в счет.3. так как респонсы
> разные он поимел иерархию то ли классов то ли интерфейсов
> и ломает голову как же красиво и удобно писать обработчики
> на основе ртти.4. если бы у него была подходящая структура
> для хранения данных респонса то необходимость в объекте
> была бы лишняя. и это сразу было бы видно.а вместо этого
> в ветке сейчас трут (и еще долго будут тереть) про то с
> какого конца разбивать яйцо.

Всё таки, почему не record? Мало параметров в процедурах, в идеале - один, можно (уже) прикрутить методы, передавать по значению, если не использовать динамические массивы внутри - сами разрушаться. Только что их иерархию не сделать. Но можно какой-то один (пусть избыточный) record придумать, что бы для всех девайсов сразу. Ну а если нужно внутри класса-обработчки специальным образом обрабатывать разные респонс-рекорды, сделать поле - DeviceID и обрабатывать по-разному. ИМХО, конечно, мот задачу не понял до конца.

← →
имя (2013-12-05 23:09) [48]

Удалено модератором

← →
Юрий Зотов © (2013-12-05 23:24) [49]

> Rouse_ © (05.12.13 19:49) [30]

Это же всего лишь пример. В реальности все определяется тем, как выполняется реквест. Например, если респонс создается при выполнении реквеста, то вызов конструктора ЗДЕСЬ вообще не нужен. Да и вызов Free - под вопросом (уничтожать респонс или нет - зависит от задачи).

> Kerk © (05.12.13 20:43) [32]

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

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

> All

Что из себя представляет респонс - зависит от задачи. Например, если при выполнении реквеста требуется какая-то перекодировка (да и вообще любая предварительная обработка данных), то логично сделать респонс именно объектом, а эту предварительную обработку загнать в его сеттеры.

← →
Kerk © (2013-12-05 23:51) [50]

> Юрий Зотов © (05.12.13 23:24) [49]
> Естественно, case от if мало чем отличается. Просто код
> становится более читабельным, особенно в случае многоэтажного
> if при большом количестве разных респонсов.

Если вместо абстрактного Tag-а обозвать это чем-то вроде ResponseCode со значениями-константами с осмысленными именами или может быть даже взять перечислимый тип, то я пожалуй даже соглашусь. Вполне себе вариант.

← →
Kerk © (2013-12-05 23:58) [51]

Ну и по второй обсуждаемой теме...
Если респонс - это биты и байты, то непременно надо их в XML запихать. Это наиболее оптимальный вариант :)

← →
Юрий Зотов © (2013-12-06 00:02) [52]

> Kerk © (05.12.13 23:51) [50]

Естественно. Но это уже вопрос реализации.

← →
имя (2013-12-06 08:39) [54]

Удалено модератором

← →
имя (2013-12-06 08:47) [55]

Удалено модератором

← →
имя (2013-12-06 10:07) [56]

Удалено модератором

← →
имя (2013-12-06 11:06) [57]

Удалено модератором

← →
имя (2013-12-06 11:18) [58]

Удалено модератором

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