Сокрытие информации и свойства

Question

Означает ли скрытие информации, что я должен минимизировать количество свойств, которые имеют мои классы? Это правильно? Вы склонны делать ваши классы закрытыми полями с методами?

Answer 1

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

Answer 2

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

Кажется, что многие в принципе понимают, что такое сокрытие информации, но в то же время думают, что примером этого являются методы получения и установки для всего / свойства для всего.

Зажигательная статья Аллена Холуба под названием " Почему добытчики и сеттеры злы " может открыть глаза на эту тему.

Короче говоря, частные члены с прямыми получателями и установщиками - это не более, чем одетые публичные члены. Это правда, что геттеры и сеттеры необходимы на границах слоев (пользовательский интерфейс, постоянство и т. Д.), Но их видимость должна быть ограничена теми классами, которые имеют законную необходимость вызывать их.

Answer 3

Когда-нибудь завели разговор, спросив «Как ты ты?», Только чтобы встретиться со списком их неприятностей и триумфов, злобой и неинтересными интересами, чувством неуверенности и, возможно, Глубина обзора кексов для завтрака ...

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

Закрытые поля, доступ к которым осуществляется через открытые методы. Хотя может показаться глупым удвоение делать что-то вроде:

private int _myInt;
public int MyInt
{
  get { return _myInt; }
  set { _myInt = value; }
}

Хотя теперь вы можете просто сделать (IIRC, мои знания 3.5 не завершены):

public int MyInt { get; set; }

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

public int MyInt
{
  get { return _myInt; }
  set
  {
    _myInt = (value % 2 == 0) ? value : _myInt;
  }
}

(Примечание: не лучший пример, поскольку он не дает понять, что их операция не удалась.)

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

Answer 8

Объявление чего-то закрытого по объему на самом деле не «скрывает» информацию.

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