Файл: История и развитие методологии объектно-ориентированного программирования. Сферы применения (Теоретическая основа объектно-ориентированного программирования).pdf

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

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

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

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

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

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

Объект складывается с структуры данных и сопряженных с ней операций, которые функционируют с данными, записанными в экземплярах текстуры данных.

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

Объект, никак не имеющий наследования, именуется базисным объектом. Объект, наследующий свойства иных объектов, именуется порожденным либо производным объектом. [22]

Один и тот же метод, который выполняется по-своему, для каждого из различных объектов называется – Полиморфизмом. Например, метод класса Музыкальный инструмент - PlayMusicForAnOrchestra - может быть определен как общий метод, который может использоваться с любой категорией музыкальных инструментов. Данный способ прописан подобным способом, что никак не важно, тот или иной именно инструмент приобретает поручение играть, однако для классов, описывающих определенные инструменты, этот способ обязан являться переопределен (override), что предоставит возможность установить определенные воздействия, учитывающие характерные черты этого инструмента. [2]

Для более комфортного и облегченного пользования объектно-ориентированного программирования было создано достаточное количество современных языков. Однако следует отметить, что можно применять техники ООП и для не-объектно-ориентированного языка и наоборот, применение объектно-ориентированного языка вовсе не означает, что код автоматически становится объектно-ориентированным.

Новейший язык объектно-ориентированного программирования обладает определенным набором синтаксических средств, а именно: Объявление классов с полями и методами.

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

Методы защиты внутренней структуры классов от влияния внешних факторов. Чаще всего это модификаторы доступа к полям и методам, типа public, private, или же protected, но иногда некоторые другие.

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

Некоторые из них:

Конструкторы, деструкторы, финализаторы.

Свойства (аксессоры). [13]

Интерфейсы (к примеру, в Java используются также как альтернатива множественному наследованию - любой класс может реализовать сколько угодно интерфейсов). [21]

Часть языков полностью создана вокруг объектных средств - в них всевозможные сведения считаются объектами, любой код - методом какого-либо класса, и нереально составить программу, в которой никак не применялись б объекты. Примеры подобных языков - C#, Smalltalk, Java, Ruby. Прочие языки содержат ООП-подсистему в первоначально установленный язык. В них существует возможность программировать, не обращаясь к объектным средствам. Классические примеры - C++ и Delphi. [11]

2. Характеристика и анализ объектно-ориентированного
программирования

2.1. Критика объектно-ориентированного программирования

Объектно-ориентированное программирование модель программирования, которая используется в большинстве случаев написания программ, не смотря на критику в адрес этой модели. Но она не является лучшим методом во всех случая программирования. Зачастую сравнивают объектное и процедурное программирование:

Процедурное программирование лучше, когда есть больше времени на разработку, но важны программные ресурсы и быстродействие программы.

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

Некоторая критика в адресс объектно-ориентированного программирования:

Исследование Thomas E. Potok, Mladen Vouk и Andy Rindos выявило отсутствие повышения продуктивности по сравнению с процедурным методом программирования.

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

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

Фредерик Брукс (Frederick P. Brooks, Jr.) в своей статье «No Silver Bullet. Essence and Accidents of Software Engineering» (Computer Magazine; April 1987) показывает на то, что более непростой составляющей формирования программного обеспечения считается « … классификация, дизайн и тестирование концептуальных конструкций, а вовсе никак не работа согласно формулировке этих концептуальных конструкций…». Объектно-ориентированного программирования (наравне с подобными технологиями равно как искусственный интеллект, проверка программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, никак не считается «серебряной пулей», которая имела возможность бы на порядок величины (то есть приблизительно в ДЕСЯТЬ раз, равно как рассказывается в заметке) уменьшить трудность исследования программных систем. Согласно Бруксу, «…объектно-ориентированное программирование дает возможность уменьшить только лишь привнесённую трудность в представление дизайна. Дизайн остаётся трудным согласно собственной натуре …».

Эдсгер Дейкстра указывал: «…в таком случае о чём социум в основной массе случаев просит - данное змеиное масло. Безусловно, „змеиное масло“ содержит весьма вдохновляющие имена, по другому будет весьма сложно что-то реализовать: „Структурный исследование и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информативные системы“ (Management Information Systems), „Интегрированные сферы помощи проектов“, „Объектная ориентированность“, „Реинжиниринг предпринимательство действий“…».

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

Патрик Киллелиа в собственной книге «Тюнинг веб-сервера» писал: «… Объектно-ориентированного программирования дает вам большое число методов замедлить работу ваших проектов …»

Популярная обзорная публикация проблем нынешнего объектно-ориентированного программирования перечисляет определенные характерные задачи объектно-ориентированного программирования - Отчего объектно-ориентированное программирование провалилось. [9]

2.2. Аспекты критики объектно-ориентированного
программирования

Выделяются несколько аспектов критики объектно-ориентированного подхода программирования. [17]

Критикуется очевидно высказываемое либо подразумеваемое в работах определенных пропагандистов объектно-ориентированного программирования, а кроме того в маркетинговых материалах «объектно-ориентированных» средств исследования понимание о объектном программировании равно как о таком-то всемогущем подходе, который волшебным образом ликвидирует трудность программирования. Равно как обращали внимание многие, в том числе перечисленные выше Брукс и Дейкстра, «серебряной пули не существует» - вне зависимости от того, какой парадигмы программирования руководствуется создатель, формирование сложной непростой программной концепции постоянно связано с внушительными расходами умственных ресурсов и времени. Из более известных экспертов в сфере объектно-ориентированного программирования ни один человек, как правило, не отвергает достоверность оценки данного вида. [8]

Критики оспаривают принцип о том, что создание объектно-ориентированных программ потребует менее ресурсов либо приводит к формированию наиболее высококачественного программного обеспечения. Проводится сравнение расходов на исследование различными способами, на основе которого делается заключение о нехватке у объектно-ориентированного программирования положительных сторон в этом направлении. Принимая во внимание крайнюю трудность объективного сопоставления разных исследований, аналогичные сравнения, как минимум, спорны. [16]

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