Инкапсуляция в определениях классов

Question

Например, вы используете аксессоры и мутаторы в определениях ваших методов или просто обращаетесь к данным напрямую? Иногда все время или когда в Риме?

Answer 1

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

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

Редактировать: Читать Автоматически против явных свойств Эрика Липперта, в котором он углубляется в эту самую проблему и объясняет вещи очень ясно. Речь идет конкретно о C #, но теория ООП универсальна и прочна.

Вот выдержка:

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

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

Answer 2

Средства доступа спроектированы так, чтобы вы могли добавлять логику для конкретного свойства. Такие как

int Degrees
{
    set
    {
        _degrees = value % 360;
    }
}

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

Если, как упомянул Эндрю, вам нужно пропустить проверку, то вполне возможно, что есть недостаток в дизайне функции или в дизайне проверки.

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

РЕДАКТИРОВАТЬ

Смотрите и этот вопрос: OO Design: Вы используете внутренние свойства или частные поля для внутреннего использования?

Answer 3

В общем, я предпочитаю аксессоры / мутаторы. Таким образом, я могу изменить внутреннюю реализацию класса, в то время как класс функционирует таким же образом для внешнего пользователя (или существующего кода, который я не хочу нарушать).

Answer 4

Я часто буду начинать с частных авто свойств, а затем рефакторинг, если это необходимо. Я проведу рефакторинг свойства со вспомогательным полем, а затем заменю вспомогательное поле «реальным» хранилищем, например Session или ViewState для приложения ASP.NET.

От:

    private int[] Property { get; set; }

до

    private int[] _property;
    private int[] Property
    {
        get { return _property; }
        set { _property = value; }
    }

до

    private int[] _property;
    private int[] Property
    {
        get
        {
            if (_property == null)
            {
                _property = new int[8];
            }
            return _property;
        }
        set { _property = value; }
    }

до

    private int[] Property
    {
        get
        {
            if (ViewState["PropertyKey"] == null)
            {
                ViewState["PropertyKey"] = new int[8];
            }
            return (int[]) ViewState["PropertyKey"];
        }
        set { ViewState["PropertyKey"] = value; }
    }

Конечно, я использую ReSharper, поэтому это занимает меньше времени, чем публикация.

Answer 5

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

Довольно редко я пишу аксессор / мутатор, который будет вызывать закрытый метод, но я подозреваю, что я здесь в меньшинстве. Может быть, я должен сделать больше, но я не склонен.

Во всяком случае, это мои [покрытые патиной] два цента.