36. Виды мышления
Наиболее полно типология видов мышления в отечественной психологии представлена в работах Р.С. Немова, в зарубежной психологии – Дж. Брунера. Так, Р.С. Немов выделяет практическое и теоретическое мышление, каждое из которых соответственно подразделяется на два подвида: наглядно-действенное и наглядно-образное мышление и теоретическое образное и теоретическое понятийное мышление
Наглядно-действенное
мышление – процесс решения умственных
задач при непосредственном манипулировании
предметами. Например, в экспериментах
с обезьянами на недоступной им высоте
подвешивали приманку. При этом по
площадке были разбросаны ящики. Сначала
обезьяна тянулась к приманке или
прыгала. Затем она сидела неподвижно
и «анализировала» ситуацию. Наконец,
обезьяны составляла пирамиду из ящиков,
брала палку и доставала фрукты. Подобная
сообразительность – это конкретное
мышление в действии, то есть
наглядно-действенное мышление.
Такое мышление широко представлено у людей, занятых ручным трудом.
Наглядно-образное мышление – процесс решения умственных задач при манипулировании образами предметов, извлеченными из кратковременной памяти. Такое мышление непосредственно связано с восприятием. Наглядно-образное мышление характерно для детей дошкольного и младшего школьного возраста, а также для художников, работающих на пленере, инженеров и конструкторов.
Теоретическое
образное мышление – процесс решения
умственных задач при манипулировании
образами предметов, извлеченными из
долговременной памяти. Мышление такого
типа является более обобщенной и
отвлеченной формой, его образы не только
извлекаются из памяти, но и реконструируются
силой воображения. Хорошо развитое
теоретическое образное мышление имел
И.М. Гончаров. Он вспоминал, что когда
писал книги: люди не давали ему покоя,
приставали, позировали в сценах. Он
слышал отрывки их разговоров.
Теоретическое понятийное мышление – процесс решения мыслительных задач при манипулировании абстрактными категориями (понятиями) без обращения к опыту, который был получен при помощи органов чувств. Такое мышление свойственно научным работникам, к нему, по мере необходимости, обращаются все люди, когда имеют дело с абстрактной (символической или знаково-символической) информацией.
Когнитивный психолог Дж. Брунер по характеру воспринимаемой информации и соответствующему типу ее репрезентации выделяет в профиле мышления 4 базовых и 6 комбинированных видов. К базовым типам он относит предметное, образное, знаковое и символическое мышление.
Предметное
мышление неразрывно связано с предметом
в пространстве и во времени и осуществляется
как преобразование информации с помощью
предметных действий. Операции предметного
мышления выполняются строго
последовательно.
Образное мышление осуществляется с помощью манипулирования образами предметов, когда его свойства воспринимаются отвлеченно от непосредственного носителя. Таким мышлением обладают люди с художественным складом ума.
Знаковое мышление оперирует информацией на уровне умозаключений. Знаки группируются в более крупные структуры, результатом является мысль в форме понятия или высказывания, фиксирующего существенные отношения между предметами и явлениями. Это тип мышления людей с гуманитарным складом ума.
Символическое
мышление преобразует информацию с
помощью логических операций, его
результатом является мысль, выраженная
в виде структур или формул, фиксирующих
существенные отношения между символами.
Такое мышление характерно для людей с
математическим складом ума.
10. Мышление.
Мышление — процесс моделирования систематических отношений окружающего мира на основе безусловных положений. Однако в психологии существует множество других определений.
— высший этап обработки информации человеком, процесс установления связей между объектами или явлениями окружающего мира; или — процесс отражения существенных свойств объектов, а также связей между ними, что приводит к появлению представлений об объективной реальности. Споры по поводу определения продолжаются по сей день.
Мышление
— высшая ступень человеческого познания,
процесс отражения в мозге окружающего
реального мира, основанный на двух
принципиально различных психофизиологических
механизмах: образования и непрерывного
пополнения запаса понятий, представлений
и вывода новых суждений и умозаключений.
Мышление позволяет получить знание о
таких объектах, свойствах и отношениях
окружающего мира, которые не могут быть
непосредственно восприняты при помощи
первой сигнальной системы.
Основные характеристики:
-Обобщение отражения действительности— осуществление поиска отдельных предметов и явлений и переход к общему;
-Опосредованное познание объективной реальности— на основе непрямой информации мы можем судить о свойствах предметов и явлений;
Классификаци:
-Наглядно-действенное мышление (Форма мышления, манипулирующая предметной сферой. Имеется у детей с рождения до 1,5 лет)
-Конкретно-предметное мышление (Задачи решаются с помощью существующего, реального объекта. Формирование в -возрасте от 1,5 — до 7 лет)
Наглядно-образное
мышление (Осуществляется при
непосредственном восприятии окружающей
действительности, образы представляются
в кратковременной и оперативной памяти
(доминирует от 3 летнего до младшего
школьного возраста).
-Абстрактно-логическое мышление (Мышление абстракциями — категориями, которых нет в природе. Формируется с 7 лет. Считается, что у животных нет абстрактного мышления.)
Мышление и интеллект
Интеллект связан с мышлением, которое обрабатывает информацию из внешнего мира. Интеллект связан с мышлением в области решения задач, это совокупность умственных способностей, обеспечивающих успех познания.
Мышление формирует понятия, понимание их взаимосвязей, анализирует их, а это, в свою очередь — основа поведения, а значит — адаптации. При этом выбор поведения зависит от критичности мышления[24]. Важно заметить, что поведение и мышление связаны только при решении определённой задачи, если её нет, поведение связано с другими механизмами. Мышление связано с деятельностью, так как в её процессе сначала решается ряд задач, а потом умственный проект осуществляется на практике[24]. Кроме того, существует творческое мышление.
Теории
о происхождении и наличии мышления у
человека делятся на 2 группы.
Представители
первой считают, что интеллектуальные
способности врождённые и неизменные.
Одной из наиболее известных теорий
первой группы является теория мышления
гештальтпсихологии. Согласно второй
группе, умственные способности развиваются
в процессе жизни человека. Мышление
зависит либо от внешних воздействий
среды, либо от внутреннего развития
субъекта, или же исходя из того и другого.
Объектное мышление — TechBookReport
| |Новые обзоры| |Методологии программного обеспечения| |Популярная наука| |ИИ/машинное обучение| |Программирование| |Ява| |Linux/с открытым исходным кодом| |XML| |Программные инструменты| |Другое| |Интернет| |Учебники| |Все по дате| |Все по названию| |Ресурсы| |О| |
Ключевые слова: Объекты, гибкая разработка, XP, моделирование Название: Объектное мышление Автор: Дэвид Уэст Издатель: Microsoft Press ISBN: 0735619654 Носитель: Книга Уровень: Вердикт: Заставляющее задуматься и противоречивое чтение | Купить в США |
Это совсем другая книга по объектно-ориентированной разработке.
Он начинается с основной предпосылки, что объектно-ориентированная парадигма — это гораздо больше, чем овладение механикой языка программирования — будь то язык Java, C#, Python или что-то еще. Пока все хорошо, это не особенно спорный момент, и большинство практиков согласится с тем, что для того, чтобы действительно «получить» объекты, требуется несколько лет, в отличие от недель или месяцев, необходимых для изучения синтаксиса языка. Однако вместо того, чтобы написать книгу по информатике по объектно-ориентированной теории — инкапсуляции, полиморфизму, наследованию и т. д., — автор Дэвид Уэст отправляет читателя в своего рода философское путешествие к пониманию «объектного мышления».
Возможно, здесь, в TechBookReport, мы ведем замкнутую жизнь, но нам удается увидеть несколько книг, в которых обсуждаются постмодернистское мышление, философская герменевтика, Хайдеггер и тонкости объектно-ориентированной разработки программного обеспечения. Хотя это может показаться со стороны Уэста теоретической игрой мускулов, на самом деле это центральное место в его утверждении о том, что объектное мышление является неотъемлемой частью более широкого подхода к решению проблем (на самом деле, более широкого, чем это, для Уэста это мировоззрение, скорее чем что-то конкретное для разработки программного обеспечения).
Книга придерживается партийной линии, критикуя рационалистическое/детерминистское мышление, отдающее предпочтение инструментам, математике и жесткому формализму, в отличие от «постмодернистской» линии, отдающей предпочтение эмерджентному поведению, герменевтике (искусству или науке интерпретации) и гибким методам. Говоря более обыденным языком, это контраст между теми, кто считает разработку программного обеспечения управляемой людьми (т. рациональная роза). Несмотря на то, что мы сильно оспариваем характеристику рационализма, данную Уэстом (которую он приравнивает к детерминизму) — например, теория сложности прочно укоренилась в рационализме и научном методе, — основная мысль его аргументов верна. Объектное мышление основано на определенном взгляде на мир и на наборе (гибких) практик, которые на этом основаны.
Однако это только одна часть книги. Обсудив философские и исторические предпосылки объектного мышления, книга переходит к рассмотрению того, что это означает на практике.
Основываясь на изложенном ранее мировоззрении, Уэст смотрит на то, как мы получаем объекты. Ответ на вопрос «откуда берутся объекты?» показывает еще один глубокий разрыв между агилистами и более традиционными разработчиками. Вместо того, чтобы полагаться на процессы и инструменты, Уэст предлагает использовать поведенческий подход, который позволяет создавать наиболее элегантные и полезные проекты. Здесь мы делаем шаг назад, чтобы взглянуть на исторические корни объектно-ориентированного развития, особенно в отношении Smalltalk. Автор снова приводит убедительные доводы в пользу использования карт CRC и других методов для определения динамики поведения объектов. Фундаментальным здесь является взгляд на объекты как на динамические, а не как на статические.
Наконец, книга переходит к некоторым практическим примерам, показывающим, как объектное мышление может решить ряд реальных проблем. Мы подозреваем, что для многих читателей это будет настоящим содержанием этой книги, и это позор, поскольку более теоретические разделы также дают реальное понимание.
Хотя текст может показаться сухим и академическим, он хорошо аргументирован, страстен и подкреплен обильными сносками и врезками. Эта книга заставляет вас серьезно задуматься о ремесле объектно-ориентированной разработки программного обеспечения. Решительно агностический подход к языку реализации здорово помогает — в специфике того или иного языка программирования не заблудишься. Это ни в коем случае не легкое чтение, но оно заставляет задуматься (и временами приводит в бешенство), и оно действительно помогает читателю разобраться с некоторыми из более глубоких концепций объектно-ориентированного проектирования.
Нажмите кнопку «Назад» в браузере, чтобы вернуться на страницу предметного указателя
Вернуться на домашнюю страницу
Мыслить объектами | Developer.com
Введение
Я написал Объектно-ориентированный мыслительный процесс для всех, кому необходимо понять основные концепции объектно-ориентированного программирования, прежде чем переходить к коду.
Базовое понимание объектно-ориентированной теории очень важно, потому что довольно часто программисты сразу переходят к коду. Большинство специалистов по программному обеспечению, которых я обучаю, пытались перейти от структурированного к объектно-ориентированному, не меняя при этом своего мышления. Это ошибка.
Объектно-ориентированная разработка — это метод проектирования, а не соглашение о кодировании. При разработке объектно-ориентированной модели вы должны уделять гораздо больше внимания дизайну, чем коду (в определенной степени это верно и для структурированной разработки). Чтобы создать надежный проект, вы должны сначала понять концепции, связанные с проектированием объектной модели.
Одним из первых навыков мыслительного процесса, которым вы должны овладеть, является умение мыслить предметно. Это может быть проще, чем вы думаете, потому что в реальном мире вы мыслите объектами. Это просто вопрос изменения вашей парадигмы разработки программного обеспечения, чтобы думать в терминах объектов, а не думать о программе как просто о коде и данных.
В этом выпуске мы рассмотрим, как вы начинаете мыслить в терминах объектов.
Как думать с точки зрения объектов
Как и в большинстве случаев в жизни, не существует единственно правильного или неправильного подхода к проблеме. Как правило, одну и ту же проблему можно решить разными способами. Так что, пытаясь спроектировать объектно-ориентированное решение, не зацикливайтесь на попытках сделать идеальный дизайн с первого раза. Что вам действительно нужно сделать, так это провести мозговой штурм и дать волю своему мыслительному процессу. Не пытайтесь соответствовать каким-либо стандартам или условностям, пытаясь решить проблему, потому что вся идея заключается в том, чтобы быть творческим. Таким образом, прежде чем приступить к проектированию системы или даже класса, хорошенько обдумайте задачу и повеселитесь! В этой статье мы исследуем изобразительное искусство и науку объектно-ориентированного мышления.
Переход от процедурного мира к объектно-ориентированному миру не является тривиальным.
Переход с FORTRAN на COBOL или даже на C требует изучения нового языка; однако переход от COBOL к C++, C# .NET, Visual Basic .NET или Java требует изучения нового мыслительного процесса. Вот где заезженная фраза объектно-ориентированная парадигма поднимает свою уродливую голову. При переходе на объектно-ориентированный язык вы должны сначала изучить концепции объектно-ориентированного программирования и соответствующий мыслительный процесс. Если этого сдвига парадигмы не произойдет, произойдет одно из двух: либо проект не будет по-настоящему объектно-ориентированным по своей природе (например, он будет использовать C++ без использования объектно-ориентированных конструкций), либо проект будет полностью объектно-дезориентированным. беспорядок.
В этой статье рассматриваются три важные вещи, которые вы можете сделать, чтобы развить хорошее представление об объектно-ориентированном мыслительном процессе:
- Знать разницу между интерфейсом и реализацией
- Думайте более абстрактно
- Предоставьте пользователю минимально возможный интерфейс
Мы уже встречались с некоторыми из этих концепций в статье 1, а теперь остановимся на них более подробно.
Понимание разницы между интерфейсом и реализацией
Как мы видели в статье 1, одним из ключей к надежному объектно-ориентированному дизайну является понимание разницы между интерфейсом и реализацией. Таким образом, при разработке класса жизненно важно, что нужно знать пользователю и что ему не нужно знать. Механизм сокрытия данных, присущий инкапсуляции, — это средство, с помощью которого несущественные данные скрываются от пользователя.
Предостережение: Не путайте понятие интерфейса с такими терминами, как графический интерфейс пользователя (GUI) . Хотя GUI, как следует из его названия, является интерфейсом, используемый здесь термин интерфейсы носит более общий характер и не ограничивается графическим интерфейсом.
Помните пример с тостером в статье 1? Тостер или любой прибор в этом отношении просто подключается к интерфейсу, который является электрической розеткой (см. рис. 1). Все бытовые приборы имеют доступ к электричеству, используя правильный интерфейс: электрическую розетку.
Тостеру не нужно ничего знать о реализации или о том, как производится электричество. Несмотря на все заботы тостера, электроэнергию может производить угольная электростанция или атомная электростанция — прибору все равно, что, лишь бы интерфейс работал.
Рисунок 1: Новый взгляд на электростанцию .
В качестве другого примера рассмотрим автомобиль. Интерфейс между вами и автомобилем включает в себя такие компоненты, как руль, педаль газа, тормоз и выключатель зажигания. Для большинства людей, если оставить в стороне эстетические вопросы, главная проблема при вождении автомобиля заключается в том, что автомобиль заводится, ускоряется, останавливается, рулит и так далее. Реализация, в основном то, что вы не видите, мало волнует среднего водителя. Фактически, большинство людей даже не смогли бы идентифицировать определенные компоненты, такие как каталитический нейтрализатор и прокладку. Однако любой водитель узнает и знает, как пользоваться рулем, потому что это обычный интерфейс.
Устанавливая в автомобиль стандартное рулевое колесо, производители уверены, что люди на их целевом рынке смогут использовать систему.
Однако, если бы производитель решил установить джойстик вместо руля, большинство водителей отказались бы от этого, и автомобиль мог бы не продаваться в больших количествах (за исключением некоторых эклектичных людей, которые любят идти против трендов). С другой стороны, пока производительность и эстетика не изменились, средний водитель не заметил бы, если бы производитель изменил двигатель — часть реализации — автомобиля.
Следует подчеркнуть, что взаимозаменяемые двигатели должны быть идентичными во всех отношениях — в том, что касается восприятия водителя. Замена четырехцилиндрового двигателя восьмицилиндровым изменит правила, так же как изменение тока с переменного на постоянный повлияет на правила в примере с силовой установкой.
Движок — часть реализации, а руль — часть интерфейса. Изменение реализации не должно влиять на драйвер, тогда как изменение интерфейса может.
Что видят пользователи Интерфейсы также напрямую относятся к классам. Конечные пользователи обычно не видят никаких классов — они видят графический интерфейс или командную строку. Однако программисты увидят интерфейсы классов. Повторное использование класса означает, что кто-то уже написал класс. Таким образом, программист, использующий класс, должен знать, как заставить класс работать правильно. Этот программист объединит множество классов для создания системы. Программист — это тот, кто должен понимать интерфейсы класса. Поэтому, когда мы говорим о пользователях в этой статье, мы в первую очередь имеем в виду дизайнеров и разработчиков, а не обязательно конечных пользователей. Таким образом, когда мы говорим об интерфейсах в этом контексте, мы говорим об интерфейсах классов, а не о графических интерфейсах. |
Правильно сконструированные классы состоят из двух частей — интерфейса и реализации.
Интерфейс
Услуги, предоставляемые конечному пользователю, составляют интерфейс. В лучшем случае представлены только услуги, необходимые конечному пользователю. Конечно, какие услуги нужны пользователю, может быть вопросом мнения. Если вы поместите 10 человек в комнату и попросите каждого из них сделать независимый дизайн, вы можете получить 10 совершенно разных дизайнов — и в этом нет ничего плохого. Однако, как правило, интерфейс класса должен содержать только то, что нужно знать пользователю. В примере с тостером пользователю нужно только знать, что тостер должен быть подключен к интерфейсу, которым в данном случае является электрическая розетка.
Идентификация пользователя Возможно, самым важным вопросом при разработке класса является определение аудитории или пользователей класса. |
Реализация
Детали реализации сервисов интерфейса скрыты от пользователя.
Следует помнить об одной цели, касающейся реализации: изменение реализации не должно требовать изменения кода пользователя. Это может показаться немного запутанным, но эта цель лежит в основе проблемы дизайна. Если интерфейс спроектирован правильно, изменение реализации не должно требовать изменения пользовательского кода. Помните, что интерфейс включает синтаксис для вызова метода и возврата значения. Если этот интерфейс не меняется, пользователю все равно, изменилась ли реализация. Пока программист может использовать один и тот же синтаксис и получить одно и то же значение, это все, что имеет значение.
Вспомните, что в примере с тостером, несмотря на то, что интерфейсом всегда является электрическая розетка, реализация может измениться с угольной электростанции на атомную электростанцию, не затрагивая тостер. Здесь необходимо сделать одну очень важную оговорку: угольная или атомная электростанция также должны соответствовать спецификации интерфейса. Если угольная электростанция производит электроэнергию переменного тока, а атомная электростанция производит электроэнергию постоянного тока, возникает проблема.
Суть в том, что и пользователь, и реализация должны соответствовать спецификации интерфейса.
Пример интерфейса/реализации
Давайте создадим простой (хотя и не очень функциональный) класс чтения базы данных Oracle. Мы напишем некоторый код Java, который будет извлекать записи из базы данных Oracle. Как мы уже говорили, знание ваших конечных пользователей всегда является самым важным вопросом при разработке любого вида дизайна. Следует провести некоторый анализ ситуации и провести интервью с конечными пользователями, а затем перечислить требования к проекту. Ниже приведены некоторые требования, которые мы могли бы использовать для чтения базы данных:
- Мы должны иметь возможность открыть соединение с базой данных.
- Мы должны иметь возможность закрыть соединение с базой данных.
- Мы должны установить курсор на первую запись в базе данных.
- Мы должны установить курсор на последнюю запись в базе данных.
- Мы должны найти количество записей в базе данных.
- Мы должны иметь возможность определить, есть ли еще записи в базе данных (то есть, находимся ли мы в конце).
- Мы должны иметь возможность установить курсор на определенную запись, указав ключ.
- Мы должны иметь возможность получить запись, указав ключ.
- Мы должны получить следующую запись, основываясь на позиции курсора.
Имея в виду эти требования, мы можем сделать первоначальную попытку разработать класс чтения базы данных, создав возможные интерфейсы для этих конечных пользователей.
В этом случае класс чтения базы данных предназначен для программистов, которым требуется использование базы данных. Таким образом, интерфейс — это, по сути, интерфейс прикладного программирования (API), который будет использовать программист. Эти методы, по сути, являются оболочками, заключающими в себе функциональные возможности, предоставляемые системой баз данных. Зачем нам это делать? Мы рассмотрим этот вопрос более подробно позже в статье; короткий ответ заключается в том, что нам может потребоваться настроить некоторые функции базы данных.
Например, нам может понадобиться обработать объекты, чтобы мы могли записать их в реляционную базу данных. Пишу это промежуточное ПО не является тривиальным с точки зрения дизайна и кодирования, но это реальный пример функциональности упаковки.
На рис. 2 показана диаграмма классов, представляющая возможный интерфейс к классу DataBaseReader.
Рис. 2: Диаграмма классов унифицированного языка моделирования для класса DataBaseReader.
Обратите внимание, что все методы этого класса являются общедоступными (помните, что рядом с именами методов, которые являются общедоступными интерфейсами, есть знаки плюс). Также обратите внимание, что представлен только интерфейс; реализация не показана. Потратьте минуту, чтобы определить, удовлетворяет ли эта диаграмма классов требованиям, изложенным ранее для проекта. Если позже вы обнаружите, что диаграмма не соответствует всем требованиям, ничего страшного; помните, что объектно-ориентированное проектирование — это итеративный процесс, поэтому вам не обязательно делать все правильно с первого раза.
Общий интерфейс Помните, что если метод является общедоступным, программист может получить к нему доступ, и поэтому он считается частью интерфейса класса. Не путайте термин интерфейс с ключевым словом interface, используемым в Java и C# — этот термин будет обсуждаться позже. |
Для каждого из перечисленных требований нам нужен соответствующий метод, обеспечивающий желаемую функциональность. Теперь вам нужно задать несколько вопросов:
- Чтобы эффективно использовать этот класс, нужно ли вам как программисту знать о нем что-то еще?
- Вам нужно знать, как код Oracle на самом деле открывает базу данных Oracle?
- Вам нужно знать, как код Oracle физически позиционирует себя над определенной записью?
- Вам нужно знать, как код Oracle определяет, остались ли еще записи?
По всем пунктам ответ решительное нет! Вам не нужно знать эту информацию.
Все, о чем вы заботитесь, это получение правильных возвращаемых значений и правильное выполнение операций. На самом деле, программист приложения, скорее всего, будет как минимум еще на один уровень абстракции от реализации. Приложение будет использовать ваши классы для открытия базы данных, которая, в свою очередь, вызовет соответствующий Oracle API.
Минимальный интерфейс Хотя, возможно, это крайность, один из способов определить минималистский интерфейс — изначально не предоставлять пользователю никаких общедоступных интерфейсов. Конечно, класс будет бесполезен; однако это заставляет пользователя вернуться к вам и сказать: «Эй, мне нужна эта функция». Таким образом, вы добавляете интерфейсы только тогда, когда это запрошено. Никогда не предполагайте, что пользователю что-то нужно. |
Создание оболочек может показаться излишним, но их написание дает много преимуществ.
Чтобы проиллюстрировать это, сегодня на рынке представлено множество продуктов промежуточного программного обеспечения. Рассмотрим проблему сопоставления объектов с реляционной базой данных. Сегодня на рынке есть объектно-ориентированные базы данных, которые идеально подходят для объектно-ориентированных приложений. Однако есть одна маленькая проблема: у большинства компаний годами хранятся данные в устаревших системах реляционных баз данных. Как компания может внедрить ООП-технологии и оставаться на переднем крае, когда ее данные находятся в реляционной базе данных?
Во-первых, вы можете преобразовать все ваши устаревшие реляционные данные в совершенно новую объектно-ориентированную базу данных. Любой, кто испытал острую (и хроническую) боль от любого преобразования данных, знает, что этого следует избегать как чумы.
Во-вторых, вы можете использовать промежуточное программное обеспечение для беспрепятственного сопоставления объектов в коде вашего приложения с реляционной моделью.
Это гораздо лучшее решение, поскольку реляционные базы данных широко распространены. Может быть аргумент, утверждающий, что объектно-ориентированные базы данных гораздо более эффективны для сохраняемости объектов, чем реляционные базы данных.
Постоянство объекта Сохранение объекта относится к концепции сохранения состояния объекта, чтобы его можно было восстановить и использовать позднее. Объект, который не сохраняется, в основном умирает, когда он выходит за пределы области видимости. Например, состояние объекта можно сохранить в базе данных. |
Однако в текущей бизнес-среде сопоставление отношений с объектами является отличным решением. Для совершенно новых объектно-ориентированных приложений, которым необходимо создавать новые хранилища данных, использование объектно-ориентированной базы данных может быть приемлемым выбором.
Тем не менее, объектно-ориентированные базы данных не получили широкого распространения.
Автономное приложение Даже при создании нового объектно-ориентированного приложения с нуля может быть непросто избежать устаревших данных. Это связано с тем, что даже недавно созданное объектно-ориентированное приложение, скорее всего, не является автономным приложением и может нуждаться в обмене информацией, хранящейся в реляционных базах данных (или любом другом устройстве хранения данных, если на то пошло). |
Вернемся к примеру с базой данных. На рис. 2 показан общедоступный интерфейс класса, и больше ничего. Конечно, когда этот класс будет завершен, он, вероятно, будет содержать больше методов и обязательно будет содержать атрибуты. Однако вам как программисту, использующему этот класс, не нужно ничего знать об этих закрытых методах и атрибутах.
Вам, конечно, не нужно знать, как выглядит код внутри общедоступных методов. Вам просто нужно знать, как взаимодействовать с интерфейсами.
Как будет выглядеть код этого общедоступного интерфейса? Давайте посмотрим на метод open():
public void open(String Name){
/* Некоторая обработка, специфичная для приложения */
/* вызов Oracle API для открытия базы данных */
/* Еще немного обработки для конкретного приложения */
};
В данном случае вы, надев шляпу программиста, понимаете, что метод open требует String в качестве параметра. Имя, которое представляет файл базы данных, передается, но не важно объяснять, как Имя сопоставляется с конкретной базой данных для этого примера. Это все, что нам нужно знать. А теперь самое интересное — что действительно делает интерфейсы такими замечательными!
Просто чтобы досадить нашим пользователям, давайте изменим реализацию базы данных. Вчера вечером мы перевели все данные из базы данных Oracle в базу данных SQLAnywhere (терпели острую и хроническую боль).
Это заняло у нас несколько часов, но мы сделали это.
Теперь код выглядит так:
public void open(String Name){
/* Некоторая обработка, специфичная для приложения */
/* вызов API SQLAnywhere для открытия базы данных */
/* Еще немного обработки для конкретного приложения */
};
К нашему великому огорчению, этим утром ни один пользователь не пожаловался. Несмотря на то, что реализация изменилась, интерфейс не изменился! Что касается пользователя, звонки остаются прежними. Изменение кода для реализации могло потребовать довольно много работы (и модуль с однострочным изменением кода пришлось бы перестраивать), но ни одна строка кода приложения, использующего этот класс DataBaseReader, не нуждалась в изменении.
Перекомпиляция кода Динамически загружаемые классы загружаются во время выполнения, а не статически связываются с исполняемым файлом. |
При использовании динамически загружаемых классов, как это делает Java, никакие пользовательские классы не нужно будет перекомпилировать. Однако в статически связанных языках, таких как C++, для добавления нового класса требуется ссылка.Отделив пользовательский интерфейс от реализации, мы можем избежать головной боли в будущем. На рисунке 3 реализации базы данных прозрачны для конечных пользователей, которые видят только интерфейс.
Рисунок 3: Интерфейс.
Заключение
В этой части серии статей об объектно-ориентированном мыслительном процессе мы начали процесс мышления в терминах объектов. Хотя процесс отличается при проектировании систем в объектно-ориентированной манере. В следующей колонке мы продолжим этот процесс, уточняя, как мы думаем с точки зрения объектов и их сообщений.
Ссылки
Фаулер, Мартин. UML Дистиллированный . Эддисон-Уэсли Лонгман, 1997.
Гилберт, Стивен и Билл Маккарти.
Объектно-ориентированное проектирование в Java . The Waite Group, 1998.
Мейерс, Скотт. Действующий C++ . Addison-Wesley, 1992.
Об авторе
Мэтт Вайсфельд — преподаватель Cuyahoga Community College (Tri-C) в Кливленде, штат Огайо. Мэтт работает в отделе информационных технологий и преподает такие языки программирования, как C++, Java и C# .NET, а также различные веб-технологии. До прихода в Tri-C Мэтт проработал 20 лет в индустрии информационных технологий, приобретая опыт в разработке программного обеспечения, управлении проектами, развитии бизнеса, корпоративном обучении и преподавании с частичной занятостью. Мэтт имеет степень магистра компьютерных наук и степень магистра делового администрирования в области управления проектами.
Статьи этой серии адаптированы из The Object-Oriented Thought Process (опубликовано Sams Publishing). Мэтт опубликовал еще две компьютерные книги и более дюжины статей в журналах, таких как Dr.