Действительно ли функция является примером инкапсуляции?

Я буду первым для несогласия с тем, что, кажется, тенденция ответа. Да, функция инкапсулирует некоторый объем реализации. Вам не нужен объект (который я думаю, что Вы используете для значения класса).

Посмотрите Meyers также.

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

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

Возвращение к автомобильному примеру: Автоматическая коробка передач предлагает хорошую инкапсуляцию: Как драйвер Вы заботитесь о вперед/назад и скорость. Механическая коробка передач является плохой инкапсуляцией: С точки зрения драйвера определенный механизм, требуемый для низких / высоких скоростей, обычно не важен намерению драйвера.

Уверенный это.

Например, метод, который воздействует только на его параметры, считали бы "лучше инкапсулировавшим", чем метод, который воздействует на глобальные статические данные.

Инкапсуляция была вокруг задолго до ООП :)

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

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

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

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

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

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

Абстрактное понятие инкапсуляции означает сокрытие деталей реализации. Объектная ориентация является всего лишь одним примером использования инкапсуляции. Другим примером является язык, названный модулем 2, который использует (или используемый) модули реализации и модули определения. Модули определения скрыли фактическую реализацию и поэтому обеспечили инкапсуляцию.

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

[РЕДАКТИРОВАНИЕ] Что касается примера в обновленном вопросе: это зависит от того, как узкий или широкий Вы определяете инкапсуляцию. Ваш пример AddOne не скрывает ничего, чему я верю. Это было бы сокрытие информации / инкапсуляция, если бы Ваша переменная будет индексом массива, и Вы назвали бы свой метод moveNext и возможно имели бы другую функцию setValue и getValue. Это позволило бы людям (вместе, возможно, с некоторыми другими функциями) перемещаться по Вашей структуре и устанавливающим и добирающимся переменным с ними являющийся знающим о Вас использующий массив. Если Вы, язык программирования поддерживал бы другие или более богатые понятия, Вы могли бы изменить реализацию moveNext, setValue и getValue с изменением значения и интерфейса. Мне, который является инкапсуляцией.

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

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

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

Это - вещь уровня компонента

Проверьте это:

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

(Я не вполне понимаю Вашего вопроса, сообщаю мне, не касается ли та ссылка Ваших сомнений),

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

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

Эталонная модель Открытой распределенной обработки - записанный Международной организацией по стандартизации - определяет следующие понятия:

Объект: Любая конкретная или абстрактная вещь интереса.

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

Поведение (объекта): набор действий с рядом ограничений на то, когда они могут произойти.

Интерфейс: абстракция поведения объекта, который состоит из подмножества взаимодействий того объекта вместе с рядом ограничений на то, когда они могут произойти.

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

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

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

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

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

Функция имеет свойство, что информация, содержавшаяся в функции, доступна только через взаимодействия в интерфейсах, поддерживаемых объектом? Хм, ну, в общем, это может.

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

Для наблюдения этого мы должны сначала рассмотреть масштаб. Легко утверждать, что, например, классы Java могут инкапсулироваться в пакете: некоторые классы будут общедоступны (и следовательно будут интерфейсом пакета), и некоторые будут частными на пакет (и следовательно информационно-скрытый в пакете). В теории инкапсуляции классы формируют узлы и форму пакетов инкапсулировавшие регионы с полнотой, формирующей инкапсулированный график; график классов и пакетов называют третьим графиком.

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

Теперь мы приходим к функциям. Если функции должны быть средством инкапсуляции сами они, они должны содержать некоторую информационную общественность к другим функциям и некоторую информацию, это информационно-скрыто в функции. Какова эта информация могла быть?

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

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

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

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

То же верно для exampe, который Вы даете. Мы можем, конечно, полагать, что n = n + 1 единственный блок McCabian, поскольку это (и оператор возврата) является единственный, последовательный поток выполнения. Но функция, в которую Вы помещаете это таким образом, содержит только один блок, и тот блок является единственным общедоступным блоком функции, и поэтому в Вашей предложенной функции нет никаких информационно-скрытых блоков. Таким образом, это может удовлетворить определение инкапсуляции, но я сказал бы, что это не удовлетворяет дух.

Все это, конечно, является академическим, если Вы не можете доказать преимущество такая инкапсуляция.

Существует две силы, которые мотивируют инкапсуляцию: семантическое и логическое.

Семантическая инкапсуляция просто означает инкапсуляцию на основе значения узлов (для использования общего термина) инкапсулировавший. Таким образом, если я говорю Вам, что имею два пакета, один названный, 'животное' и один названный 'минерал', и затем даю Вам три класса Собака, CAT и Коза и спрашиваю, в который упаковывает эти классы, должен инкапсулироваться, затем, не даваться никакую другую информацию, Вы были бы совершенно правы утверждать, что семантика системы предложит, чтобы эти три класса инкапсулировались в, 'животное', пакет, а не, 'минерал'.

Другая мотивация для инкапсуляции, однако, является логикой.

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

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

Теория инкапсуляции предлагает, чтобы все инкапсулированные графики выразили максимальное потенциальное количество краев (MPE). В системе Java классов и пакетов, например, MPE является максимальным потенциальным количеством зависимостей от исходного кода, которые могут существовать между всеми классами той системы. Два класса в том же пакете не могут быть информационно-скрыты друг от друга и таким образом, оба могут потенциально сформировать depdencies друг на друге. Два частных на пакет класса в отдельных пакетах, однако, не могут сформировать зависимости друг от друга.

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

Данные n классы и требование p общедоступных классов на пакет, теория инкапсуляции показывает, что количество пакетов, r, нам придется минимизировать MPE, дан уравнением: r = sqrt (n/p).

Это также относится к количеству функций, которые Вы должны иметь, учитывая общее количество, n, блоков McCabian в Вашей системе. Функции всегда имеют всего один общедоступный блок, как мы упомянули выше, и таким образом, уравнение для количества функций, r, чтобы иметь в Вашей системе упрощает до: r = sqrt (n).

По общему признанию немногие рассмотрели общее количество блоков в их системе при осуществлении инкапсуляции, но это с готовностью сделано на уровне класса/пакета. И кроме того, уменьшение MPE почти совершенно интуитивно: это сделано путем уменьшения количества общедоступных классов, и пытаясь однородно распределить классы по пакетам (или по крайней мере избежать имеют большинство пакетов с, скажем, 30 классами и одного монстра pacakge с 500 классами, в этом случае внутренний MPE последнего может легко сокрушить MPE всего другие).

Инкапсуляция таким образом включает устанавливание равновесия между семантическим и логическим.

Все отличное развлечение.

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

для пуристов ОО, которые возмущаются этим богохульством, рассмотрим статический анонимный класс без состояния и с единственным методом; Если функция AddOne () не является инкапсуляцией, то и этот класс тоже не является!

и, просто чтобы быть педантичным, инкапсуляция - это форма абстракции, а не наоборот. ; -)

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