Применение объектно-ориентированного подхода при проектировании информационной системы (Объектно-ориентированный подход.)
Содержание:
ВВЕДЕНИЕ
Наша жизнь – существование в необыкновенное время. Наши предки не могли и представить себе создание компьютера в своё время. Бурное развитие данной отрасли дало толчок к открытию и созданию множества ранее неизвестных технологий, изменивших мир. Текущее поколение возможно станет свидетелем нового этапа эры компьютеризации общества, когда машинам будет требоваться меньшее вмешательство со стороны человека нежели сейчас, а пока этого не случилось проектирование информационных систем остается одной из важных задач.
Создание бизнес-информационных систем представляет довольно сложную и трудоемкую задачу, требующую высокой квалификации специалистов в сфере информационных технологий.
Проектирование информационных систем всегда начинается с определения цели проекта. Основная задача любого успешного проекта заключается в том, чтобы на момент запуска системы и в течение всего времени ее эксплуатации можно было обеспечить:
- требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;
- требуемую пропускную способность системы;
- требуемое время реакции системы на запрос;
- безотказную работу системы в требуемом режиме, иными словами - готовность и доступность системы для обработки запросов пользователей;
- простоту эксплуатации и поддержки системы;
- необходимую безопасность.
Производительность является главным фактором, определяющим эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.
Проектирование информационных систем охватывает три основные области:
- проектирование объектов данных, которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
В реальных условиях проектирование — это поиск способа, который удовлетворяет требованиям функциональности системы средствами имеющихся технологий с учетом заданных ограничений.
Объектно-ориентированный подход
Разница между структурным и объектно-ориентированным подходом сводится к способу декомпозиции. Объектно-ориентированный подход активно использует в своем арсенале объектную декомпозицию, но при этом статическая структура системы описывается в терминах объектов и связей между ними, а определение поведения системы в терминах обмена сообщениями между объектами. Абсолютно каждый объект системы имеет собственное поведение, моделирующее поведение объекта окружающего мира. Само понятие объект первоначально было использовано приблизительно 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 можно воспользоваться вызовом из одного конструктора другого:
Такой подход помогает решить еще одну проблему: модификацию внутренних (объектных) переменных в теле только одного конструктора.
ЗАКЛЮЧЕНИЕ
Рассмотрев теоретические аспекты и основные ошибки при использовании объектно-ориентированного подхода в проектировании можно прийти к выводу, что со временем использование данного метода найдет новое применение, а уже имеющиеся будут задействованы более эффективно.
Список литературы
- Голицына О.Л. Информационные системы/ Голицына О.Л., Максимов Н.В., Попов И.И. – Учебное пособие. 2-е изд. М.: ФОРУМ,2016 – 448 с.
- Проектирование информационных систем [электронный ресурс]: Архив Компьютер пресс – 2011. – Режим доступа: https://compress.ru/article.aspx?id=11764
- Штанюк А.А. Ошибки начинающих программистов при использовании Объектно-Ориентированного Подхода [электронный ресурс]: Текст научной статьи по специальности «Автоматика. Вычислительная техника» - 2017. – Режим доступа: https://cyberleninka.ru/article/n/oshibki-nachinayuschih-programmistov-pri-ispolzovanii-obektno-orientirovannogo-podhoda
- Русскоязычная электронная энциклопедия «Википедия» ru.Wikipedia.org
- Управление поведением в конфликтных ситуациях (Конфликт как процесс.)
- Общие особенности кадровой стратегии организаций бюджетной сферы (Сущность стратегического управления в организации.)
- Структура финансирования проектов (Теоретические вопросы финансирования инвестиционных проектов)
- Современные языки программирования (Ассемблер.)
- Система защиты информации в банковских системах (Система информации в банковских системах)
- Управление дебиторской задолженностью организаций индустрии гостеприимства (Понятие дебиторской задолженности)
- СОЦИАЛЬНО-ПСИХОЛОГИЧЕСКИЙ КЛИМАТ ОРГАНИЗАЦИИ (ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ИЗУЧЕНИЯ СОЦИАЛЬНО-ПСИХОЛОГИЧЕСКОГО КЛИМАТА В ОРГАНИЗАЦИИ)
- Профессиональный стресс в управленческой деятельности (Теоретический анализ подходов к управлению профессиональным стрессом в организации.)
- «Невербальные проявления эмоциональных состояний человека»
- Нотариат (его роль в защите гражданских прав и охраняемых законом интересов)
- Технология «клиент-сервер» (1.СТРУКТУРА КЛИЕНТ-СЕРВЕРНОГО ВЗАИМОДЕЙСТВИЯ 4)
- Функции операционных систем персональных компьютеров (АНАЛИЗ РЫНКА.)