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

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

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

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

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

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

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

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

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

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

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;
  }
}

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

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

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

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

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

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

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

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