Сила дизайна OO в семантике или инкапсуляции?
Файл / формат .fig не поддерживается для включения в (La) TeX в качестве изображения. Вам необходимо экспортировать изображение в поддерживаемый формат через диалог File> Export. Поддерживаемые форматы включают в себя Postscript, EPS в виде PDF-файлов как отдельные векторные форматы, комбинированные файлы (vector + LaTeX для текста) и многие растровые форматы (такие как BMP, PNG и JPEG).
Также используйте \centering для центрирования изображения в среде figure.
11 ответов
Вы, кажется, используете довольно узкое определение, ”Encapsulation. ” я был бы прав в предположении, что Вы определяете инкапсуляцию, чтобы быть, данные “Combining с методами? ”
, Если I’m неправильно тогда проигнорируйте остальную часть этого сообщения.
Инкапсуляция не является широким термином; на самом деле, it’s определенный Международной организацией по стандартизации. Эталонная модель ISO’s Открытой распределенной обработки - определяет следующие пять понятий:
Объект: Любая конкретная или абстрактная вещь интереса.
Объект: модель объекта. Объект характеризуется его поведением и, двойственно, по его состоянию.
Поведение (объекта): набор действий с рядом ограничений на то, когда они могут произойти.
Интерфейс: абстракция поведения объекта, который состоит из подмножества взаимодействий того объекта вместе с рядом ограничений на то, когда они могут произойти.
Инкапсуляция: свойство, что информация, содержавшаяся в объекте, доступна только через взаимодействия в интерфейсах, поддерживаемых объектом.
Мы можем далее внести самоочевидное предложение: поскольку некоторая информация доступна через эти интерфейсы, некоторая информация должна быть скрыта и недоступна в объекте. Свойство, которое показывает такая информация, называют сокрытием информации, которое Parnas, определенный путем утверждения, что модули должны быть разработаны для сокрытия и трудных решений и решений, которые, вероятно, изменятся, см. одну из замечательных вычислительных бумаг:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
It’s важный, чтобы отметить, что это не только данные, которые информационно-скрыты: это - некоторое подмножество поведения, связанного с объектом, который является трудным или вероятным измениться.
В Вашем сообщении, Вы, кажется, говорите, что различие между инкапсуляцией в OO и в основах функционального программирования от управления данными, но по крайней мере согласно ISO и Parnas, управление данными не является ключом к инкапсуляции. Так я don’t видят, почему инкапсуляция в функциональном программировании должна несколько отличаться от этого в OO.
Вы упоминаете, кроме того, в Вашем сообщении, что функциональное программирование обеспечивает инкапсуляцию, Ҡ¦ методами, а не структурами данных. ” Это, я думаю, является различием масштаба, а не абсолюта. Если я использую слово, “Object, ”, а не, структура “Data, ” (снова, сообщите мне, если неверное истолкование I’m), то Вы, кажется, находите значение в инкапсуляции OO’s объектом и функциональной programming’s инкапсуляции методом.
все же по определению ISO выше, объект - что-либо, что я хочу смоделировать. Таким образом классы могут инкапсулироваться в пакете, пока некоторые из тех классов способствуют интерфейсу package’s (т.е. общедоступные классы пакета), и некоторые информационно-скрыты (частные классы в пакете).
К тому же, методы инкапсулируются в классе †“немного метода быть общедоступным и некоторые частные. Можно даже взять это, метка понижает и говорит, что McCabian последовательные последовательности кода инкапсулируется в рамках методов. Каждый формирует график узлов, инкапсулировавших в инкапсулированных регионах; и все эти графики формируют стопку графика. Таким образом функциональное программирование может хорошо инкапсулировавший на уровне функции/файла, но это не отличается от графика метода/класса OO и по существу никакого различия от графика класса/пакета OO также.
кроме того, обратите внимание, что слово Parnas использует выше: изменение. Сокрытие информации касается потенциальных событий, таких как изменение трудных проектных решений в будущем. Вы спрашиваете, где OO’s strength’s лежат; хорошо, инкапсуляция является, конечно, силой OO, но вопрос тогда становится, “Where encapsulation’s сила лежит? ” и ответ являются одной из звучной ясности: управление изменениями. Особенно, инкапсуляция уменьшает максимальную потенциальную нагрузку изменения.
понятие, связь “Potential, ” полезна здесь.
“Coupling, ” сам определяется как, мера “A силы ассоциации, созданной соединением от одного модуля до другого, ” в другой из computing’s больших газет:
в http://www.research.ibm.com/journal/sj/382/stevens.pdf
И как бумага говорится в словах никогда, так как улучшено, соединения “Minimizing между модулями также минимизирует пути, вдоль которых изменения и ошибки распространяют в другие части системы, таким образом устраняя имеющий катастрофические последствия, “Ripple, ” эффекты, где изменения в одной части вызывают ошибки в другом, требуя дополнительных изменений в другом месте, давая начало новым ошибкам, и т.д. ”
, Как определено здесь, однако, существуют два ограничения, которые могут легко быть сняты. Во-первых, связь не измеряет соединения внутримодуля, и эти соединения внутримодуля могут дать начало столько же, “Ripple, ” эффекты сколько межмодульные соединения (бумага действительно определяет, “Cohesion, ” для связи элементов внутримодуля, но это не определяется с точки зрения соединений между элементами (т.е. ссылки на маркировки или адреса), с которым связь была определена). Во-вторых, связь любой компьютерной программы является данным, в котором модули соединены или; существует мало объема в рамках определения связи для управления потенциальными изменениями, о которых говорит Parnas.
Оба этих вопроса решены, до некоторой степени, с понятием потенциальной связи: максимальное возможное количество соединений, formable среди всех элементов программы. В Java, например, классу, который является частным на пакет (средство доступа по умолчанию) в пакете, нельзя было сформировать соединения на нем (т.е. никакие внешние классы не могут зависеть от него, отражение, несмотря на это), но общедоступный класс в пакете может иметь зависимости от него. Этот общедоступный класс способствовал бы связи потенциала, даже если никакие другие классы не зависят от него в данный момент †“классы, мог бы зависеть от него в будущем, когда конструктивные изменения.
Для наблюдения encapsulation’s силы рассмотрите Принцип Нагрузки. Принцип Нагрузки принимает две формы.
сильная форма указывает, что нагрузка преобразования набора объектов является функцией количества преобразованных объектов. Слабая форма указывает, что максимальная потенциальная нагрузка преобразования набора объектов является функцией максимального потенциального количества преобразованных объектов.
нагрузка создания или изменения любой программной системы является функцией количества классов, созданных или измененных (здесь, мы используем, “Classes, ” предположение системы OO, и обеспокоены инкапсуляцией на уровне класса/пакета; мы, возможно, одинаково интересовались уровнем функции/файла функционального программирования). (Обратите внимание, что, “Burden, ” является современной разработкой программного обеспечения, обычно стоится, или время или оба.) Классы, которые зависят от конкретного, измененного класса, имеют более высокую вероятность того, чтобы быть повлиявшимся, чем классы, которые не зависят от измененного класса.
максимальная потенциальная нагрузка, которую может наложить измененный класс, является влиянием всех классов, которые зависят от него.
Сокращение зависимостей от измененного класса поэтому уменьшает вероятность, что ее обновление повлияет на другие классы и так уменьшает максимальную потенциальную нагрузку, которую может наложить тот класс. (Это немного больше, чем повторное заявление, дизайн “Structured, ” бумага.)
Сокращение максимального потенциального количества зависимостей между всеми классами в системе поэтому уменьшает вероятность, что влияние на конкретный класс вызовет обновления других классов и таким образом уменьшает максимальную потенциальную нагрузку всех обновлений.
Инкапсуляция, путем сокращения максимального потенциального количества зависимостей между всеми классами, поэтому смягчает слабую форму Принципа Нагрузки. Это все покрыто, теория “Encapsulation, ”, который пытается математически доказать такие утверждения, с помощью потенциала, связывающегося как логические средства структурирования программы.
Примечание, однако, это, когда Вы спрашиваете, инкапсуляция “Is ключ ко всему стоящему коду? ” ответ должен, конечно, быть: нет. Нет никакого единственного ключа ко всему стоящему коду. Инкапсуляция, при определенных обстоятельствах, просто инструмент, чтобы помочь улучшить качество кода так, чтобы это могло стать, “Worthwhile. ”
Вы также пишете, что, “ †¦ инкапсуляция может быть барьером для гибкого расширения объекта. ” Да это несомненно может: это действительно разработано, чтобы быть барьером против расширения проектных решений объекта, которые являются трудными или вероятными измениться. Это, как, однако, думают, не плохая вещь. Альтернативный подход должен был бы иметь всю общественность классов и иметь программу, выражают ее максимальную потенциальную связь; но тогда слабая форма Принципа Нагрузки указывает, что обновления станут все больше дорогостоящими; это затраты, против которых должны измеряться барьеры для расширения.
Наконец, Вы делаете интересное сравнение между инкапсуляцией и семантикой, и что по Вашему мнению семантика OO’s является своей большей силой. I’m никакой semanticist, любой (я didn’t даже знают такое слово, существовал перед хорошим господином Ramsey, не сослался на него в его комментарии), но я предполагаю, что Вы имеете в виду, “Semantics, ” в смысле, “the значение или интерпретация значения, слова, ” и очень в основном, что класс с a, лай () метод нужно назвать Собакой.
существует большая сила действительно в этой семантике.
то, Чему любопытно мне, - то, что Вы настраиваете семантику против инкапсуляции и ищете победителя; я сомневаюсь, что you’ll находят тот.
, По-моему, существует две силы, которые мотивируют инкапсуляцию: семантическое и логическое.
Семантическая инкапсуляция просто означает инкапсуляцию на основе значения узлов (для использования общего термина) инкапсулировавший. Таким образом, если я говорю Вам, что имею два пакета, один названный, 'животное' и один названный 'минерал', и затем даю Вам три класса Собака, CAT и Коза и спрашиваю, в который упаковывает эти классы, должен инкапсулироваться, тогда, не даваться никакую другую информацию, Вы были бы совершенно правы утверждать, что семантика системы предложит, чтобы эти три класса инкапсулировались в, 'животное', пакет, а не, 'минерал'.
другая мотивация для инкапсуляции, однако, является логикой и особенно исследованием потенциальной связи, упомянутой выше. Теория инкапсуляции на самом деле обеспечивает уравнения для количества пакетов, которые должны использоваться, чтобы инкапсулировать много классов, чтобы минимизирует потенциальную связь.
Для меня, инкапсуляция в целом была компромиссом между этим семантическим и логическим подходом: I’ll позволяет потенциальной связи моих программ повышаться выше минимума, если это делает программу семантически легче понимать; но огромные и расточительные уровни потенциальной связи предупреждением, что моя программа реструктурируемая, неважно, как семантически очевидный это.
(И если хороший господин Ramsey все еще читающий, мог, Вы или Ваши semanticist друзья дает мне лучшее слово для, “Semantics, ” фаза I’m, использующий здесь? Хорошее использовать более соответствующий термин.)
С уважением, Ed.
Инкапсуляция и получающаяся абстракция являются ясно основными преимуществами OO. Предикат "вещей", какие "действия" могут быть вызваны на них, таким образом, существительные имеют более высокое семантическое значение, чем глаголы.
В конечном счете, трудно предположить разработку сложной системы в последовательной и удобной в сопровождении форме без некоторого уровня инкапсуляции.
Как программист Lisp, объектная система которого возможно не обеспечивает ни один из них, я говорю: ни одно из вышеупомянутого.
jwz: "pseudo-Smalltalk объектная модель проигрывает и что родовые функции (соответственно ограниченный правилом no-external-overrides) побеждают".
я думаю желательные атрибуты, которые Вы и другие перечисляете здесь (инкапсуляция, модульный принцип, и т.д.) не так свойственны от OO, как Вы думаете. Им часто предоставляют вместе со стилем Java OO, но не просто последствие его.
Сложность Изоляции является IMO главная цель любого дизайна: инкапсуляция функциональности позади интерфейса, который является более прост использовать , чем сама функциональность.
OO обеспечивает различные механизмы для того - два, которые Вы упоминаете:
Инкапсуляция позволяет разрабатывать пользовательскую поверхность, которая независима от фактической реализации. (для перефразирования, "Более простой означает отличающийся").
Семантика позволяет моделировать объекты, которые представляют элементы проблемной области, таким образом, их легче понять.
<час>Любой проект, достигающий определенного размера, становится упражнением в руководящей сложности. Я держал бы пари на заявление, что за эти годы, программирование скользило вдоль пределов сложности we#ve, учился справляться.
я не баловался функциональным программированием в течение многих лет, но в моем понимании оно может лучше всего быть описано значением математиком мощных слов, elgant, красивая AMD. "Красивый" и "изящный", в этом контексте, попытка описать блестящее понимание истинного или соответствующей структуры сложной системы, смотря на него с точки зрения, где это удивительно просто. это принимает сложность как данный и пытается переместиться по нему.
гибкость, которую Вы упоминаете, находится в моем понимании способности изменить POV согласно Вашим потребностям - но это работает вопреки инкапсуляции: то, что является бессмысленной деталью от одного положения, может быть единственным соответствующим в другом.
OO, OTOH, является редукционистами, приблизьтесь: мы изменяем POV путем движения в более высокий уровень. В "старом OO", существует единственная иерархия POVs, интерфейсы - в этой модели - способ смоделировать другой POVs.
, Если я могу сказать так, сила OO лучше подходящий "для нормальных людей".
Некоторая форма модульный принцип является ключом к любому масштабируемому дизайну. Ограничения людей предотвращают людей от "понимания" слишком много информации сразу, таким образом, мы должны подразделить проблемы на управляемые, связные блоки, оба для обеспечения основания для понимание крупный проект, а также путь к подразделяет присвоения работы из крупного проекта среди многих людей.
, Как выбрать самое эффективное "подразделение" / "разделение" крупного проекта удовлетворить целям выше? Опыт показал, что OO является крупным победителем здесь, и я думаю, что многие люди согласились бы, что два ключевых атрибута OO, которые делают это хорошим в этом:
- Инкапсулировавший : каждый класс инкапсулирует "секрет" - ряд определенного для реализации assumptions-that-are-likely-to-have-to-change-over-time о его реализации - и представляет интерфейс, который является агностиком к этим предположениям; разделение на уровни таких инкапсулированных абстракций позволяет спроектировать устойчивый дизайн, где компоненты/реализации могут легко быть подкачаны перед лицом ожидаемых изменений.
- центральный Существительным : в большинстве доменов люди кажутся лучше в первом разложении модели предметной области путем размышления о существительных/данных домена, сопровождаемого путем идентификации поддерживающих глаголов, которые связаны с каждым существительным.
Относительно функционального программирования (FP) по сравнению с OO, я имею , вел блог об этом, но кратко я думаю, что FP больше о методах реализации, тогда как OO больше о структуре программы и дизайне, и таким образом эти два дополнительны, при этом OO более доминирующее на 'большом' конце масштаба и FP, являющегося более доминирующим на 'маленьком' конце. Таким образом, на крупном проекте высокоуровневая структура лучше всего описана дизайном класса OO, но многие детали уровня модуля (реализации и детали форм интерфейсов модулей) лучше всего формируются влияниями FP.
Сила объектно-ориентированного дизайна пропорциональна тому, сколько позднего связывания происходит в дизайне. Это - понятие Kay OO, не понятие Nygaard. Alan Kay записал:
ООП мне означает только обмениваться сообщениями, локальное хранение и защита и скрываться процесса состояния и экстремального позднего связывания всех вещей. Это может быть сделано в Smalltalk и в LISP. Существуют возможно другие системы, в которых это возможно, но я не знаю о них.
Большая часть литературы игнорирует позднее связывание в пользу идеи C++ объектной ориентации.
Инкапсуляция в сочетании с Полиморфизмом. Способность классов на большинстве языков ООП для реализации одного или нескольких интерфейсов оказала самое большое влияние на разработку моего программного обеспечения. Эта функция позволяет мне точно определять взаимодействие между двумя объектами.
Не только определяют взаимодействия, но и документируют его так, чтобы несколько лет спустя я мог возвратить тому разделу кода и видеть то, что происходит ясно.
Этой функцией является главная причина, почему я предпочитаю использовать языки ООП по функциональным языкам. В то время как очень мощный я нашел программное обеспечение записанным на функциональных языках, чтобы быть болью для поддержания, когда цикл техобслуживания измеряется в десятилетиях. (Программное обеспечение AutoLisp, найденное в AutoCAD)
Давайте предпримем шаги назад и посмотрим на это от более высокого уровня. Преимущества любой функции языка заключаются в способности кратко выразить проблему/решение более естественным способом относительно проблемной области.
Механика ООП легко реализована в плоскости C со структурами и указателями функции. Можно даже получить немного ощущения ООП, делающего его тот путь. Однако идиомы ООП совсем не как предстоящие в такой среде. Когда существует фактическая поддержка языка ООП затем, выразительность парадигмы выходит, и способ, которым язык реализовывает идею, оказывает очень реальное влияние на то, что "сказано" и как. Например, посмотрите различия в коде с помощью закрытий/лямбд в шепелявости, Python, рубине, и т.д.
Таким образом в конце это не о компонентах и базовых понятиях, а скорее как они соединены и использовали, которые делают OO в C++, каково это.
По моему скромному мнению, OO просто означает объекты, взаимодействующие с другими объектами. Инкапсуляция просто означает абстрагировать понятие. Так, Вы создаете Сокет и.Connect () к чему-то. Как это соединяется, Вы действительно не заботитесь (который является в основном моим определением инкапсуляции).
И, чистое функциональное программирование может использовать объект связаться.. но те объекты должны быть неизменными. Так, снова по моему скромному мнению, FP может легко использовать понятие OO; Императивный язык, такой как C может все еще использовать понятие OO.. например, файл для каждого "Класса" с частным разделом, который не должен использоваться.
Ваши чтения вопроса как Вы хотят получить преимущества дома путем анализа кирпича.
Наличие способности обеспечить семантический контекст и инкапсуляцию является просто основными возможностями класса в OO. (Как кирпич может противостоять определенной силе и требовать определенного пространства.)
Продолжать аналогию: Для вытаскивания максимума из кирпичей просто соедините их. Тот же самый применяется к классам и объектам.
Существует много шаблонов разработки, которые могут использоваться для программирования OO. Большинство из них полагается на способности "инкапсуляция" и "семантический", который Вы упомянули.
Некоторые из тех шаблонов являются даже ответом на третий абзац Вашего вопроса:
- Если Вы хотите расширить поведение существующего класса, можно создать производный класс.
- Если Вы хотите расширить или изменить поведение существующего объекта, Вы могли бы рассмотреть шаблон "декоратор".
Настоящая сила объектно-ориентированного программирования заключается в полиморфизме, а чем инкапсуляция. Инкапсуляция в определенной степени достижима и используется в функциональных языках, но полиморфизм был бы очень неудобным, если бы реализован на функциональном языке.
(Прочтите «шаблон проектирования» от банды из четырех , чтобы понять мощь объектно-ориентированного программирования.)
@Phil, Если я правильно вас понял, разница, которую вы упомянули, заключается в том, как программа вызывает данные / метод: в oo сначала есть объект / экземпляр, а затем данные / метод объекта вызываются через объект; в функционале метод вызывается напрямую.
Однако, глядя на реализацию функциональной программы, мы видим, что данные и метод заключены в оболочку (в файле, но не в классе). Например, программа на C имеет файл заголовка, в котором объявляются функции, доступные из другого файла, и данные являются личными данными, если они доступны только через эти объявленные функции. Пока программист достаточно внимателен, большая часть инкапсуляции в объектно-ориентированном пространстве может быть реализована в функциональных программах. (Даже наследование возможно при использовании определенных уловок с указателями.)