Объектно-ориентированный подход. Объектно_ориентированный_подход. Объектно ориентированный подход Мэтт Вайсфельд 5е международное издание ббк 32. 973. 2018
 Скачать 5.43 Mb.
|
|
20 Подход, примененный в этой книге К настоящему времени должна быть очевидна моя твердая убежденность в том, что сначала нужно хорошо освоить объектно-ориентированное мышление, а за- тем уже приступать к изучению языка программирования или моделирования. Эта книга наполнена примерами кода и UML-диаграмм, однако необязательно владеть определенным языком программирования или UML для того, чтобы переходить к ее чтению. Но после всего того, что я сказал об изучении в первую очередь объектно-ориентированных концепций, почему же в этой книге так много кода и диаграмм класса? Во-первых, они отлично иллюстрируют объектно-ориентированные концепции. Во-вторых, они жизненно важны для освоения объектно-ориентированного мышления и должны рассматриваться на вводном уровне. Основной принцип заключается не в том, чтобы сосредотачиваться на Java, C# и т. д., а в использо- вании их в качестве средств, которые помогают понять основополагающие концепции. Обратите внимание на то, что мне очень нравится применять UML-диаграммы классов как визуальные средства, помогающие понять классы, их атрибуты и методы. Фактически диаграммы классов — это единственный компонент UML, использованный в этой книге. Я считаю, что UML-диаграммы классов отлично подходят для представления концептуальной природы объектных моделей. Я продолжу использовать объектные модели в качестве образовательного ин- струмента для наглядной демонстрации конструкции классов и того, как клас- сы соотносятся друг с другом. Примеры кода в этой книге иллюстрируют концепции вроде циклов и функций. Однако понимание этого кода как такового не является необходимым условием для понимания самих концепций; возможно, целесообразно иметь под рукой книгу, в которой рассматривается синтаксис соответствующего языка, если вы захотите узнать дополнительные подробности. Я не могу строго утверждать, что эта книга не учит языку Java, C# .NET, VB .NET, Objective-C, Swift или UML, каждому из которых можно было бы посвятить целые тома. Я надеюсь, что она пробудит в вас интерес к другим объектно-ориентированным темам вроде объектно-ориентированного анали- за, объектно-ориентированного проектирования и объектно-ориентированно- го программирования. Глава 1 ВВЕДЕНИЕ В ОБЪЕКТНО- ОРИЕНТИРОВАННЫЕ КОНЦЕПЦИИ Хотя многие программисты не осознают этого, объектно-ориентированная раз- работка программного обеспечения существует с начала 1960-х годов. Только во второй половине 1990-х годов объектно-ориентированная парадигма начала набирать обороты, несмотря на тот факт, что популярные объектно-ориентиро- ванные языки программирования вроде Smalltalk и C++ уже широко использо- вались. Расцвет объектно-ориентированных технологий совпал с началом использова- ния сети интернет в качестве платформы для бизнеса и развлечений. А после того как стало очевидным, что Сеть активно проникает в жизнь людей, объект- но-ориентированные технологии уже заняли удобную позицию для того, чтобы помочь в разработке новых веб-технологий. Важно подчеркнуть, что название этой главы звучит как «Введение в объектно- ориентированные концепции». В качестве ключевого здесь использовано слово «концепции», а не «технологии». Технологии в индустрии программного обе- спечения очень быстро изменяются, в то время как концепции эволюциониру- ют. Я использовал термин «эволюционируют», потому что хотя концепции остаются относительно устойчивыми, они все же претерпевают изменения. Это очень интересная особенность, заметная при тщательном изучении концепций. Несмотря на их устойчивость, они постоянно подвергаются повторным интер- претациям, а это предполагает весьма любопытные дискуссии. Эту эволюцию можно легко проследить за последние два десятка лет, если по- наблюдать за прогрессом различных индустриальных технологий, начиная с первых примитивных браузеров второй половины 1990-х годов и заканчивая мобильными/телефонными/веб-приложениями, доминирующими сегодня. Как и всегда, новые разработки окажутся не за горами, когда мы будем исследовать гибридные приложения и пр. На всем протяжении путешествия объектно-ори- ентированные концепции присутствовали на каждом этапе. Вот почему вопро- сы, рассматриваемые в этой главе, так важны. Эти концепции сегодня так же актуальны, как и 25 лет назад. Глава.1..Введение.в.объектно-ориентированные.концепции 22 Фундаментальные концепции Основная задача этой книги — заставить вас задуматься о том, как концепции используются при проектировании объектно-ориентированных систем. Исто- рически сложилось так, что объектно-ориентированные языки определяются следующими концепциями: инкапсуляцией, наследованием и полиморфизмом (справедливо для того, что я называю классическим объектно-ориентированным программированием). Поэтому если тот или иной язык программирования не реализует все эти концепции, то он, как правило, не считается объектно-ориен- тированным. Наряду с этими тремя терминами я всегда включаю в общую массу композицию; таким образом, мой список объектно-ориентированных концепций выглядит так: инкапсуляция; наследование; полиморфизм; композиция. Мы подробно рассмотрим все эти концепции в книге. Одна из трудностей, с которыми мне пришлось столкнуться еще с самого перво- го издания книги, заключается в том, как эти концепции соотносятся непосред- ственно с текущими методиками проектирования, ведь они постоянно изменя- ются. Например, все время ведутся дебаты об использовании наследования при объектно-ориентированном проектировании. Нарушает ли наследование ин- капсуляцию на самом деле? (Эта тема будет рассмотрена в следующих главах.) Даже сейчас многие разработчики стараются избегать наследования, насколько это представляется возможным. Вот и встает вопрос: «А стоит ли вообще при- менять наследование?». Мой подход, как и всегда, состоит в том, чтобы придерживаться концепций. Независимо от того, будете вы использовать наследование или нет, вам как минимум потребуется понять, что такое наследование, благодаря чему вы смо- жете сделать обоснованный выбор методики проектирования. Важно помнить, что с наследованием придется иметь дело с огромной вероятностью при сопро- вождении кода, поэтому изучить его нужно в любом случае. Как уже отмечалось во введении к этой книге, ее целевой аудиторией являются люди, которым требуется общее введение в фундаментальные объектно-ориен- тированные концепции. Исходя из этой формулировки, в текущей главе я пред- ставляю фундаментальные объектно-ориентированные концепции с надеждой обеспечить моим читателям твердую основу для принятия важных решений относительно проектирования. Рассматриваемые здесь концепции затрагивают большинство, если не все темы, охватываемые в последующих главах, в которых соответствующие вопросы исследуются намного подробнее. 23 Объекты.и.унаследованные.системы. . Объекты и унаследованные системы По мере того как объектно-ориентированное программирование получало ши- рокое распространение, одной из проблем, с которыми сталкивались разработ- чики, становилась интеграция объектно-ориентированных технологий с существующими системами. В то время разграничивались объектно-ориенти- рованное и структурное (или процедурное) программирование, которое было доминирующей парадигмой разработки на тот момент. Мне всегда это казалось странным, поскольку, на мой взгляд, объектно-ориентированное и структурное программирование не конкурируют друг с другом. Они являются взаимодопол- няющими, так как объекты хорошо интегрируются со структурированным кодом. Даже сейчас я часто слышу такой вопрос: «Вы занимаетесь структурным или объектно-ориентированным программированием?» Недолго думая, я бы отве- тил: «И тем и другим». В том же духе объектно-ориентированный код не призван заменить структури- рованный код. Многие не являющиеся объектно-ориентированными унаследо- ванные системы (то есть более старые по сравнению с уже используемыми) довольно хорошо справляются со своей задачей. Зачем же тогда идти на риск столкнуться с возможными проблемами, изменяя или заменяя эти унаследо- ванные системы? В большинстве случаев не стоит этого делать лишь ради внесения изменений. В сущности, в системах, основанных не на объектно-ори- ентированном коде, нет ничего плохого. Однако совершенно новые разработки, несомненно, подталкивают задуматься об использовании объектно-ориентиро- ванных технологий (в некоторых случаях нет иного выхода, кроме как поступить именно так). Хотя на протяжении последних 25 лет наблюдалось постоянное и значительное увеличение количества объектно-ориентированных разработок, зависимость мирового сообщества от сетей вроде интернета и мобильных инфраструктур способствовала еще более широкому их распространению. Буквально взрывной рост количества транзакций, осуществляемых в браузерах и мобильных прило- жениях, открыл совершенно новые рынки, где значительная часть разработок программного обеспечения была новой и главным образом не обремененной за- ботами, связанными с унаследованными системами. Но даже если вы все же столкнетесь с такими заботами, то на этот случай есть тенденция, согласно кото- рой унаследованные системы можно заключать в объектные обертки. ОБЪЕКТНЫЕ ОБЕРТКИ ________________________________________________________________ Объектные.обертки.представляют.собой.объектно-ориентированный.код,.в.который. заключается.другой.код..Например,.вы.можете.взять.структурированный.код.(вроде. циклов.и.условий).и.заключить.его.в.объект,.чтобы.этот.код.выглядел.как.объект..Вы. также.можете.использовать.объектные.обертки.для.заключения.в.них.функциональ- ности,.например.параметров,.касающихся.безопасности,.или.непереносимого.кода,. связанного.с.аппаратным.обеспечением,.и.т..д..Обертывание.структурированного.кода. детально.рассматривается.в.главе.6.«Проектирование.с.использованием.объектов». Глава.1..Введение.в.объектно-ориентированные.концепции 24 Одной из наиболее интересных областей разработки программного обеспечения является интеграция унаследованного кода с мобильными и веб-системами. Во многих случаях мобильное клиентское веб-приложение в конечном счете «под- ключается» к данным, располагающимся на мейнфрейме. Разработчики, одно- временно обладающие навыками в веб-разработке как для мейнфреймов, так и для мобильных устройств, весьма востребованы. Вы сталкиваетесь с объектами в своей повседневной жизни, вероятно, даже не осознавая этого. Вы можете столкнуться с ними, когда едете в своем автомоби- ле, разговариваете по сотовому телефону, используете свою домашнюю раз- влекательную систему, играете в компьютерные игры, а также во многих других ситуациях. Электронные соединения, по сути, превратились в соединения, ос- нованные на объектах. Ориентируясь на мобильные веб-приложения, бизнес тяготеет к объектам, поскольку технологии, используемые для электронной торговли, по своей природе в основном являются объектно-ориентированными. МОБИЛЬНАЯ ВЕБ-РАЗРАБОТКА ______________________________________________________ Несомненно,.появление.интернета.значительно.способствовало.переходу.на.объек- тно-ориентированные.технологии..Дело.в.том,.что.объекты.хорошо.подходят.для. использования.в.сетях..Хотя.интернет.был.в.авангарде.этой.смены.парадигмы,.мо- бильные.сети.теперь.заняли.не.последнее.место.в.общей.массе..В.этой.книге.термин. «мобильная.веб-разработка».будет.использоваться.в.контексте.концепций,.которые. относятся.как.к.разработке.мобильных.веб-приложений,.так.и.к.веб-разработке..Тер- мин.«гибридные.приложения».иногда.будет.применяться.для.обозначения.приложений,. которые.работают.в.браузерах.как.на.веб-устройствах,.так.и.на.мобильных.аппаратах. Процедурное программирование в сравнении с объектно-ориентированным Прежде чем мы углубимся в преимущества объектно-ориентированной разра- ботки, рассмотрим более существенный вопрос: что такое объект? Это одно- временно и сложный, и простой вопрос. Сложный он потому, что изучение любого метода разработки программного обеспечения не является тривиальным. А простой он в силу того, что люди уже мыслят в категориях «объекты». ПОДСКАЗКА __________________________________________________________________________ Посмотрите.на.YouTube.видеолекцию.гуру.объектно-ориентированного.программи- рования.Роберта.Мартина..На.его.взгляд,.утверждение.«люди.мыслят.объектно». впервые.сделали.маркетологи..Немного.пищи.для.размышлений. Например, когда вы смотрите на какого-то человека, вы видите его как объект. При этом объект определяется двумя компонентами: атрибутами и поведением. У человека имеются такие атрибуты, как цвет глаз, возраст, вес и т. д. Человек 25 Процедурное.программирование.в.сравнении.с.объектно-ориентированным. . также обладает поведением, то есть он ходит, говорит, дышит и т. д. В соответ- ствии со своим базовым определением, объект — это сущность, одновременно содержащая данные и поведение. Слово одновременно в данном случае опреде- ляет ключевую разницу между объектно-ориентированным программировани- ем и другими методологиями программирования. Например, при процедурном программировании код размещается в полностью отдельных функциях или процедурах. В идеале, как показано на рис. 1.1, эти процедуры затем превраща- ются в «черные ящики», куда поступают входные данные и откуда потом выво- дятся выходные данные. Данные размещаются в отдельных структурах, а мани- пуляции с ними осуществляются с помощью этих функций или процедур. РАЗНИЦА МЕЖДУ ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ И СТРУКТУРНЫМ ПРОЕКТИРОВАНИЕМ _______________________________________________ При.объектно-ориентированном.проектировании.атрибуты.и.поведения.размеща- ются.в.рамках.одного.объекта,.в.то.время.как.при.процедурном.или.структурном. проектировании.атрибуты.и.поведение.обычно.разделяются. Рис. 1.1. Черный.ящик При росте популярности объектно-ориентированного проектирования один из фактов, который изначально тормозил его принятие людьми, заключался в том, что использовалось много систем, которые не являлись объектно-ориентиро- ванными, но отлично работали. Таким образом, с точки зрения бизнеса не было никакого смысла изменять эти системы лишь ради внесения изменений. Каж- дому, кто знаком с любой компьютерной системой, известно, что то или иное изменение может привести к катастрофе, даже если предполагается, что это изменение будет незначительным. В то же время люди не принимали объектно-ориентированные базы данных. В определенный момент при появлении объектно-ориентированной разработки в какой-то степени вероятным казалось то, что такие базы данных смогут за- менить реляционные базы данных. Однако этого так никогда и не произошло. Бизнес вложил много денег в реляционные базы данных, а совершению пере- хода препятствовал главный фактор — они работали. Когда все издержки и ри- ски преобразования систем из реляционных баз данных в объектно-ориентиро- ванные стали очевидными, неоспоримых доводов в пользу перехода не оказалось. Глава.1..Введение.в.объектно-ориентированные.концепции 26 На самом деле бизнес сейчас нашел золотую середину. Для многих методик разработки программного обеспечения характерны свойства объектно-ориен- тированной и структурной методологий разработки. Как показано на рис. 1.2, при структурном программировании данные зачастую отделяются от процедур и являются глобальными, благодаря чему их легко модифицировать вне области видимости вашего кода. Это означает, что доступ к данным неконтролируемый и непредсказуемый (то есть у множества функций может быть доступ к глобальным данным). Во-вторых, поскольку у вас нет контроля над тем, кто сможет получить доступ к данным, тестирование и от- ладка намного усложняются. При работе с объектами эта проблема решается путем объединения данных и поведения в рамках одного элегантного полного пакета. Рис. 1.2. Использование.глобальных.данных ПРАВИЛЬНОЕ ПРОЕКТИРОВАНИЕ ____________________________________________________ Мы.можем.сказать,.что.при.правильном.проектировании.в.объектно-ориентирован- ных.моделях.нет.такого.понятия,.как.глобальные.данные..По.этой.причине.в.объ- ектно-ориентированных.системах.обеспечивается.высокая.степень.целостности. данных. Вместо того чтобы заменять другие парадигмы разработки программного обес- печения, объекты стали эволюционной реакцией. Структурированные програм- 27 Процедурное.программирование.в.сравнении.с.объектно-ориентированным. . мы содержат комплексные структуры данных вроде массивов и т. д. C++ вклю- чает структуры, которые обладают многими характеристиками объектов (классов). Однако объекты представляют собой нечто намного большее, чем структуры данных и примитивные типы вроде целочисленных и строковых. Хотя объекты содержат такие сущности, как целые числа и строки, используемые для пред- ставления атрибутов, они также содержат методы, которые характеризуют по- ведение. В объектах методы применяются для выполнения операций с данными, а также для совершения других действий. Пожалуй, более важно то, что вы мо- жете управлять доступом к членам объектов (как к атрибутам, так и к методам). Это означает, что отдельные из этих членов можно скрыть от других объектов. Например, объект с именем Math может содержать две целочисленные переменные с именами myInt1 и myInt2 . Скорее всего, объект Math также содержит методы, необходимые для извлечения значений myInt1 и myInt2 . Он также может включать метод с именем sum() для сложения двух целочисленных значений. СОКРЫТИЕ ДАННЫХ __________________________________________________________________ В.объектно-ориентированной.терминологии.данные.называются.атрибутами,.а.по- ведения.—.методами..Ограничение.доступа.к.определенным.атрибутам.и/или.ме- тодам.называется.сокрытием.данных. Объединив атрибуты и методы в одной сущности (это действие в объектно- ориентированной терминологии называется инкапсуляцией), мы можем управ- лять доступом к данным в объекте Math . Если определить целочисленные пере- менные myInt1 и myInt2 в качестве «запретной зоны», то другая логически несвязанная функция не будет иметь возможности осуществлять манипуляции с ними, и только объект Math сможет делать это. |