(no subject)

[yms]

хе-хе! недостаточек C# по крайней мере 2.0: в проперти нельзя один аксессор сделать абстрактным, а другой реализовать. Хотя разную публичность они там сделали.

Comments

[e-levy.livejournal.com]

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

[yms.livejournal.com]

почему совсем другая? аналогичная добавка в синтаксисе - и вперёд.

[e-levy.livejournal.com]

Другая - с логической точки зрения. Что есть проперти, с чего все начиналось в том же Дельфи, где впервые я с этим понятием познакомился - не более чем "умное" поле. И с этой точки зрения "переопределение" доступа к его геттеру и сеттеру еще можно понимать как "добавление" гибкости, возможность "запихнуть в него еще функциональности". Хотя уже даже виртуальность и абстракность "тяжело" впихнуть в это представление. Ну какой смысл у "виртуального" или тем более "абстрактного" поля? То, что проперти реализуется через пару методов - это техническая реализация, которая потянула за собой и все остальные навороты - разный уровень доступа к этим методам, а там уже захочется и один из них сделать виртуальным или абстрактным, а другой нет и т.д. и т.п. Имхо, это кодеры "победили" архитекторов и заставили их дать возможность изменить уровень доступа к методам. Но их "виртуальность" пока архитекторы отстояли ;).

[yms.livejournal.com]

Проперти - не "улучшенное поле", а скорее удобное сокращение для пары GetValue()/SetValue(), которая часто встречается в C++ и Джаве.

Ну какой смысл у "виртуального" или тем более "абстрактного" поля?

Точно такой же, как у виртуальных и абстрактных функций. Пример: базовый класс, наследующий от TextBox'а, определяет проперти object Value, абстрактный геттер которого парсит его текст для каждой реализации по-своему (int.Parse, float.Parse), а сеттеру достаточно вызвать ToString(), так почему бы его прямо в базовом и не определить.
Впрочем, я от этого уже отказался, потому что захотел Value с более конкретными типами.

[e-levy.livejournal.com]

Проперти - не "улучшенное поле", а скорее удобное сокращение для пары GetValue()/SetValue()
Все-таки, имхо, это не "удобное сокращение". Да и судя по указанной здесь формулировке это именно некий "интерфейс" доступа к полю и это именно "свойство" объекта, что, имхо, ближе к понятию "поле", а не к понятию "удобное сокращение пары методов". Пара методов - просто реализация. Пока на самом деле единственная, другого "паттерна" реализации проперти я не встречал. Я согласен, что чисто с технической точки зрения кодировщика гораздо удобнее было бы рассмативать проперти как удобное сокращение пары методов и тогда ясное дело хочется получить "полную" функциональность от каждого метода. Вплоть до того, что еще и придумать какой-нибудь синтаксис для возможности передачи этим методам параметров и даже сделать возможность их перезагрузки :), а не только само собой разумеющуюся в этом случае виртуальность, абстракность, уровень доступа и т.п. Только зачем изобретать такого монстра, если тогда проще сделать на самом деле пару методов? ;) Да даже в случае, когда возникает желание сотворить виртуальное или абстрактное или с разным уровнем доступа к аксессорам проперти, имхо, стоит переспросить себя - а не проще ли сделать парочку методов вместо этого? ;) Не зря один мой знакомый джавист упорно отрицал нужность такого понятия вообще, мотивируя тем, что это только усложняет чтение кода :).

[yms.livejournal.com]

Я бы на твоем месте постеснялся давать ссылку на статью русской википедии о программировании :) См. английскую статью. Проперти не есть "интерфейс" для "доступа к полю", потому что никакого поля за ним может и не быть. А перенагрузка свойства - самая обычная техника построения иерархии классов, например, мой любимый GoDiagram это широко использует.

[e-levy.livejournal.com]

Я не знал, что ты не любишь русскую вики ;). Из английской статьи кстати не следует, что никакого поля за ним может и не быть. . Наоборот, ясно сказано:
That is, properties are intermediate between member code (methods) and member data (instance variables) of the class. То есть instance variables, то есть поля существуют, иначе между чем и чем быть посредником? Так что и там property не рассматривается как "облегчение пары методов" ;). Хотя, как я уже сказал, мне как программеру это было бы намного удобней.
GoDiagram это построитель разных UML-ек?
Я использую Enterprise Architect и имел долгую переписку с его авторами, пытаясь их убедить, что может быть описанная тобой ситуация, что что никакого поля за ним может и не быть.. У нас есть покупной ORM layer который "дописывает" код (наследует от наших классов и делает их "хранимыми") и он требует чтобы у нас были абстрактные проперти. EA их генерирует, но при этом _обязательно_ создает никому не нужную instance variable :). Потому что "архитектура требует" и его создатели, очень неглупые люди действительно создавшие классный продукт, настаивают, что поле обязательно должно быть :(.

[yms.livejournal.com]

GoDiagram - это библиотека классов для создания редакторов диаграмм любого вида, очень гибкая.

[e-levy.livejournal.com]

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

[yms.livejournal.com]

Да как угодно: например, перехватить сеттер свойства Bounds, чтобы в процессе установки границ элемента чего-нибудь пересчитать. Или перехватывать геттер свойства Text, чтобы в качестве текста элемента возвращать текст его конкретного подэлемента. Или перехватить свойство StringTrimming, чтобы при печати выдавать строку неусечённую, а при показе на экране - усечённую по дефолту. И т.д. и т.п. Там всё построено на многослойных действиях, и любое действие ты можешь перехватить на нужном уровне и изменить дефолтовое поведение, в том числе через проперти, а если не перехватываешь - имеешь стандартное поведение, подходящее в большинстве случаев. Образцово-показательный дизайн.

[e-levy.livejournal.com]

Понятно. Действительно дизайн удобный. Только к overloading, то есть "перезагрузке", имхо, это никакого отношения не имеет ;). Это широкое использование "виртуальности", т.е. имплементация полиморфизма через наследование и виртуальные методы. Из твоего примера это хорошо видно.
А перезагрузка у проперти в принципе невозможна. Только у методов. Потому я ее и привел выше как пример возможных последующих абсурдных желаний разработчиков ;). Если бы как-то заставили придумать для проперти перезагрузку, то, имхо это выглядело бы вот так:

public bool Printable
{
get
{
return Text.Length != 0 && base.Printable;
}
get(bool DoNotCheckTextLength)
{
return base.Printable;
}
}
И тогда использование такое:
SomeClass a = new SomeClass();
if (a.Printable)
{
//Do something
}
if (a.Printable(false))
{
//Do something else
}
Но такого монстра уж точно никто делать не будет ;). Собственно, как и виртуальные или абстрактные аксессоры :). Хотя было бы довольно удобно. А вообще в Delphi, ну это уже чисто мое мнение, как-то более удобней проперти сделаны. Ты просто делаешь два метода, по идее они могут быть какими угодно: с какими угодно уровнями видимости и какой угодно виртуальностью, и "связываешь" их в проперти. Но в C# синтаксис другой, потому и приходится изобретать всякие хитрые синтаксические конструкции, вроде private/protected аксессоров.

[yms.livejournal.com]

тьфу! только сейчас дошло, что ты говорил об overloading, а не overriding. Нет, это не нужно, конечно, достаточно стандартных средств.

[e-levy.livejournal.com]

Ну и я о том же :). А разная виртуальность/абстрактность аксессоров конечно не помешала бы, но могу спорить на что угодно, что Microsoft их не сделает ни в 4.0 ни в 5.0 :). Архитекторы не дадут.
Имхо, надо было им побольше вещей с дельфи скопировать. Anders Hejlsberg-а, главного архитектора Дельфи они к себе переманили и поэтому в C# много идей взято с Дельфи, а вот идея пропертей у них своя. А, имхо, зря :). Благодаря ей разной виртуальности/абстрактности у аксессоров в С# и не будет.

[yms.livejournal.com]

Ну, Хейлсберг уже давно увлекся совсем другими цацками (см. C# 3.0).

[e-levy.livejournal.com]

Да, смотрел. Но мы еще на 2.0 сидим. Так что пока никаким синтаксическим сахарком типа лямбда функций, объект-инициализаторов, экстеншен-методов, да и собственно линка, ради которого все затевалось, нас не балуют :).
Кстати, так называемые объект-инициализаторы в дельфи были для рекордов (аналог структур), так что и тут он взял идейку из "прошлой жизни" ;). Вот через пару месяцев выйдет новая версия нашей ORM-ки под 3.5 с поддержкой линка и прочих радостей жизни, тогда и повеселимся :). И никакие виртуальные аксессоры не понадобятся :)).

[yms.livejournal.com]

вдогонку - примерчик еще:

/// <summary>
/// Don't print param box if it's empty (and colored)
/// </summary>
public override bool Printable
{
get
{
return Text.Length != 0 && base.Printable;
}
}

[e-levy.livejournal.com]

Ой, прости, не "вчитался" в текст. intermediate - имеется в виду "среднее", а не посредник. Однако все равно это не отменяет их фразу You read and write a property just as you read and write a field ;).

[e-levy.livejournal.com]

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