Я читаю «Параллелизм Java на практике», и там говорится: «К счастью, те же объектно-ориентированные методы, которые помогают вам писать хорошо организованные, поддерживаемые классы, такие как инкапсуляция и скрытие данных, могут также помочь вам создать поточно-ориентированный классы «.
Проблема № 1 - я никогда не слышал о сокрытии данных и не знаю, что это такое.
Проблема № 2 - я всегда думал, что инкапсуляция использует private против public и фактически скрывает данные.
Не могли бы вы объяснить, что такое сокрытие данных и чем оно отличается от инкапсуляции?
java
design
object-oriented
dhblah
источник
источник
Ответы:
Сокрытие данных и информации является более широким понятием в области компьютерных наук и разработки программного обеспечения. Это относится к тому факту, что те части компьютерной программы, которые могут измениться, не должны быть доступны из других модулей / от клиентов.
Инкапсуляция - это термин, который встречается в объектно-ориентированной парадигме и относится к хранению данных в закрытых полях и изменению их только с помощью методов.
Таким образом, инкапсуляция может рассматриваться как способ достижения сокрытия данных в объектно-ориентированных системах .
источник
Инкапсуляция и сокрытие данных являются связанными терминами. Важно понимать, что они возникают по отношению к абстракции . Booch et. и др. в объектно-ориентированном анализе и проектировании с приложениями объясняет,
источник
Создание класса включает в себя понятие инкапсуляции. Когда вы создаете класс, вы помещаете в него данные и поведения, и класс становится одной единицей, которую мы называем объектом. Таким образом, сокрытие данных является частью инкапсуляции.
источник
Из Википедии :
источник
Они часто используются взаимозаменяемо при обсуждении, и часто я думаю, что они работают вместе для достижения одной и той же цели, и хотя следующее может быть не совсем точным, оно может обеспечить некоторое значимое различие, если необходимо провести различие:
Когда речь идет об инкапсуляции, часто она реализуется как процедурный / функциональный механизм. Для базового состояния существует некоторый тип защиты, и для доступа через защиту требуется соблюдение определенных протоколов (чтение или изменение требуемого состояния). Инкапсуляция также дает возможность возникновения побочных эффектов из-за доступа (например, каскадного изменения состояния или уведомления / инициирования события / выдачи сигнала, когда объект, представляющий интерес, читается или изменяется), так что можно инициировать последующие действия. Опять же, я часто думаю о инкапсуляции как о концепции, которая реализуется как процедура.
Я вижу, что концепция сокрытия данных похожа на инкапсуляцию; однако механизм является структурным и работает на другом уровне. На практике, вместо обеспечения механизма защиты и побочных эффектов посредством процедуры, состояние защищается и подвергается воздействию через структурные механизмы языка и среды выполнения. Этими типами охранников могут быть предложения видимости, определения типов, наследование и тому подобное. Побочные эффекты, которые вы можете использовать от структурно охраняемых объектов, опять-таки зависят от языка и времени выполнения: возможно, активация объекта, подсчет ссылок или что-то в этом роде.
источник
Они часто, может быть, обычно используются взаимозаменяемо. Но обратите внимание на приведенную выше цитату Буча: «Инкапсуляция чаще всего достигается путем сокрытия информации ...», то есть чаще всего, но не всегда в каждом случае.
Обратите внимание, что Python позволяет сворачивать данные в классах, но не позволяет использовать закрытые переменные. Таким образом, можно сказать, что Python обеспечивает инкапсуляцию без скрытия данных.
Вы можете сделать то же самое в Java, создав все переменные-члены
public, но помимо сердечного приступа, вы потеряете преимущество сокрытия данных ... то есть сохранения семантики объекта путем ограничения доступа к его состоянию.источник
В ОО инкапсуляция - это место, где информация хранится внутри объекта. Например, a
Personимеет anameи клиенты Person (то есть вы) знают, что Person хранит имя, либо через открытые поля, либо с помощью методов доступа. И, надеюсь, вам не нужно также хранить имена в каком-то глобальном массиве имен и т. Д. Так что это большой шаг, чтобы избежать неуправляемого кода спагетти. Но клиент все еще должен знать кое-что о том, как Person обрабатывает имена: например, пробел или запятая?Скрытие данных , где
Personесть поле имени, но, по крайней мере в теории, никто не знает . Поле является приватным без общедоступных методов доступа. Клиенты могут передавать имя из записи базы данных, XML, HTTP POST, что угодно, но внутренняя работа того, как Person обрабатывает имя, является «черным ящиком». Будущие реализации Person могут свободно менять, например, переключаться на наличие afirstNameи alastName.В идеальном мире скрытие данных превосходит инкапсуляцию, но не все миры идеальны. :-)
источник