Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Aen Sidhe, Вы писали:
AS>>А чем использование обычного свойства отличается от использования автосвойства? MM>В обычном свойстве сеттер может быть не пустой и на запись пароля можно хоть как-то прореагировать, хэшировать, например. У автосвойства тело сеттера — это простая запись в "невидимую" переменную, которую генерирует компилятор. Какой прок от этого действия?
У автосвойства всегда есть приватный геттер
Да, в целом, я на эту тему не думал, потому что я как-то не рассматривал автосвойство без геттера вообще.
Здравствуйте, Ikemefula, Вы писали: I>Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ? I>Нахрена тогда свойство нужно ?
Например, в сеттере пароля будет вычисляться соль+хеш и сохраняться в объекте. А потом запишется в бд.
Или над паролем сразу будут производиться все преобразования, требуемые реализуемым протоколом. И внутри объека храниться будет уже пароль в преобразованном виде. Например, в WEP, емнип, текстовый пароль — "passphrase" — введен лишь для удобства — на его основе вычисляется числовой ключ.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, ilya.buchkin, Вы писали:
IB>>user u = users_repository.get( ... ); IB>>u.password = "blahblah";
IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
I>Вот интересно, что за фича — записать можно, а прочесть нельзя.
man Immutable Object
Например, объекты типа String в Java именно такие.
I>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?
Скорее всего, простой getProperty() не удовлетворяет протоколу получения информации об бъекте, в частности, для криптографических алгоритмов нужно определять явно дополнительный протокол для получения секретной информации из других связанных методов проверки авторизации запрашивающего и шифрованной передачи пароля. Вот и всё.
Здравствуйте, iZEN, Вы писали:
IB>>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
I>>Вот интересно, что за фича — записать можно, а прочесть нельзя.
ZEN>man Immutable Object
ZEN>Например, объекты типа String в Java именно такие.
Здравствуйте, Aen Sidhe, Вы писали:
AS>У автосвойства всегда есть приватный геттер
Это уже не "половинчатое автосвойство".
AS>Да, в целом, я на эту тему не думал, потому что я как-то не рассматривал автосвойство без геттера вообще.
Дык!
Здравствуйте, ilya.buchkin, Вы писали: IB>объясните? (каюсь — мой пример не из практики; действительно интересно, чем плохим он заканчивается.)
Навскидку:
1. Часть интерфейса или поведения объекта: уменьшается возможность контроля состояния объекта.
2. То, что хочется сделать в сеттерах (и не только) свойств (а это, практически всегда — сквозной функционал), логичнее решать, используя АОП.
Здравствуйте, ilya.buchkin, Вы писали: IB>почему нельзя (или чем именно плохо) то, что у меня.
Конкретно в Вашем примере, Вы сильно нагружаете сеттер свойства. По сути, используете синтаксический сахар там, где он становится менее информативным, нежели выполняющий аналогичную функцию метод.
Ну и еще, почти наверняка, приходится делать самопальное сохранение состояния объекта u — его же надо как-то помещать в user_repository
Здравствуйте, iZEN, Вы писали:
IB>>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
I>>Вот интересно, что за фича — записать можно, а прочесть нельзя.
ZEN>man Immutable Object ZEN>Например, объекты типа String в Java именно такие.
Не такие, а ровно наоборот — прочитать можно сколько угодно раз.
Здравствуйте, Mr.Cat, Вы писали:
MC>Или над паролем сразу будут производиться все преобразования, требуемые реализуемым протоколом. И внутри объека храниться будет уже пароль в преобразованном виде. Например, в WEP, емнип, текстовый пароль — "passphrase" — введен лишь для удобства — на его основе вычисляется числовой ключ.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, iZEN, Вы писали:
IB>>>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
I>>>Вот интересно, что за фича — записать можно, а прочесть нельзя.
iZEN>>man Immutable Object iZEN>>Например, объекты типа String в Java именно такие.
I>Не такие, а ровно наоборот — прочитать можно сколько угодно раз.
Здравствуйте, Aen Sidhe, Вы писали:
I>>Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ?
AS>Полезная функция свойства в том, что оно позволяет изменить пароль, если надо. И не позволяет его прочитать. В этом тоже польза.
Автор треда хочет set only auto property.
Это значит
1. никогда ни при каких условия значение не может быть прочитано
2. никогда ни при каких условиях на изменение свойства не может быть вызвана какая нибудь логика, вроде хеширования.
Понятно бы, если это С++, там есть доступ по указателю. В случае с предложением автора доступиться к значению будет только через рефлексию или какие то особо хитрые способы со структурами.
Здравствуйте, iZEN, Вы писали:
iZEN>>>man Immutable Object iZEN>>>Например, объекты типа String в Java именно такие.
I>>Не такие, а ровно наоборот — прочитать можно сколько угодно раз.
ZEN>Прочтите уже, что я дальше по тексту написал.
Я не понял, что же ты имел ввиду, ибо там предполагается что какой то доступ таки будет к сохраненному значению.
Как это сделать чз string Prop {set;} мне не ясно.
Получается живая ссылка на объект значение которой можно получить чз рефлексию
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Aen Sidhe, Вы писали:
I>>>Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ?
AS>>Полезная функция свойства в том, что оно позволяет изменить пароль, если надо. И не позволяет его прочитать. В этом тоже польза.
I>Автор треда хочет set only auto property.
I>Это значит I>1. никогда ни при каких условия значение не может быть прочитано I>2. никогда ни при каких условиях на изменение свойства не может быть вызвана какая нибудь логика, вроде хеширования.
I>Понятно бы, если это С++, там есть доступ по указателю. В случае с предложением автора доступиться к значению будет только через рефлексию или какие то особо хитрые способы со структурами.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Ikemefula, Вы писали: I>>И как это сделать в auto property ? MC>В auto — никак. В этой подветке речь не о нем.
В не-auto никто не мешает сделать один setter.
лэт ми спик фром май харт
Re[2]: Почему в C# нельзя сделать реализация только сеттера?
S>If the property getter cannot be provided, use a method to implement the functionality instead. The method name should begin with Set followed by what would have been the property name. For example, AppDomain has a method called SetCachePath instead of having a set-only property called CachePath.
Что лучше читается:
Button.Enabled = false;
или
Button.SetEnabled(false);
?
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, ilya.buchkin, Вы писали: IB>>u.password = "blahblah"; IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде). MC>Так ТС про автосвойство говорит, без кастомной логики в сеттере.
да, конечно — я это пропустил.
мой пример не на автосвойство, а только на write-only property
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, ilya.buchkin, Вы писали: IB>>почему нельзя (или чем именно плохо) то, что у меня.
W>Конкретно в Вашем примере, Вы сильно нагружаете сеттер свойства. По сути, используете синтаксический сахар там, где он становится менее информативным, нежели выполняющий аналогичную функцию метод.
спасибо.
не уверен правда, что согласен с "сильно нагружаете". (да и с " менее информативным" тоже.) имхо, дело вкуса:
user u = new user();
u.login = "vpupkin";
u.password = "neskolko zvezdochek"; // так мне красивее, единообразный код
u.first_name = "vasya";
u.last_name = "pupkin";
....
ИЛИ:
user u = new user { login = "vp", password = "neskolko zvezdochek", .... } // а так вообще только с property можно
W>Ну и еще, почти наверняка, приходится делать самопальное сохранение состояния объекта u — его же надо как-то помещать в user_repository
когда я предлагал свой пример, то думал о write-only property (а ветка-то была про "автосвойство") — моя извиняется за невнимательность.
(в моем же [неполно изложенном] сценарии, user_repository тоже не будет оперировать с исходным password — оное останется сеттером.)
Здравствуйте, mrTwister, Вы писали:
T>Что лучше читается:
Неудачный пример. Button.Enabled может быть прочитан. Если не может — второе.
Свойства (концептуально) — это способ указать наличие данных у объекта и (опционально) дать возможность их изменять. Делая свойства без геттера вы нарушаете общепринятые соглашения, как результат, ваш код сложнее использовать.
Re[4]: Почему в C# нельзя сделать реализация только сеттера?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, mrTwister, Вы писали:
T>>Что лучше читается:
S>Неудачный пример. Button.Enabled может быть прочитан. Если не может — второе.
Допустим, не может. Либо это просто никакому из клиентов не надо. Ну не держать же dead code, вот геттер и удалили.
S>Свойства (концептуально) — это способ указать наличие данных у объекта и (опционально) дать возможность их изменять. Делая свойства без геттера вы нарушаете общепринятые соглашения, как результат, ваш код сложнее использовать.
Итак, что лучше читается:
Button.Enabled = false;
или
Button.SetEnabled(false);
Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.
