Всегда ли надо прописывать список переменных в pack?

[dech]

Ну во-первых, RunBase много чего дает. Тот же диалог, прогресс-бар или запуск заданий.
Во-вторых, паттерн может быть уже реализован (см. RunBaseReport).
В-третьих, если нельзя сделать всем понятную заглушку, а нужно "четко следовать" стандартам, то здесь попахивает занудством и бессмыслицей.

Цитата:

Сообщение от Владимир Максимов

Почему, собственно я обязан поддерживать возможность сериализации, если она в данном конкретном случае мне не нужна?

Полностью поддерживаю Владимира и задаю вопрос, зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут? Опять же повторюсь:

Цитата:

Сообщение от dech

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

[DSPIC]

Цитата:

Сообщение от dech

Ну во-первых, RunBase много чего дает. Тот же диалог, прогресс-бар или запуск заданий.
Во-вторых, паттерн может быть уже реализован (см. RunBaseReport).
В-третьих, если нельзя сделать всем понятную заглушку, а нужно "четко следовать" стандартам, то здесь попахивает занудством и бессмыслицей.

Полностью поддерживаю Владимира и задаю вопрос, зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут? Опять же повторюсь:

Судя по всему, обоснованные ответы, которые вы запросили вас неудовлетворяют. По факту они вам не нужны, все упирается в "зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут?".

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

[eugene egorov]

Цитата:

Сообщение от DSPIC

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

Отличный совет. Как человек прокопавший не один десяток тыщ строк Х++ рекомендую - делайте так! И я без работы не останусь

[Владимир Максимов]

Цитата:

Сообщение от DSPIC

Судя по всему, обоснованные ответы, которые вы запросили вас неудовлетворяют.

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

Цитата:

Сообщение от DSPIC

По факту они вам не нужны, все упирается в "зачем делать то, что абсолютно не нужно. Потому что так надо? Или потому что другие не поймут?".

По факту, я и пытаюсь получить обоснованный и аргументированный ответ на правильно понятый Вами вопрос.

Цитата:

Сообщение от DSPIC

Ответ: Как нужно - не делайте, делайте как вам нравится. Кому будет нужно - разберется и поправит. Не заморачивайтесь.

А КАК нужно-то? Точнее, не столько даже "как", сколько "почему именно ТАК"?

[DSPIC]

Цитата:

Сообщение от Владимир Максимов

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

По факту, я и пытаюсь получить обоснованный и аргументированный ответ на правильно понятый Вами вопрос.

А КАК нужно-то? Точнее, не столько даже "как", сколько "почему именно ТАК"?

Как нужно:
- паковать перменные в pack\unpack, использовать их в диалоге
- написать конструктор, с getLast() и перетереть сохраненные значение переменных, если предыдущее значение какой-то переменной

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice
- класс сможет выполняться на сервере, в Batch даже если вам этого пока не нужно (может другим понадобится)
- вы полностью сохраняете универсальность класса, задавая нужное вам поведение отдельным конструктором.

Обоснуйте, почему вы "не хотите" сделать так?

[Владимир Максимов]

Цитата:

Сообщение от DSPIC

Обоснование
- поддержав сериализацию, вы не нарушаете правил RunBase Framework и следуете BestPractice

- Отказ от поддержки сериализации НЕ нарушает правила RunBase FrameWork. Это один их штатных, предусмотренный самим FrameWork, способ реализации
- В Best Practices я не встречал упоминания об обязательности перекрытия pack/unpack. Ну, кроме обязательности перекрытия абстрактных методов из-за чего и возникает необходимость в заглушке. Но к Best Practices это не относится

Цитата:

Сообщение от DSPIC

- класс сможет выполняться на сервере, в Batch даже если вам этого пока не нужно (может другим понадобится)

- Класс и так выполняется на сервере. Это было в постановке задачи. RunOn = Server
- Batch не нужен и не понадобиться. Это также было в постановке задачи

Если Batch все-таки понадобиться, то объем модификаций при использовании заглушек и при затирании кеша будет сопоставим. Надо будет организовать "вырезание" из кеша тех переменных, которые не надо сохранять от тех, которые понадобятся для работы Batch. Там придется добавлять ряд переменных именно для Batch

Цитата:

Сообщение от DSPIC

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

- Не понял этого тезиса. О чем идет речь?

[DSPIC]

Цитата:

Сообщение от DSPIC

[U]
Обоснуйте, почему вы "не хотите" сделать так?

?

[Владимир Максимов]

Цитата:

Сообщение от DSPIC

Обоснуйте, почему вы "не хотите" сделать так?

По той причине, что я вынужден буду делать лишнюю и бессмысленную работу.

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

Т.е. делать "мусорную" работу. С этим можно смирится, если бы в этом был какой-то практический смысл. Но вот этого самого смысла я и не вижу

[DSPIC]

Цитата:

Сообщение от Владимир Максимов

По той причине, что я вынужден буду делать лишнюю и бессмысленную работу.

- Писать "лишний" код pack/unpack
- Инициализировать переменные, которые сразу после инициализации необходимо затирать (очищать) (getLast())

Т.е. делать "мусорную" работу. С этим можно смирится, если бы в этом был какой-то практический смысл. Но вот этого самого смысла я и не вижу

Я расцениваю ваше обоснование так: "не хочу". Ну так и не делайте. О всех нюансах вы в курсе, ответ/совет вам таки не нужен, как я предполагал.

Вам приходилось сдавать майкрософту ISV решения? Там куда больше спорных моментов из ряда "кому это нужно", правки занимали недели. Так принято, работа не бессмысленная и не мусорная - вам за неё платят, как минимум. Есть стандарт, принято ему следовать и не плодить антипатиерны. Еще раз - сделать можно так как вам хочется, кому нужно будет - переделает, тоже за деньги