Как и обещал, начинаю рубрику об ООП. Рассматривать данный вопрос, не остановившись на теоретических выкладках, невозможно. Поэтому начнём именно с теории.

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

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

Класс

Практически любая книга, описывающая ООП, оперирует при описании основных понятий автомобилями, мы же давайте сразу перейдем к терминам системы. Итак, представим себе договор (например, договор покупки шарикоподшипников). Мы знаем, что у всех договоров согласно ГК РФ есть обязательные атрибуты, есть набор действий, который совершается с этим договором: создание прототипа, согласование, подписание, расторжение, пролонгация и т.д. Теперь представьте, что вы все эти атрибуты, действия и т.д. описали в каком-то положении. Вот это положение и называется классом.

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

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

С точки зрения программирования класс можно рассматривать как набор данных (полей, атрибутов, членов класса) и функций для работы с ними (методов). Т.е. в нашем случае, класс будет описывать сущность – договор. Атрибутами класса будут подписывающие стороны, предмет договора, спецификация, статус к нему и т.д. Методами класса, например, будет: создание прототипа, изменение статуса (подписание, расторжение), пролонгация.

В случае с автомобилем я думаю понятно 😉

Объект

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

Объект (экземпляр) – это отдельный представитель класса, имеющий конкретное состояние и поведение, полностью определяемое классом.

Интерфейс

Вот тут-то я и пожалел, что не стал описывать все на основе автомобилей…

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

Метод – предоставляемая объектом функция. Методы могут вызываться как, например, функции, при этом возвращать значения и принимать параметры

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

После определения интерфейса его можно реализовать в классе. Это означает, что в таком случае класс будет поддерживать все свойства и члены, указанные данным интерфейсом. Интерфейсы не существуют сами по себе. «Создать экземпляр» интерфейса, как для класса, нельзя. Кроме того, интерфейсы не могут содержать код с реализацией их членов, они могут лишь определять их. Реализация членов осуществляется в классах, реализующих данный интерфейс.

При описании интерфейса очень важно соблюсти баланс между гибкостью и простотой. Класс с простым интерфейсом будет легко использовать, но он будет ограничен функционально. Гибкость же интерфейса сильно усложнит его, увеличив количество методов и атрибутов, что сделает его использование очень сложным. Представьте себе регламент на 1000 страницах…

При этом основными принципами ООП являются:

Наследование


Наследование (inheritance) — один из самых важных механизмов в ООП. Любой класс может наследоваться от другого класса, а это значит, что он будет иметь все те члены, что и класс, от которого он унаследован. В терминологии ООП класс, от которого наследуется (порождается) другой класс, называется родительским или базовым классом. Классы в ABAP могут непосредственно наследоваться только от одного базового класса, хотя у того базового класса может быть собственный базовый класс, и т.д. Механизм наследования позволяет расширять или создавать конкретные классы от одного более общего базового класса. Например, возьмем класс, представляющий все договоры, назовем его Contract. У класса Contract есть методы: Заключение и Расторжение. Но от Contract можно создать производный класс LOAN (Ссуды),который будет поддерживать методы Заключение и Расторжение, а также собственный Расчет процентов.

 

Полиморфизм

Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Для примера полиморфизма возьмем классы, которые я описал выше (см. Наследование). Так метод Заключение в производном классе Loan будет отличесться от метода Заключение в родительском классе Contract т.к. чтобы заключить ссудный договор необходимо выполнить несколько другие операции, нежели при заключении, например, договора купли-продажи. Но при этом вне зависимости от содержимого метода Заключение в том или ином классе, проделав данную процедуру, мы получим одинаковый результат – заключенный договор.

Также простым примером полиморфизма может послужить руль автомобиля. Руль (интерфейс) остается рулем независимо от того, какой тип рулевого механизма используется в автомобиле. Использование руля дает одинаковый результат: оснащен ли ваш автомобиль рулевым управлением прямого действия, рулевым управлением с усилителем или реечным управлением. Таким образом, поворот руля влево заставит автомобиль поехать влево независимо от типа используемого в нем рулевого управления. Достоинство такого единообразного интерфейса состоит, безусловно, в том, что, если вы знаете, как обращаться с рулем, вы сможете водить автомобиль любого типа.

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

Инкапсуляция

Инкапсуляция (по-русски: «сокрытие») — это свойство объектов скрывать некоторые свои данные и способы их обработки.

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

В языках программирования инкапсуляция достигается определением зоны видимости свойств и методов объекта.

 

Абстракция

Абстрагирование – это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

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

В данной статье я описал основные понятия и принципы объектно-ориентированного программирования, в дальнейшем я попытаюсь более детально осветить все эти вопросы, но уже применительно к языку ABAP. Надеюсь, данный материал будет вам полезен.

  Один комментарий в “Объектно-ориентированное программирование (ООП): Немного теории (Часть I)”

  1. Привет, Артем. Искал инфу по локальным классам, заскочил к тебе. Хорошо пишешь, легко читается.

© 2013 sap-blog.ru
Яндекс.Метрика