Модификаторы доступа... Почему?

Question

Итак, я просто подумал, почему программисты так сильно напрягаются, когда дело доходит до модификаторов доступа в ООП.

Давайте возьмем этот код для примера / PHP!

class Stackru
{
    private var $web_address;

    public function setWebAddress(){/*...*/}
}

Поскольку web_address является закрытым, он не может быть изменен $object->web_address = 'w.e.', но тот факт, что эта переменная только когда-либо изменится, - это если ваша программа $object->web_address = 'w.e.';

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

Итак, мой вопрос: каковы основные правила и причины использования частных / защищенных / непубличных организаций

Answer 1

Потому что (в идеале) класс должен состоять из двух частей:

1. интерфейс, доступный остальному миру, манифест того, как другие могут с ним общаться. Пример в классе дескриптора файла: String read(int bytes), Конечно, это должно быть публично, (одна / основная) цель нашего класса - предоставить эту функциональность.
2. внутреннее состояние, о котором никто (кроме самого экземпляра) должен (должен) заботиться. Пример в классе дескриптора файла: private String buffer, Это может и должно быть скрыто от остального мира: у них нет дела с этим, это деталь реализации.

Это даже делается на языке без модификаторов доступа, например, Python - за исключением того, что мы не принуждаем людей уважать конфиденциальность (и помните, что они всегда могут использовать отражение в любом случае - инкапсуляция никогда не может быть обеспечена на 100%), но префикс частных членов с _ чтобы указать "вы не должны касаться этого; если вы хотите возиться с этим, делайте на свой страх и риск".

Answer 2

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

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

Answer 3

Итак, мой вопрос: каковы основные правила и причины использования частных / защищенных / непубличных организаций

В Python нет модификаторов доступа.

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

Это довольно распространенный вопрос о Python. Многим программистам из Java или C++ (или других) фонов нравится глубоко задумываться над этим. Когда они изучают Python, на самом деле нет глубокого мышления. Принцип действия

Мы все здесь взрослые

Непонятно, кто именно - модификаторы доступа помогают. В книге Лакоса "Разработка крупномасштабного программного обеспечения" долго обсуждается "защищенный", так как семантика защищенного делает подклассы и клиентские интерфейсы немного мутными.

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

Answer 4

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

Answer 5

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

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

Answer 6

Вы удерживаете себя от случайного выполнения $object->web_address = 'w.e.';, Это может показаться ненужным на данный момент, но это не будет ненужным, если

• через два месяца вы хотите что-то изменить в проекте (и забыли все о том, что web_address не должны быть изменены напрямую) или

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