В чем смысл public полей, если они нарушают принцип инкапсуляции?

В ООП есть три основных принципа:

  • Наследование,
  • Инкапсуляция
  • Полиморфизм.

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


Ответы (4 шт):

Автор решения: Aarnihauta

Инкапсуляция это не совсем скрытие полей.

Вот что говорит майкрософт по этому поводу:

Инкапсуляция - Скрытие внутреннего состояния и функций объекта и предоставление доступа только через открытый набор функций

Публичные свойства позволяющие получить и/или установить значение приватного поля инкапсулируют эту самую логику получить и/или установить.

UPD: Свойства и поля - это абсолютно разные вещи (судя по вашему профилю вы занимаетесь C#), так вот в С# - свойства это синтаксический сахар над двумя методами: GetField, SetField. В большинства языках программирования свойства выглядят следующим образом:

private SmthType field;
public SmthType GetField()
{
   return field;
}
public void SetField(SmthType value)
{
   field = value;
}

В C# же:

public SmthType MyProperty { get; set; }

[CompilerGenerated]
private SmthType <Property>k__BackingField;

public SmthType MyProperty
{
   [CompilerGenerated]
   get
   {
      return <Property>k__BackingField;
   }
   [CompilerGenerated]
   set
   {
      <Property>k__BackingField = value;
   }
}

После чего этот код на C# преобразуется в IL код, а в этом IL коде get и set - это методы

Как мы можем видеть, это два метода, в которых вы можете инкапсулировать какую-то логику. Модификаторы доступа представляют способ инкапсуляции членов.

Публичные члены класса как могут, так и не могут нарушать инкапсуляцию, всё зависит от контекста вашего класса, если у вас есть много "вспомогательных" методов, то их стоит сделать private - тобишь инкапсулировать внутрь объекта класса.


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

→ Ссылка
Автор решения: CrazyElf

Заглянем в Википедию:

В общем случае в разных языках программирования термин «инкапсуляция» относится к одной или обеим одновременно следующим нотациям:

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

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

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

→ Ссылка
Автор решения: Тарас Атавин

Ничего они не нарушают. Наоборот. Если из объекта ничего не торчит наружу, то и сделать с ним ничего нельзя. И скрывать в таком объекте нечего. Поэтому public-члены в любом осмысленном ООП языке обязательны. Как и protected-члены в любом ООП языке, даже бессмысленном: что-то скрывать надо.

→ Ссылка
Автор решения: Герман Борисов

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

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

→ Ссылка