Применение объектно-ориентированного подхода при проектировании информационной системы (УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

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

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

Объектно-ориентированный подход

Разница между структурным и объектно-ориентирован­ным подходом сводится к способу декомпозиции. Объектно-ориен­тированный подход активно использует в своем арсенале объектную декомпозицию, но при этом статиче­ская структура системы описывается в терминах объектов и связей между ними, а определение поведения системы в терминах обме­на сообщениями ме­жду объектами. Абсолютно каждый объект системы имеет собственное поведение, моделирующее поведение объекта окружающего мира. Само понятие объект первоначально было использовано приблизительно 30 лет назад в тех средствах в надежде отойти от привычной архи­тектуры фон Неймана и преодолеть барьер между уровнями абстрагирования в компьютерах. На объектно-ориентированной архи­тектуре завязаны объектно-ориентированные операционные сис­темы. Тем не менее значительный вклад в данный подход внесен объект­ными и объектно-ориентированными языками программирования такими, как например С++. Наибольшее влияние на ОО подход оказали развивавшиеся достаточно независимо методы модели­рования баз дан­ных, в особенности подход сущность-связь.

Основой объектно-ориентированного подхода яв­ляется объектная модель. Основными элементами являются:

• абстракция;

• инкапсуляция;

• модульность;

• иерархия.

Помимо основных дополнительно имеются еще три элемента, не являю­щихся строго обязательными:

• типизация;

• параллелизм;

• устойчивость.

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

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

Модульность — это свойство системы, связанное с возможностью ее де­композиции на ряд внутренне связных, но слабо связанных между собой моду­лей. Инкапсуляция и модульность создают барье­ры между абстракциями.

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

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

Параллелизм — свойство объектов находиться в активном или пассивном состоянии и различать активные и пассивные объекты между собой.

Устойчивость — свойство объекта существовать, но времени (вне зависи­мости от процесса, породившего данный объект) и/или в пространстве (при пе­ремещении объекта из адресного пространства, в котором он был создан).

Основные понятия объектно-ориентированного подхода - объект и класс.

Объект определяется как осязаемая реальность — предмет или явление, имеющие четко определяемое поведе­ние. Объект обладает со­стоянием, поведением и индивидуаль­ностью; структура и поведение схожих объектов определяют общий для них класс. Термины "экземпляр класса" и "объект'' являются эквивалентными. Состояние объекта характеризуется переч­нем всех возможных (статических) свойств данного объек­та и текущими значе­ниями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на дру­гие объекты и наоборот относительно изменения со­стояния этих объектов и передачи сообщений. Иначе говоря, поведение объек­та полностью определяется его действиями. Индивидуальность — это свойства объекта, отличающие его от всех других объектов.

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

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

Следующую группу важных понятий объектного подхода состав­ляют на­следование и полиморфизм. Понятие полиморфизма может быть интерпретиро­вано как способность класса принадлежать более чем одному типу. Наследова­ние означает построение новых классов на основе существующих с возможно­стью добавления или переоп­ределения данных и методов.

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

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

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ

UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:

• Диаграммы;
• Сущности;
• Связи.

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

Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.

Сущности

Диаграммы классов оперируют тремя видами сущностей UML:

• Структурные.
• Поведенческие.
• Аннотирующие.

Структурные сущности – это «имена существительные» в модели UML. В основном, статические части модели, представляющие либо концептуальные, либо физические элементы. Основным видом структурной сущности в диаграммах классов является класс.
Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.
Аннотирующие сущности – это поясняющие части UML-моделей, иными словами, комментарии, которые можно применить для описания, выделения и пояснения любого элемента модели. Главная из аннотирующих сущностей – примечание. Это символ, служащий для описания ограничений и комментариев, относящихся к элементу либо набору элементов. Графически представлен прямоугольником с загнутым углом; внутри помещается текстовый или графический комментарий.

Структурные сущности — классы

Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой. 
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:

• имя класса
• атрибуты (свойства) класса
• операции (методы) класса. 
  Для атрибутов и операций может быть указан один из трех типов видимости:
• — — private (частный)
• # — protected (защищенный)
• + — public (общий)

Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк. 
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы).
Для абстрактного класса имя класса записывается курсивом.
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty(проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием. 
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует.

Отношения между классами

Существует четыре типа связей в UML:

• Зависимость
• Ассоциация
• Обобщение
• Реализация

Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.

Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее.
Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами. 
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.

Двойные ассоциации представляются линией без стрелок на концах, соединяющей два классовых блока.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Множественность ассоциации представляет собой диапазон целых чисел, указывающий возможное количество связанных объектов. Он записывается в виде выражения с минимальным и максимальным значением; для их разделения используются две точки. Устанавливая множественность дальнего конца ассоциации, вы указываете, сколько объектов может существовать на дальнем конце ассоциации для каждого объекта класса, находящегося на ближнем ее конце. Количество объектов должно находиться в пределах заданного диапазона. Множественность может быть определена как единица 1, ноль или один0...1, любое значение 0...* или *, один или несколько 1…*. Можно также задавать диапазон целых значений, например 2…5, или устанавливать точное число, например 3.
Агрегация – особая разновидность ассоциации, представляющая структурную связь целого с его частями. Как тип ассоциации, агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём, по умолчанию агрегацией называют агрегацию по ссылке, то есть, когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет.
Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть».
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция – это форма агрегации с четко выраженными отношениями владения и совпадением времени жизни частей и целого. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется как и агрегация, но с закрашенным ромбиком.
Третья связь – обобщение – выражает специализацию или наследование, в котором специализированный элемент (потомок) строится по спецификациям обобщенного элемента (родителя). Потомок разделяет структуру и поведение родителя. Графически обобщение представлено в виде сплошной линии с пустой стрелкой, указывающей на родителя.

Четвертая – реализация – это семантическая связь между классами, когда один из них (поставщик) определяет соглашение, которого второй (клиент) обязан придерживаться. Это связи между интерфейсами и классами, которые реализуют эти интерфейсы. Это, своего рода, отношение «целое-часть». Поставщик, как правило, представлен абстрактным классом. В графическом исполнении связь реализации – это гибрид связей обобщения и зависимости: треугольник указывает на поставщика, а второй конец пунктирной линии – на клиента. Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений. Пример программы представлен на рисунках 2.2 и 2.3, а также результат вывода на рисунке 2.4 и диграмма классов кода 2.1.

Рисунок 2.1 – UML диаграмма классов

Рисунок 2.2 – Код программы на С++

Рисунок 2.3 – Продолжение кода программы на С++

Рисунок 2.4 – Результат выполнения программы

На диаграмме классов основным классом является класс TemperatureMeasure, который и является измерителем температуры. В качестве измеренного значения формируется среднее арифметическое всех измерений - сумма всех измерений, деленная на их количество.
Для получения измерений и их суммирования используется класс Sensor (в качестве датчика температуры). В консольной задаче сами измерения передаются в этот класс для суммирования. Класс состоит в отношении агрегации с основным классом TemperatureMeasure: мы сначала создаем объект класса Sensor, а потом передаем его в качестве параметра конструктора классу TemperatureMeasure, чтобы использовать его в качестве части класса.
Количество измерений формируется классом MeasureCount, который содержит статическое свойство totalдля подсчета общего измерений, а также свойство count для подсчета количества измерителей конкретного объекта TemperatureMeasure. Класс MeasureCount находится в отношении композиции с классом TemperatureMeasure: объект MeasureCount создается непосредственно при создании объекта TemperatureMeasure (в его конструкторе).
Класс ITemperatureMeasure представляет собой интерфейс класса TemperatureMeasure и является своего рода поставщиком в отношении реализации.
Наконец, класс ShowTemperature находится в отношении зависимости с классом TemperatureMeasure, поскольку реализация единственного метода Show класса ShowTemperature зависит от структуры класса TemperatureMeasure.

ОШИБКИ ПРИ ИСПОЛЬЗОВАНИИ ПОДХОДА

Благодаря трудам Штанюка Антона Александровича, доцента Нижегородского государственного университета им. Н.И. Лобачевского были собраны и классифицированы ошибки при использовании ОО подхода. Несколько простейших языковых ошибок.

Рассмотрим несколько типичных ошибок, определяемых на ранних стадиях.

Неправильное использование конструкций, вызванное особенностями реализации в разных языках. Типичный пример: когда конструкции try…catch() в языке С++ ошибочно приписывают блок finally, используемый в Java. Другой пример: для создания абстрактного класса языке С++ необходимо объявить в таком классе абстракный (чисто-виртуальный) метод, в то время как в языке Java можно воспользоваться спецификатором abstract для этой цели. - Ограниченное использование спецификатора const в С++ Использование const для создания ссылок на неизменяемые объекты и определения константых методов в классе предотвращает ошибочные изменения данных в объектах, что способствует повышению надежности всей программы. Начинающие программисты часто не уделяют этому факту должного внимания и не используют данный спецификатор. В языке Java подобным образом может игнорироваться спецификатор final.

Ошибки именования. Ошибки, связанные с неправильными именами классами, методами и объектами. Неправильные имена классов. В языке Java имя файла должно совпадать с именем публичного класса, определенного в этом файле. Несоответствие имен приводит к ошибкам компиляции. Кроме того, в программах с большим количеством классов, неправильные имена могут приводить к путанице при наследовании. - Неправильные имена методов. Помимо путаницы в использовании, неправильные имена в иерархиях (как и ошибки в сигнатурах методов) часто приводят к ошибкам замещения (override) или перегрузок (overload) методов. Например, если разработчик базового класса при выборе метода допустил синтаксическую ошибку, то разработчик производного класса может этого не заметить и выбрать корректное имя, что и приведет к ошибке. Частое использование методов, которые не возвращают результаты своей работы, может свидетельствовать о дефектах в проектировании классов (сильной зависимости от состояния объекта) и может потребовать дополнительного комментирования в тексте или документирования. - Слишком длинные или короткие имена Начинающие разработчики часто предпочитают давать объектам программы короткие имена, которые в дальнейшем быстро “заканчиваются”, при этом создавая известную путаницу в силу своей схематичности. Использование слишком длинных имен, особенно при активной разработке «оберток» (wrappers) к существующим объектам, может приводить к появлению сверхдлинных цепочек имен, затрудняющих работу с кодом. Пример длинного выражения: container.add((new JLabel("label text")).setMaximumSize(new Dimension(100,200))); В языке Java принято собирать классы в пакеты, которые, в свою очередь вкладываются друг в друга. В результате глубоких вложений или при использовании очень длинных имен могут образовываться очень длинные цепочки.

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

Усложнение модели предметной области, увеличение количества классов и связей Принцип декомпозиции предметной области, позволяющий выделить базовые сущности, описать классы и отношения, может применяться так «успешно», что даже в простых задачах схема классов оказывается чрезвычайно сложной и запутанной на рисунке 3.1.

Рисунок 3.1 – усложнение модели предметной области

Недостаточная декомпозиция, малое количество сущностей. Здесь наблюдается обратная картина: вместо хорошей декомпозиции, разработчик работает с малым количеством сущностей. Классы становятся громоздкими, нарушается принцип повторного использования, поскольку один и тот же функционал начинает дублироваться в разных классах. Возникает такой антипаттерн ООП, как «божественный объект», при котором одному объекту программы соответствует слишком большой функционал. Нарушение принципов ООП - Использование большого количества открытых членов класса 81 Сокрытие данных и кода придумали для их защиты от прямого доступа (в целях безопасности) и для облегчения тестирования и отладки. С другой стороны, этот принцип может стать помехой при написании кода, и начинающие программисты охотно заменяют закрытые и защищенные элементы классов на открытые. Вместо закрытых классов в С++ применяют открытые по умолчанию структуры. - Злоупотребление «дружбой» классов в С++ Ключевое слово friend, принятое в С++ используется для предоставления исключительного доступа одного класса к другому. Если этой возможностью начать злоупотреблять, то принцип сокрытия сойдет на нет и в программе начнется бесконтрольный прямой доступ между классами. - Нарушение принципа единственной ответственности (SRP) Если проектировать слишком большие классы с богатым набором функционала, то, скорее всего, будет нарушаться SRP. Основная проблема возникнет при дальнейшей работе над классом, при внесении в него изменений. Кроме того, такой класс будет иметь множество связей и при изменениях требований потребуется вносить много изменений в связанные участки программы. Неправильное использование наследования. Наиболее сложной стороной ООП для новичков выступают вопросы, связанные с использованием наследования и полиморфизма. Одна из наиболее часто встречающихся ошибок: Подмена агрегации (композиции) наследованием на рисунке 3.2.

Рисунок 3.2 – подмена агрегации наследованием

Если в классе cтудент имеется расчет среднего балла и такая же цель определяется для группы, то начинающие связывают эти классы наследованием, полагая, что в таком случае внутри группы удобно вызвать метод Student::calcGPA(). - Игнорирование виртуальных деструкторов. При отсутствии виртуальных деструкторов проблемы будут возникать при освобождении ресурсов, занимаемыми различными объектами в рамках одной иерархии. - Наследование вместо делегирования. Довольно популярная ошибка, связанная с неправильным подходом к наследованию и имеющая специальное название «антипаттерн BaseBean».

Использование копий объектов при полиморфизме вместо адресов и ссылок. Очень удобно, напpимер, хранить объекты разных связанных между собой классов в контейнере, который работаeт с указателями на базовый класс. Благодаря виртуальным функциям выполняeтся именно тот код, который нужен. Но если помещать в контейнеры копии объектов, то полиморфизм уже работать не будет и в контейнере будут храниться только экземпляры базового класса.

Дублирование кода в конструкторах. Если несколько конструкторов должны выполнить идентичный код, то нет смысла дублировать его. В языке С++ можно вынести общий код в приватный метод, а затем в каждом конструкторе поместить вызов этого метода. В языке Java можно воспользоваться вызовом из одного конструктора другого:

Такой подход помогает решить еще одну проблему: модификацию внутренних (объектных) переменных в теле только одного конструктора.

ЗАКЛЮЧЕНИЕ

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

Список литературы

1. Голицына О.Л. Информационные системы/ Голицына О.Л., Максимов Н.В., Попов И.И. – Учебное пособие. 2-е изд. М.: ФОРУМ,2016 – 448 с.
2. Проектирование информационных систем [электронный ресурс]: Архив Компьютер пресс – 2011. – Режим доступа: https://compress.ru/article.aspx?id=11764
3. Штанюк А.А. Ошибки начинающих программистов при использовании Объектно-Ориентированного Подхода [электронный ресурс]: Текст научной статьи по специальности «Автоматика. Вычислительная техника» - 2017. – Режим доступа: https://cyberleninka.ru/article/n/oshibki-nachinayuschih-programmistov-pri-ispolzovanii-obektno-orientirovannogo-podhoda
4. Русскоязычная электронная энциклопедия «Википедия» ru.Wikipedia.org