Когда считается правильным проектировать прямую установку значений свойств объекта без использования установщика? - PullRequest
Новая
       35

Когда считается правильным проектировать прямую установку значений свойств объекта без использования установщика?

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

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

Рассмотрим этот пример ... 

class Test
{
    public propertyA;
    protected propertyB;

    public function setPropertyB(val)
    {
        // do some logic to validate 'val'
        this.propertyB = val;
    }

    public function getPropertyB()
    {
        return this.propertyB;
    }
}

Почему вы выбрали бы стиль прямой установки propertyA: 

var Test = new Test();
Test.propertyA = 1;

Над опцией setter для propertyB: 

var Test = new Test();
Test.setPropertyB(1);

Я всегда использую подход сеттер / геттер, но я видел несколько довольно устоявшихся фреймворков, использующих подход propertyA, вкрапленных подходом propertyB.Какие преимущества мы имеем при использовании этого метода?

Ответы [ 2 ]

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

Почему вас не заботит инкапсуляция:

  1. Возможно, вы выбрасываете проект через 15 минут.

  2. Возможно, вы обнаружили, что геттеры / сеттеры являются узкими местами для вашего кода, связанного с процессором, что приводит к оптимизации производительности вместо проектирования.

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

  4. Вам лень писать геттеры / сеттеры.

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

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

Например, допустим, у меня есть класс банковского счета в приложении Java: 

class BankAccount {
    private int balance;

    BankAccount() {
        balance = 0;
    }

    public void deposit(int amount) {
        balance = balance + amount;
    }

    public void withdraw(int amount) {
        balance = balance - amount;
    }
}

Когда моему программному обеспечению требуется изменить баланс банковского счета посредством пополнения и снятия средств, оно вызывает соответствующие методы.

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

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

Зачем вам использовать открытые поля? В общем случае, вы, вероятно, не должны. Некоторые языки позволяют вам сделать область видимости общедоступной, тогда, если вам понадобится добавить метод получения / установки позже, вы можете сделать это без изменения интерфейса вашего объекта (я считаю, что C # делает это, но исправьте меня, если я ошибаюсь).

...