Свойства с пустыми аксессорами - PullRequest
3 голосов
/ 16 января 2012

Хотя я, конечно, знаком с авто-свойствами, я просто наткнулся на это на работе, которая, кажется, совершенно другой зверь:

public SomeType SomeProp
{
  get
  {
    return someField;
  }
  set
  {
  }
}

Я был удивлен, что он даже скомпилирован, и я предполагаю, что это должно быть ошибкой: свойство, кажется, разрешает установку, но это абсолютно ничего не делает.

Есть ли польза от этой конструкции? Это как те кнопки «Закрыть дверь» в лифтах, которые ничего не делают, но заставляют пользователя чувствовать себя хорошо?

Ответы [ 5 ]

5 голосов
/ 16 января 2012

Почему вы ожидаете, что он не скомпилируется? По сути, метод set - это просто пустой метод с одним параметром. Вы можете легко написать испорченные методы, не ожидая, что компилятор это заметит, и то же самое относится и к свойствам.

Я не могу легко представить ни одного случая, когда это было бы преднамеренно, кроме как для «частичных» реализаций - например, чтобы продемонстрировать языковые возможности, или если вы тестируете что-то, что делает , задает свойство, но вам все равно, на что это указывает тест. (Лично я все еще обычно по крайней мере записываю, что свойство было установлено.)

4 голосов
/ 16 января 2012

Вы часто видите это, когда результат должен быть сериализован в веб-сервисе или с использованием XML или двоичного сериализатора.

Это лениво и неряшливо, но это случается часто. Это оставляет объект с «внешним видом», который свойство может быть установлено. Если это сделано для того, чтобы реализовать интерфейс и разрешить компиляцию, то разработчик, который сделал это, должен быть свободно избит по голове и плечам тупым предметом, поскольку он только что сломал интерфейс. Если есть веская причина, по которой он не может быть реализован, то разработчик должен отправить его обратно на рассмотрение архитектору. Вы не просто оставляете пустые методы-заглушки при реализации интерфейса. Если у вас нет метода, определенного для реализации в данный момент, то, по крайней мере, сгенерируйте новое NotImplementedException, чтобы модульные тесты его поймали.

Что касается сериализации: свойства ReadOnly не включаются в обычную сериализацию, и это может сделать свойство недоступным для клиента веб-службы. (ref: Свойства, доступные только для чтения, не могут быть предоставлены веб-службами XML .) Это одна из причин, по которой мы все должны перейти на WCF и DataContracts. Если вы примете этот класс в качестве типа ввода для метода через WCF, то снова получите тупой объект.

2 голосов
/ 16 января 2012

Это не кажется полезным само по себе, но рассмотрим интерфейс, для которого классы должны иметь SomeProp, и вам нужно реализовать этот интерфейс в своем классе, но иметь SomeProp только для чтения и не для записи.

public interface IQuestion
{
    public int AnwserToLife { get; set; } //leave out 'set' for read-only
}

public class HitchHiker : IQuestion
{
    public int AnwserToLife
    {
        get
        {
            return 42;
        }
        set
        {  
            //never changes
        }
    }
}
1 голос
/ 16 января 2012

Я бы рекомендовал избегать такого рода программирования.Он компилируется, потому что нет никаких причин, по которым он не должен этого делать, но если интерфейс требует, чтобы вы внедрили метод установки, тогда есть две опции:

  1. Либо установщик является избыточным, и свойство должно бытьсделанный только для чтения, или
  2. Существует часть вашего кода, которая установит это значение и ошибочно предположит, что это сработало.
1 голос
/ 16 января 2012

Есть несколько вариантов использования, где это было бы необходимым обходным путем, с некоторыми из которых я уже сталкивался «в дикой природе».

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...