Частный по сравнению с Общедоступными участниками на практике (насколько важный инкапсуляция?) [закрытый]

Соответствуйте инструменту к заданию... недавно, я видел некоторый код как это в моей текущей кодовой базе:

private static class SomeSmallDataStructure {
    public int someField;
    public String someOtherField;
}

И затем этот класс использовался внутренне для того, чтобы легко раздать несколько значений данных. Это не всегда имеет смысл, но если у Вас есть просто ДАННЫЕ без методов, и Вы не представляете его клиентам, я нахожу его довольно полезным шаблоном.

новое использование я имел этого, была страница JSP, где у меня была таблица данных, отображаемых, определенных наверху декларативно. Так, первоначально это было в нескольких массивах, одном массиве на поле данных..., которое это закончило в коде, являющемся довольно трудным пробраться через с полями, не являющимися друг рядом с другом в определении, которое будет отображено вместе..., таким образом, я создал простой класс как вышеупомянутый, который сплотит его..., результатом был ДЕЙСТВИТЕЛЬНО читаемый код, намного больше, чем прежде.

Мораль... иногда необходимо считать "принятым плохо" альтернативы, если они могут сделать код более простым и легким для чтения, пока Вы продумываете его и полагаете, что последствия... вслепую не принимают ВСЕ, что Вы слышите.

, Который сказал..., общедоступные методы get и методы set в значительной степени эквивалентны общедоступным полям..., по крайней мере, по существу (существует немного больше гибкости, но это - все еще плохой шаблон для применения к КАЖДОМУ полю, которое Вы имеете).

Даже библиотеки стандарта Java имеет некоторые случаи общедоступные поля .

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

, Например: Человек. Рука. Захват (howquick, howmuch);

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

Моя тенденция состоит в том, чтобы попытаться сделать все частным, если это возможно. Это сохраняет границы объекта максимально ясно определенными и сохраняет объекты максимально разъединенными. Мне нравится это потому что, когда я должен переписать объект, что я испортил первое (второй, пятый?) время, это сохраняет повреждение содержавшим к меньшему числу объектов.

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

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

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

Инкапсуляция важна когда по крайней мере одно из этих хранений:

1. Любой, но Вы собирается использовать Ваш класс (или они повредят Ваши инварианты, потому что они не читают документацию).
2. Любой, кто не читает документацию, собирается использовать Ваш класс (или они повредят Ваши тщательно задокументированные инварианты). Обратите внимание, что эта категория включает you-two-years-from-now.
3. В какой-то момент в будущем кто-то собирается наследоваться Вашему классу (потому что, возможно, дополнительные меры должны быть приняты, когда значение поля изменяется, таким образом, должен быть метод set).

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

Это - все об управлении, что могут сделать люди, с каким Вы даете им. Чем больше управления Вы - тем больше предположений можно сделать.

кроме того, theorectically можно изменить конкретную реализацию или что-то, но так как по большей части это:

private Foo foo;
public Foo getFoo() {}
public void setFoo(Foo foo) {}

немного трудно выровнять по ширине.

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

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

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

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

Свойства C# 'моделируют' общедоступные поля. Выглядит довольно прохладным, и синтаксис действительно ускоряет создание, те добираются/методы установки

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

Пример: я пишу код, который обновляет переменную, и я должен сделать абсолютно уверенным, что Gui изменяется для отражения изменения, самый легкий путь состоит в том, чтобы добавить метод доступа (иначе "Метод set"), вместо которого называют того, чтобы обновить данные, обновляется.

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

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

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

После этих слов для большинства небольших программ, которые являются одним использованием, без расширений, как те, Вы достигаете университет, это - больше "хорошей практики", чем что-нибудь, потому что Вы будете помнить в течение записи их, и затем Вы вручите их и никогда не касаться кода снова. Кроме того, если Вы пишете структуру данных как способ узнать о том, как они хранят данные, а не как код выпуска, тогда существует хороший аргумент, что Методы get и Методы set не помогут и помешают полезному опыту.

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

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

Я склонен следовать правилу довольно строго, даже когда это - просто мой собственный код. Мне действительно нравятся Свойства в C# по этой причине. Это делает действительно легким управлять тем, что оценивает, это дано, но можно все еще использовать их в качестве переменных. Или сделайте набор частным и получить общественность, и т.д.

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

С уважением, Ollie

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

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

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

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