Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Методология объектно ориентированного программирования

Объектно-ориентированное программирование: на пальцах

Ста­тья не маль­чи­ка, но мужа.

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

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

Обычное программирование (процедурное)

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

Напри­мер, в интернет-магазине может быть функ­ция «Про­ве­рить email». Она полу­ча­ет на вход какой-то текст, сопо­став­ля­ет со сво­и­ми пра­ви­ла­ми и выда­ёт ответ: это пра­виль­ный элек­трон­ный адрес или нет. Если пра­виль­ный, то true, если нет — то false.

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

Что не так с процедурным программированием

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

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

Тут при­хо­дит продакт-менеджер и гово­рит: «Хочу, что­бы поль­зо­ва­тель точ­но знал, в чём ошиб­ка при вво­де элек­трон­но­го адре­са». Теперь вам нуж­но научить функ­цию выда­вать не про­сто true — false, а ещё и код ошиб­ки: напри­мер, если в адре­се опе­чат­ка, то код 01, если адрес спа­мер­ский — код 02 и так далее. Это неслож­но реа­ли­зо­вать.

Вы зале­за­е­те внутрь этой функ­ции и меня­е­те её пове­де­ние: теперь она вме­сто true — false выда­ёт код ошиб­ки, а если ошиб­ки нет — пишет «ОК».

И тут ваш код лома­ет­ся: все десять мест, кото­рые ожи­да­ли от про­ве­ряль­щи­ка true или false, теперь полу­ча­ют «ОК» и из-за это­го лома­ют­ся.

Теперь вам нуж­но:

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

Зада­ча, конеч­но, реша­е­мая за час-другой.

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

Это назы­ва­ет­ся спагетти-код, и для борь­бы с ним как раз при­ду­ма­ли объектно-ориентированное про­грам­ми­ро­ва­ние.

Объектно-ориентированное программирование

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

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

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

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

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

Инкап­су­ля­ция — объ­ект неза­ви­сим: каж­дый объ­ект устро­ен так, что нуж­ные для него дан­ные живут внут­ри это­го объ­ек­та, а не где-то сна­ру­жи в про­грам­ме. Напри­мер, если у меня есть объ­ект «Поль­зо­ва­тель», то у меня в нём будут все дан­ные о поль­зо­ва­те­ле: и имя, и адрес, и всё осталь­ное. И в нём же будут мето­ды «Про­ве­рить адрес» или «Под­пи­сать на рас­сыл­ку».

Абстрак­ция — у объ­ек­та есть «интер­фейс»: у объ­ек­та есть мето­ды и свой­ства, к кото­рым мы можем обра­тить­ся извне это­го объ­ек­та. Так же, как мы можем нажать кноп­ку на блен­де­ре. У блен­де­ра есть мно­го все­го внут­ри, что застав­ля­ет его рабо­тать, но на глав­ной пане­ли есть толь­ко кноп­ка. Вот эта кноп­ка и есть абстракт­ный интер­фейс.

В про­грам­ме мы можем ска­зать: «Уда­лить поль­зо­ва­те­ля». На язы­ке ООП это будет «пользователь.удалить()» — то есть мы обра­ща­ем­ся к объ­ек­ту «поль­зо­ва­тель» и вызы­ва­ем метод «уда­лить». Кайф в том, что нам не так важ­но, как имен­но будет про­ис­хо­дить уда­ле­ние: ООП поз­во­ля­ет нам не думать об этом в момент обра­ще­ния.

Напри­мер, над мага­зи­ном рабо­та­ют два про­грам­ми­ста: один пишет модуль зака­за, а вто­рой — модуль достав­ки. У пер­во­го в объ­ек­те «заказ» есть метод «отме­нить». И вот вто­ро­му нуж­но из-за достав­ки отме­нить заказ. И он спо­кой­но пишет: «заказ.отменить()». Ему неваж­но, как дру­гой про­грам­мист будет реа­ли­зо­вы­вать отме­ну: какие он отпра­вит пись­ма, что запи­шет в базу дан­ных, какие выве­дет пре­ду­пре­жде­ния.

Насле­до­ва­ние — спо­соб­ность к копи­ро­ва­нию. ООП поз­во­ля­ет созда­вать мно­го объ­ек­тов по обра­зу и подо­бию дру­го­го объ­ек­та. Это поз­во­ля­ет не копи­па­стить код по две­сти раз, а один раз нор­маль­но напи­сать и потом мно­го раз исполь­зо­вать.

Напри­мер, у вас может быть некий иде­аль­ный объ­ект «Поль­зо­ва­тель»: в нём вы про­пи­сы­ва­е­те всё, что может про­ис­хо­дить с поль­зо­ва­те­лем. У вас могут быть свой­ства: имя, воз­раст, адрес, номер кар­ты. И могут быть мето­ды «Дать скид­ку», «Про­ве­рить заказ», «Най­ти зака­зы», «Позво­нить».

На осно­ве это­го иде­аль­но­го поль­зо­ва­те­ля вы може­те создать реаль­но­го «Поку­па­те­ля Ива­на». У него при созда­нии будут все свой­ства и мето­ды, кото­рые вы зада­ли у иде­аль­но­го поку­па­те­ля, плюс могут быть какие-то свои, если захо­ти­те.

Иде­аль­ные объ­ек­ты про­грам­ми­сты назы­ва­ют клас­са­ми.

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

При этом внут­ри объ­ек­та мето­ды могут быть реа­ли­зо­ва­ны по-разному. Напри­мер, уда­лить товар — это выдать пре­ду­пре­жде­ние, а потом поме­тить товар в базе дан­ных как уда­лён­ный. А уда­лить поль­зо­ва­те­ля — это отме­нить его покуп­ки, отпи­сать от рас­сыл­ки и заар­хи­ви­ро­вать исто­рию его поку­пок. Собы­тия раз­ные, но для про­грам­ми­ста это неваж­но. У него про­сто есть метод «Уда­лить()», и он ему дове­ря­ет.

Такой под­ход поз­во­ля­ет про­грам­ми­ро­вать каж­дый модуль неза­ви­си­мо от осталь­ных. Глав­ное — зара­нее про­ду­мать, как моду­ли будут общать­ся друг с дру­гом и по каким пра­ви­лам. При таком под­хо­де вы може­те улуч­шить рабо­ту одно­го моду­ля, не затра­ги­вая осталь­ные — для всей про­грам­мы неваж­но, что внут­ри каж­до­го бло­ка, если пра­ви­ла рабо­ты с ним оста­лись преж­ни­ми.

Плюсы и минусы ООП

У объектно-ориентированного про­грам­ми­ро­ва­ния мно­го плю­сов, и имен­но поэто­му этот под­ход исполь­зу­ет боль­шин­ство совре­мен­ных про­грам­ми­стов.

  • Визу­аль­но код ста­но­вит­ся про­ще, и его лег­че читать. Когда всё раз­би­то на объ­ек­ты и у них есть понят­ный набор пра­вил, мож­но сра­зу понять, за что отве­ча­ет каж­дый объ­ект и из чего он состо­ит.
  • Мень­ше оди­на­ко­во­го кода. Если в обыч­ном про­грам­ми­ро­ва­нии одна функ­ция счи­та­ет повто­ря­ю­щи­е­ся сим­во­лы в одно­мер­ном мас­си­ве, а дру­гая — в дву­мер­ном, то у них боль­шая часть кода будет оди­на­ко­вой. В ООП это реша­ет­ся насле­до­ва­ни­ем.
  • Слож­ные про­грам­мы пишут­ся про­ще. Каж­дую боль­шую про­грам­му мож­но раз­ло­жить на несколь­ко бло­ков, сде­лать им мини­маль­ное напол­не­ние, а потом раз за разом подроб­но напол­нить каж­дый блок.
  • Уве­ли­чи­ва­ет­ся ско­рость напи­са­ния. На стар­те мож­но быст­ро создать нуж­ные ком­по­нен­ты внут­ри про­грам­мы, что­бы полу­чить мини­маль­но рабо­та­ю­щий про­то­тип.

А теперь про мину­сы:

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

Что дальше

Впе­ре­ди нас ждёт раз­го­вор о клас­сах, объ­ек­тах и всём осталь­ном важ­ном в ООП. Кре­пи­тесь, будет инте­рес­но!

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

Методология процедурно-ориентированного программирования

Появление первых электронных вычислительных машин, или компьютеров, ознаменовало новый этап в развитии техники вычислений. Казалось, достаточно разработать последовательность элементарных действий, каждое из которых можно преобразовать в понятные компьютеру инструкции, и любая вычислительная задача будет решена. Эта идея оказалась настолько жизнеспособной, что долгое время доминировала над всем процессом разработки программ. Появились специализированные языки программирования, созданные для разработки программ, предназначенных для решения вычислительных задач. Примерами таких языков могут служить FOCAL (FOrmula CALculator) и FORTRAN (FORmula TRANslator).

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

Читать еще:  Методология структурного программирования

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

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

Назначение данной процедуры — вывести на экран приветствие Hello, Name , где Name передается в процедуру в качестве входного параметра.

Со временем вычислительные задачи становились все сложнее, а значит, и решающие их программы увеличивались в размерах. Их разработка превратилась в серьезную проблему. Когда программа становится все больше, ее приходится разделять на все более мелкие фрагменты. Основой для такого разбиения как раз и стала процедурная декомпозиция , при которой отдельные части программы, или модули, представляли собой совокупность процедур для решения одной или нескольких задач. Одна из основных особенностей процедурного программирования заключается в том, что оно позволило создавать библиотеки подпрограмм (процедур), которые можно было бы использовать повторно в различных проектах или в рамках одного проекта. При процедурном подходе для визуального представления алгоритма выполнения программы применяется так называемая блок-схема . Соответствующая система графических обозначений была зафиксирована в ГОСТ 19.701-90. Пример блок-схемы изображен на рисунке (рис. 2.1).

Появление и интенсивное использование условных операторов и оператора безусловного перехода стало предметом острых дискуссий среди специалистов по программированию. Дело в том, что бесконтрольное применение в программе оператора безусловного перехода goto может заметно осложнить понимание кода. Такие запутанные программы сравнивали с порцией спагетти ( bowl of spaghetti), имея в виду многочисленные переходы от одного фрагмента программы к другому, или, что еще хуже, возврат от конечных операторов программы к начальным. Ситуация казалась настолько драматичной, что многие предлагали исключить оператор goto из языков программирования. Именно с этого времени отсутствие безусловных переходов стали считать хорошим стилем программирования.

Дальнейшее увеличение программных систем способствовало формированию новой точки зрения на процесс разработки программ и написания программных кодов, которая получила название методологии структурного программирования. Ее основой является процедурная декомпозиция предметной области решаемой задачи и организация отдельных модулей в виде совокупности процедур. В рамках этой методологии получило развитие нисходящее проектирование программ, или проектирование «сверху вниз». Пик популярности идей структурного программирования приходится на конец 70-х — начало 80-х годов.

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

Методология объектно-ориентированного программирования

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

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

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

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

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

Модель содержит не все признаки и свойства представляемого ею предмета или понятия, а только те, которые существенны для разрабатываемой программной системы. Таким образом, модель «беднее», а следовательно, проще представляемого ею предмета или понятия.

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

Объектно-ориентированный подход обладает такими преимуществами, как:

  • уменьшение сложности программного обеспечения;
  • повышение надежности программного обеспечения;
  • обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;
  • обеспечение возможности повторного использования отдельных компонентов программного обеспечения.

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

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

Методология объектно-ориентированного программирования

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

Объектно-ориентированное программирование (ООП, Object-Oriented Programming) — совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов.

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

Основные принципы ООП: абстракция, наследование, инкапсуляция и полиморфизм.

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

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

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

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

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

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

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

Читать еще:  Для чего предназначены системы программирования

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

Рис. 1.1. Иерархия вложенности классов для примера общего класса «Компьютер»

Подобное изображение обладает серьезным недостатком. Из представленного рисунка не ясно, изображена ли на нем иерархия понятий или декомпозиция класса «Компьютер» на его составные части. Как будет показано далее, использование нотации UML позволяет устранить данную неопределенность посредством введения в рассмотрение двух различных отношений: обобщения и агрегации (Лекция 6).

Следующий принцип ООП — инкапсуляция. Инкапсуляция характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей.

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

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

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

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

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

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

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

Объектно-ориентированное программирование: на пальцах

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

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

Обычное программирование (процедурное)

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

Напри­мер, в интернет-магазине может быть функ­ция «Про­ве­рить email». Она полу­ча­ет на вход какой-то текст, сопо­став­ля­ет со сво­и­ми пра­ви­ла­ми и выда­ёт ответ: это пра­виль­ный элек­трон­ный адрес или нет. Если пра­виль­ный, то true, если нет — то false.

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

Что не так с процедурным программированием

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

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

Тут при­хо­дит продакт-менеджер и гово­рит: «Хочу, что­бы поль­зо­ва­тель точ­но знал, в чём ошиб­ка при вво­де элек­трон­но­го адре­са». Теперь вам нуж­но научить функ­цию выда­вать не про­сто true — false, а ещё и код ошиб­ки: напри­мер, если в адре­се опе­чат­ка, то код 01, если адрес спа­мер­ский — код 02 и так далее. Это неслож­но реа­ли­зо­вать.

Вы зале­за­е­те внутрь этой функ­ции и меня­е­те её пове­де­ние: теперь она вме­сто true — false выда­ёт код ошиб­ки, а если ошиб­ки нет — пишет «ОК».

И тут ваш код лома­ет­ся: все десять мест, кото­рые ожи­да­ли от про­ве­ряль­щи­ка true или false, теперь полу­ча­ют «ОК» и из-за это­го лома­ют­ся.

Теперь вам нуж­но:

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

Зада­ча, конеч­но, реша­е­мая за час-другой.

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

Это назы­ва­ет­ся спагетти-код, и для борь­бы с ним как раз при­ду­ма­ли объектно-ориентированное про­грам­ми­ро­ва­ние.

Объектно-ориентированное программирование

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

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

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

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

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

Инкап­су­ля­ция — объ­ект неза­ви­сим: каж­дый объ­ект устро­ен так, что нуж­ные для него дан­ные живут внут­ри это­го объ­ек­та, а не где-то сна­ру­жи в про­грам­ме. Напри­мер, если у меня есть объ­ект «Поль­зо­ва­тель», то у меня в нём будут все дан­ные о поль­зо­ва­те­ле: и имя, и адрес, и всё осталь­ное. И в нём же будут мето­ды «Про­ве­рить адрес» или «Под­пи­сать на рас­сыл­ку».

Абстрак­ция — у объ­ек­та есть «интер­фейс»: у объ­ек­та есть мето­ды и свой­ства, к кото­рым мы можем обра­тить­ся извне это­го объ­ек­та. Так же, как мы можем нажать кноп­ку на блен­де­ре. У блен­де­ра есть мно­го все­го внут­ри, что застав­ля­ет его рабо­тать, но на глав­ной пане­ли есть толь­ко кноп­ка. Вот эта кноп­ка и есть абстракт­ный интер­фейс.

Читать еще:  Условия безопасности жизнедеятельности в постиндустриальную эпоху

В про­грам­ме мы можем ска­зать: «Уда­лить поль­зо­ва­те­ля». На язы­ке ООП это будет «пользователь.удалить()» — то есть мы обра­ща­ем­ся к объ­ек­ту «поль­зо­ва­тель» и вызы­ва­ем метод «уда­лить». Кайф в том, что нам не так важ­но, как имен­но будет про­ис­хо­дить уда­ле­ние: ООП поз­во­ля­ет нам не думать об этом в момент обра­ще­ния.

Напри­мер, над мага­зи­ном рабо­та­ют два про­грам­ми­ста: один пишет модуль зака­за, а вто­рой — модуль достав­ки. У пер­во­го в объ­ек­те «заказ» есть метод «отме­нить». И вот вто­ро­му нуж­но из-за достав­ки отме­нить заказ. И он спо­кой­но пишет: «заказ.отменить()». Ему неваж­но, как дру­гой про­грам­мист будет реа­ли­зо­вы­вать отме­ну: какие он отпра­вит пись­ма, что запи­шет в базу дан­ных, какие выве­дет пре­ду­пре­жде­ния.

Насле­до­ва­ние — спо­соб­ность к копи­ро­ва­нию. ООП поз­во­ля­ет созда­вать мно­го объ­ек­тов по обра­зу и подо­бию дру­го­го объ­ек­та. Это поз­во­ля­ет не копи­па­стить код по две­сти раз, а один раз нор­маль­но напи­сать и потом мно­го раз исполь­зо­вать.

Напри­мер, у вас может быть некий иде­аль­ный объ­ект «Поль­зо­ва­тель»: в нём вы про­пи­сы­ва­е­те всё, что может про­ис­хо­дить с поль­зо­ва­те­лем. У вас могут быть свой­ства: имя, воз­раст, адрес, номер кар­ты. И могут быть мето­ды «Дать скид­ку», «Про­ве­рить заказ», «Най­ти зака­зы», «Позво­нить».

На осно­ве это­го иде­аль­но­го поль­зо­ва­те­ля вы може­те создать реаль­но­го «Поку­па­те­ля Ива­на». У него при созда­нии будут все свой­ства и мето­ды, кото­рые вы зада­ли у иде­аль­но­го поку­па­те­ля, плюс могут быть какие-то свои, если захо­ти­те.

Иде­аль­ные объ­ек­ты про­грам­ми­сты назы­ва­ют клас­са­ми.

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

При этом внут­ри объ­ек­та мето­ды могут быть реа­ли­зо­ва­ны по-разному. Напри­мер, уда­лить товар — это выдать пре­ду­пре­жде­ние, а потом поме­тить товар в базе дан­ных как уда­лён­ный. А уда­лить поль­зо­ва­те­ля — это отме­нить его покуп­ки, отпи­сать от рас­сыл­ки и заар­хи­ви­ро­вать исто­рию его поку­пок. Собы­тия раз­ные, но для про­грам­ми­ста это неваж­но. У него про­сто есть метод «Уда­лить()», и он ему дове­ря­ет.

Такой под­ход поз­во­ля­ет про­грам­ми­ро­вать каж­дый модуль неза­ви­си­мо от осталь­ных. Глав­ное — зара­нее про­ду­мать, как моду­ли будут общать­ся друг с дру­гом и по каким пра­ви­лам. При таком под­хо­де вы може­те улуч­шить рабо­ту одно­го моду­ля, не затра­ги­вая осталь­ные — для всей про­грам­мы неваж­но, что внут­ри каж­до­го бло­ка, если пра­ви­ла рабо­ты с ним оста­лись преж­ни­ми.

Плюсы и минусы ООП

У объектно-ориентированного про­грам­ми­ро­ва­ния мно­го плю­сов, и имен­но поэто­му этот под­ход исполь­зу­ет боль­шин­ство совре­мен­ных про­грам­ми­стов.

  1. Визу­аль­но код ста­но­вит­ся про­ще, и его лег­че читать. Когда всё раз­би­то на объ­ек­ты и у них есть понят­ный набор пра­вил, мож­но сра­зу понять, за что отве­ча­ет каж­дый объ­ект и из чего он состо­ит.
  2. Мень­ше оди­на­ко­во­го кода. Если в обыч­ном про­грам­ми­ро­ва­нии одна функ­ция счи­та­ет повто­ря­ю­щи­е­ся сим­во­лы в одно­мер­ном мас­си­ве, а дру­гая — в дву­мер­ном, то у них боль­шая часть кода будет оди­на­ко­вой. В ООП это реша­ет­ся насле­до­ва­ни­ем.
  3. Слож­ные про­грам­мы пишут­ся про­ще. Каж­дую боль­шую про­грам­му мож­но раз­ло­жить на несколь­ко бло­ков, сде­лать им мини­маль­ное напол­не­ние, а потом раз за разом подроб­но напол­нить каж­дый блок.
  4. Уве­ли­чи­ва­ет­ся ско­рость напи­са­ния. На стар­те мож­но быст­ро создать нуж­ные ком­по­нен­ты внут­ри про­грам­мы, что­бы полу­чить мини­маль­но рабо­та­ю­щий про­то­тип.

А теперь про мину­сы:

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

Что дальше

Впе­ре­ди нас ждёт раз­го­вор о клас­сах, объ­ек­тах и всём осталь­ном важ­ном в ООП. Кре­пи­тесь, будет инте­рес­но!

лабы по информатике, егэ

лабораторные работы и задачи по программированию и информатике, егэ по информатике

Объектно-ориентированное программирование (как расшифровывается ООП) – это, прежде всего, парадигма программирования.
Парадигма программирования определяет то, как программист видит выполнение программы.
Так, для парадигмы ООП характерно, что программист рассматривает программу в виде набора взаимодействующих объектов, в то время как, например, в функциональном программировании программа представляется в виде последовательности вычисления функций. Процедурное программирование или, как его еще правильно называют, классическое операциональное, подразумевает написание алгоритма для решения задачи; при этом ожидаемые свойства конечного результата не описываются и не указываются. Структурное программирование в основном придерживается тех же принципов, что и процедурное, лишь немного дополняя их полезными приемами.
Парадигмы непроцедурного программирования, к которым можно отнести объектно-ориентированную парадигму, имеют совершенно другие идеи.
Определение Гради Буча гласит: “Объектно-ориентированное программирование – это методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса (типа особого вида), а классы образуют иерархию на принципах наследуемости”.
Структурное и объектно-ориентированное программирование строятся на таком научном методе как декомпозиция — метод, который использует структуру задачи и позволяет разбить решение общей большой задачи на решение последовательности меньших задач. Декомпозиция ООП происходит не по алгоритмам, а по объектам, использующимся при решении задачи. Данная декомпозиция уменьшает размер программных систем благодаря повторному использованию общих механизмов. Известно, что системы визуального программирования или системы, построенные на принципах объектно-ориентированного программирования, являются более гибкими и легче эволюционируют со временем.

История развития ООП берет свое начало в конце 60-х годов. Первым объектно-ориентированным языком был язык программирования Simula, созданный в компьютерном центре в Норвегии. Язык предназначался для моделирования ситуаций реального мира. Особенностью Simula было то, что программа, написанная на языке, была организована по объектам программирования. Объекты имели инструкции, называемые методами, и данные, которые назывались переменными; методы и данные определяли поведение объекта. В процессе моделирования объект вел себя согласно своему стандартному поведению и, в случае необходимости, изменял данные для отражения влияния назначенного ему действия.

Сегодня существует достаточное количество объектно-ориентированных языков программирования, наиболее популярными из которых в настоящее время являются C++, Delphi, Java, Visual Basic, Flash. Но, кроме того, многие языки, которые принято причислять к процедурной парадигме, тоже обладают свойствами ООП, имея возможность работать с объектами. Так, объектно-ориентированное программирование в C — это большой раздел программирования на данном языке, то же самое касается ООП в python и многих других структурных языках.

Говоря об ООП, часто всплывает еще одно определение — визуальное программирование. Оно дополнительно предоставляет широкие возможности использования прототипов объектов, которые определяются как классы объектов.
События. Во многих средах визуального программирования реализована характеристика (помимо инкапсуляции, полиморфизма и наследования) объекта – событие. Событиями в объектно-ориентированном программировании называется возможность обработки так называемых сообщений (или событий), получаемых от операционной системы Windows или самой программы. Данный принцип характерен для всех компонентов среды, которые обрабатывают различные события, возникающие в процессе выполнения программы. По сути, событие — это некоторое действие, которое активизирует стандартную реакцию объекта. Событием может рассматриваться, например, щелчок по кнопке мыши, наведение курсора мыши на пункт меню, открытие вкладки и т.п. Очередность выполнения тех или иных действий определяется как раз таки событиями, возникающими в системе, и реакцией на них объектов.
Классы и объекты в ООП — различные понятия. Понятие класса в ООП – это тип данных (такой же как, например, Real или String), а объект – конкретный экземпляр класса (его копия), хранящийся в памяти компьютера как переменная соответствующего типа.
Класс является структурным типом данных. Класс включает описание полей данных, а также процедур и функций, которые работают с этими полями данных. Метод ООП – это и есть такие процедуры и функции применительно к классам.
Классы имеют поля (как тип данных запись — record), свойства, которые похожи на поля, но имеют дополнительные описатели, определяющие механизмы записи и считывания данных и методы — подпрограммы, которые направленны на изменение полей и свойств класса.

Основные принципы ООП

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

Принцип наследования ООП и подклассы

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

Полиморфизм ООП

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

На сайте представлена частичная теория объектно-ориентированного программирования для начинающих и ООП примеры решения задач. ООП уроки сайта представляют собой подробные алгоритмы выполнения поставленной задачи. На основе выполнения данных лабораторных работ учащийся сможет в дальнейшем самостоятельно решать другие аналогичные задачи.
Желаем Вам легкого и интересного изучения объектно-ориентированного программирования!

Ссылка на основную публикацию
Adblock
detector