Здравствуйте, 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'ы?
Вам не угодишь

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


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

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

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

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

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

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

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

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