Когда класс должен использовать свои собственные методы получения / установки вместо прямого доступа к членам? - PullRequest
13 голосов
/ 25 февраля 2009

При создании сеттеров и геттеров в Eclipse одним из вариантов является использование геттеров и сеттеров внутри класса, а не прямой доступ к членам класса. Является ли этот уровень внутренней инкапсуляции класса полезным или он зашел слишком далеко?

DUPE : Следует ли использовать свойства средства доступа из класса или только из-за пределов класса?

Ответы [ 7 ]

11 голосов
/ 25 февраля 2009

Я думаю, это хорошая идея, если вы хотите, чтобы возникали потенциальные побочные эффекты - проверка, ведение журнала и т. Д. (В C # я хотел бы иметь возможность объявить переменную и свойство и сказать, что only доступ к переменной осуществляется через свойство.)

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

3 голосов
/ 25 февраля 2009

Краткий ответ "это зависит":)

У Эрика Липперта есть отличная статья о Автоматических и Явных свойствах , которая касается этой проблемы, хотя и с несколько иной точки зрения.

По сути, вопрос, который вам нужно задать:

"Изнутри класса, [есть] желаемая семантика доступа к этому свойству ... отличается от желаемой семантики доступа к свойству извне?"

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

3 голосов
/ 25 февраля 2009

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

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

0 голосов
/ 12 марта 2009

Когда вам нужно расширить поведение класса getter / setter, полезно иметь инкапсулированные поля (getters / setters вместо прямого доступа к члену). И все же в наследовании концептуально интересно сохранить внутренности вашего класса, если его подклассы не должны знать о своих личных вещах. Поэтому иногда поле является частным для реализации класса, так что даже подклассы не знают об этом.

0 голосов
/ 25 февраля 2009

Если вы хотите, чтобы этот элемент мог быть привязан к данным в Winform или WPF, я считаю, что вам нужно объявить его как свойство. Я на 95 процентов уверен, что для привязки данных требуется свойство (синтаксис получения / установки). У меня есть небольшое решение wpf, которое демонстрирует это, но я не вижу способа прикрепить его здесь.

Вот код: (построен с VS 2008 SP1, ориентирован на .net 3.5 - я использовал проект WPF). В проекте WPF есть 2 элемента: главное окно (window1) и объект, который мы тестируем (DataObject) В окне есть метка, привязанная к свойству Name в экземпляре объекта данных. Если вы преобразуете свойство Name в поле (удалите метод получения / установки), привязка данных перестанет работать.

Window1.xaml:

<Window x:Class="WpfDatabinding.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
    <Label Name ="Label1" Height="28" Margin="12,24,37,0" VerticalAlignment="Top" Content="{Binding Name}"></Label>
</Grid>

Window1.xaml.cs

using System;
using System.Windows;

namespace WpfDatabinding
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        private DataObject ADataObject;

        public Window1()
        {
            InitializeComponent();
            this.ADataObject = new DataObject();
            this.ADataObject.Name = "Hello!";
            this.DataContext = this.ADataObject;
        }
    }
}

namespace WpfDatabinding
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        private DataObject ADataObject;

        public Window1()
        {
            InitializeComponent();
            this.ADataObject = new DataObject();
            this.ADataObject.Name = "Hello!";
            this.DataContext = this.ADataObject;
        }
    }
}

DataObject.cs:

namespace WpfDatabinding
{
    public class DataObject
    {
        // convert this to a field, and databinding will stop working
        public string Name
        {
            get;
            set;
        }
    }
}
0 голосов
/ 25 февраля 2009

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

Я считаю, что наличие частных / внутренних свойств помогает в этих случаях.

Но я определенно не делаю этого для любого члена.

Последний .NET / VS действительно помогает здесь, так как вы можете объявить свойство следующим образом:

public string SomeProperty
{
get;
set;
}

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

0 голосов
/ 25 февраля 2009

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

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

...