Здравствуйте, _ks_, Вы писали:
__>Кто впервые придумал проперти (это которые { get; set; }) ? __>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
Я думаю, тут все дело в Хейлсберге, который делал и Delphi и C#.
См. интервью здесь.
People have suggested that C# is sort of Delphi v2.0. Do you think that is a fair assessment? Is a lot of like breaking in the component model as part of the language, is a lot of that experience from having done some of the stuff with Delphi at Borland?
Well, there is no doubt that there is heritage from Delphi. Delphi has properties, Delphi has events and so forth, and if I have to go do it again, I still think they are useful concepts. So I would put into the next one too, if there was a next one. I think you learn from what you've done. You learn from your past mistakes, you know what worked and what didn't, and you keep the stuff that worked, and then you get rid of the stuff that didn't. Those are definitely things that worked and I think they are some of the things that made Delphi a great product.
Здравствуйте, _ks_, Вы писали:
__>Кто впервые придумал проперти (это которые { get; set; }) ?
__>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
И что же такого хорошего в этих пропетях? По моему так без них только лучше.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _ks_, Вы писали:
__>>Кто впервые придумал проперти (это которые { get; set; }) ? __>>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
N>Я думаю, тут все дело в Хейлсберге, который делал и Delphi и C#. N>См. интервью здесь.
А в разработке технологии COM он случайно участия не принимал? Там эти пропети уже давненько. Ж..ой чую — в COM из Васика пошло, а откуда там это чудо взялось — я не знаю.
Здравствуйте, _d_m_, Вы писали: ___>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
Обоснуй. Плодить геттеры и сеттеры (как в Java)? Я конечно понимаю, что в современных IDE это не особая проблема (ассистенты и снипетты всякие), но, ИМХО, код более загроможденный.
Так
string networkID;
public int NetworkID
{
get { return this.networkId; }
set { this.networkId = value; }
}
удобнее чем
private int id;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, _ks_, Вы писали:
__>>Кто впервые придумал проперти (это которые { get; set; }) ?
__>>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
___>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, _ks_, Вы писали:
__>>Кто впервые придумал проперти (это которые { get; set; }) ?
__>>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
___>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
Я думаю главное достоинство — возможность разграничения доступа, например паблик геттер и интернал сеттер. Ну и возможность выполнения дополнительного кода при обращении как с полями.
Здравствуйте, BlackHeretic, Вы писали:
BH>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, _ks_, Вы писали:
__>>>Кто впервые придумал проперти (это которые { get; set; }) ?
__>>>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
___>>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
BH>Не приведи господь поддерживать твой код
Нда? Ну в таком случае — тебе прямая дорога в церковь. Я с этой мыслью не первый, а лишь согласен с Рихтером. Слышал про такого?
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, _d_m_, Вы писали: ___>>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
F>Обоснуй. Плодить геттеры и сеттеры (как в Java)? Я конечно понимаю, что в современных IDE это не особая проблема (ассистенты и снипетты всякие), но, ИМХО, код более загроможденный.
Чем он загромажденный? :
int networkID;
public int NetworkID
{
get { return this.networkId; }
set { this.networkId = value; }
}
То же самое, что и:
private int id;
public int getId() { return id; }
public void setId(int id) { this.id = id; }
А семантика полей и проперти совпадают. Только в случае проперти можно реально огрести. Типа исключений, неочевидных изменений состояния объекта и прочего. К Рихтеру.
Одно из преимуществ propreties -- это связность getter-а и setter-а на уровне метаданных с введением новой, вполне естественной сущности. Возможность писать ABC, а не get_ABC(), set_ABC() -- это не более, чем приятный синтаксический сахар.
___>А семантика полей и проперти совпадают. Только в случае проперти можно реально огрести. Типа исключений, неочевидных изменений состояния объекта и прочего. К Рихтеру.
Все это примеры неудачного дизайна и использования properties не по назначению.
Здравствуйте, _d_m_, Вы писали:
___>А семантика полей и проперти совпадают. Только в случае проперти можно реально огрести. Типа исключений, неочевидных изменений состояния объекта и прочего. К Рихтеру.
Ну это сказки. Посмотри в MSIL. Там компилятором генерируются те же геттеры и сеттеры. Это не более чем повышение комфорта при программировании.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, BlackHeretic, Вы писали:
BH>>Здравствуйте, _d_m_, Вы писали:
___>>>Здравствуйте, _ks_, Вы писали:
__>>>>Кто впервые придумал проперти (это которые { get; set; }) ?
__>>>>Просто у меня такое ощущение, что в C# оно появилось не первым. Обычно MS берёт идеи у других. Неужели такую удобную штуку они придумали сами?
___>>>И что же такого хорошего в этих пропетях? По моему так без них только лучше.
BH>>Не приведи господь поддерживать твой код
>Нда? Ну в таком случае — тебе прямая дорога в церковь. Я с этой мыслью не первый, а лишь согласен с Рихтером. Слышал про такого?
Если твой Рихтер сказал это тебе нежно на ушко — про такого не знаю. А если это тот, который автор книг — слышал и хочется увидеть цитаты.
... Mab>Здравствуйте, _d_m_, Вы писали:
Mab>Одно из преимуществ propreties -- это связность getter-а и setter-а на уровне метаданных с введением новой, вполне естественной сущности. Возможность писать ABC, а не get_ABC(), set_ABC() -- это не более, чем приятный синтаксический сахар.
...
Еще удобно их использовать при привязке полей объектов к форме.
Разметил атрибутами и при построении формы, автоматом идет привязка полей объектов к контролам на форме, и не надо писать тупой код по установке и получению значений контролов и пропихивания их в объект.
Здравствуйте, _d_m_, Вы писали:
___>Нда? Ну в таком случае — тебе прямая дорога в церковь. Я с этой мыслью не первый, а лишь согласен с Рихтером. Слышал про такого?
Ты бы сначала задался вопросом, что именно не понравилось Рихтеру в свойствах и уже только потом решал, соглашаться с ним или нет.
Ты вот на каких основаниях с ним согласен?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Mab, Вы писали:
___>>А семантика полей и проперти совпадают. Только в случае проперти можно реально огрести. Типа исключений, неочевидных изменений состояния объекта и прочего. К Рихтеру. Mab>Все это примеры неудачного дизайна и использования properties не по назначению.
+1, я бы ещё запретил возможность объявить set-метод с более широкой областью видимости, чем get- к прочему сахару из C# 3.0. В принципе, то, что свойства можно использовать неправильно тогда, когда этого можно _безболезненно_ избежать, говорит не в их пользу
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Andrbig, Вы писали:
A>Если твой Рихтер сказал это тебе нежно на ушко — про такого не знаю. А если это тот, который автор книг — слышал и хочется увидеть цитаты.
CLR via C#, Издательство "Питер", 2007 г., стр 208.
Лично мне свойства не нравятся, и я был бы рад, если бы их поддержку убрали из Microsoft .NET Framework и сопутствующих языков программирования.