Здравствуйте, mrTwister, Вы писали:

T>Что лучше читается:

Неудачный пример. Button.Enabled может быть прочитан. Если не может — второе.
Свойства (концептуально) — это способ указать наличие данных у объекта и (опционально) дать возможность их изменять. Делая свойства без геттера вы нарушаете общепринятые соглашения, как результат, ваш код сложнее использовать.

Здравствуйте, ilya.buchkin, Вы писали:
IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

А почему, в свою очередь, нельзя сделать
user u = users_repository.get( ... );
u.setPassword("blahblah");

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

Здравствуйте, snaphold, Вы писали:

S>Почему нельзя сделать половинчатое автосвойство?

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

Впрочем, обычные свойства с одним setter'ом — тоже не лучшее решение. FDG -Property Design:

Do not provide set-only properties.

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.

Здравствуйте, MxMsk, Вы писали:
MM>А каков сценарий использования такого свойства?

user u = users_repository.get( ... );
u.password = "blahblah";

пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

Здравствуйте, ilya.buchkin, Вы писали:
IB>u.password = "blahblah";
IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
Так ТС про автосвойство говорит, без кастомной логики в сеттере.

Здравствуйте, Sinix, Вы писали:


T>>Какая именно моя трактовка? И что смущает?
S>

S>для стабильного API не рекомендуют использовать интерфейсы, а вместо них абстрактные классы, так как при добавлении нового метода в интерфейс сломаются существующие клиентские реализации этого интерфейса. С другой стороны использование абстрактных классов вместо интерфейсов имеет свои известные проблемы в плане поддерживаемости кода.

S>Вы явно противопоставляете стабильность поддерживаемости, стабильный код у вас нестабильный — у вас он ломается. Изменение интерфейса после публикации продукта — мягко говоря моветон.

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

S>>>Если мы говорим о массовом применении инттерфейсов/базовых типов, то обычно интерфейсы применяются в API для add-инов, базовые классы — в фреймворках.
T>>Что произойдет с существующими add-инами, когда в реализуемом интерфейсе появится новый метод?

S>Такого не будет. Будут IAddIn2/IHost2. Полюбуйтесь на DTE студии.

Да, это вариант, но с введением IAddIn2/IHost2 мы опять сознательно жертвуем поддерживаемостью кода, так как количество интерфейсов, которые надо теперь поддерживать удвоится. Но нас это не смущает, так как OCP в данном случае важнее поддерживаемости. Об этом я и толкую. А вот если бы код не был бы широкоиспользуемым и клиенты были бы в нашей власти, то мы могли бы не вводить новые иерархии интерфейсов и потом их поддерживать, а просто отредактировать старую, плюс подправить клиента.

S>Вам не угодишь
Стал бы я тут писать, если бы все было так просто

Здравствуйте, snaphold, Вы писали:

S>Почему нельзя сделать половинчатое автосвойство?
А зачем оно такое нужно?
Зачем нужно устанавливать свойство, которое не содержит логики и которое никто не может прочитать?
В случае не обычного свойства (не авто, с переменной) половинчатое свойство вполне можно сделать.

А вообще — на троллинг смахивает...

Здравствуйте, Aen Sidhe, Вы писали:

I>>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

AS>Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

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

Нахрена тогда свойство нужно ?

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.
MM>Ну круто. Я таки снова попрошу сценарий использования такого свойства (мы говорим об автосвойствах, конечно же).

А чем использование обычного свойства отличается от использования автосвойства?

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Ikemefula, Вы писали:
I>>И как это сделать в auto property ?
MC>В auto — никак. В этой подветке речь не о нем.

В не-auto никто не мешает сделать один setter.

Почему нельзя сделать половинчатое автосвойство?

Здравствуйте, snaphold, Вы писали:

S>Почему нельзя сделать половинчатое автосвойство?

А чем не устраивает?

public A { private get; set; }

Здравствуйте, snaphold, Вы писали:

S>Почему нельзя сделать половинчатое автосвойство?
А каков сценарий использования такого свойства?

Здравствуйте, ilya.buchkin, Вы писали:

IB>Здравствуйте, MxMsk, Вы писали:
MM>>А каков сценарий использования такого свойства?

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

Я выше предложил вариант.

Здравствуйте, ilya.buchkin, Вы писали:

IB>Здравствуйте, MxMsk, Вы писали:
MM>>А каков сценарий использования такого свойства?

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

public string Password
{
    set { .... }
    get { throw new InvalidOperationException("Password can not be read."); }
}

Как-то так.

Сначала думал использовать NotSupportedException, но тут по идее не не поддерживается, а не допускается. InvalidOperationException больше подходит.

Здравствуйте, Wolverrum, Вы писали:

W>Здравствуйте, ilya.buchkin, Вы писали:
IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
W>А почему, в свою очередь, нельзя сделать
W>user u = users_repository.get( ... );
W>u.setPassword("blahblah");

конечно, "можно"... вопрос — почему нужно? т.е. почему нельзя (или чем именно плохо) то, что у меня.

W>За свой короткий срок написания ПО, пришел к выводу, что решения, подобные Вашему суть дефекты.

объясните? (каюсь — мой пример не из практики; действительно интересно, чем плохим он заканчивается.)

Здравствуйте, ilya.buchkin, Вы писали:

IB>user u = users_repository.get( ... );
IB>u.password = "blahblah";

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

Вот интересно, что за фича — записать можно, а прочесть нельзя.

Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

Здравствуйте, ilya.buchkin, Вы писали:

IB>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
И что прикажете с этим делать потом? Нафига что-то записывать куда-то, откуда это что-то нельзя потом прочитать?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, ilya.buchkin, Вы писали:

IB>>user u = users_repository.get( ... );
IB>>u.password = "blahblah";

IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

I>Вот интересно, что за фича — записать можно, а прочесть нельзя.

I>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, ilya.buchkin, Вы писали:

IB>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).
MM> И что прикажете с этим делать потом? Нафига что-то записывать куда-то, откуда это что-то нельзя потом прочитать?

Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.

Здравствуйте, Aen Sidhe, Вы писали:

AS>Пароль во многих современных системах, фактически, write-only. В открытом виде его не хранят. Следовательно, прочесть его невозможно.
Ну круто. Я таки снова попрошу сценарий использования такого свойства (мы говорим об автосвойствах, конечно же).

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Aen Sidhe, Вы писали:

I>>>Вот, к примеру, записал ты в свойство пароль. А потом тебе надо этот парол отправить на сервер. Откуда возьмешь его если свойство прочесть нельзя ?

AS>>Ниоткуда. В клиентском софте не нужен пароль в открытом виде.

I>Т.е. свойство исключительно для того, что бы можо было его установить, безо всякой полезной функции ?

Полезная функция свойства в том, что оно позволяет изменить пароль, если надо. И не позволяет его прочитать. В этом тоже польза.

I>Нахрена тогда свойство нужно ?

Да, в этом плане логичнее бы выглядел метод ChangePassword, но write-only свойство тоже норм.

Здравствуйте, Aen Sidhe, Вы писали:

AS>А чем использование обычного свойства отличается от использования автосвойства?
В обычном свойстве сеттер может быть не пустой и на запись пароля можно хоть как-то прореагировать, хэшировать, например. У автосвойства тело сеттера — это простая запись в "невидимую" переменную, которую генерирует компилятор. Какой прок от этого действия?

Здравствуйте, 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 именно такие.

Они и в .net такие.

Здравствуйте, 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" — введен лишь для удобства — на его основе вычисляется числовой ключ.

И как это сделать в auto property ?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, iZEN, Вы писали:

IB>>>>пароль можно поменять, никогда нельзя прочитать (он просто не хранится в этом же виде).

I>>>Вот интересно, что за фича — записать можно, а прочесть нельзя.

iZEN>>man Immutable Object
iZEN>>Например, объекты типа String в Java именно такие.

I>Не такие, а ровно наоборот — прочитать можно сколько угодно раз.

Прочтите уже, что я дальше по тексту написал.

Здравствуйте, Ikemefula, Вы писали:
I>И как это сделать в auto property ?
В auto — никак. В этой подветке речь не о нем.

Здравствуйте, 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>Понятно бы, если это С++, там есть доступ по указателю. В случае с предложением автора доступиться к значению будет только через рефлексию или какие то особо хитрые способы со структурами.

Или аспекты.

Здравствуйте, Sinix, Вы писали:

S>

S>Do not provide set-only properties.

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 — оное останется сеттером.)

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, mrTwister, Вы писали:

T>>Что лучше читается:

S>Неудачный пример. Button.Enabled может быть прочитан. Если не может — второе.

Допустим, не может. Либо это просто никакому из клиентов не надо. Ну не держать же dead code, вот геттер и удалили.

S>Свойства (концептуально) — это способ указать наличие данных у объекта и (опционально) дать возможность их изменять. Делая свойства без геттера вы нарушаете общепринятые соглашения, как результат, ваш код сложнее использовать.

Итак, что лучше читается:

Button.Enabled = false;
или
Button.SetEnabled(false);

Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.

Здравствуйте, mrTwister, Вы писали:

T>Либо это просто никакому из клиентов не надо. Ну не держать же dead code, вот геттер и удалили.
Вы никогда не писали мало-мальски широко используемого кода. Стоимость "dead code" наноскопична по сравнению с шансом поломать что-нибудь у клиента/вызвать его раздражение игнорированием общепринятых практик.

T>Итак, что лучше читается:
Что именно из объяснения в моём предыдущем посте вам не ясно?

T>Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.
И с англоязычными пользователями вы тоже не общаетесь. "Стань активной" — это Activate().

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, mrTwister, Вы писали:

T>>Либо это просто никакому из клиентов не надо. Ну не держать же dead code, вот геттер и удалили.
S>Вы никогда не писали мало-мальски широко используемого кода.

Месье телепат?

S>Стоимость "dead code" наноскопична по сравнению с шансом поломать что-нибудь у клиента/вызвать его раздражение игнорированием общепринятых практик.

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

T>>Итак, что лучше читается:
S>Что именно из объяснения в моём предыдущем посте вам не ясно?
Нет.

T>>Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.
S>И с англоязычными пользователями вы тоже не общаетесь.

Ну точно телепат.

S>"Стань активной" — это Activate().
Полного русского аналога слову "Enabled" я не придумал. Или вы предлагаете вместо одного метода сделать два?

Здравствуйте, mrTwister, Вы писали:

T>>>Итак, что лучше читается:
S>>Что именно из объяснения в моём предыдущем посте вам не ясно?
T>Нет.

В смысле, непонятно какая из записей лучше читается. Первая или вторая.

Здравствуйте, mrTwister, Вы писали:

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

Когнитивный диссонанс. В моём понимании, поддерживаемость включает в себя стабильность используемого API.
Изобретение собственного стиля для "узкоспециализированного" кода — тоже bad practice.

T>>>Итак, что лучше читается:
Я в третий раз намекаю, что стиль кодирования определяется кучей других факторов помимо желания "сделать красиво".

Если рассматривать сферокод в вакууме, вариант с Enabled = false смотрится логичней. Если вернуться на землю (слегка сфероконическую — приведённый вами код абсолютно нежизнеспособен), вы нарушаете принцип наименьшего удивления, заставляя вместо собственно использования API материться в сторону автора.

Объявляя члены типа, вы тем самым заявляете, как тип может использоваться. Заводя свойство, вы говорите: вот доступное значение; возможно, его можно изменять. Если значение недоступно, то свойство превращается в метод, меняющий внутреннее состояние объекта. Именно так оно и должно быть объявлено.

T>>>Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.
T>Полного русского аналога слову "Enabled" я не придумал. Или вы предлагаете вместо одного метода сделать два?
Вы придумали абсолютно неестественный пример и недовольны тем, что имя метода выглядит неестественно?

В более-менее правдоподобном варианте (Например, Set/ChangePassword()) имя метода не вызывает никаких нареканий

P.S. Никто не запрещает писать вам так, как вам нравится. Ровно до тех пор, пока вашим кодом не будет пользоваться никто кроме вас.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, mrTwister, Вы писали:

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

S>Когнитивный диссонанс. В моём понимании, поддерживаемость включает в себя стабильность используемого API.

Ну вот пример: для стабильного API не рекомендуют использовать интерфейсы, а вместо них абстрактные классы, так как при добавлении нового метода в интерфейс сломаются существующие клиентские реализации этого интерфейса. С другой стороны использование абстрактных классов вместо интерфейсов имеет свои известные проблемы в плане поддерживаемости кода. Эта дилемма решается по-разному в шорокоиспользуемых библиотеках и в узкоспециализированном коде: в широкоиспользуемом коде предпочтение отдается абстрактным классам, а в узкоспециализированном — интерфейсам.

S>Изобретение собственного стиля для "узкоспециализированного" кода — тоже bad practice.
Нет никакого собственного стиля, есть учет разных приоритетов.

S>Я в третий раз намекаю, что стиль кодирования определяется кучей других факторов помимо желания "сделать красиво".
S>Если рассматривать сферокод в вакууме, вариант с Enabled = false смотрится логичней. Если вернуться на землю (слегка сфероконическую — приведённый вами код абсолютно нежизнеспособен), вы нарушаете принцип наименьшего удивления, заставляя вместо собственно использования API материться в сторону автора.

Предложите решение лучше. В данном случае идеальным решением было бы оставить метод SetEnabled, но переименовать его во что-то более удобоваримое. Но вот только адекватное имя придумать трудно.

T>>>>Вообще, фраза "Button.SetEnabled(false)" выглядит дико. Мы говорим кнопке: "Стань активной (SetEnabled)", но при этом кнопка после вызова станет неактивной.
T>>Полного русского аналога слову "Enabled" я не придумал. Или вы предлагаете вместо одного метода сделать два?
S>Вы придумали абсолютно неестественный пример и недовольны тем, что имя метода выглядит неестественно?
Ок, заменим Button на Foo. Foo — это сущность, которая может быть либо enabled, либо disabled. Никакому клиенту не надо знать её текущее состояние, но надо менять.

S>В более-менее правдоподобном варианте (Например, Set/ChangePassword()) имя метода не вызывает никаких нареканий
Меня интересует именно имя SetEnabled, так как не далее, чем вчера я мучился с придумыванием адекватного имени для него.

Здравствуйте, mrTwister, Вы писали:

T>Ну вот пример: для стабильного API не рекомендуют использовать интерфейсы, а вместо них абстрактные классы, так как при добавлении нового метода в интерфейс сломаются существующие клиентские реализации этого интерфейса. С другой стороны использование абстрактных классов вместо интерфейсов имеет свои известные проблемы в плане поддерживаемости кода.

Весьма странное разделение, особенно смущает ваша трактовка стабильного|поддерживаемого API. Если мы говорим о массовом применении инттерфейсов/базовых типов, то обычно интерфейсы применяются в API для add-инов, базовые классы — в фреймворках.

T>Предложите решение лучше. В данном случае идеальным решением было бы оставить метод SetEnabled, но переименовать его во что-то более удобоваримое. Но вот только адекватное имя придумать трудно.
Ну да, потому что сама концепция кривая. Если гнаться за красотой, можно завести методы Enable()/Disable, или использовать какую-нить другую модель (например, SuppressProcessing() по аналогии с GC.SuppressFinalize()).

Здравствуйте, Sinix, Вы писали:

S>Весьма странное разделение,

Общепринятое. Точнее принятая в .Net Framework. Krzysztof Cwalina (Program Manager on the Common Language Runtime team) в книге "Framework Design Guidelines" подробно об этом рассказывает. Приводится пример абстрактного класса System.IO.Stream, что именно на этом основании он был сделан абстрактным классом, а не интерфейсом.

S>особенно смущает ваша трактовка стабильного|поддерживаемого API.

Какая именно моя трактовка? И что смущает?

S>Если мы говорим о массовом применении инттерфейсов/базовых типов, то обычно интерфейсы применяются в API для add-инов, базовые классы — в фреймворках.
Что произойдет с существующими add-инами, когда в реализуемом интерфейсе появится новый метод?

T>>Предложите решение лучше. В данном случае идеальным решением было бы оставить метод SetEnabled, но переименовать его во что-то более удобоваримое. Но вот только адекватное имя придумать трудно.
S>Ну да, потому что сама концепция кривая. Если гнаться за красотой, можно завести методы Enable()/Disable, или использовать какую-нить другую модель (например, SuppressProcessing() по аналогии с GC.SuppressFinalize()).

И везде потом лепить if'ы? То есть вместо

Foo.Ehabled = flag;

писать

if(flag)
{
    Foo.Enable();
}
else
{
    Foo.Disable();
}

Здравствуйте, mrTwister, Вы писали:

Последний пост и завязываю — беседа пошла по кругу.

S>>особенно смущает ваша трактовка стабильного|поддерживаемого API.

T>Какая именно моя трактовка? И что смущает?

для стабильного API не рекомендуют использовать интерфейсы, а вместо них абстрактные классы, так как при добавлении нового метода в интерфейс сломаются существующие клиентские реализации этого интерфейса. С другой стороны использование абстрактных классов вместо интерфейсов имеет свои известные проблемы в плане поддерживаемости кода.

Вы явно противопоставляете стабильность поддерживаемости, стабильный код у вас нестабильный — у вас он ломается. Изменение интерфейса после публикации продукта — мягко говоря моветон.

S>>Если мы говорим о массовом применении инттерфейсов/базовых типов, то обычно интерфейсы применяются в API для add-инов, базовые классы — в фреймворках.
T>Что произойдет с существующими add-инами, когда в реализуемом интерфейсе появится новый метод?

Такого не будет. Будут IAddIn2/IHost2. Полюбуйтесь на DTE студии.

T>И везде потом лепить if'ы?
Вам не угодишь