Свойства
Синглтон, например. Ну, либо фабрика абстрактных объектов, хех.
Алсо, у Троелсена было немало примеров в книге, как можно извратиться с операторами доступа.
Т.е. явно реализовать эти две функции гет/сет, понятно, спасибо. Вообще определить мы можем сколь угодно много свойств и через эти свойства в дальнейшем взаимодействовать с полем, подбирая нужное в зависимости от ситуации, верно?
Хотел бы разобрать на конкретном примере:Класс DirectoryInfo и его свойство GetFiles, которое возвращает список объектов FileInfo. Я создал объект класса DirectroyInfo и получаю список файлов этим свойством. Не понятно, к какому полю это свойство привязано, если вообще к какому-то привязано или нас это, в принципе, не сильно интересует? Известно только, что будет перехвачено DirectoryNotFoundException, это и есть та защита?
P.S. За Троелсена отдельное спасибо!
Какое-то у тебя странное отношение к операторам доступа. Свойств должно быть столько, сколько у тебя приватных переменных, к которым ты хочешь предоставить доступ. Эти переменные могли бы быть и публичными, но тогда какой-нибудь программист Василий захотел бы проинициализировать переменную типа String переменной иного типа через оператор присваивания. Ты — умный чувак и предусмотрел такую возможность, сделал переменную приватной, а для доступа к ней написал сеттер, в котором проверяешь тип присваемого значения, устанавливаешь, что он не String и в этом случае конвертируешь присваиваемое значение к String, чтобы ничего не сломалось. А Василий даже знать ничего об этом не будет, ну, ему оно и не нужно. А вот если Василий постарался передать вместо String, например, Dictionary и ты понимаешь, что к строке его ну никак не привести, то бросаешь исключение, либо присваиваешь значение поумолчанию(например, String,Empty) вместо того, которое присвоил Василий. И опять же, Васю не интересует, что там происходит внутри.
Это исключение уже будет брошено, когда ты вызовешь метод, а не во время присвоения значения какому-нибудь полю, так что нет, это не защита операторов доступа. О ней я написал выше.
Это исключение уже будет брошено, когда ты вызовешь метод, а не во время присвоения значения какому-нибудь полю, так что нет, это не защита операторов доступа. О ней я написал выше.
Теперь вроде понятно. Представляю себе это так: Пусть есть участок кода
public int Number
{
get
{
return number;
throw new DirectoryNotFoundException();
}
set
{
if (value<5) number=value;
}
}
Почему?
Может и должен, но я не обнуляю, поэтому и спрашиваю почему number=0 при попытке присвоить некорректное знаечение?
Свойства с ключевым словом static можно использовать даже без создания объекта.
P.S. Обычно за свойством стоит приватное поле. Св-во дает защищенный от ошибок способ доступа к нему. Но, формально свойство не обязано быть "привязано" к конкретной переменной. Скажем гетом можно отдавать какую-нибудь информацию об объекте, но не всегда ее нужно хранить внутри поля объекта. Не слишком полезный пример: гетом возвращать время, прошедшее от момента создания объекта в программе или имя класса и т.п.
Это как бы смысл парадигмы, нет?
Скорей всего. События тоже.
На счет парадигмы не понял. Слишком мелкие это вещи для парадигм.
Вон из профессии. То есть, ты не считаешь, что свойства объектов — это инкапсуляция данных? Или не знаешь этого? Или мы говорим о разном?
P.S. Формально в терминалогии С++ свойств и нет. Там члены-данные, члены-функции. Но часто используют и терминалогию других языков, там, где это недоразумений не вызывает. Похоже последнее встречается :)
Кстати о той-же терминологии. Встречал на форуме, что пишут "метод класса" имея ввиду метод, описанный в классе. Дельфи-программиста это напряжет: методом класса в Дельфи называют метод, который "общее достояние" всего класса, а не объекта. Он может вызываться без объекта и даже без создания объекта --- то, что в C++ имеют ввиду, объявляя функцию с ключевым словом static.
Оу, не знал, что у дельфийцев есть такое.
Надо поискать что-нибудь у google на эту тему, кто-то же должен был придумать хоть какую-то натацию, которой кто-нибудь придерживается.