2015-08-02 7 views
0

Перебрав SO вопросов, я узнал, что,Помогает ли «инкапсуляция» создавать несколько модулей параллельно?

Инкапсуляция о защите инварианты и скрытии реализации деталей.

абстракция имеет отношение к разделительным интерфейс от реализации.

Из класса номера Java training, я узнал, что, Инкапсуляция имеет следующие преимущества,

Почему инкапсуляция ваш друг?

[1] Реализация не зависит от функциональности. Программист , имеющий документацию интерфейса, может самостоятельно реализовать новую версию модуля или ADT. Новая, лучшая реализация может заменить .

[2] Инкапсуляция не позволяет Doug писать приложения, которые повреждают внутренние данные модуля . В реальном программировании инкапсуляция сокращает время отладки. Много.

[3] ADT могут гарантировать сохранение их инвариантов.

[4] Командная работа. Как только вы строго определите интерфейсы между модулями, , каждый программист может независимо реализовать модуль, не имея доступа к другим модулям. Большой, сложный проект программирования может быть разбит на десятки штук.

[5] Документация и ремонтопригодность. Определив недвусмысленный интерфейс , вы упростите другим программистам исправить ошибки, которые возникают спустя годы после того, как вы покинули компанию. Многие ошибки являются результатом непредвиденных взаимодействий между модулями. Если есть ясная спецификация каждого интерфейса и поведение каждого модуля, ошибки проще отслеживать.

[6] Когда ваш проект не работает, будет проще выяснить, кто из виноват.

Вопрос 1:

Wrt Point1 (выше) говорит, "новый, лучше реализация может заменить старую.". Это абстракция, но не инкапсуляция. Я прав?

Вопрос 2:

Wrt Пункт 4 (выше), как Инкапсуляция помощь программисту самостоятельно реализовать модуль, не имея доступа к другим модулям?Как параллельная реализация модулей имеет какое-либо отношение к Инкапсуляция? Потому что инкапсуляция касается защиты в вариантах. Это answer также поддерживает мои аргументы

+1

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

+0

@PeterLawrey Но ваша точка имеет какое-то отношение к * Абстракции *, но не к * Инкапсуляции *. Потому что * Абстракция * связана с отделением интерфейса ('java.util.List' или' java.util.AbstractList') от реализации ('java.util.ArrayList'). – overexchange

+1

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

ответ

0

(1) Интерфейс должен толковаться широко; потому что он имеет некоторые конкретные технические значения, я предпочитаю термин договор (от "design by contract") означает одно и то же. Это формальная спецификация того, как взаимодействовать с определенным модулем (или видом модуля). Отличным примером является API коллекций; a List чаще всего является ArrayList, но это может быть LinkedList, ImmutableList, или что-то более экзотическое, как прокси-сервер с ленивой загрузкой. Я почти никогда не забочусь о своем коде, который имеет конкретный тип; Я просто взаимодействую с интерфейсом List.

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

В гораздо большем масштабе я использую Spring MVC для обработки веб-уровня моих приложений. Spring MVC взаимодействует с API-интерфейсом Servlet для взаимодействия с контейнером сервлетов, который по существу является самим веб-сервером. Команда Spring не должна знать ничего о сервере; несколько разных контейнеров сервлетов (Tomcat, Jetty, Undertow, WebLogic) были написаны разными командами, но поскольку каждый использует общий интерфейс, им не нужно выполнять дальнейшую координацию своих усилий в области развития.

+0

поддельная почтовая служба с использованием java-заглушек? – overexchange

+0

@overexchange Действие подделано (или «издевается»); это не поддельная почтовая служба, так как нет службы. См. [Инъекция зависимостей] (https://github.com/castleproject/Windsor/blob/master/docs/services-and-components.md) для «практического» результата Encapsulation - инкапсуляция позволяет разделять компоненты и службы , – user2864740

+0

Интерфейс 'MailService' имеет метод' send'. Служба * real * отправляет почту. Служба * fake * просто записывает сообщение журнала, в котором говорится: «Я отправил бы это сообщение этому человеку здесь». В более крупном проекте я мог бы работать над своей частью приложения, которое должно отправлять почту, в то время как кто-то еще действительно работал с передающей частью. – chrylis

0

Чтобы ответить на этот вопрос, мы должны уточнить, что мы подразумеваем под «абстракцией» и «инкапсулированием».

Википедия defines абстракции следующим образом:

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

и for mathematics:

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

и computer science:

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

Таким образом, абстракция - это процесс обобщения, а абстракции - это результаты этого процесса.

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

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

Абстракция поэтому тесно связана с концепцией сокрытия информации, что Википедия defines следующим образом:

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

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

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

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

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

Т.е. инкапсуляция - это скрытая информация (мы скрываем поля или методы).


С этой теорией в виду, по вашим вопросам:

WRT Point1 (выше) говорит, "Новый, лучше реализация может заменить старое.". Это цель абстракции, но не инкапсуляция. Я прав?

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

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

То есть в статье, которую вы цитируете, подразумевается, что инкапсуляция использовалась правильно.

Как программа поддержки инкапсуляции может независимо реализовать модуль без доступа к другим модулям? Как эта параллельная реализация модулей имеет какое-либо отношение к инкапсуляции? Потому что инкапсуляция - это защита в-вариантах.

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