Автоматически реализованные методы получения и установки по сравнению с открытыми полями

Question

Я вижу много примеров кода для классов C #, которые делают это:

public class Point {
    public int x { get; set; }
    public int y { get; set; }
}

Или, в более старом коде, то же самое с явным частным вспомогательным значением и без новых автоматически реализуемых свойств:

public class Point {
    private int _x;
    private int _y;

    public int x {
        get { return _x; }
        set { _x = value; }
    }

    public int y {
        get { return _y; }
        set { _y = value; }
    }
}

У меня вопрос почему. Есть ли какая-либо функциональная разница между выполнением вышеприведенных и просто открытием этих членов открытых полей, как показано ниже?

public class Point {
    public int x;
    public int y;
}

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

Answer 1

AFAIK сгенерированный интерфейс CIL отличается. Если вы изменяете открытый элемент на свойство, вы изменяете его открытый интерфейс и должны перестраивать каждый файл, который использует этот класс. В этом нет необходимости, если вы меняете только реализацию методов получения и установки.

Answer 2

Сеттеры и геттеры в принципе плохие (они плохо пахнут ОО - я не скажу, что они являются анти-паттернами, потому что иногда они действительно необходимы).

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

Способ установки и получения «продан» заключается в том, что вам может понадобиться знать, что кто-то получает значение или меняет его - что имеет смысл только для примитивов.

Объекты мешков свойств, такие как DAO, DTO и экранные объекты, исключаются из этого правила, поскольку они не являются объектами в реальном значении "OO Design" слова Object. (Вы не думаете о «передаче сообщений» в DAO, это просто куча пар атрибут / значение).

Answer 3

Если вам нужно изменить способ получения x и y в этом случае, вы можете просто добавить свойства позже. Это то, что я нахожу наиболее запутанным. Если вы используете открытые переменные-члены, вы можете легко изменить их на свойство позже и использовать закрытые переменные с именами _x и _y, если вам нужно хранить значение внутри.

Answer 4

Самое большое отличие состоит в том, что, если вы когда-либо измените свою внутреннюю структуру, вы все равно сможете поддерживать методы получения и установки как есть, изменяя их внутреннюю логику, не причиняя вреда пользователям вашего API.

Answer 5

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