публичные и частные модификаторы доступа

Question

если мы можем получить доступ к частным членам через сеттеры и геттеры, то что такое личное?

Answer 1

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

Просто потому, что ваш геттер/сеттер имеет имя getName(), и ваше свойство называется name, не означает, что он всегда будет таким.

Что делать, если вы хотите изменить переменную fullName. Если вы напрямую обращаетесь к общедоступным переменным, это изменение приведет к разрыву большого количества кода. Вместо этого вы можете просто переназначить, откуда getName() извлекает свои данные.

Одним из моих лучших примеров является мой собственный класс URL, где я разрешаю создавать и манипулировать URL-адресом. Если вы хотите установить схему, вы можете получить $obj->setScheme(). Однако вы не знаете, вручную ли я создаю строку при каждом изменении URL-адреса, независимо от того, храню ли я их как отдельные части. Это дает мне гибкость, поскольку я могу хранить ваши данные, но я хочу.

Кроме того, я могу предварительно обработать данные, прежде чем хранить их. В моем классе URL я предполагаю, что все схемы и имена хостов имеют строчные буквы. Я могу стандартизировать это, преобразовывая все строки, сохраненные с помощью setHost(), в нижний регистр, а затем сохраняя их. Если бы я использовал общедоступную переменную, вам пришлось бы предположить, что клиент, который поместил данные, правильно сохранил ее.

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

Answer 2

Никто не заставляет вас вводить геттеры и сеттеры для каждой переменной. Действительно, слепо использовать частные члены + фиктивные getters & сеттеры для каждой переменной бессмысленны, хотя многие «объектно-ориентированные инкапсуляции» учебники делают это все время по какой-то причине. Во-первых, такая инкапсуляция no инкапсуляция с точки зрения параллелизма.

Answer 3

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

What is the difference between a Field and a Property in C#?

Answer 4

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

Рассмотрим следующий пример:

class toto { 
    private String someThing; 

    public String getSomething(); 
    public void setSomething(String Something); 
} 

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

class toto { 
    private ComplexSomeThing someThing; 

    public String getSomething(){ someThing.toString();} 
    public void setSomething(String something){ something = new ComplexSomeThing(something);} 
    public ComplexSomeThing (getComplexSomething(); 
    public void setComplexSomething(ComplexSomething someThing); 
} 

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

---

EDIT Существует несколько из дискуссии прямо сейчас, чтобы используя защищенные против частного или использовать понятия сродни свойства в некоторых языках (Delphi, C#), а не добытчики и сеттеров (как в Java). Защищенная, а не частная, позволит пользователям легче выполнять изменения кода, но при этом больше подвергает внутреннюю среду вашей системы, поэтому существует баланс между удобством использования API и его ремонтопригодностью. Однако основной принцип инкапсуляции остается. Независимо от выбранного варианта все еще необходимо выявить функциональность, которая является связной и на том же уровне абстракции, и скрыть подробности о том, как это делается.

Для меня дебаты состоят не в том, чтобы объявить джихад против частного, а в том, чтобы найти способ обеспечить расширяемость и гибкость, не нарушая согласованности API.

Heresomeinteresting чтение о частном, если вы хотите копать дальше. Однако я должен подчеркнуть, что прежде чем формировать мнение о частных, вы должны действительно осмыслить концепции encapsulation и polymorphism, их кажущаяся простота скрывает некоторые тонкие complexities.

Answer 5

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

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

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